Workshop SASE 2022: Desarrollo de sistemas embebidos en framework multiplataforma

[royconejo]

Estimados:

Mi nombre es Santiago Germino y el día Viernes 19 estaré dictando el workshop de referencia en SASE 2022. Abro este hilo aquí para aclarar un poco el temario, alcance y objetivos.

La idea principal es desarrollar los siguientes temas:

1) Como utilizar Visual Studio Code (en versión libre VSCodium) para desarrollar sistemas embebidos.

2) Arquitecturas para la abstracción de detalles de implementación dependiente del hardware. Vamos a revisar las capas de abstracción típicas del paquete de firmware de un vendor y como eso difiere de la arquitectura de un sistema que asegura total independencia del hardware.

3) Ventajas en desarrollar una aplicación en ese tipo de sistemas. ¿Cómo facilita la validación y testing?

4) Programación orientada a objetos en C. ¿Por qué no usar C++?
5) Uso del Stack y Heap en sistemas embebidos. ¿Por qué no es deseable usar el Heap?

Vamos a abordar estos temas introduciéndonos en las decisiones de diseño de un framework llamado embedul.ar y programando una aplicación simple. Aclaro que la razón por la cual aún no hay información disponible sobre este framework es que es una novedad. La presentación formal se hará durante el mismo SASE 2022.

Espero que la propuesta les interese. Estaré atento a cualquier consulta o inquietud. En particular, debido a que el workshop requiere una PC con software pre-instalado y configurado.

Más información e inscripción en http://www.sase.com.ar/2022/programa-del-sase/ (cupos limitados).

Saludos!
Santiago.

[Mirko Serra]

4) Programación orientada a objetos en C. ¿Por qué no usar C++?

- Porque tengo miedo al cambio.

- Porque no quiero aprender cosas nuevas.

- Porque no lo entiendo.

- Porque me dijeron que es más lento. No tengo pruebas pero tampoco dudas.

- Porque quiero que mi código sea más críptico así cuando falla me llaman a mí.

- Porque cuando en tu caja de herramientas solo tenés un martillo terminás martillando los tornillos.

Saludos,

Mirko Serra.

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/embebidos32/c5d1c0ac-01f2-4aae-bb59-bda168d41059n%40googlegroups.com.

[royconejo]

Hola Mirko, todo eso te pasó? Contanos un poco más del contexto!

En realidad no es un tema de ser valiente ni pasa por lo individual, sino por la visión de management de proyectos medianos o grandes en sistemas con importantes restricciones de memoria o almacenamiento.

El primer punto, en el que caen los recién llegados según mi experiencia, es creer que C++ es la evolución de C. No es. Son lenguajes distintos con una sintaxis a veces compatible.

Por ejemplo, embedul.ar hace un uso extendido de C11, por ejemplo _Generic. Eso no existe en el estándar de C++.

Gracias a eso, en el framework se puede hacer lo siguiente:

LOG ("entero: `X1 `x1 -- string: `U0 `c0", "hola", 94);

eso imprime: "entero: 5E 5e -- string: HOLA Hola".

Los tipos y la cantidad de parámetros son automáticos. A ver si notan otras particularidades.

El segundo, los errores. En C, generalmente son una linea que apunta inequívocamente al problema. En C++, por ejemplo, al usar contenedores de la librería estándar, un solo error genera una decena de lineas.

Eso produce que depurar código en C++ sea mas difícil para alguien no experto en C++. Por ejemplo, para alguien que entiende que C++ es C con clases.

En general, se usa C++ con el paradigma de programación orientada a objetos. Pero esa es una decisión de arquitectura de software, no de lenguaje. También se puede usar C.

Por último (así no la hago larga acá y vienen al workshop jaja) los smart pointers de C++ están diseñados para resolver problemas relacionados con el heap. No heap, no hay problema.

Dejo una pregunta por acá: como se usa el operador new sin heap? y por extensión: como se usa la librería estándar de C++ sin heap?

Para implementar diseños complejos (o para resolver las "metidas de pata" que hicieron los programadores en C que creen saber C++) es necesario contratar gente experta en C++.
Hoy en el mercado eso no abunda. Y si hay, como todo lo que no abunda, cuesta bastante más caro. Ya gente que sepa bien C no abunda...

Si hacemos un cuadro con las ventajas y desventajas, desde el punto de vista del project owner de algo de sistemas embebidos, C gana. Ese sería un poco el resumen.

Obvio no tienen que coincidir conmigo. Yo simplemente voy a explicar en que se basan las decisiones tomadas para implementar el framework que veremos.

La idea de un workshop también es debatir y aprender de las experiencias de todos. E irse con la sensación de que esa experiencia nos enriqueció.

Saludos!
Santiago.

[Mirko Serra]

Hola Mirko, todo eso te pasó? Contanos un poco más del contexto!

Todo eso es lo que he visto como puntos para usar C en vez de C++. Agrego a la lista "no hay suficientes programadores C++" (es un punto válido).

El segundo, los errores. En C, generalmente son una linea que apunta inequívocamente al problema. En C++, por ejemplo, al usar contenedores de la librería estándar, un solo error genera una decena de lineas.

Si la persona no está diseñando y manteniendo sus propios contenedores en C (lo cual va a ser más motivo de falla) estamos comparando distintas complejidades.

Además, en C++ hay menos errores (menos líneas de código para la misma funcionalidad, menos copy&paste, más checking, etc.); y los errores se agarran mucho más en tiempo de compilación. Esto es crítico en un embebido en el que puede ser lento o difícil de hacer debugging. Los errores más costosos son los de runtime, no los de compile time.

Sí, el error puede ser verbose, pero ese es el factor miedo que yo citaba (asumir que le van a tener miedo a un mensaje de error detallado).

Eso produce que depurar código en C++ sea mas difícil para alguien no experto en C++. Por ejemplo, para alguien que entiende que C++ es C con clases.

Esto es complicado para el que usa contenedores sin conocerlos. Igual que sería complicado debuggear C para alguien que solo sabe BASIC. El punto es dejar de asustar a la gente con el cuco de C++ para que lo aprendan, no hacer malabares para evitar aprenderlo.

Y se lo puede usar como C con clases (es válido, no existe la cpp police)... y eso sería no usar contenedores (y sería sin mensajes de error kilométricos). El simple hecho de meter funciones dentro de las struct hace el código más legible (sobretodo en proyectos grandes).

La comparación honesta es entre un código C y su equivalente C++; no con un código C++ que tiene más funcionalidades.

 

En general, se usa C++ con el paradigma de programación orientada a objetos. Pero esa es una decisión de arquitectura de software, no de lenguaje. También se puede usar C.

No critico hacer OOP en C. Pero no es lo mismo decir "cómo usar el destornillador para martillar" que "cómo usar el destornillador para martillar, por qué no usar un martillo".

Por último (así no la hago larga acá y vienen al workshop jaja) los smart pointers de C++ están diseñados para resolver problemas relacionados con el heap. No heap, no hay problema.

Manejo de memoria (no solo el heap) es la mitad de la historia. La otra mitad es asegurarse de que se llame al destructor. Usar RAII evita anti patrones horrendos como el de un solo return y hace el código más corto y no hay más olvidos (de free(), de cerrar un archivo, de decrementar un contador de recurso, de cerrar un socket, de un bit de stop).

Dejo una pregunta por acá: como se usa el operador new sin heap?

Igual. Se hace override de new (que puede sacar memoria de un pool estático); puede ser general o por clase. Esto está soportado por el lenguaje.

por extensión: como se usa la librería estándar de C++ sin heap?

De la misma manera (override de new), o usando custom allocators. Más allá de la que librería estándar no son solo contenedores (y de que std::array es equivalente al array de C, pero mejor).

Para implementar diseños complejos (o para resolver las "metidas de pata" que hicieron los programadores en C que creen saber C++) es necesario contratar gente experta en C++.

Hoy en el mercado eso no abunda. Y si hay, como todo lo que no abunda, cuesta bastante más caro. Ya gente que sepa bien C no abunda...

De acuerdo, pero justo ese es el punto: tenemos que dejar de repetir que C++ no sirve para embebidos y que es bueno no usarlo... ¡¡¡porque así es como terminás sin programadores de embebidos que sepan C++!!!

Me atrevo a decir que el problema es la gente que sabe bien C: el lenguaje C fomenta el código chapucero.

Si hacemos un cuadro con las ventajas y desventajas, desde el punto de vista del project owner de algo de sistemas embebidos, C gana. Ese sería un poco el resumen.

Mi punto de vista es que es ir a contramano de las buenas prácticas y de la industria a nivel mundial.

Obvio no tienen que coincidir conmigo. Yo simplemente voy a explicar en que se basan las decisiones tomadas para implementar el framework que veremos.

La idea de un workshop también es debatir y aprender de las experiencias de todos. E irse con la sensación de que esa experiencia nos enriqueció.

Un nuevo framework es bienvenido y es positivo (y puede ser un factor decisivo al elegir el lenguaje de un proyecto), solo que no concuerdo con el enfoque recursivo de usar C porque no hay programadores C++ y que no haya programadores C++ porque los proyectos son en C.

Me es imposible atender al SASE y espero que luego publiquen algo del material.

Mucha suerte.

 

[Gonzalo Nahuel Vaca]

Aloha!

Para no hacer forobardo, tiro como recurso el libro de Bjarne Stroustrup "programming principles and practice using c++" y el libro de Fedor G. Pikus "The Art of Writing Efficient Programs: An advanced programmer's guide to efficient hardware utilization and compiler optimizations using C++ examples".

En rigor C++ es un superset de C y en el caso de sistemas embebidos hay un subset que es apto para sistemas embebidos "pequeños", Entiendo que el estándar 22 que salió/debería salir ya introduce memory pool y contenedores que usan ese memory pool.

Para mi la principal ventaja de C++ es que te lleva errores que en C son de tiempo de ejecución a tiempo de compilación.

Saludos!!!

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/embebidos32/daf113f7-2e8e-4d87-8728-30830613f88cn%40googlegroups.com.

[royconejo]

Hola Mirko, agradezco tus puntos de vista.

No es objetivo del workshop evangelizar apasionadamente o hacer una defensa fundamentalista sobre el uso de tal o cual lenguaje, sino simplemente dar las razones objetivas que justifican la elección en este caso concreto.

Me pareció interesante tratar este tema enmarcado en la discusión de las decisiones de diseño de embedul.ar.

Cuando se trabaja en proyectos grandes, tampoco es potestad de un individuo elegir con que herramienta pica la piedra. Eso ya está definido de antemano con otros criterios y objetivos mas amplios.

Por ejemplo, el framework apunta a estar centrado en sistemas críticos y en cumplir estándares como MISRA-C o CERT C.

Las versiones en C++ de esos estándares son más recientes y están menos depuradas en el tiempo. También existe algo llamado Verifiable-C.

Esa es una de las razones por las cuales no se usa el heap. Todo uso de memoria se define en tiempo de compilación.

Casualmente, otra parte del workshop tratará sobre como depurar, validar y testear la aplicación desarrollada en el framework de manera local, por fuera del embebido, sin modificaciones.

La portabilidad es otra razón para elegir C. No porque C++ no sea portable, sino porque es mas fácil portar C. Y también exponer cualquier elemento del mundo C a otros lenguajes. La clave es definir que es alto o bajo nivel.

Los lenguajes ayudan a la modularidad, la legibilidad y la mantenibilidad del código, pero no la garantizan per-se. Por todos los paradigmas que soporta y lo potente que es, mal C++ es potencialmente más dañino que mal C.

Las buenas prácticas tampoco son exclusivas de algún lenguaje en particular. Buen C++ implementando un buen diseño de software es algo hermoso de ver, pero en mi experiencia requiere gente experta en ambas áreas. Por eso no se ve seguido jaja.

En cuanto a la industria, por ejemplo podríamos decir que mBed es el abanderado de C++ en sistemas embebidos, pero no usa C++ moderno porque los compiladores de embebidos (IAR, ARMCC) no lo soportan mucho.

E imagino que, cuanto más esotérica se vuelve la sintaxis de C++ con respecto a C, el código se vuelve imposible de leer por gente que viene de C. Algunos se sentirán motivados a aprender, pero en lo inmediato dejaría un montón de gente afuera.

Entonces, en mBed uno se encuentra usando C++ básico para cosas muy básicas, con el impacto en runtime, memoria y almacenamiento que sí existe y aún cuando conscientemente los diseñadores se propusieron mitigar ese impacto no generando vtables.

Sería interesante oír por qué decidieron usar "ese" C++ y no C. Probablemente esos argumentos no pasaron por quitar miedo o por educar futuros recursos humanos.

No sería raro si se dejaron llevar por la moda, algo que no es nada raro en la industria. Por otra parte, mBed OS está mayormente escrito en C... compilado en un compilador de C++.

Si no corto se van a cansar de mí antes del workshop jaja :)

Seguramente se haga una transmisión o una grabación, los mantengo al tanto! En general debo adecuarme a lo que los organizadores del SASE dispongan.

Saludos!
Santiago.

[royconejo]

Hola! Gracias por el aporte! En realidad C y C++ tienen un área de overlap en la sintaxis, pero en rigor son lenguajes distintos. Hay cosas de C11 que no están en C++17, ni siquiera están los designated initializers de C99.

Por otra parte, como decía Mirko, sí, se puede usar new con un memory pool. Pero cual es el caso de uso? Cual sería la ventaja de un memory pool contra el heap para objetos "alocados" dinámicamente?

Si cada pool tiene un fin determinado y no puede liberarse, entonces por qué directamente no asignar un espacio estático máximo a la lista de objetos que contendrá el pool? Que pasa si se acaba la memoria en un sistema embebido?

Saludos!
Santiago.

[Gonzalo Nahuel Vaca]

Dale genial! programá en C hasta el final de tu carrera profesional entonces. Saludos!!!

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/embebidos32/eb34d02c-029e-4cd8-8313-1839a167508cn%40googlegroups.com.

[royconejo]

Gracias Gonzalo! Si bien tengo experiencia en otros lenguajes como C++, la verdad si fuese como decís, sería un privilegio.

Más cuando uno en su carrera profesional se mueve de la mera "programación" a otras esferas del diseño y la planificación y por ende, otra visión y otras responsabilidades.

No creo que nada bajo nivel se mueva de C a mediano plazo, por ende aprender bien C aseguraría un buen nicho de mercado.

Saludos!
Santiago.