You are viewing an older revision! See the latest version
mbed SDK porting
The porting of the mbed SDK to a new target is divided in three steps:
- Add the new target to the build system
- Add a CMSIS module for the given target
- Implement the mbed library drivers for the given target
The source code of the mbed SDK (tools + libraries) is available in this repository: https://github.com/mbedmicro/mbed
Before starting the mbed SDK porting, you might want to familiarize with the mbed library internals first.
Build System¶
You can get an introduction about the mbed SDK command line tools, from a user perspective, reading the mbed-tools handbook page.
Adding a new target to the build system is as easy as adding a new Target
class to this python module:
workspace_tools/targets.py
For example, this is the Target class for the LPC1768:
class LPC1768(Target): def __init__(self): Target.__init__(self) self.core = "Cortex-M3" self.vendor = "nxp" self.supported_toolchains = ["ARM", "GCC_ARM", "GCC_CS", "GCC_CR", "IAR"]
An instance of this new Target
class has to be added to the TARGETS
list:
TARGETS = [ LPC2368(), LPC1768(), LPC11U24(), KL25Z() ]
When scanning for source code to be compiled, directories named like one of the TARGETS
are considered "target specific" and get included only if they match with the desired microcontroller target name.
cmsis and capi target directory names
The following cmsis
and capi
target directory names will have to match the name (case sensitive) of the Target
.
CMSIS Module¶
Each target has its standalone CMSIS directory under its vendor directory, for example:
- libraries/mbed/vendor/Freescale/cmsis/KL25Z
- libraries/mbed/vendor/NXP/cmsis/LPC2368
- libraries/mbed/vendor/NXP/cmsis/LPC1768
- libraries/mbed/vendor/NXP/cmsis/LPC11U24
- libraries/mbed/vendor/NXP/cmsis/LPC812
The content of the CMSIS folder for a given target is usually provided by the CMSIS-CORE distributed by the silicon vendor itself.
The addition/modification that should be provided by the mbed SDK are:
- Add a startup file and linker script for the specific target and toolchain, properly configuring the memory model.
- Implement the cmsis_nvic API for dynamically setting the vector table.
mbed Library Drivers¶
Currently, all the target dependent code, implementing the mbed library drivers API, is divided in "vendors" directories, for example:
The reason behind this choice is that, very often, a silicon vendor is reusing the same digital IP for implementing the peripherals of its SoC, therefore its drivers usually share large part of the code.
Each target does have a standalone directory containing the headers defining many of its specific features, for example:
- libraries/mbed/vendor/Freescale/capi/KL25Z
- libraries/mbed/vendor/NXP/capi/LPC2368
- libraries/mbed/vendor/NXP/capi/LPC1768
- libraries/mbed/vendor/NXP/capi/LPC11U24
- libraries/mbed/vendor/NXP/capi/LPC812
Probably the most important file, at the beginning of a port to a new target, is device.h.
device.h
contains all the defines that enable/disable the inclusion of a certain set of peripherals in the mbed library.
When you start a port for a new target, setting all these defines to 0
will quickly allow you to compile the whole mbed library and start running tests.
Currently, the bare minimum you should implement to start running the first tests is:
- GPIO API
- us ticker API:
void us_ticker_init(void);
uint32_t us_ticker_read(void)
Having this initial block in place will allow you to run simple programs like the mbed hello world:
#include "mbed.h" DigitalOut myled(LED1); int main() { while(1) { myled = 1; wait(0.2); myled = 0; wait(0.2); } }
This is the full list of the mbed drivers API that could be potentially implemented for a target:
- analogin_api.h
- analogout_api.h
- can_api.h
- ethernet_api.h
- gpio_api.h
- gpio_irq_api.h
- i2c_api.h
- pinmap.h
- port_api.h
- pwmout_api.h
- rtc_api.h
- semihost_api.h
- serial_api.h
- sleep_api.h
- spi_api.h
- us_ticker_api.h
Testing¶
The mbed SDK provides a test system to validate the addition of your new target.
You may want to familiarize with the command line interface and structure of the test system reading the mbed-tools handbook page.
The description of the tests aimed at validating the mbed SDK are prefixed with the string "MBED:
".
Smoke Test¶
[ 0] MBED: Basic
is the first smoke test that represents the basis to execute all the other tests in the mbed SDK suite. This is an example command line test run:
mbed> python workspace_tools\make.py -m LPC1768 -t ARM -s COM41 -d E:\ -p 0 >>> BUILD PROJECT: BASIC (LPC1768, ARM) Compile: main.cpp Compile: test_env.cpp Link: basic Elf2Bin: basic Image: C:/Users/emimon01/mbed/build\test\LPC1768\ARM\MBED_A1\basic.bin {success} {end}
C/C++ environment initialization¶
MBED: Heap & Stack
- setting of the single area memory model with heap and stack collision detection.MBED: C++
- initialization of static C++ objects
Digital I/O and IRQ¶
For this set of tests you will need to connect together a pair of pins:
MBED: DigitalInOut
- Setting digital I/O functionality, direction and value.MBED: InterruptIn
- Triggering and handling of GPIO IRQs
Timing functionalities¶
For this set of functionalities it is preferable to use a logic analyser to verify the correctness of the time intervals:
MBED: Time us
- simple us_ticker init/read functionalityMBED: Ticker 2
- correct triggering of timing events
SPI¶
The SPI tests require the wiring of additional peripherals:
MBED: SPI ADXL345
- See ADXL345 AccelerometerMBED: SD File System
- See SDFileSystem
ADC/DAC¶
This test relies on a connection among one ADC pin and one DAQ pin on the same target:
MBED: Analog
Semihosting¶
The following tests are used to verify the semihosting functionalities that may be provided by the "mbed interface"
MBED: semihost file system
- Local file systemMBED: Semihost
- mbed unique ID