Aprende C, y consigue una placa de desarrollo de microcontroladores barata, como un MSP430 o un ARM Cortex, y al menos escribe y carga unos cuantos programas en C.
Tengo una licenciatura en ciencias de la computación y un fondo de desarrollo de software, sobre todo la programación de C ++ para los juegos y ahora los juegos de iOS y aplicaciones, pero mi último trabajo fue un semi-profesional EE concierto que comenzó con hacer un montón de programación de firmware para un sistema ARM Cortex M3, y luego terminó conmigo aprender a hacer un poco de diseño de circuitos básicos y diseño de la placa y el diseño de un par de placas simples. Así que básicamente tuve que enfrentarme al problema de utilizar el mejor lenguaje de programación para unir el diseño de hardware/software como alguien que era responsable de ambos extremos.
C es absolutamente el lenguaje que necesitas conocer. Es fácil para la gente que programa en C++ y nunca tiene que limitarse al conjunto de características de C decir "es lo mismo", pero no es así. Especialmente por la forma en que C++ ha evolucionado y reunido características, y la forma en que los programadores de C++ utilizan esas características, es realmente muy diferente trabajar en una aplicación C razonablemente grande que en una aplicación C++. Tu SDK de firmware será un montón de librerías C, cualquier otra cosa que quepa en una MCU será una librería C, cualquier SO que tenga sentido en una MCU estará escrito en C, etc. etc.
Dicho esto, dado que muchas de las cadenas de herramientas de MCU acaban utilizando GCC como compilador, es casi seguro que dispondrás de un compilador de C++ si utilizas una familia de MCU decente. Pero hay que tener mucho cuidado con las características que se utilizan, especialmente las cosas de la biblioteca estándar, ya que es muy fácil terminar con un binario que es demasiado grande para caber en el dispositivo. Creo que hay una buena razón para usar C++ en dispositivos embebidos, C++ tiene bastantes buenas características que tienen poca o ninguna penalización de tamaño o velocidad, sólo tienes que saber lo que estás haciendo y escribir código que está mucho más en el extremo del espectro del estilo C que en el extremo del espectro STL en términos de uso inteligente de características.
No hagas demasiado caso a la gente que dice que puedes usar Lua o Python en una MCU con el intérprete embebido adecuado bla, bla. Eso es cierto, yo lo he hecho y es divertido, pero por el momento es más para proyectos de juguete y cosas que aparecen en Hack a Day. Creo que veremos más de ese tipo de cosas a medida que la Ley de Moore se aplique implacablemente incluso a los procesadores más pequeños, esto es algo que pasó con los juegos, donde solía haber mucho ensamblador, luego aguantaron con C y C++ más que los demás, y ahora todo es tan rápido, y la productividad del desarrollador es tan importante que gran parte del desarrollo se hace con lenguajes de alto nivel embebidos o en un lenguaje de alto nivel a secas. Aun así, pasarán algunos años antes de que las empresas contraten programadores de firmware con conocimientos de Python y Lua.
Tampoco dediques demasiado tiempo al montaje. No está mal familiarizarse con los conceptos, pero es poco probable que te encuentres haciendo mucha, si acaso alguna programación en ensamblador. Hay como esta sabiduría convencional con los juegos y embebidos que es "bueno saber" ensamblador, a menudo repetido por personas que en realidad no trabajan en esos campos. Pero en realidad es muy poco probable que escribas nada de ensamblador, nunca, y si lo haces probablemente sólo serán unas pocas líneas para optimización o algo con el hardware para lo que simplemente no tienes una API (pero la tendrás después de escribir una que envuelva unas pocas líneas de ensamblador). He trabajado en varios juegos y en ese proyecto de diseño de placa/firmware, y el número total de líneas de ensamblador que he escrito para proyectos comerciales es probablemente de unas pocas decenas. No es productivo, no es portable y no es legible, así que sólo se usa como última opción posible.
