gbfans / afterlife-lightkit

This is the code repository for the Afterlife Light Kit, coming soon!
GNU General Public License v3.0
1 stars 0 forks source link

Portability between Microprocessors? #4

Open ajquick opened 2 years ago

ajquick commented 2 years ago

For this version of the hardware I have decided to use the ESP8266 as the microprocessor. The main reason for that was the following:

That being said. There will only be a few things that the ESP8266 can do that the Arduino chips cannot and that is primarily running the web server and Wi-Fi connection. I think it would be ideal to allow for portability between boards so that an Arduino could be used if need be.

It would be good to have the settings stored and accessible with the ability to change them over the command line.

I've actually already written two utilities for a program that are run on the ESP32 to change settings:

https://github.com/CNCxyz/Grbl_Esp32_Utility (Qt program, EXE) https://github.com/CNCxyz/Grbl_Esp32_Web_Utility (Web utility)

The web utility is what I would focus on and could adapt. It allows someone to plug their device into a computer and visit a web page in Chrome. Chrome can communicate with the device over the serial port and the configuration can be read and written back without downloading anything.

That would help people that may not want to go through the hassle of downloading Arduino and compiling customizations.

I think having the ability to disable Wi-Fi completely using the serial port would be ideal as well. It would help speed up the boot time.

prodestrian commented 2 years ago

Just leaving this note for later, it should be possible to add conditional includes in our Arduino code which only require/enable certain features based on the board type. So if you're compiling for an ESP8266 it will include the Wifi features, otherwise (eg Arduno Nano) it will just use all the configuration default values.

We'll want a default config file (eg config.h.default) which users clone to config.h and modify all the settings (Cyclotron speed, mode, directions, etc) as needed. We'll want config.h gitignored too. This way users can still git pull to get the latest features.

We may need to implement a Configuration provider which is intelligent enough to load settings from the three different scopes:

  1. From the Wifi-defined configuration (if enabled)
  2. From the user-overridden config.h
  3. From the hard-coded default value

One thing I'm not sure about is where we'll actually store this configuration (it may need a separate Issue to track this). I know the ESP8266 has an onboard EEPROM, but it has a limit of 100,000 write cycles. Is that enough? If we're only writing to EEPROM when Configuration is changed, it should be fine (you could change your CYCLOTRON speed 25 times a day and still get 11 years out of your device). But if we're not smart about it and we're constantly writing to it, we're going to burn out the board. The alternative is to write to the SD Card. I personally prefer the sound of this, but I don't know if this will introduce undesirable latency, or how difficult it will be to read/write config files to the filesystem. I'd hope that there's some libraries around to handle this already, but I don't know how lightweight they are.

ajquick commented 2 years ago

I would prefer the EEPROM approach personally. I don't think we'll have a problem with that many cycles. These D1 Mini boards are about $3-4 on Amazon, so not bad.

For the web server portion, I think we will need to implement a LittleFS (file system) to store a HTML page, CSS and could potentially also store the config there as a JSON file. Space will be tight, but I'm sure we wouldn't be using more than a 1/4 of the memory space for that.

Definitely plan on having a #define BOARD = ESP8266; or something at the top to allow for the includes to be changed.

prodestrian commented 2 years ago

I've done some testing and added some notes in #5 related to the filesystem and webserver.

Apparently we can use this to detect the device automatically, so users won't need to change anything themselves when compiling:

#if defined(__AVR__)
// AVR specific code here
#elif defined(ESP8266)
// ESP8266 specific code here
#endif