programación del microcontrolador vs programación orientada a objetos

Deberá abandonar completamente el paradigma orientado a objetos cuando trate con la mayoría de los microcontroladores.

Los microcontroladores generalmente están limitados por el registro y la memoria RAM, con velocidades de reloj lentas y sin rutas de código de canalización / paralelo. Puedes olvidarte de Java en un PIC, por ejemplo.

Tienes que entrar en una mentalidad de lenguaje ensamblador y escribir de manera procesal.

Tienes que mantener tu código relativamente plano y evitar la recursión, ya que las limitaciones de RAM pueden llevar a problemas de apilamiento.

Debe aprender a escribir rutinas de servicio de interrupción que sean eficientes (generalmente en lenguaje ensamblador).

Es posible que tenga que refactorizar partes del código manualmente, en lenguaje ensamblador, para implementar una funcionalidad que el compilador no admita (o no admita).

Debe escribir código matemático que tenga en cuenta el tamaño de la palabra y la falta de capacidades de FPU de la mayoría de los microcontroladores (es decir, realizar la multiplicación de 32 bits en un micro = mal de 8 bits).

Es un mundo diferente. Para mí, tener una formación en ciencias informáticas o programación profesional puede ser un obstáculo tan grande como no tener ningún conocimiento al tratar con microcontroladores.

Debes pensar en varias cosas:

• Usarás C como el idioma
• Aún puede crear una sensación de orientación de objeto usando punteros de función para poder anular funciones, etc. He usado este método en proyectos pasados y actuales y funciona muy bien. Así que OO está parcialmente ahí pero no en el sentido de C ++.

Existen otras limitaciones para jugar, como la velocidad y la memoria limitadas. Entonces, como una guía general, evito:

• Usando Heap, si hay una manera de resolver el problema sin Malloc, lo hago. Por ejemplo, preasigno buffers y solo los uso.
• Intencionalmente reduzco el tamaño de pila en la configuración del compilador para enfrentar los problemas de tamaño de pila desde el principio, optimizo eso cuidadosamente.
• Supongo que cada línea de código será interrumpida por un evento, por lo que evito el código no reentrante
• Supongo que incluso las interrupciones están anidadas, por lo que escribo ese código en consecuencia
• Evito usar el sistema operativo a menos que sea necesario. El 70% de los proyectos integrados realmente no necesita un sistema operativo. Si debo usar un sistema operativo, solo uso algo con el código fuente disponible. (Freertos etc)
• Si estoy usando un sistema operativo, casi siempre abstraigo las cosas para poder cambiar el sistema operativo en cuestión de horas.
• Para los controladores, etc. Solo usaré las bibliotecas proporcionadas por el proveedor, nunca toco los bits directamente, a menos que no tenga otra opción. Esto hace que el código sea legible y mejora la depuración.
• Miro los bucles y otras cosas, especialmente en ISR, para asegurarme de que sean lo suficientemente rápidos.
• Siempre tengo algunos GPIO a la mano para medir cosas, cambio de contexto, tiempo de ejecución ISR, etc.

La lista continúa, probablemente estoy por debajo del promedio en términos de programación de software, estoy seguro de que hay mejores prácticas.

Yo hago ambas cosas, así que aquí está mi opinión.

Creo que la habilidad más importante, por mucho, en la incrustada es tu capacidad de depuración. La mentalidad requerida es muy diferente, ya que mucho más puede salir mal, y debes estar muy abierto a considerar todas las formas en que lo que estás tratando de hacer puede salir mal.

Este es el mayor problema para los nuevos desarrolladores integrados. Las personas de PC tienden a tenerlo más duro, ya que están acostumbrados a trabajar solo para ellos. Tendrán a perder mucho tiempo buscando herramientas para hacer cosas por ellos (pista: no hay muchas). Hay muchas cabezas de golpes en las paredes una y otra vez, sin saber qué más hacer. Si siente que se está atascando, dé un paso atrás y averigüe si puede identificar qué podría estar yendo mal. Rastrear sistemáticamente tu lista de problemas potenciales hasta que lo descubras. De este proceso se deduce directamente que debe limitar el alcance de los problemas al no cambiar demasiado de una vez.

Las personas integradas con experiencia tienden a dar por sentado la depuración ... la mayoría de las personas que no pueden hacerlo bien no duran mucho tiempo (o trabajan en grandes compañías que simplemente aceptan que "el firmware es difícil" como respuesta al por qué) una cierta característica lleva años de retraso)

Está trabajando en un código que se ejecuta en un sistema externo para su sistema de desarrollo, con diversos grados de visibilidad en su objetivo de una plataforma a otra. Si está bajo su control, presione para obtener ayudas de desarrollo que ayuden a aumentar esta visibilidad en su sistema objetivo. Utilice los puertos serie de depuración, la salida de depuración de bit banging, la famosa luz parpadeante, etc. Ciertamente, como mínimo, aprenda cómo usar un osciloscopio y use la E / S de pin con el 'alcance' para ver cuándo ciertas funciones entran / salen, disparan los ISR, etc. He visto a la gente luchar literalmente durante más años de lo necesario simplemente porque nunca se molestaron en configurar / aprender a usar un enlace de depuración JTAG adecuado.

Es mucho más importante estar muy al tanto de los recursos que tiene con respecto a una PC. Lea las hojas de datos con cuidado. Considere el 'costo' del recurso de cualquier cosa que esté tratando de hacer. Aprenda trucos de depuración orientados a los recursos, como llenar el espacio de la pila con un valor mágico para rastrear el uso de la pila.

Si bien se requiere cierto grado de habilidad de depuración tanto para la PC como para el software integrado, es mucho más importante con la incrustación.

Supongo que su experiencia con C ++ está basada en PC.

Un error que cometen frecuentemente los programadores al pasar de la PC al microcontrolador es que no se dan cuenta de cómo pueden ser los recursos limitados . En una PC, nadie lo detendrá cuando cree una tabla con 100 000 entradas o escriba un programa que se compile en 1 MB de código de máquina.
Hay microcontroladores que tienen una gran cantidad de recursos de memoria, especialmente en el extremo alto, pero aún está muy lejos de lo que estará acostumbrado. Para un proyecto de pasatiempo, es probable que siempre pueda ir al máximo, pero en un proyecto profesional a menudo se verá obligado a trabajar con el dispositivo más pequeño porque es más barato .
En un proyecto, estaba trabajando con una MSP430F1101 de TI. 1KB de memoria de programa, 128 bytes de configuración Flash, 128 bytes de RAM. El programa no encajaba en el 1K, así que tuve que escribir una función de 23 bytes en la configuración de Flash. Con estos pequeños controladores, calcula por byte . En otra ocasión la memoria del programa era 4 bytes demasiado pequeña. Boss no me permitió usar el controlador con más memoria, pero en su lugar tuve que optimizar un código de máquina ya optimizado (ya estaba escrito en el ensamblador) para que quepan los 4 bytes adicionales. Obtienes la imagen.

Dependiendo de la plataforma en la que estés trabajando, tendrás que lidiar con E / S de muy bajo nivel . Algunos entornos de desarrollo tienen funciones para escribir en una pantalla LCD, pero en otros están por su cuenta, y tendrá que leer la hoja de datos de la pantalla LCD de principio a fin para saber cómo controlarla.
Puede que tenga que controlar un relé, que es más fácil que un LCD, pero requerirá que vaya al nivel de registro del microcontrolador. De nuevo una hoja de datos o manual de usuario. Tendrá que conocer la estructura del microcontrolador, que encontrará en un diagrama de bloques, nuevamente en la hoja de datos. En los días del microprocesador hablamos de un modelo de programación , que era básicamente una alineación de los registros del procesador. Los microcontroladores de hoy son tan complejos que una descripción de todos los registros puede tomar la mejor parte de una hoja de datos de 100 páginas. IIRC solo la descripción del módulo de reloj para el MSP430 fue de 25 páginas.

A menudo tendrás que lidiar con el manejo de eventos en tiempo real . Una interrupción que debe manejar dentro de 10 \ $ \ mu \ $ s, por ejemplo, y durante eso tiene otra interrupción que requiere la misma precisión de tiempo.

Los microcontroladores suelen estar programados en C . C ++ es bastante hambriento de recursos, por lo general eso es todo. (La mayoría de las implementaciones de C ++ para microcontroladores ofrecen un subconjunto limitado de C ++). Como dije, dependiendo de la plataforma, puede tener disponible una extensa biblioteca de funciones que puede ahorrarle bastante tiempo de desarrollo. Vale la pena tomarse un tiempo para estudiarlo, puede ahorrarle mucho tiempo más adelante si sabe qué hay disponible.

"programación de hardware" puede significar muchas cosas. Programar un chip muy pequeño (piense en 10F200, 512 instrucciones, algunos bytes de RAM) puede ser casi como diseñar un circuito electrónico. Por otro lado, la programación de un gran microcontrolador Cortex (1 Mb FLASH, 64 kB RAM) puede ser muy similar a la programación de PC / GUI, utilizando un gran kit de herramientas GUI. En mi humilde opinión, un buen programador integrado / en tiempo real necesita habilidades tanto desde el punto de vista del software como desde el lado del diseño del circuito. Para el uC más grande, C ++ es una buena opción de lenguaje, para los más pequeños C podría ser la única opción. El conocimiento del ensamblaje puede ser útil, pero no recomendaría que se realicen proyectos serios completamente en ensamblaje.

He realizado un trabajo integrado serio con personas de ambos lados (SWI y EE). Generalmente prefiero a las personas de SWI, siempre que tengan alguna experiencia con la programación multihilo.

Su pregunta suena como si desea sumergirse en la programación integrada. Por todos los medios hacerlo. Para los aspectos de bajo nivel (interconectando los periféricos en su chip y el hardware a su alrededor) necesitará aprender algunas habilidades nuevas, pero es mucho trabajo sin muchos conceptos nuevos. Para las capas más altas de sus proyectos, puede dibujar en su conocimiento existente.

Por cada método de biblioteca arduino al que llama, existe una gran cantidad de código C / C ++ que lo hace posible, simplemente está bien empaquetado para que lo use como API. Eche un vistazo al código fuente de arduino en el directorio hardware / arduino / * y verá todo el C / C ++ escrito para usted que interactúa directamente con los registros del microcontrolador AVR. Si su objetivo es aprender a escribir cosas como esta (directamente para el hardware), hay mucho que cubrir. Si su objetivo es hacer que algo funcione con sus bibliotecas, es posible que no haya mucho de qué hablar, ya que la mayor parte del trabajo duro que se realiza para usted y sus bibliotecas y el entorno de desarrollo son muy fáciles de usar.

Algunas reglas de oro, sin embargo, cuando se trabaja con dispositivos con recursos limitados que podrían aplicarse a un entorno arduino u otros:

Tenga en cuenta la cantidad de memoria que está utilizando. Tanto el tamaño del código (que va a la memoria flash) como el uso de RAM estática (constantes en su código que siempre existirán en la RAM). Yo diría que el uso de RAM estática es un poco más importante al comenzar, ya que es fácil de ver. No es raro que solo tenga 1000 bytes para trabajar con su pila, montón y constantes. Sea prudente en cómo lo gasta, así que evite cosas como largas matrices de enteros (4 bytes cada uno) cuando bastarán los bytes o los caracteres sin signo (1 byte cada uno). Otra respuesta aquí cubre algunos otros puntos importantes muy bien, por lo que me detendré aquí. Principalmente quería explicar que hay mucho para cubrir si no está usando la biblioteca arduino y escribiendo. tus propias bibliotecas C

En cuanto a la programación de microcontrolador vs OOP, no son algo opuestos. Es cierto que todas las bibliotecas de proveedores están en C simple, pero todas las plataformas son compatibles con C ++ OOP también. Los desarrolladores pueden crear y construir bibliotecas de alto nivel de C ++ y firmware de dispositivos además de eso. El buen ejemplo son las bibliotecas de Arduino, oficiales y construidas por el usuario, principalmente clases de C ++. Tal vez no todas las ventajas de OOP se pueden utilizar completamente en un entorno integrado, pero las ventajas bien conocidas de C ++ vs C también son válidas aquí.

En lo que respecta a la mentalidad y el pensamiento, como se señala en otras respuestas, los microcontroladores son plataformas con recursos muy limitados (especialmente en RAM, menos en velocidad): cosas como la asignación de memoria dinámica, las excepciones de C ++ generalmente se descartan. Dado que se elige el hardware correcto, es fácil adoptar estas limitaciones y utilizar otras técnicas (también se usan ampliamente en otras plataformas).

En mi opinión, el desafío más difícil podría ser una dimensión adicional que se encuentra en la programación integrada: el tiempo. Esto se debe a que, por lo general, el software incorporado trata mucho con eventos en tiempo real, protocolos estrictamente cronometrados para controlar el hardware periférico y la tarea en sí misma (esto también es un paralelismo en otras plataformas de "alto nivel", como las aplicaciones multiproceso).

Esté preparado para leer muchas hojas de datos cuando trabaje con hardware nuevo. Supongo que podría estar relacionado con la parte de la pregunta "mentalidad" :) Seguramente se necesitarían conocimientos de EE y hardware.

También me gustaría señalar que en estos días el desarrollo de software integrado no requiere lenguaje ensamblador. De hecho, Java (BTW es OOP por defecto) ya está aquí y se está haciendo más fuerte (al menos para algunos tipos de dispositivos integrados, por ejemplo, dispositivos IoT, podría tener un futuro muy brillante).