You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Accessing one wire memories is a hard real-time operation implemented with interrupts so it cannot be run at the same time as the bluetooth stack which is 'stealing' CPU time.
Currently this is solved by reading and caching all the memory at startup before enabling the bluetooth stack and writing to one-wire memories is disabled if the bluetooth stack is enabled.
I see two ways to solve that:
Using the bluetooth stack timeslot api to communicate only in timeslots when the bluetooth stack is not working.
Disabling the bluetooth stack during one-wire operation.
The text was updated successfully, but these errors were encountered:
90ac428 fixes the problem by disabling the bluetooth stack when accessing the OW memories. This has at least two concequences:
OW memories cannot be programmed when using the bluetooth link. This is not expected to be a problem in practice as programming OW memory is an advanced functionality.
The Crazyflie should read all memory at startup and not when the system has started. This is also the case in practice and I cannot see a use case where accessing the OW memory over bluetooth in runtime would be required.
Accessing one wire memories is a hard real-time operation implemented with interrupts so it cannot be run at the same time as the bluetooth stack which is 'stealing' CPU time.
Currently this is solved by reading and caching all the memory at startup before enabling the bluetooth stack and writing to one-wire memories is disabled if the bluetooth stack is enabled.
I see two ways to solve that:
The text was updated successfully, but these errors were encountered: