Bluenet is the in-house firmware on Crownstone hardware. Functions: switching, dimming, energy monitoring, presence detection, indoor localization, switchcraft.
The current method of keeping track of pin states by the GPIO driver is by keeping a vector of only active pins. This makes for difficult access of pins since the API required the index of the virtual pin vector. E.g. to write to a LED pin, it matters which non-LED GPIO pins are active on the board.
In the refactor, the GPIO driver keeps track of both active and inactive pins which means accessing pins does not require looping over all pins and checking which are active. Accessing pins for configuring/reading/writing can be done via a hardware-agnostic virtual pin index.
To save memory, instead of copying the hardware pins to the GPIO driver, a pointer to the board config struct is passed in in the initialization, and during operation the driver can retrieve hardware pins from it.
Also, the driver will check in the board config for the flag ledInverted and if it is true, the write function will invert the logical value to be written if the pin is a LED pin.
Separating dimmer and switch from microapp pin protocol
Instead of considering the dimmer and switch as a GPIO, I thought it made more sense to consider them separate entities and separated them from the pin protocol in the communication between microapp and bluenet.
I have not updated the MICROAPP.MD document yet reflecting the dimmer/switch protocol update (I think it may still to be updated from some past updates as well). I do not know how to generate the nice pictures for message structure, but if you let me know I could try to update the docs.
GPIO driver changes
The current method of keeping track of pin states by the GPIO driver is by keeping a vector of only active pins. This makes for difficult access of pins since the API required the index of the virtual pin vector. E.g. to write to a LED pin, it matters which non-LED GPIO pins are active on the board. In the refactor, the GPIO driver keeps track of both active and inactive pins which means accessing pins does not require looping over all pins and checking which are active. Accessing pins for configuring/reading/writing can be done via a hardware-agnostic virtual pin index.
To save memory, instead of copying the hardware pins to the GPIO driver, a pointer to the board config struct is passed in in the initialization, and during operation the driver can retrieve hardware pins from it.
Also, the driver will check in the board config for the flag
ledInvertedand if it is true, thewritefunction will invert the logical value to be written if the pin is a LED pin.Separating dimmer and switch from microapp pin protocol
Instead of considering the dimmer and switch as a GPIO, I thought it made more sense to consider them separate entities and separated them from the pin protocol in the communication between microapp and bluenet.
See also (https://github.com/crownstone/crownstone-microapp/pull/11) for the microapp PR.
Documentation
I have not updated the
MICROAPP.MDdocument yet reflecting the dimmer/switch protocol update (I think it may still to be updated from some past updates as well). I do not know how to generate the nice pictures for message structure, but if you let me know I could try to update the docs.