Programateando #1. Mi tutorial básico para programar embebidos en C

[Ardogan]

Buenas tardes.
Después de un tiempo de probar distintas herramientas de grabación de escritorio, video, pelearme con micrófonos, cámara, etc; estoy haciendo mi primer intento de video-tutorial de programación de micros.

Va a ser una serie de videos que se llama Programateando (programación + mate, a la Argentina). Empieza con la implementación de una interfaz de comandos por puerto serie, hice alguna consulta en el foro hace algunas semanas sobre eso:
Interfaz de comandos: switch-case vs punteros[] a función
Sobre la marcha voy hablando sobre la marcha: algunos conceptos de C, IDEs, como se utilizan las herramientas, forma de trabajo, etc.

NO ES para gente que arranca desde cero, sino para alguien que ya se marchitó la cabeza haciendo algún programa sencillo, que lidió con que no le ande el programador, la placa, que el micro no ejecute código, etc.
Requerimientos para verlo diría que es saber lenguaje C (nivel básico al menos), y alguna herida de batalla tratando de hacer funcionar el programa en físico.
Estoy usando un msp430 launchpad con el msp430g2553, pero lo que estoy haciendo (salvando la programación de registros específicos del micro) debería ser aplicable a cualquier micro en general, no me centro tanto en el micro como en el proceso de desarrollo.

Estuve el Domingo grabando clips y de ahí en adelante a editar durante la semana. Por eso me parece que el formato más conveniente es separar los videos por semana (Programateando #1 va a ser la 1ra semana, #2 la 2da, etc) así divido los temas temporalmente y se los puede discutir por separado.

• Lista Programateando #1 (todos los videos de abajo en orden): https://www.youtube.com/playlist?list=PLGL5AjNW8FqrC4nG78msLqIiTcxzeSBIO

1. Programateando #1. Presentación del proyecto CLI. Visión rápida de las herramientas utilizadas.
   
2. Programateando #1 - Verificando herramientas de desarrollo, led blink. Hacemos una verificación rápida y somera de las herramientas de desarrollo, con el nunca bien ponderado proyecto de hacer parpadear un led.
3. Programateando #1 - Planificando el proyecto. Hacemos una planificación muy básica y mínima del proyecto. El objetivo es obtener la primera tarea a desarrollar con un objetivo muy claro.
4. Programateando #1 - Eco por uart. Escribimos código muy básico para recibir/enviar un caracter por el puerto uart usando un ejemplo de código provisto por el fabricante.
5. Programateando #1 - Refactorizando. Luego de tener código que funciona, lo corregimos y estructuramos para que sea más legible y fácil de mantener.
6. Programateando #1 - Interrupciones, plantUML. ¿Por qué precisamos utilizar interrupciones para recibir texto por uart?. ¿Cómo cambia el flujo de programa?. Una presentación rápida de PlantUML. Actualizamos lista de tareas.
7. Programateando #1 - Implementando fifo (básica). Programamos una fifo para recibir los caracteres uart.Inicializamos estructura con macros. Convención de código John Carmack.
8. Programateando #1 - Fifo test, introduciendo código de test. Un primer test de la fifo. Escribimos código de test que se ejecuta dentro de la aplicación para determinar si cometimos algún error. Mini-crítica de IDEs (Eclipse, Arduino IDE, Code Blocks).

Escucho críticas, sugerencias, insultos y cualquier otro feedback que crean oportuno para mejorar ésto que, seguramente, tendrá errores varios e irá mejorando a medida que tenga más práctica.
Saludos!!!.

 

[Ardogan]

Otro recién salido del horno, en este perdí un poco el orden de los temas y divagué más de la cuenta. En vista de eso en la descripción puse las marcas temporales de cada cosa

Todavía me faltan editar 2 más para dar por terminado el Programateando #1. Pero sarna con gusto no pica :estudiando:.



//PD
Una aclaración que aprovecho para escribirla sin que haya que ver una hora de video para darse cuenta:
NO ES para gente que arranca desde cero, sino para alguien que ya se marchitó la cabeza haciendo algún programa sencillo, que lidió con que no le ande el programador, la placa, que el micro no ejecute código, etc.
Requerimientos para verlo diría que es saber lenguaje C (nivel básico al menos), y alguna herida de batalla tratando de hacer funcionar el programa en físico.

 

[Ardogan]

Quema... quema mucho!!!!

Mmmmm, da para charlar la fifo. ¿Qué tipos de datos usar? (1 solo tipo de dato, puntero a void?), ¿punteros o indices?, ¿como llevar la cuenta?. Todas cosas que omito haciéndome el tonto, porque sino no avanzamos más .

 

[Ardogan]

Otro más... y no termino más

IDE Arduino.... prrrffffff

 

[cosmefulanito04]

Recién llegué al de interrupciones. Me gusta, muy bien explicado, tranquilo y en el momento.

No conocía esa herramienta PlantUML, la veo muy interesante para entender los procesos de ejecución de múltiples Threads (más allá del diagrama en bloques de un solo hilo), porque muchas veces al volverse complejo el programa, tal vez se pierde la secuencia de comunicación de los múltiples hilos.

Otra cosa que me gustó y voy a darle una chance, es el eclipse, yo suelo usar el code::blocks, pero veo que el eclipse es bastante más completo.

Una última cosa, en el video anterior de interrupción, cuando llevaste todos los registros a distintas funciones para que sea más entendible para una persona, noté que cambió mucho el tamaño de transferencia entre los 3 códigos:

1- Código con todos el setup en el main.
2- Código con los setup separados.
3- Código con las funciones de uart en un archivo separado.

 

[Ardogan]

Recién llegué al de interrupciones. Me gusta, muy bien explicado, tranquilo y en el momento.

Muchas gracias!!!, viniendo de vos vale doble.
A veces puedo hablar muy tranquilo, lo que pasa es que la cpu (mía, mi cabeza) está al 100% mientras voy pensando en que instrucción escribir, más lo que quiero decir, más como va la secuencia de explicación en el video, etc. No me queda mucha ram para tratar de hacerlo más llevadero con algún chiste, jeje.

Seguramente a más de uno le hice dormir la siesta .
Pensé en poner algo de música de fondo... quizás distraiga mucho?, no sé, habría que probarlo.

No conocía esa herramienta PlantUML, la veo muy interesante para entender los procesos de ejecución de múltiples Threads (más allá del diagrama en bloques de un solo hilo), porque muchas veces al volverse complejo el programa, tal vez se pierde la secuencia de comunicación de los múltiples hilos.

Claro, ese diagrama en particular sirve para arquitectura multi-hilo, cliente-servidor, etc. Y sí, un dibujito sirve, aunque no sea más que texto encuadrado con flechas (algún día ojalá introduzcan la posibilidad de animar los diagramas).

Otra cosa que me gustó y voy a darle una chance, es el eclipse, yo suelo usar el code::blocks, pero veo que el eclipse es bastante más completo.

Sí, tiene sus desventajas, en el video de fifo test menciono algo .

Una última cosa, en el video anterior de interrupción, cuando llevaste todos los registros a distintas funciones para que sea más entendible para una persona, noté que cambió mucho el tamaño de transferencia entre los 3 códigos:

1- Código con todos el setup en el main.
2- Código con los setup separados.
3- Código con las funciones de uart en un archivo separado.

No entiendo bien cual es la cuestión, a que te referís con tamaño de transferencia?, ¿el tipo de datos de las funciones enviar y recibir por uart?.
Si metí la pata introduzco un cuadrito de texto aclarando, pero no entiendo bien la cuestión.

Muchas gracias!!!!

 

[cosmefulanito04]

Cuando mandás el binario al micro, la respuesta que te dá la consola es cuantos bytes se envió, como ese valor fue distinto en los 3 casos que planteaste, daría la impresión que el binario del segundo resultó en más código de máquina.

 

[Ardogan]

Aaaaahhh, que atención al detalle. A ver... sí, ahí esta:

• El programa que estaba funcionando antes de 18:15 en el video refactorizando se ve que ocupa 200 bytes
• Luego de programar la versión sacando manejo de registros en funciones separadas ocupa 312 bytes (112 bytes de más, >50%)

Seguramente el compilador no está optimizando las funciones hoja (leaf), esto es, las funciones que no llaman a otra función. Un compilador más inteligente al ver que la función se llama 1 sola vez desde 1 solo lugar, directamente incrusta en el lugar de llamada el código de la función, como si fuera un cortar-pegar.
Se ve que este compilador (mspgcc) no está haciendo eso, y el código extra se debe a los prólogos y epílogos de cada llamada a función (se salva y recupera contexto de ejecución: registros, stack pointer...).
Quizás si hubiera compilado para optimizar tamaño con -Os habría tenido un tamaño de código similar.


Ahí agrego la aclaración, una muy buena observación, gracias .

 

[cosmefulanito04]

A eso iba.

De todas formas, más me llamó la atención entre el 2do ejemplo (con las funciones para c/periférico) y el 3ero cuando separaste las funciones de la uart en otro archivo (24:49 del video), en ese ejemplo el código prácticamente es el mismo y sin embargo el peso resultante es de 284 bytes vs 312 bytes del anterior.

Eso particularmente no me lo esperaba, es raro lo que hizo el compilador ahí.

 

[Ardogan]

A eso iba.

De todas formas, más me llamó la atención entre el 2do ejemplo (con las funciones para c/periférico) y el 3ero cuando separaste las funciones de la uart en otro archivo (24:49 del video), en ese ejemplo el código prácticamente es el mismo y sin embargo el peso resultante es de 284 bytes vs 312 bytes del anterior.

Eso particularmente no me lo esperaba, es raro lo que hizo el compilador ahí.

Interesante... quizás el linker optimiza mejor habiendo archivos por separado?, no sé, estoy especulando en vacío...
La pucha, voy a tener que agregar eso a la lista de temas a revisar .