Initialization Control Flow and Error Handling

[AronRubin]

I really like what you have done with this framework but flow control is unclear to me. I don't see returns being passed in the code. In the talk, you had a global; is that the intent? How does that interact with constexpr? It is also unclear if there was a best practice to handle a more general initialization failure.
For context, I have firmware that starts the appropriate device code based on a detection step. I have for example a number of devices with either the VL53L0X or the VL53L1X laser ranger depending on when I was sourcing the parts. My current firmware initialization checks which devices actually respond on the bus and choose which to use. Likewise, if an OLED display shows up on I2C it displays debug information.

[lukevalenty]

Hi @AronRubin! I'll try to answer your questions the best I can. 😄

In the talk, you had a global; is that the intent? How does that interact with constexpr?

I think I need more detail here, which global are you talking about?

For context, I have firmware that starts the appropriate device code based on a detection step. I have for example a number of devices with either the VL53L0X or the VL53L1X laser ranger depending on when I was sourcing the parts. My current firmware initialization checks which devices actually respond on the bus and choose which to use. Likewise, if an OLED display shows up on I2C it displays debug information.

cib excels at compile-time initialization. It can't make any decisions at runtime. The callback and flow services don't support any sort of control-flow. However, there are some options:

1. I have used boost::sml to create state machines that can make decisions at runtime. The arcs will execute one or more flows based on runtime decisions. You could also have a regular function make a runtime decision on which flow or callback to call.
2. You could encapsulate laser range-finder support into a generic library that knows how to detect which device is present and load the driver for that one at runtime.
3. You could keep support for the OLED display, but only activate it if the display is present.
4. You could add a runtime initialization scheme to add callbacks based on runtime information. There are a lot of ways to do this, but it is not something that cib is focused on.

[lukevalenty]

That being said...it would be interesting and useful for cib to have built-in support for runtime-initialization of services. I'll have to think about how that would look and work.

The key benefit is keeping a declarative syntax for initialization that works the same for runtime and compile-time.

[AronRubin]

In the talk, you had a global; is that the intent? How does that interact with constexpr?

I think I need more detail here, which global are you talking about?

If memory serves, you made a "volatile int OUTPUT" and seemed to have set a value for it in a constexpr config member.

cib excels at compile-time initialization. It can't make any decisions at runtime. The callback and flow services don't support any sort of control-flow. However, there are some options [...]

Right. I realize that the CIB effort is meant to make well-formed initialization routines assemble into a relatively monolithic block of compiled instructions. That is great. If I were to write that block directly, however, I would still want to include branching as described and some error handling. I don't know if something needs to be different in CIB or if I just need to adopt a good practice of use.

Separately, I was a little surprised that there isn't a well-known library to scan the I2C bus and initialize drivers for the addresses that respond. There is more to code of course but it has been common to a few of my projects now.

[lukevalenty]

I would still want to include branching as described and some error handling. I don't know if something needs to be different in CIB or if I just need to adopt a good practice of use.

If you have a component that adds support for a hardware device of some sort, I would expect that the error handling for the initialization of that device would be encapsulated by that device-specific code. I wouldn't expect it would need to have flow control across multiple components.

Maybe it would help me understand better with a specific example of the sort of error handling and flow control you have in mind.

[lukevalenty]

If memory serves, you made a "volatile int OUTPUT" and seemed to have set a value for it in a constexpr config member.

Ohh yeah. The OUTPUT variable was just there to emulate some sort of hardware IO register. The lambdas and function pointers that get passed into the cib config members still get executed at runtime.