added weakptr link to settings and checks
it wont crash on deinitialized setings now
Pseuto UT are passing
Added:
- deregistration on Settings destrution
- weak referencing of Service to not crash Settings on missuse
- Proxy as initialization parameter to Settings
Unused code removed
Enabled tests to be written for Settings
Removed dependency from freertos in test global file
EntryPath tests updated and compilation slimed
added weakptr link to settings and checks
it wont crash on deinitialized setings now
Pseuto UT are passing
Added:
- deregistration on Settings destrution
- weak referencing of Service to not crash Settings on missuse
- Proxy as initialization parameter to Settings
Unused code removed
Enabled tests to be written for Settings
Forced each message to have declared type as parts of Bus logic
depends on it and previously we encountered undefined
behaviours. Added tests and messages validators.
The system watchdog monitors whether there is message traffic
on the Bus. If no message was sent for an extended period of time,
a reset will occur. It should also protect against system-wide hangs.
On Linux, watchdog is simulated by a FreeRTOS task that will call exit
on timeout.
Added Gui timer auto refresh window on count and additional
name based API to detach timer from window. Added
TimerIDGenerator and exception throw on creating user timer
with same name.
* 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
Till now there was no clear way to register hanlder for message in
Service, with this approach one can register function/lambda handler
for Message which encurages handling messages in functions rather than
in hudge switch cases.
With aproach like this our Messages resembe something between Command
and State pattern. In state pattern `Message` would be `Event` send,
whereas Service would be `Context`.
