Skip to content
This repository has been archived by the owner on Jan 15, 2021. It is now read-only.

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

Open
maxpeng opened this issue May 4, 2016 · 5 comments
Open

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

maxpeng opened this issue May 4, 2016 · 5 comments
Labels

Comments

@maxpeng
Copy link

maxpeng commented May 4, 2016

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
Copy link
Author

maxpeng commented May 4, 2016

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
Copy link
Contributor

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
Copy link
Author

maxpeng commented May 5, 2016

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
Copy link
Contributor

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
Copy link
Member

@maxpeng Are you happy with this answer?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants