RIOT-OS
sys/bhp_*: add initial support for generic Bottom Half Processor
Contribution description
This PR addresses this comment and adds a generic Bottom Half Processor mechanism to be used by any device that requires ISR offloading. The mechanism is agnostic to the underlying processing module (events, messages, thread flags), as it simply defines an interface for storing an (IRQ) handler and a context.
On top of that, a dedicated Bottom Half Processor module (bhp_*) exposes an init function that configures the underlying mechanism and setups the callback. Then, the device driver init function sets the ISR callback to bhp_*_cb and passes the bhp_*_t descriptor as the ISR context. The module will take care of the rest.
Based on this, I implemented an event based Bottom Half Processor (see bhp_event), which allows to offload the handler to an event queue. In the future, there could be more of these implementations (bhp_thread_flags, bhp_msg, bhp_mbox, etc).
Testing procedure
Unittests should pass.
Issues/PRs references
It will be come extremely handy to implement network-stack-and-device-agnostic IRQ offloaders for SPI radios (https://github.com/RIOT-OS/RIOT/pull/18383)
@leandrolanzieri, @MrKevinWeiss could you please check if the Kconfig modelling looks ok?
if this is merged before #18383, I can adapt the kinetis radio to this BHP mechanism
The mechanism is agnostic to the underlying processing module (events, messages, thread flags), as it simply defines an interface for storing an (IRQ) handler and a context.
Is it that simple? The memory model of the four methods is very different.
The mechanism is agnostic to the underlying processing module (events, messages, thread flags), as it simply defines an interface for storing an (IRQ) handler and a context.
Is it that simple? The memory model of the four methods is very different.
It is agnostic from an interface point of view. Neither the device nor the network stack care about which underlying mechanism is being used and these can be exchanged at any time.