ESP32 32-bit HAL #6524
Comments
|
Did you see the "32bit-RCBugFix-new" branch? Would it make sense to merge this into that branch? If yo could you create a pull request? The reason for my questions is that there have been a few forks with implementations for 32bit based cpus. They all have been abounded. And Marlin tries to channel the 32bit effort into that branch so that we all together can maintain that single branch and won't have to deal with too many different branches. |
|
hi @JustAnother1, thanks, yes actually this fork is from 32bit-RCBugFix-new :), I should have been more specific in my post. I won't create a pull request for now, the code is too fiddly at the moment once it's okay enough to run on my own printer and if people show interest then I will. I think maintaining Marlin for 32bit code might not be too bad, the HAL in the current branch is quite straightforward and actually getting Marlin compiled for the ESP32 wasn't that bad. (okay it's far from done but still) |
|
My impression is that the 32bit branch is currently more of a "work in progress" type branch. So IMHO unfinished code should be ok if it helps move the HAL interface forward. If you don't want the pull now then that is ok, but don't forget to send the pull request once your satisfied with your code. Do you use arduino IDE to compile your code? Or do you have a build environment that is independent of Arduino? |
The code is compatible with the arduino IDE, the ESP32 guys have done a great job in getting this working. However for the dev I use platformIO (in arduino mode) as it's much more practical to dev. with Atom than the terrible IDE of Arduino |
|
I think it would be very interesting to see Marlin on an ESP. I've got one coming as well.
Possible usecase for #undef? |
|
The ESP32 actually has quite a few GPIO pins. 48 to be exact, the limitation only comes from the Wroom module. If a board would be created using the IC itself, not the breakout board the GPIO shortness might not be an issue. Though FCC certification etc. might be an issue in that case. The IC is only really getting into larger production right now so there might be more breakout boards in the future with more pins available. |
Hi thanks for the comment, actually the WROOM32 exposes most of the pins on the chip, if you look at the datasheet you sent page 15--17 you can see that quite a few pins are power related, one for RF antenna, enable pin and analog stuff. So at the end by having a dedicated module you might gain a very few pins (6, 7, might be one or two more that I missed). The main issue is that 6 pins are used for the quad-IO flash which the datasheet recommend not to use them for anything else (but they are still exposed on the module). Anyway like you say, going through the troubles of dedicated FCC certification is probably not worth it when some pins can be easily freed. I'm thinking of getting one of the TI 16 pins I2C GPIO extender for the end-stops, probe, LED anything that's not super timing critical. Thanks for the different comments, if I have some time I will try to get a bit more working tonight, at the moment it crashes in the temperature ISR after a few ticks, need to investigate. |
|
if you implement a web upload page with nice gui, you are the man.! nice work... |
|
look at that : this is an regular 3D printer fw with nice gui for old esp chip. |
|
Thats not a 3D printer firmware, it just acts as a wifi bridge that includes a web UI. Totally different beast. |
|
Hi @simon-jouet , what do you think about aprinter firmware ? |
|
I think using the ESP would be a great idea. The chip has enough power, and has the potential to run circles around the Arduino Due for example. The one downside is the low number of IO's - if that can be worked around this has the potential to be a worthy replacement for the Arduino 2560 / RAMPS1.4. |
|
Regrading low number of pins: Also there are temperature sensor Chips that have I2C or SPI. All this will probably cause bigger changes in Marlin though,.... |
|
Just $0.02 but you could also put the display on an I2C expander too. It doesn't need to be updated frequently. In fact I removed my display from RAMPS since I have no use for a built in UI. An rPi3 running a print server works for UI and it even gives a camera interface. |
|
Adding an interface like octoprint would be fantastic. The all-in-one board. About the end stops, you might get away with only one pin: if th pin goes low while your moving the Y, then it's the Y's 0. Then, move the Y 1 mm forward until it "unclick" the microswitch and move tha X to get the X's home. Etc. |
|
Do you have any progress with ramps like esp32 board? |
|
Re-ARM with a RAMPS v1.4 board is limping along. But right now it needs to have a Graphical LCD panel on it. When the Folder & File layout is updated this weekend... It is very possible it will work with a 20x4 LCD Panel also. But if it doesn't.... I'll get that fixed fairly quickly.... The first thing to get added to the Re-ARM HAL is a simulation of the EEPROM by using a file on the SD-Memory card. That will be done in a way other HAL's can also just use it. The Re-ARM board uses a LPC1768. But I expect all of the ARM flavors to start making faster progress. |
|
I do have, got quite a bit working with a ramps 1.4 and an ESP32, I will push the code at some point soon, there is still quite a few things to debug. Once the first iteration of Marlin 2.0 code is release I will bring the ESP32 changes and push it to my branch. The ESP still has some issues that won't make the merge with master very simple, I have some ideas on how to tackle them but didn't had much time to look at it. Anyway if the new code refactor is release over the weekend I might work on it next week. |
|
Btw another possibility to free up some pins is to use i2c for communicating with steppers and endstops |
Yes. But that is so slow... It kind of begs the question: Why move to a 32-Bit platform if you are just going to slow everything down with bit-banging? |
|
Using I2C based devices =/= bit-banging but I agree that timing intensive tasks like stepper control should run directly on the MCU. |
|
Also... There was talk about putting a RTOS underneath the 32-bit processors. With an RTOS there, it is easy to side step the concern because the I^2C task would be lower priority than the really important stuff. It doesn't matter if it uses a lot of CPU to talk to things on that I^2C bus. |
|
This can in part already be accomplished by prioritizing the interrupts on ARM chips. I could also see Marlin making use of semaphores at some point in the future. |
|
Using Trinamic stepper drivers with SPI like TMC2130, TMC260 or even the TRAMS board (TMC5130) would safe a lot of pins and it is fast, quiet and just great. |
|
The ESP32 also has multiple cores, so if you dedicate one core to running the
steppers, and the other to doing the communications/planning you may not need
more prioritization.
|
|
Using TMC2130 in XDIRECT mode or TMC26xx in SPI mode would need a very significant change in Marlin's design. It's only 3 pins that are needed to drive a traditional driver, so 12 for a basic machine. Marlin will be getting support for TRAMS after the 2.0 release and after I get to do some proper testing first. But I see no reason for it not to work on any 32bit MCU with an SPI interface. I was under the impression that one of the ESP32 cores handles the wifi communication and you can't program it. |
|
BTW there already L6470 drivers that supported by marlin that only has SPI interface. |
|
In stepper_indirection.h // L6470 has STEP on normal pins, but DIR/ENABLE via SPIThe current Marlin support is very basic for them. |
|
@teemuatlut You are right. With a RAMPS board you will use 3 pins per stepper. But you have to adjust the voltage manually. The TRAMS board uses XYZE-ENABLE-PIN, CS-XYZE, XYZEAXIS each plus SPI pins for all of them and the endstops are also read by SPI RAMPS vs TRAMS/TMC SPI drivers RAMBO vs TRAMSTMC SPI drivers As I see it you safe PINs using TRAMS/TMC SPI stepper drivers and it should be worth to get into it. Update to 3 SPI pins and not just 2 :-) |
|
Good to see some movement on the esp32 front. I haven't had time to even look at it yet, but it has been on the to-do list for a while |
|
I've pushed some more changes, I managed to get a print started, got the printer homed properly and issued the first few dozens of commands properly. I am now running in an issue with the ESP32 rebooting due to interrupt watchdog timeout which is caused by the processor hanging (or taking too long) while in an interrupt. The default timeout is 300ms so even if it's because it's taking too long the stepper interrupt should take far far less than this. I disabled the interrupt watchdog in esp-idf to give it a try but as expected marlin just hangs at some point. After quite a bit of debugging I think it's something to do with acquiring the semaphores, either for the timer_set_compare or from the enable/disable ISR in the stepper interrupt. I'm not too sure how to go about debugging this, so if someone wants to give it a try or have a look I would be happy to help. There is no need for a full setup, just a running ESP32 with a serial port is enough. |
|
Marlin operates in a single thread and doesn't use semaphores. Is this something you've added? The stepper interrupt blocks everything else while it runs, except the serial UART. When it exits it resumes the main loop. Same with the Temperature ISR and the Endstop ISR. The stepper ISR tries to ensure that it will give some time to the main loop and not re-enter right away. |
|
@thinkyhead I've added in the ESP32 hal some locks when entering a critical section or to disable the interrupts ( Quite a lot of the esp-idf code contains locks when accessing the peripheral to prevent both cores to access the same peripheral at the same time which I think might be where the code locks. Some of the traces i've seen when it crashes points to the |
|
Almost first complete print :) crashed quite far in (not too sure why) but anyway very happy with the result.
|
|
Getting closer! Did the board simply reboot? |
|
@thinkyhead Nope, from what I could see, it stopped accepting commands from the serial port but I don't think it hanged as I was still getting the temperature readings in Octoprint. I'm soldering a second ESP32 board right now so I can do tests on the PC with the JTAG debugger plugged in without having to connect/disconnect everything from the printer every time. |
|
Good news and bad news: good news is that I finished a print, bad news it that I haven't changed anything since the previous print...
|
|
Hmm, maybe it's just a serial communication issue. Grab the latest |
|
@thinkyhead I've figured the code hanging - it had nothing to do with Marlin. I added some very basic code to be able to do Over-The-Air firmware update and it looks like that the current code doesn't like some UDP packets that are coming in. Anyway I've disabled that for the time being and it's working perfectly fine. I've managed to print for 3--4 hours without any issues (attached below is something that was printed with the ESP) And for people that are not afraid of terrible time-lapses https://www.youtube.com/watch?v=Iuuk50c1B7E |
|
Excellent progress! |
|
Can you share how you connect the ESP32 to a RAMPS board? And is it just a normal RAMPS 1.4? I really like the ESP32 and this idea of using it to control a 3D printer, and was wondering how I can use a 3D printer shield with the ESP32 when I came across this thread. |
|
@vivian-ng The current board is independent and doesn't use a RAMPS board. You could potentially use a RAMPS but it doesn't make too much sense - most of the IO on the ramps won't be routed as the ESP32 doesn't have enough GPIOs, and the logic level will be 3.3V instead of 5V. Anyway if you still want to do so it's fairly straightforward, on the ESP32 PR (#11020) I've listed the current pin assignment for the prototype, you could just make an ESP32 board exposing the right pins for the RAMPS. You can have a look at https://github.com/simon-jouet/ESPRamps for the first attempt I've done with the ESP32, please note that the pinout is different from what it is now. |
|
@simon-jouet Thank you for pointing the way to the PR, it helps to clarify what pins go where. I guess the ESP32 has enough pins for the actual printing (min switches, steppers, thermistors, heaters) but wiring it to a LCD is going to be challenging. Or is that where all the VSPI pins come in? If I do try it out, I guess I will just take one of my breakout boards and hook it up to a breadboard first, then maybe solder something together it that works. |
|
@vivian-ng Yeah the ESP32 has just enough pins for printing and it helps to do some tricks (share the enable line for all the drivers). One of the issue is the ADC, the ESP32's ADC is quite bad, which means that at the moment I can only sense between ~25degree to 248 so okay but not great, it might be able to tweak that which would be great otherwise as backup on the current prototype I've added an ADS1015 external ADC. I've also added an SX1509 GPIO expander to add some additional IO but it's not yet supported in marlin. The VPSI pins have been exposed mostly for this and TMCs' (though they are shared with the microSD card), I was thinking if connecting an ILI9341 or something like that on the SPI bus to get a nice tft screen but that's not yet supported. At the moment if you need a screen I guess your best bet is one of the 0.96" OLED screens over I2C, I'vet got some lying around I should try. My current thinking though is that if we get the Wifi interface working properly , there isn't much point for a screen, just use an app/webpage on a phone/desktop. If you want to see the current prototype board check here https://github.com/simon-jouet/ESP32Controller the full schematic is available. You can definitely get something working on a breadboard, that's how I started to prototype, it can get quickly messy but it will work :) |
|
@simon-jouet Thank you again for sharing the link to the controller. I guess I will have to start learning how to make my own PCBs at home, but I am not a fan of SMD soldering because I don't have a proper oven at home, and soldering by hand is going to be really challenging, given my skills at soldering. As for controlling the ESP32 via WiFi, does this mean the ESP32's terminal will be accessible via telnet? Or does it have a HTTP server listening for commands from an interface like Pronterface? I guess I also need to find time to actually read the code. The code probably answers all my questions (once I figure out what all that C means...) |
|
Just a crazy idea. There is a product being sold known as the M5Stack, which is basically an ESP32 connected to a TFT, TF card reader, and 3 buttons, plus exposing unused pins. The pinout shows 20 GPIO pins exposed, but 3 of them are MISO, MOSI, and SCK used also by TFT and TF card reader. That leaves exactly 17 pins. 9 for stepper motor drivers (XYZE), 3 for endstops (one of them needs to be GPIO25, which is connected to the speaker), 2 for thermistors, and 3 for outputs (fan, hotend, heatbed). The company is already selling a module with 3-axis stepper motor drivers, but I think there is the potential to make a 3d printer module for this. The TFT can be the output display, and the buttons can be used to move through menu items. But this will require programming of the UI. Guess I should go take a look at the UI code for Marlin to see how much is already supported and what extra work needs to be done. |
|
My own version. Based on anet3d board |
|
It seems the challenge for using the M5Stack for this is the ILI9341 display. It doesn't seem to be supported right now in Marlin, so there will be a need to write a module to provide support for it. Anyone has any hints on which files to use as reference to create such a module? |
|
I think you need to use a I2s port and some shift registers to control 4 stepper motors to have the best results on terms of critical time, and free more pins for other purposes like TFT, rotary encoder, sdcard etc... If you do not know and/or never used I2s port, this is used generally to transfer audio to external DAC, to be more precise it can send a word of max 32 bit 192.000 times every second with precise timing, this can be done on ESP8266, I think even on ESP32 that has 2 DAC if i remember good. On the Arduino IDE (or PlatformIO in Arduino mode) you need just to fill a DMA hardware circular buffer and there is an instruction to check if the buffer is full, if yes just stop to fill it, wait a bit and then continue to fill, this way you have 32 or more GPIOs without use slow i2c GPIO expanders. I know you just used ESP32 ports, not slow i2c expander, but using i2s you can free all (or some) chip GPIOs. But this require a big change on the Marlin firmware. Here you can see an exampe using ESP8266. |
|
@simon-jouet I'm curious if your work on this has progressed any further? I've been tracking this issue for some time and was coming to comment about the potential to use shift registers via I2S - but @maxmeli123 beat me to it. I think two shift registers (or more) would be perfect for driving up to 5 steppers (XYZ and 2 extruders) and then using the built in PWM and ADC fuctions and remaining pins for the other features of a printer. I know the ADC is less then great but it seems like there have been several improvements both by users and by the factory including calibration data with new chips. Using only the shift registers would reduce the cost significantly as well (a few cents in bulk vs several dollars for an i2c expander) I'd be interested in sponsoring further work on this if there is interest - The stack up I'm interested in supporting on an ESP32 is: 5 steppers |
|
My idea was to use the i2s for output of steppers and the ADS1115 for ADC (4-channel, 16 bit) and something like PCA 9685 (16-channel 12bit) for PWM.With 32bit i2s shift register you get literally 32 outputs, so 5 steppers (DIR, STEP, ENABLE) will not even use half of the capacity. On top, the remaining PWMs can also be used as outputs. |
|
@sanchosk - yes you get 32 bits and 32 outputs, I think any implementation of it would easily support 32 outputs (4 shift registers) but of course it'd be nice to be able to just use 2 (by doubling the first 16 bits in the buffer, or some other method) for 16 outputs since most won't need the two extra shift registers for their printer. |
|
We've been looking at I2S with 4 shift registers, there is a discussion on going here: https://github.com/simon-jouet/ESP32Controller/issues I've just made a prototype yesterday and I will probably have a deeper look into that over the Christmas break (hopefully). Regarding the price of shift registers, my current plan is to populate the 4 of them and allow 5 drivers with separate STEP/DIR/EN and expose the rest. They are dirt cheap so having as much as possible is probably not going to be a bad thing (at least in the prototype). @sanchosk The current prototype board uses an ADS1015 but it's not optimal and I'm planning on not using it in the next revision. There a few reasons for that and i'm not going to go into details here but the ESP32 R1 is good enough with the calibration data and by changing the attenuation dynamically. I've been printed that way for many hours without any issues. |
|
@simon-jouet - thank you for pointing out that new thread, I've read the issues threads on your repos but hadn't looked in the last week - I'll follow up over there Also great to hear you've had more success with the ADC as well, that matches my more recent experiences with it as well |
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
and others
Hi everyone,
So I've forked @thinkyhead 32-bit branch and started to work on an ESP32 implementation. The code isn't functional yet, I got the very basic code working to get it compiled + uploaded to the ESP as well as basic code to handle timers. The fork is available here: https://github.com/simon-jouet/Marlin/tree/HAL_ESP32/Marlin If some people find the idea of running Marlin (or more generally a 3d printer ...) with an ESP32 feel free to contribute. I've little free time to spend on this project so it's likely to be a bit slow for now.
Why the ESP32?: It's a very very nice chip with a lot of horse power (dual core up to 240MHz), it has built-in WiFi and Bluetooth plus a bunch of peripherals and it's very cheap ~$5. I think it can be a very nice chip to use for a 3d printer and with some love that might happen... The main downside is the fairly limited number of GPIO ports but that can mostly be dealt with.
I also started drafting the circuit in KiCad to make a ramps like board with a built-in ESP32. The design isn't on github yet, I will push that a bit later. Anyway for the moment I've been trying things on protoboard it's dodgy but it looks to be working okay (the hot glue is to keep the deadbug-style wires in place):
Going back to the limited availability of the GPIO, could users give some details about what they are using? I would like to figure out what the minimum required to fit most users (pretty much should I include an IO expander by default or we can do without). For instance I've got a clone of a prusa i3 mk2 (thanks @tom3d for the build series)
As a side note: On the ESP32 arduino implementation ENABLED is defined for a pinMode, so I had to change all references to ENABLED(config) to OPTION_ENABLED(). Make sense to have the #define slightly less broad than what it is currently, but in the long term not sure how this should be dealt with.
The text was updated successfully, but these errors were encountered: