Table of Contents
The mbed hardware architecture is designed to give you a really reliable and accessible platform to be able to quickly pick up and prototype with, whilst giving you bare-metal access to the underlying target microcontroller without needing any form of bootloader or monitor. Here is how it works...
This is the basic architecture of the mbed Microcontroller board:
How programming works¶
When you plug in an mbed Microcontroller in to your PC using USB, it appears like a USB flash disk. This small disk is presented by the mbed Interface, and allows you to save ARM microcontroller binaries you want to run directly on to the mbed, without needing drivers. Note that when you save a binary file to the mbed disk, it is not immediately loaded in to the internal microcontroller FLASH memory.
When you hit reset, the mbed interface looks at the disk for the newest .bin file it can find. If there is a new file, it will load it in to the microcontroller's internal FLASH memory using the JTAG interface. If the newest binary is already loaded, it won't load it again. It then starts the microcontroller running.
This means if you hit reset again, it will simply reset the target microcontroller and start it running again, as the latest binary is already loaded.
If there is no binary on the mbed disk, the target microcontroller will simply be kept held in reset.
How USB serial works¶
The mbed Interface also presents a USB serial/com interface. This is basically a UART-USB bridge, and connects to UART0 of the interface. So if you send characters out of UART0 of the target microcontroller, they will be read by the mbed interface and transfered over the USB link. When you printf(), it is just sendin characters to UART0. This means if you make your own PCB, these characters will still appear on UART0.
How the LocalFileSystem works¶
Because we have a USB disk, we also thought it'd be really useful to let you read and write files to it from the target microcontroller. To do this, the mbed Interface acts like a host debugger and listens out for filesystem "semihosting" requests via JTAG.
The USB interface used for programming the microcontroller is not using the USB interface of the target LPC1768 microcontroller. This means the target USB interface is still available on the mbed pins (D+, D-), allowing your applications to have their own USB interfaces.
The .bin files the mbed Microcontroller accepts are standard raw ARM binaries, and can be generated by any compiler you like. You have bare-metal control of the target microcontroller, as the separate interface manages programming over JTAG i.e. we don't use a bootloader or monitor on the target. So you really are just loading on a raw binary. This means you can build your own PCB using the same target microcontroller, and the same program binary will run on that.
Posting comments for this page has been disabled