Niall Cooling wrote:

As a company who’s been involved with training many thousands of embedded software engineers over the last 18 years (in technologies such as C, C++ and Real-Time Operating Systems) our goal was always to try and recreate an engineer’s everyday environment in the training courses. To this end we have always used embedded target boards on which an application is programmed. Initially we started with a Renesas SH-2 based system, but over a decade ago we switched to an ARM7TDMI (NXP LPC21xx) target.

However, with the announcement and release of the Cortex-M family of microcontrollers we made the decision to port our training to a Cortex-M3 based system. Ideally we like to use off-the-shelf hardware where possible, but have always struggled to find target system that fit our requirements. As we work very closely with ARM (as both a provider of training to ARM and an ARM Approved Training Center) we were made aware of the mbed in its very early days.

Initially we thought the concept of the mbed was a great idea, but unfortunately had to rule it out on a number of reasons:

1. We need an offline IDE (e.g. Keil uVision or IAR EW) as when training on a customer site we cannot guarantee internet access - may sites, for security reasons, are locked down.
2. As great as the mbed library is, it actually hides all the code we are teaching engineers to develop (e.g GPIO, programming UARTs, handling interrupts, fault handling, etc.)
3. As a consequence of (2) we also need source level debugging (e.g. breakpoint, reading assembler, memory access, single-step, etc.) and visibility of the build process (e.g. what the compiler & linker are doing, memory maps, etc.)

Even though I was a fan of the mbed (I did some early work on MQTT with the mbed) we didn’t pursue it as a viable target, instead prototyping our own board deliberately based around the same core as the original mbed platform (NXP LPC17xx series). Students are always asking for hardware they can continue to experiment with after the course and by using the same core it allowed us to point them at the mbed. As an aside, in the Embedded C++ courses, we recommend students take a look at the mbed libraries to illustrate how well device drivers can be wrapped in C++ objects.

Luckily for us, before we’d gone into full production, ARM announced CMSIS-DAP and its support for the mbed. So recently we have spent some time experimenting with CMSIS-DAP using the mbed and the Keil uVision IDE. The details of which are:

1. Native C/C++ Application development for the mbed using CMSIS-DAP
2. User I/O from mbed with CMSIS-DAP
3. Rehosting ARMCC for the mbed with CMSIS-DAP
4. Test Driven Development (TDD) with the mbed

The great news is that mbed + CMSIS-DAP meet our needs and as such we are redesigning our training platform to be to accommodate an mbed rather than mounting the NXP LPC1768 directly. We also have a full TDD (Test Driven Development) setup using the mbed, the Unity TDD framework and a little bit of Python for use on our embedded software testing course.

You can find me at: https://mbed.org/users/feabhas/