Is it possible to provide a way to easlily use customized modules?

[maxpeng]

I posted a question to mbed forum - Customized modules. I think it is better to re-post to here.

Original post:

"Write once and use everywhere" is the goal of component-based development. In my opinion, mbed OS utilizes modules to head towards that goal. However, sometimes I need to customize existing module(s) to meet my needs, but I could not find a feasible way to achieve that.

For example, the retarget.cpp of mbed-drivers implements the the low-level _write function to re-direct the debug messages to the serial port, but its speed is slow. On the contrary, Segger RTT could output debugging messages with very high performance. To use Segger RTT, I also need to re-implement the low level _write function. The end result is that I need a customized version of mbed-dirvers to disable the _write function in order to utilize Segger RTT.

To use the customized mbed-dirvers for my executable, I could use yotta link command to link to it. But how do I share the source of the executable to others to successfully build that executable? If they build the executable without using yotta link, yotta will pull mbed-drivers from the yotta registry.

How does mbed OS to solve this kind of problem? For example, the retarget.cpp of mbed-drivers implements the the low-level _write function to re-direct the debug messages to the serial port, but its speed is slow. On the contrary, Segger RTT could output debugging messages with very high performance. To use Segger RTT, I also need to re-implement the low level _write function. The end result is that I need a customized version of mbed-dirvers to disable the _write function in order to utilize Segger RTT.

To use the customized mbed-dirvers for my executable, I could use yotta link command to link to it. But how do I share the source of the executable to others to successfully build that executable? If they build the executable without using yotta link, yotta will pull mbed-drivers from the yotta registry.

How does mbed OS to solve this kind of problem?

[maxpeng]

Presently, I found many mbed developers forked the official modules in order to use their customized modules. For example, forked cmsis-core to use the customized module cmsis-core-xxxx. so I think they also have this kind of problem.

Maybe yotta could provide a command line option, for example:

yotta override-mod mymod "git+ssh://somwhere.com/anything/mymod" ^1.0.0

Then when yotta sees mymod module is referenced, it pull mymod from the specified URL instead of from yotta registry.

[autopulated]

You'd generally want to use yotta's config system to do this: http://yottadocs.mbed.com/reference/config.html

It's up to the designers of a module to make it as customisable as it needs to be (e.g. provide an API, or configuration option that allows different handlers for output streams). You have to be careful though, as only the application can configure modules (modules cannot configure each other, as each module can exist in only one configuration in the system, but may have many modules depending on it): for modules which provide APIs that can have multiple instances these need to be configured dynamically.

[maxpeng]

Maybe I didn't describe the problem clearly.

Assuming that I build a simple blinky application by setting the target as stm32f429i-disco-gcc, the module tree is like this:

blinky 0.0.0
\_ mbed-drivers 1.5.0
  |_ mbed-hal 1.3.0 yotta_modules\mbed-hal
  | \_ mbed-hal-st 1.0.0 yotta_modules\mbed-hal-st
  |   \_ mbed-hal-st-stm32f4 1.3.5 yotta_modules\mbed-hal-st-stm32f4
  |     |_ uvisor-lib 2.1.2 yotta_modules\uvisor-lib
  |     |_ mbed-hal-st-stm32cubef4 1.2.0 yotta_modules\mbed-hal-st-stm32cubef4
  |     \_ mbed-hal-st-stm32f429zi 1.1.0 yotta_modules\mbed-hal-st-stm32f429zi
  |_ cmsis-core 1.2.0 yotta_modules\cmsis-core
  | \_ cmsis-core-st 1.0.1 yotta_modules\cmsis-core-st
  |   \_ cmsis-core-stm32f4 1.2.0 yotta_modules\cmsis-core-stm32f4
  |     \_ cmsis-core-stm32f429xi 1.0.3 yotta_modules\cmsis-core-stm32f429xi
  |_ ualloc 1.3.0 yotta_modules\ualloc
  | \_ dlmalloc 1.1.0 yotta_modules\dlmalloc
  |_ minar 1.3.0 yotta_modules\minar
  | \_ minar-platform 1.1.0 yotta_modules\minar-platform
  |   \_ minar-platform-mbed 1.3.0 yotta_modules\minar-platform-mbed
  |_ core-util 1.8.0 yotta_modules\core-util
  |_ compiler-polyfill 1.3.0 yotta_modules\compiler-polyfill
  \_ greentea-client 1.1.0 yotta_modules\greentea-client

Assuming that I need to customize "mbed-hal-st-stm32cubef4" module to meet my needs, how could I direct yotta to import my version of "mbed-hal-st-stm32cubef4" module from a particular URL instead the one from yotta registry?

[autopulated]

In general, make a pull request against mbed-hal-st-stm32cubef4 to add the things you would like to be configurable to the config system.

Otherwise, use yotta link to link in your version. You could also add your version as a dependency of your application (use the github Username/modulename as the version specification): when doing a fresh install this version would be used in preference to the other, this isn't necessarily a good idea though, as you'd need to keep the version number the same to ensure compatibility.

[thegecko]

@maxpeng Are you happy with this answer?