Replies: 1 comment 3 replies
-
Late answer :). I had the same problem. I did an example with the c++17 version. In my case I have an interface class for a uart which instantiates multiple uarts for the same chip. Maybe this give you a glue how this could work https://godbolt.org/z/6bGWKdf5o @lukevalenty or @bdeane-intel Maybe you can have a look if this is intended like this. Also I have a problem on this. It compiles so far. The routines were called but in line 122, the general RuntimeInit service was not executed, and dont know why. |
Beta Was this translation helpful? Give feedback.
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
In the systems I'm developing, we typically have to run the exact same control algorithm with different sets of inputs and outputs.
In cib terminology, I would consider the inputs/outputs as Services and the control algorithm as a Feature.
I'm wondering how one would tell cib to create multiple "instances" of a Feature and a Service. I reckon these should also be "compile time" constants, so I think we would use templates to pass in different configurations.
For example: consider a heating system with multiple zones and a central controller that collects the different temperatures (inputs) and on the other hand controls a boiler and radiator valves to distribute the heat to the appropriate zones.
This example is in now way a real world example, but I think it does illustrate a typical "distribution" of components.
In this case, I think there would be multiple services for each of the temperature inputs (let's assume there's one temperature sensor per zone).
They would all adhere to the same "temperature sensor" interface and probably share the same implementation except for having a different configuration (e.g. ADC port to read out).
Similarly, there would be multiple services for each of the radiator valves (again, let's assume one valve per zone).
These would all adhere to the same "radiator valve" interface and (again) probably share the same implementation except for having a different configuration (e.g. GPIO pin of which the state should be changed or a PWM channel).
Finally, there would be a feature that needs one "temperature sensor" and one "radiator valve". This would have some logic to convert the temperature into an action on the radiator valve. This logic is the same for all our zones.
Based on the situation described so far, I think this might be "do-able" with just having a nexus for each zone and have use a template to pass in the configuration (e.g. ADC port or output pin) to the Services at compile time. Right?
But, what if I add the boiler in to the mix: now I need some Service/Feature to collect the heating demands of all the zones (determined by the Feature mentioned just above) and based on that control the output to the boiler accordingly.
How can we solve this without getting "multiple" instances of this service? Or can we solve the problem mentioned earlier with a single nexus?
In other words, I have multiple components that an adhere to one or more of the same services/feature "interfaces", can I somehow tell cib which components go together and which do not?
Hopefully I explained my use case clear enough, if not, please do tell so I can try to clarify.
Disclaimer: Keep in mind that I just stumbled across cib this morning. I saw quite some similarities with a project I wanted to make myself to make embedded software more modular without lots of overhead, so I got intrigued. I have no hands-on experience with cib just yet, other than going through the docs and some of the examples. I'm also rather new to C++, as I have been mainly using C in the past 6 years or so for embedded development.
Beta Was this translation helpful? Give feedback.
All reactions