I'm an embedded developer with a lot of experience with M4s in the shape of STM32s, but I'm completely new to mbed. I'm a bit curious about what the API does under the hood, and how capable it is.

Take Serial for instance. You give it a TX and RX pin, and it automatically works out which USART peripheral each pin for those functions, and raises an error if there is no match or the pins are attached to different peripherals. Neat! But which peripheral is actually used? Is it USART2 or USART3 or whatever? Should I care? I think I'd like to know that sort of thing.

Now suppose I want to use DMA for the transfers. I guess it looks up the relevant DMA streams and sorts it all out for me. But the DMA channel table has redundancy, but can start to get crowded if you have several devices using DMA. I've had to jiggle things around in the past to avoid clashes. Are clashes detected? i.e. does mbed know that a stream (or other peripheral) is already in use?

Suppose I want to use a timer to check the NDTR register of the RX DMA stream rather than wait for transfer complete. I don't want to hang around waiting if the received message is not long enough to trigger the interrupt.

Sorry if these are dumb questions. I'm used to understanding the parts I'm programming quite intimately, and having to go through the sometimes painful process of constraint solving with pins, peripherals, IRQs and DMA. I suppose the question is, to what extent can mbed do this for me?

UnicycleBloke

Unless you need to change USART registers directly in order to use some feature the API doesn't support is there any real need to care which USART is being used? The only situation I can think of would be to set different interrupt priorities for different ports.

The full library is open source, if in place of the mbed library you import the mbed-dev library into your project you will get the source code which means you can dig into which USART is used for which pins if you want to. You just have to figure out where in the directory tree the code for your specific platform is. Or you can always look in the user manual for the CPU you are using, generally you'll need that to hand anyway if you are accessing the CPU resources directly.

One nice feature is that the libraries #define all of the registers and peripherals using the names in the user manual which means if you want you can use the library purely for things like startup and clock configuration and then talk directly to the hardware for everything else if you want. You do however lose the cross platform capability if you do that,

Also within the API source any directory name in capitals will be #defined if it is being used for the current platform. This makes it easy if you want to include some target specific code.

Generally the API is fairly dumb, e.g. if you use the API to configure a peripheral and then access the registers directly and change something the API will carry on regardless.

DMA isn't a core part of the API, there are 3rd party libraries to make use of it but they can be platform specific.

I guess it doesn't matter what peripheral is used, but it does seem as if the capabilities of the API are necessarily going to be a subset of the capabilities of <your device here>.

Suppose I want (say) a 5MHz SPI driver that buffers writes in a queue and uses DMA for each write. It sounds as if I'll have to roll my own, and it will work on STM32F4 (say) but not on Giant Gecko. Hmm. I do this already. I really enjoy that kind of work, but had understood mbed abstracts a lot of it away. Now I'm not sure I understand what the benefits are. Essentially all of my projects involve a fairly intimate knowledge of at least some of the peripherals on the devices I use.

Thanks.