In various places we have a running discussion about using an esp32 as a replacement for the Arduino. I want to consolidate and focus that work in one place.
The esp32 would give us a lot more processing power and the ability to connect the machine over bluetooth and wifi. At the same time the esp32 can be programmed by the Arduino IDE making it relatively easy to use.
On the basis that one of the goals is to incorporate all functionality (web/ground control and firmware) into the esp32, one of my concerns is the flash memory space that’s available. With the current branch of grbl_esp32, there’s very little room left in the program area and spiffs area when you retain OTA capability.
I think the OTA capability is pretty awesome and would love for it to stay, but I’m concerned that we will be limiting the functionality of ‘espcontrol’ just because we can’t fit the code into the program area. If the plan is to incorporate the esp32 directly into a custom controller board, then I think using an ESP32 with a bigger flash space is readily doable and would ease the concern over what can and cannot be incorporated. However, I believe most existing users of grbl_esp32 are using 4MB flash variants so the changes/improvements we make won’t be able to be incorporated into the main branch.
In a nut shell, I’m ok with sticking with the stock 4MB flash drive and making it work, understanding that some functionality will likely not be able to be incorporated and we’d need to find some other solution.
For example, if optical calibration is something desired (in whatever form/method it ultimately is), we could conceivably decouple it from the esp32 and make it a stand alone application that would run on an RPI, windows/mac computer, maybe phone?, and communicate with the esp32 over wifi/bluetooth or something. I don’t think eps32 can run opencv which is needed, so maybe the idea would be to use the esp32 to grab a picture, it gets sent over bluetooth or wifi to something else (i.e., pc/mac, phone? cloud???) to process and it responds back to the esp32 with location information. That actually sounds pretty cool…
Finally, another possibility is to include an additional eeprom directly on the custom controller to house ‘maslow’ specific data outside the esp32. For example, there maybe maslow-specific html/js/css code that won’t fit in the spiffs partition and we can put that data there… that would allow us to maintain compatibility with the main branch.
I like this idea more and more. There’s already a build process using gulp? that combines all the html/ccs/js into a single zip file so we can simply maintain a maslow-specific web interface but have our maslow-specific code incorporated into the main branch. For those that are using stock grbl_esp32, the webserver can serve whatever is in the esp32’s spiffs, but for people using maslow, the webserver can serve whatever is in the external eeprom of the custom controller. That way, we can size the eeprom to our needs and not affect stock grbl_esp32 users. The only constraint on us at that point is to make sure whatever program (c++) modifications we make, it fits in the program data area.
I’m not too worried about trying to push our changes back up into the main esp32 repository since I doubt that we would be making many contributions which would benefit them so they probably wouldn’t be interested in taking the time to address our pull requests, and being able to remove a lot of the stepper specific code would be really great for freeing up space for our uses
I just don’t think we’d be doing them any favors with our changes, and that would leave us a lot more room to improve on the design and add our own things (like holey calibration) which they probably wouldn’t want
It would also be nice to leverage that existing stepper code to expand Maslow to work with Steppers which are more familiar to much of the CNC community. We can try to split stepper and servo(motor and encoder) code into seperate .h files and conditionally compile only what is needed. Perhaps one or the other could fit within the 4MiB flash, but if the user had larger flash he could use both. That would allow motors w/encoders for X,Y but one of those cheap prefab stepper Z axis.
Edit: This is a stretch goal. Just want to make it clear that no decision needs to be made on this. We can discard stepper code completely now, and if we want it back at any point, the GRBL code base will still have it for us to plug in when we need it.
Would it work to use microSD card instead of EEPROM? ESP32 has a native SD interface which is actually what is used to connect external flash. With all that SD space would we still need to compress the HTML? SD would be a convenient location to store all sorts of things. We could pop the SD card into phone, or computer, write some configuration files, perhaps with the help of a simple app. We could load up some G code on SD, then pop it back into Maslow ready to run our stock parts at any time without requiring any network connectivity.
That’s an option also. I think the new controller should have an SD slot for loading gcode… however, I’m concerned about reusing it for the web interface (what if someone messes it up, or loads an old sd card in, etc.) I think if we aren’t concerned about backward compatibility and the chip will be integrated in the board, I’d say we go with one with more flash ram and not worry about it.
eMMC modules have been tested to work on the ESP32 SD lines. Just in case we need non removable huge storage. Unfortunately I dont think it can be memory mapped to program space so that doesn’t solve the unavailability of large flash dev boards.
they have other people asking for using the firmware for v-plotters, so I don’t
see any reason why they should reject our changes, as long as we make everything
compile-time options so that they can opt not to use it if they don’t want it.
html is small and can probably fit in the flash, not the SD card, the SD card
would be more for pretty icons, and we can store a default one in flash to use
if the SD card isn’t there or has gotten messed up.
having a “don’t touch this at the risk of breaking your machine” directory on
the SD card doesn’t seem like it is going to be that risky to depend on.
and if it eliminates another chip (and the gpio pins it would take up, and board
complexity), it seems like a win.
Depending on a SD card that can get messed up hasn’t seemed to hurt the
Raspberry Pi that much