To be able to connect to the BT device with more than one audio
profile, we need something to manage those profiles. Created here
ProfileManager made it convenient
To be able to work properly with BT, CPU freq has to be at least
at Level_5 - to be fixed!
After BT refactor settings init for key storage has been moved,
thus in the initial phase settings were unavailable and btstack
couldn't import keys from storage
There is no functional tests related to the Bluetooth. As the
refactor is on the way,we need to have a tool to check if it works
By the way fixed worker deinit
To be able to handle properly the Bluetooth stack we need to
get rid of doubled FreeRTOS task and do refactor of
the whole BT section. This is first part of refactor and it
includes integrating run loop into our worker and unifying
namespaces
This change demonstrates how to work with Bluetooth messages
in application settings windows.
Responses to bluetooth status messages are mocked because
settings storage and message handlers in Service Bluetooth
are not ready yet.
* Timers now are Application thread safe
* Timers now have consistent API independend of Application (no more c style timers)
* Timers can have either: callback or override onTimer() method - this
way we can create more complicated timers or just use existing ones
* gui::Timer added via adapter class GuiTimer to decouple sys::Timer
with gui::Timer
* Fixed race in wrapper
* Updated docs
* fixed using std and cpp_freertos and DataReceivedHandler hidden in Application.hpp
* Improved bluetooth library interface write in one demand
* can start scan
* not used BT options hidden
* still some issues on flood - transaction style interface should be considered
BlueKitchen requests from data, which doesn't mean it knows amount
need - need to provide handling to buffer in Uart handler - than
copy form handler on request, then sent notification when ready
