ChibiOS Free Embedded RTOS

I have an application (running on an stm32f103) with a fairly large codebase -- for modularity, portability, and readability I've split it into several 'modules,' each which lives within its own file and has its own initialization routines. I have several different pins I want to monitor for changes with the EXT driver, and some of these are in different modules. There seems to be no way to cleanly do this, since any call to extStart() will affect ALL the channels. So the options are:

- Do the EXT initialization in main, separately from any module. I don't like this option because it puts extra requirements on each module, and makes it harder to port the code
- Do the EXT initialization for all modules in a single one's initialization routine. Similarly non-ideal because it introduces inter-module requirements
- Write an EXT wrapper which maintains a local copy of the config which can be modified by multiple modules. This is probably what I'll end up doing

Mostly, I'm just verifying that I do indeed have this correct. It also seems like this kind of functionality could be baked into the EXT driver -- specifically, the ability to modify the configuration on a per-channel basis after extStart() has been called. Is there a reason why this hasn't been done? I ask more for curiousity's sake than anything else.

Thanks!

Hi,

Making the EXT configuration modifiable would require keeping it in RAM and it is not small. for many application a const EXTConfig structure is sufficient. Adding functions that modify the EXTConfig structure would *require* keeping it in RAM even if not needed.

The current approach allows the implementation of your centralized handling but does not forbid the simple approach of having all constant.

Giovanni

As usual, right after I posted this I came across extSetChannelModeI(), which seems to do what I want (but I understand the drawbacks of any such implementation, that is, keeping the config in RAM). Thanks for the fast feedback!

That function is troublesome, it requires the EXTConfig structure in RAM and it causes MISRA violations because the pointer to the structure assumes a const structure... You don't even get an error for trying to modify a const structure.

I was considering to remove it and let users do exactly what you suggested (doing exactly the same thing outside the driver).

Giovanni

I'll keep that in mind, perhaps will end up writing my own wrapper after all.

Austin

You just need to wrap that function, in case I will decide to remove it you will just need to copy the code inside. Note that it is not a real problem, it just bothers me to KNOW that I am doing something not exactly clean in one point of the code....

Giovanni