Project JEspOs: Difference between revisions
No edit summary |
(→Logs) |
||
Line 54: | Line 54: | ||
Provide a uniform way to print logs that are seen on serial or syslog. | Provide a uniform way to print logs that are seen on serial or syslog. | ||
==== Buttons ==== | |||
handle button press events with debounce, inform modules about events like pressed, released, pressed since..., released since . | |||
==== LEDs ==== | |||
Manage access to leds. Switch them off, on, blink with some frequency and x repeats, request current status (on/off and busy/free). | |||
==== WLAN ==== | |||
Auto connect to configured WLAN as STA. Also provide AP to configure new STA WLAN parameters. |
Revision as of 16:27, 6 December 2017
JEspOs
Joba's ESP OS - a kind of operating system for ESP8266 based boards.
Goals
- Describe or script installation of PlatformIO
- Install Atom rpm
- Install Atom module PlatformIO
- Install the ESP8266 core for PlatformIO
- Configure PlatformIO to contain all necessary arduino/esp libraries
- Provide a library for each subsystem an esp8266 may need to operate
- Operate means: listen for requests (from serial, web, mqtt, udp, ...), collect data, send data, operate peripherals (leds, relays, buttons, ...)
Subsystems
Design Principles
Jespos should provide a subsystem library for each topic. The libraries should be very easy to use. Each library should provide a class to provide the functionality. There should be a constructor for that class taking only arguments really needed during object construction. Then there should be an init method taking arguments to bring the class in a running state. Finally there should be a handle method, called in the main loop, that does the actual work. All methods of the class are not allowed to block. Blocking tasks are done asynchronously. There will be a worker subsystem that will help with that. All classes will avoid using dynamic memory as much as possible. Classes should be as independent from other topics as possible and explicitly name dependencies. Classes should be designed in a way that they can collect data they provide via network until a connection is available.
Topics
Persistence
Each subsystem can allocate some (small) space that should be reboot safe. It is stored in rtc memory
Sleep
Each subsystem provides a handler that is called before the system can go down. The handler returns true if it is ok to go to sleep. Awaking is just a normal reboot, so a subsystem should store everything it needs to restore its current state via the persistence module.
Update
Subsystem providing OTA update capability. Also calls the shutdown handlers before an update is done.
Communication
Subsystem to handle multiple input and output channels and dispatch incoming requests. Each channel will get its own subtopic (serial, mqtt, ...)
Sensors
Most sensors need some setup tasks, then get data either continuously or on request. Some provide an interrupt if data is ready. This subsystem provides an interface for these patterns. The details are handled in derived subtopics which will usually use external libraries for the specific sensors.
Logs
Provide a uniform way to print logs that are seen on serial or syslog.
Buttons
handle button press events with debounce, inform modules about events like pressed, released, pressed since..., released since .
LEDs
Manage access to leds. Switch them off, on, blink with some frequency and x repeats, request current status (on/off and busy/free).
WLAN
Auto connect to configured WLAN as STA. Also provide AP to configure new STA WLAN parameters.