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.
The first plan of attack is to use the existing esp32 port of GRBL (https://github.com/bdring/Grbl_Esp32) and modify it for use with a closed loop control system.
I have been playing around with reading the encoder values and creating an asynchronous web server on the esp32. Here are the files I have been using.
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.
having an external SD card so that we could load/save gcode on that rather than
have it trickle in a line at a time or have to get stored in RAM would be a good
idea.
This could potentially eliminate the need for OTA upgrades (save the new
firmware file on the SD card under a specific name, the system boots, sees the
file, and upgrades itself)
look at whatās being done with the current generation of 3d printers and how
they get upgraded.
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
