* A modern, block-structured programming language: I would pick C, since it's still the most common for embedded, but you could learn the principles using Pascal, Modula-2, or other languages. Most tool chains use some flavor of gcc, and if you want to start working with gcc on your PC, you could use mingw or cygwin to get started. My favorite C reference book is by Harbison and Steele. There are also some great little starter kits for embedded targets, including TI's LaunchPad for the MSP430 and several platforms for PIC and Atmel processors.

* A modern assembly language: Since ARM owns 60+ percent of the embedded world, I would learn a bit of embedded assembler using one of the ARM processors, e.g. something simple like an ARM Cortex-M0. Several companies have cheap exploration kits for these cores, and most manufacturers are making silicon with tons of peripherals around this 16/32-bit core. A good book and development module is here. In truth, you will seldom have to resort to assembler, but it's important to have an understanding of how the processor actually works in some cases.

* Data structures and algorithms: I have yet to take on a project where I have not needed some structures and algorithms like linked lists, queues, sorting, stacks, tree searches, etc. A basic understanding of how to implement these is a must-have, although in modern languages such as C++ you may get them for "free" through the STL or 3rd party libraries.

* Operating systems concepts: Everything from simple "supervisory loops" to timer-driven state machines, to real-time operating systems to full-blown operating systems like Linux, Windows, and the Cloud. Especially "real-time" or deadline-critical operating systems, which must execute threads or tasks within a certain time, or the system may fail. Common/free examples these days might include FreeRTOS, although I would also buy the book and get the academic source to Jean Labrosse's uC/OS-II and/or uC/OS-III and read them thoroughly. They are a great explanation of how an RTOS can be implemented, and he's an excellent author. The big difference between II and III is that III adds the use of a memory management unit, where you can protect tasks from stomping on each other. You can find the books here. For FreeRTOS, you could try this.

* No course on RTOS is going to be complete without a discussion of how you hook up devices to the RTOS, e.g. with device drivers. Unfortunately, most of the info on this will be inside one of the RTOS books, or else will be a book specific to Linux or Windows device drivers. If I come across some better examples, I will pass them along. The CMSIS library that is provided by ARM vendors often has good examples that can be the start of device drivers, but marrying them to an RTOS can be tricky. This is where a thorough understanding of the facilities that your RTOS provides, such as tasks, ISRs, semaphores, queues, etc. can be extremely helpful. The POSIX model uses some standard APIs for controlling device drivers: creat(), open(), close(), read(), write(), ioctl(), poll(), select()...

* Object Oriented Analysis/Design - How to break down and design a system using object-oriented and other methods. The standard notation for this is the Unified Modeling Language, but I confess that use about 1% of what it's capable of. I would like to learn how to use this better myself. Other requirements and design techniques can also be used for breaking down WHAT has to be done (requirements), and how you're going to do it (DESIGN).

* A modern object oriented language: For this, I would recommend C++, as it is the most common one you will find if you are able to use such language on an embedded processor. I'm using an NXP LPC1850 with the IAR Embedded Workbench tools, and we can actually support full C++ including templates, function overloading, multiple inheritance, exceptions, etc. It's rare to have such a luxury on embedded systems, which are often very constrained. For reference books, I really like the free ones from Bruce Eckel, called "Thinking in C++".

* Dan Saks offers a killer course in Embedded C++ that I would love to attend.

* You have already been exposed to much of this, but a course dealing with Software Project Management would help, which will go over all of the life cycle models and typical steps that a software project goes through from napkin concept to retirement. A good standard for medical is IEC 62304. Basic models include things like project stages, development models (linear/waterfall, spiral, evolutionary, agile), implementation, testing, deployment. I think that incremental, evolutionary, and agile are the ones you will l most likely encounter today.

* For development environments, I would try to learn something based on Eclipse, which has become a free and de facto standard for IDEs. You can even get C/C++ GNU toolkits that plug into Eclipse so you have an editor, debugger, and compiler to learn the basic languages you'll need, and then many vendors have specialized plug-ins for their own debuggers, processor-specific register views, and compilers. Even some RTOS visibility tools are available.

* Something in embedded/real-time math (fast, usually limited precision, often with software floating point or scaled fixed point math may be helpful.) Jack Crenshaw has a great book on "Real-Time Math Toolkit", and if you need to do some serious math, "Numerical Recipes in C" is great.

Desarrollo con microcontroladores ARM Cortex-M3 microcontroladores <<= 2

La documentación de ARM es extensa y completa, tan completa que para
entender las diferencias entre el Cortex-M0 y el Cortex-M0+ hay que leer
tres manuales de referencia y correr un diff mental.

Este libro está concebido como una guía para el desarrollador que desea
pasar de 8- a 32-bits. El primer capítulo introduce conceptos esenciales
para poder entender las arquitecturas de 32-bits y evaluar este tipo de
micros en general; mientras que el segundo capítulo abarca todo lo que
puede de todas las arquitecturas ARM de 32-bits al momento, con la
profundidad suficiente como para no ahogar, pero tampoco mojando sólo
los tobillos. La decisión de dónde poner el límite es mérito del foco
decidido para la obra, dado que cada arquitectura podría extenderse por
sí misma hasta ocupar el libro por completo.

Dicho foco está, como se desprende sutilmente del título, en Cortex-M3,
por lo que se lo describe primero. A continuación, todos los demás
procesadores del perfil M se describen en función de éste. El esquema de
descripción para los cuatro procesadores se mantiene uniforme y
minimalista, así como todo lo presentado en el resto del libro, por lo
que si comparamos la cantidad de información por unidad de volumen con
respecto a toda la bibliografía de ARM, el capítulo 2 sea tal vez
considerado un agujero negro.

Pero la información por sí sola es inerte, necesita de la práctica para
volverse conocimiento. Es así que los capítulos siguientes analizan las
herramientas de desarrollo en un ambiente independiente de cualquier
fabricante en particular, siguiendo luego con el análisis de las
prácticas más comunes en C y sus efectos en un procesador de 32-bits,
para finalizar con análisis de cuatro familias de microcontroladores de
distintos fabricantes, con ejemplos prácticos.

Sintetizando, este libro será una herramienta para ayudarnos en la
búsqueda del conocimiento, para a su vez dominar otra herramienta: los
microcontroladores ARM de 32-bits.

In response to your question, the main problem with maintenance is that it usually is not "maintaining" but enhancing.  The application is being extended by adding features that were never planned and then trying to shoehorn them into the same code and micro that was originally used.  Most suppliers have an upgrade path for a micro that allows an almost "easy" transition when a micro becomes obsolete.

Of course, the problem with feature creep during the original product development is that at some point, you make the product work late in the schedule and nobody can remember all the little tricks done late at night to make the code work just right.  I try to comment extensively since I can not remember what I did two months later, let alone anyone else.  This makes maintenance something tossed over the partition to the new guy.

A company hires a freelance engineer, and asks him to support a few software packages, making the host side of some embedded devices. The devices are sold, updated and supported for twenty years, so are the software packages. And that doesn't mean all that software is working flawlessly, neither that it's been debugged at it's best.

This engineer finds himself juggling with multiple modules, each nearly 30 kLOC large, where one quarter of the code is under #ifdef (to support multiple architectures, or even to be always excluded from compilation!), multiple global variables are nested in structures (often duplicated because too large to be remembered), and 4-5 developers over time have added different coding styles (but almost no comments).

Talking to the company's senior engineer, our intrepid hero proposes to start pruning and cleaning the code base, since maintenance is a big burden. The answer is always "no, we can't risk to change what's working now". So, the freelancer keeps being paid day by day, keeping together a software that risks to explode every time a new features is added (or any old bug is fixed).

Another funny part, is that the same freelancer contributed, more than 20 years before, to the growth of that same company. As he left to follow new projects, the heirs of software base kept intact most of the two decades old software (that again couldn't stay the same for so long), while some newcomers were coding ("bugging") without any clear guideline the new products.

Shouldn't be this the case for stop prolonging a product's agony and restart from a tabula rasa?