Over the past few weeks I’ve been fascinated with the idea of re-designing the Maslow electronics to use an ESP32 module instead of an Arduino Mega. There are some compelling advantages:
Arduino Mega costs $45 or $10 for a cheap clone. ESP-WROOM-32 module costs $3.50.
ATMega2650 is clocked at 16Mhz, ESP32 runs at 40Mhz or higher.
ESP32 has built-in WiFi and Bluetooth support, opening up new possibilities for wireless control.
To top it off, the Arduino environment has already been ported to the ESP32 so I don’t expect it to take much work to get the existing Maslow firmware to run on it.
I’ve looked into various versions of ESP32 for the Maslow, and the major obstacles are
number of gpis required
reliance on TimerOne library
encoder routines written in assembly to handle interrupts.
None are insurmountable. The lack of gpios would mean having fewer AUX pins, and perhaps changing the PWM-to-gpio routines (see latest Firmware release as a partial example) to use fewer pins. The encoder interrupt routines currently use assembly for speed, the ESP32 is enough faster that they might work in C++.
I also looked at the Teensy3.5 and Teensy3.6 which offer more gpio as well as on-board SD storage. Significantly more expensive, though . The Maslow firmware doesn’t need too very much changing to compile for one of those.
Maslow uses this clone, inexpensive but well made and reliable. At $13, not a bad deal.
The ESP32 is a development platform. It is not stabilized at this point. It’s considered an experimental stage still being developed. Their are parts that are not working in the Arduino IDE. It is a very powerful platform but it has many cheviots to specific uses. I’d say it’s not ready for prime time yet.
To top it off, the Arduino environment has already been ported to the ESP32 so I don’t expect it to take much work to get the existing Maslow firmware to run on it.
Okay, I take that back. It will take a fair bit of work. Still promising though.
Fewer AUX pins is a good point. I didn’t realize how useful they were until you pointed it out and I did a bit of digging. Also the ESP32 pins aren’t 5v tolerant and could be more sensitive to transients, etc.
The Maslow board will run from the 3v3 logic supply that most ESP32 boards provide. I spent some time getting the firmware up on a Sparkfun ESP32 Thing, it can be done. The Teensy boards are easier to port to, though - the guy who designed them wrote the TimerOne library that the Maslow uses, and he has a version of that for the Teensy3.x boards. They have plenty of gpio pins, too.
I’ve looked into various versions of ESP32 for the Maslow, and the major obstacles are
number of gpis required
reliance on TimerOne library
encoder routines written in assembly to handle interrupts.
None are insurmountable. The lack of gpios would mean having fewer AUX pins, and perhaps changing the PWM-to-gpio routines (see latest Firmware release as a partial example) to use fewer pins.
TheESP32 has far more GPIOs available than the arduino
The encoder interrupt routines currently use assembly for speed, the ESP32 is enough faster that they might work in C++.
something to do with operating at 240 MHz and having two cores available instead
of operating at 16MHz
if needed, the assembly could be ported, but I don’t expect that it would be
needed.
a bigger problem would be that the ESP32 doesn’t have EEPROM, it has flash, so
things would have to be tracked a bit differently
We’re comparing the Arduino Mega with boards based on the ESP-WROOM-32, which make up almost all the ESP32 market right now. The Mega has many more gpios available, count the pins.
The EEPROM library was ported to the ESP32 Arduino environment about 6 months ago, and works with the Maslow firmware code without modification. It leaves room for over-the-air updates and a separate file system besides. Not enough room to store a 60,000 line gcode program, though.
You don’t know what head bashing is until you start debugging multiprocessor real-time code. It’s even worse when your 50MHz 68030 VME board has an intermittent off board test and set and after you isolate it on a bus analyzer the vendor insists it’s Motorola’s bug, not his.
Usually one of the ESP32’s cores is dedicated for the wireless stack and the other one is for application code. Doing it that way let’s you write real-time code without fear of interruption from an incoming wireless packet.
This is exciting! How much work do you think was left?
Not a bad idea if it comes to that. A $12 price increase isn’t going to make or break my decision to buy a Maslow. I guess it depends on how much time we’d save vs running everything on the ESP32.
The current generation of Maslow PowerControl boards need 15 pins (9 output, 6 interrupt input) for motor control and four pins for version detection. That’s without any AUX pins. That’s a tight squeeze for any available ESP32 board and some compromises would be needed. I got this far trying to wedge the Sparkfun ESP32 Thing onto the Maslow PowerControl board, with a possible connection schema for the Maslow motor signals in blue:
Many of the ESP32 pins that I avoided need to be in special states at power-up, or have other duties or limitations beyond pure gpio. When I compared those limits to the Teensy3.5/3.6, I put it aside.
I spent more time on the Teensy3.5/3.6 boards, made a carrier to connect a Maslow PowerControl board and have had a first go at bringing the firmware up on it. That seemed like an easier way to get higher speed, with fewer trade-offs.
using one of the thing/feather/etc boards that they have stuffed a ESP32 on is going to be very limiting. the raw ESP32 castelated module is not nearly as limiting
The ESP is more powerful and includes wifi and bluetooth
the teensy is designed to be closer to a drop-in arduino board replacement.
if it was me, I’d be looking really hard at the ESP32, and not in any of the
plugin modules, just as something soldered to the motor controller
board (eliminating all those connectors saves cost and space )
. The Maslow firmware doesn’t need too very much changing to compile for one of those.
)