Question about module dependence

Mbed OS
1

When I tried mbed OS on ST STM32F4-Discovery board, because this board was not supported yet, so I created few new modules and used yotta link and yotta link-target commands to run mbed OS on this board. The module dependency tree is like this:

blinky-stm32f4-disco 0.0.0
\_ mbed-drivers 0.11.6
  |_ mbed-hal 1.2.0 yotta_modules\mbed-hal
  | \_ mbed-hal-st 1.0.0 yotta_modules\mbed-hal-st
  |   \_ mbed-hal-st-stm32f4 1.1.0 yotta_modules\mbed-hal-st-stm32f4
  |     |_ uvisor-lib 1.0.10 yotta_modules\uvisor-lib
  |     |_ mbed-hal-st-stm32cubef4 1.0.2 yotta_modules\mbed-hal-st-stm32cubef4
  |     \_ mbed-hal-st-stm32f407vg 0.0.1 yotta_modules\mbed-hal-st-stm32f407vg

From above dependency tree, mbed-hal-st-stm32f4 depends on mbed-hal-st-stm32f407vg. In order to achieved that I needed to modify module.json of the official module mbed-hal-st-stm32f4 by adding mbed-hal-st-stm32f407vg to its targetDependencies.

Now comes the problem, if I have created required modules to support a new STM32F4xx board and publish them to yotta public registry, I still could not make it work without resorting yotta link and yotta target commands, because official version of mbed-hal-st-stm32f4 does not list the required module (mbed-hal-st-stm32f4xxx) to its target dependencies. Besides it is not practical for mbed-hal-st-stm32f4 to include all STM32F4 boards used by developers.

How does mbed OS solve this problem?

2

Hi Max,

The intention is that you won’t need to add a code module to use mbed OS on a previously unused board in the future.

We’re working on moving the code that’s in the board-specific modules into chip-specific modules, using for example pin-definitions generated by config. You can find some documentation on the way pin names are defined here: mbed-hal/pins.md at master · ARMmbed/mbed-hal · GitHub

It’s likely that the presence/selection of external crystals will be configured in a similar way, and we’re considering the options for supporting different external RAM configurations.

3

Hi James,

Thanks for your explanation.

I should change the word “board” to “chip”.

Yes, target.json of target-st-stm32f429i module uses config to configure board specific settings.

Different chips need different chip-dependent files, using STM32F4xx as an example, below 2 files are different for STM32F4 chips:

  1. CMSIS device file - stm32f4xxxxx.h: This belongs to cmsis-core-stm32f4xxxxx module.
  2. Bootstrap start file - startup_stm32f4xxxxx.s: This belongs to mbed-hal-st-stm32f4xxxxx module.

Do we still need above 2 kinds of modules to support different chips in the future?

4

Currently to use mbed OS with a chip (or chip family), the vendor needs to either support, or have accepted someone else’s port which supports that family (this is by design).

We think that in the future we can eliminate the need for the separate startup code for each chip, even, but for now both of those are required (along with the actual mbed-hal implementation :wink: