* lay groundwork for a possible future architecture
* switch from feature opt-out to feature opt-in
* lay groundwork for a possible future architecture
* switch from feature opt-out to feature opt-in
* fix USE_RTC in variant.h for rak4631_epaper and t-echo
* ensure Screen.h is not included without configuration.h
Co-authored-by: Peter Lawrence <12226419+majbthrd@users.noreply.github.com>
Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
bogus wakes on TBEAMS because the USB->SERIAL chip pulls the RX input
to ground. This feature is no longer needed because in !isRouter
nodes we force the node to never sleep anyways when on USB power.
// this doesn't work on TBEAMs when the USB is depowered (causes bogus interrupts)
// So we disable this "wake on serial" feature - because now when a TBEAM (only) has power connected it
// never tries to go to sleep if the user is using the API
// gpio_wakeup_enable((gpio_num_t)SERIAL0_RX_GPIO, GPIO_INTR_LOW_LEVEL);
oh - I think I found the problem (probably)! we were isolating gpio12 (which isn't used on other boards) to save power during sleep. gpio12 is the button for this board. @thomslik would you mind pulling this commit and seeing if it works better?
Note - we do this not by using the uart wake feature, but by the lower
power GPIO edge feature. Recommend sending "Z" 0x5A - because that has
many edges. Send the character 4 times to make sure the device is awake
* preflightSleep, notifySleep, notifyDeepSleep now allow arbitrary
drivers/devices/software to register for sleep notification.
* Use the proceeding to clean up MeshRadio - now the mesh radio is more
like an independent driver that doesn't care so much about other systems
* clean up MeshService so that it can work with zero MeshRadios added.
This is a prelude to supporting boards with multiple interfaces (wifi,
extra LORA radios etc) and allows development/testing in sim with a bare
ESP32 board
* Remove remaining ESP32 dependencies from the bare simulation target
this allows running on anything that implements the arduino API
because the ESP32 implementation will be different from NRF52
to make this possible I needed to decouple knowlege about bluetooth from
our mesh service. Instead mesh service now uses the Obserable pattern
to let any interested consumer get notified of important mesh changes
(currently that is only bluetooth, but really we should do the same
thing for decoupling the GUI 'app' from the mesh service)
@girtsf would you mind reviewing my Observer changes? I haven't written
C++ code in a long time ;-)
* to allow changing to new mesh transport
* to allow a different chipset for the radio
* to allow testing on hardware with a SimRadio
* new "bare" build env for a devboard with virtually no hardware
* make buttons optional
Thomas GöttgensandGitHub
lewishe
Ben MeadorsandGitHub
Sacha Weatherstone
Mike Schiraldi
Jm Casler
Kevin Hester
Garret Kelly
grcasanova