Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Portability between Microprocessors? #4

Open
ajquick opened this issue Jun 21, 2022 · 3 comments
Open

Portability between Microprocessors? #4

ajquick opened this issue Jun 21, 2022 · 3 comments
Labels
discussion Talk about development enhancement New feature or request

Comments

@ajquick
Copy link
Contributor

ajquick commented Jun 21, 2022

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

  • It's cheaper than most Arduino clones (nano, mini, micro),
  • It has a 32-bit processor, which may be better at driving a large number of LEDs quickly(?)
  • It has a ton of hardware features like Wi-Fi and is more next-gen than most simple Atmega chips.

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.

@ajquick ajquick added enhancement New feature or request question Further information is requested labels Jun 21, 2022
@prodestrian
Copy link
Collaborator

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
Copy link
Contributor Author

ajquick commented Jun 21, 2022

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.

@ajquick ajquick added discussion Talk about development and removed question Further information is requested labels Jun 22, 2022
@prodestrian
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Talk about development enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants