neulatuntimittari.2.06 plan for ESP32 code
26.10.23: questios that need answering
What functionalities need to be implemented? How is the new code going to be structured? What libraries do I need for the new code? How am I going to test the functionality of the new modules? How will the new code interact with the old code? Do I need to add some new graphics for the display? Do I need to expand the functionality of the push button to accommodate the new code? ie do I need a specific reset for the new functionalities. How does the push button functionality (change stylus, reset) behave with the new code?
modules I don’t think need to be touched
- sensor modules: the reed switch and IR sensor modules only describe the behaviour of how their respective ‘sensors’ interact with the world
- sleep.cpp: this only describes the internal process when the device is going to sleep mode. The call to go_sleep is made in the main loop after cleanup
modules that require revamp
- storage: since we are moving from csv to json, another module needs to be written just for handling json files. I’m sure theres a good helper library for this
- since the data is moving from just updating the time fields of the corresponding stylus, we might need a module for building the session data points from raw data
- time: because we are moving away from just having datetime counters to actual current datetime, we need logic to get the time and date via wifi
- do we make another directory for all the wireless functionality so the imports are clearer?
- yes, for the high level connection to wifi, then ssid keys stored in secrets.h (or maybe
esp_wifi_set_config()? (in which the creds are stored in esp-idf config)). I’m guessing we keep the wifi connection open once the connection is made outside deep sleep.- do we make the connection on startup before we start tracking events, or do we first start tracking events and once the first event is noted try to connect to wifi, where the connection process is bookended by either completion, timeout or event interrupt (another event happens which needs to be noted)
- the first one is easier, but the second one is better. Let’s implement the easy one for once
- do we make the connection on startup before we start tracking events, or do we first start tracking events and once the first event is noted try to connect to wifi, where the connection process is bookended by either completion, timeout or event interrupt (another event happens which needs to be noted)
- yes, for the high level connection to wifi, then ssid keys stored in secrets.h (or maybe
- do we make another directory for all the wireless functionality so the imports are clearer?