simon-jouet / ESP32Controller

ESP32-based 3D printer controller
120 stars 29 forks source link

[Not an Issue] Hint on I2S Parallel DMA and shift register stepper driving #4

Closed Aggebitter closed 3 years ago

Aggebitter commented 5 years ago

I have thinking a lot about this I2S to a shift register. The time resolution should be good and look at this driver for RGB displays: https://github.com/mrfaptastic/ESP32-RGB64x32MatrixPanel-I2S-DMA https://github.com/ESP32DE/I2S_parallel_example_drive_a_64x32_display

from thread: https://esp32.com/viewtopic.php?f=17&t=3188

Aggebitter commented 5 years ago

@Ringel Just ordered some PCB of your design and will test it out on my holiday. @simon-jouet, @vivian-ng and @Ringel. When we are talking about debouncing filters and integration to common end stops this link [https://www.facebook.com/groups/1499045113679103/permalink/1731855033731442/?hc_location=ufi] confirms official that the ESP32 is 5V tolerant on it's inputs as long as it's driven by 3.3V.

I'm thinking RAMPS 1.4! The 5V tolerance, shift registers (X,Y,Z,E0,E1), voltage dividing the analog input and adding a mosfet driver for heater mosfets and we have a direct Arduino Mega replacement. Adding additional SPI CS on GPIO 25, 26 for X,Y TMC2130 drivers or could we use IS2 for this CS as well ? (I realy need to learn KiCad soon) // Agge

Ringel commented 5 years ago

@Aggebitter 5V tolerance might be not needed, if we drive the end stops with 3V3. To debounce it even better you can rise the c9-c11 value. But You're right with the fet drive issue.

I've started r3-branch for some more improvements:

The last 2 shift registers are supplied with 5V to have enough voltage for some logic-level fets. By using 5V shift-register outputs for all fets, the remaining io's are enough for a REPRAP_DISCOUNT_SMART_CONTROLLER. I hope @simon-jouet didn't avoid using shift registers for fets for some reason.

There are some more fan fet's and wild shuffled pinout for cleaner routing.

I'll order R2+R3 the next days to test this out.

simon-jouet commented 5 years ago

For my flavour there aren't enough FET outputs - for 2 Extruders there should be at least Heater1, Heater2, Bed, Part-Fan, E0-Fan, E1-Fan, Controller-Fan - best used from the shift registers.

I totally agree with that but with the ESP it's a bit of a tricky one. If you use the GPIO pins of the ESP32 then it will work but you will very quickly run out, and if you want to do things like SPI,I2C then you won't have enough GPIO to do both, so the current version was the bare minimum to get stuff working.

The shift registers could be an option but then you enter a different problem. If you use the I2S stream like for the steppers then the issue is the latency, when you queue the operations for the steps it's not time critical but do to closed loop PID control it will likely be an issue. It might be possibly to tweak/improve Marlin to do the PWM over I2S (I don't think it's too complicated) but for the heater/bed it might be trickier (I haven't tried, it might be good enough or the current PID might be slow enough that the latency doesn't matter).

The other alternative which is a bit of a mix between the two is the way the I2S is currently configured, the lower 16 bits are part of the I2S stream and can be used to schedule the steps while the higher 16bits are based on a register so you can just set a value and it will show on the pins shortly after. This allow to get a very rough GPO expander, it works fine but it's not very accurate timing wise. The other issue with that is as soon as the 16 higher bits are used with the register instead of the DMA stream you limit the number of drivers you can run.

How about Z-Probe input - and BLTouch-Servo-Out?

There are few IO ports that are not used for anything so you can just use that, or use the second SPI port if it's not used or even the I2S port if you're not planning on using it. If we could move the FET outputs to the I2S then we would free 3 pins which would be nice (but then back to point 1).

And a display port would be the icing on the cake ;)

I think I tried to run an SSD1306 screen at some point over I2S and it was working fine. My original idea was to use something like an ILI9341 or something similar over SPI to have a fairly large TFT screen. But i'm a bit reconsidering that, with WiFi in the ESP32 it might be just better to use your smartphone as a screen... You will get a better resolution better control and less wires :)

Is the pin-mapping already fixed? Shuffling the shift-register pins (and splitting J6) could reduce some pressure from the routing.

The pin mapping can be changed without much issues, the ESP32 can be rerouted pretty much however we want so we can change pins to make things simpler. The only thing to consider are the pullups and pulldowns on the pins that can limit what we can attach to it (for instance we don't want a pullup for the heaters)

I'm thinking RAMPS 1.4!

The first board I made quite a while ago before this was for ramps, the problem is that there is so much difference in pin capabilities that half your RAMPs pins won't be connected to anything. Considering how basic the RAMPS board is I decided to just have an all-in-one and designed this controller. (I can probably send a photo of the old board if you're curious)

Adding additional SPI CS on GPIO 25, 26 for X,Y TMC2130 drivers or could we use IS2 for this CS as well ?

I haven't tried but I'm (pretty) sure you can't use the I2S for the CS pins. The ESP32 has a built-in SPI controller with DMA that will assert the CS line and do the transfers. Like I said in the first point with I2S you have some latency and very rough timing when you use the fixed channel which very likely will end up with the CS lines not being asserted when it's needed (not even close). The option I had in mind which I haven't tried would be to use a demux on the CS lines, reading the ESP32 datasheet it seems possible and it would allow 8 CS lines with only 3 pins.

If i've missed anything let me know :)

Aggebitter commented 5 years ago

Nice to be in the lopp again. My ramps idea is just based on the fact that hos many used all the features?

I am a nog fan of open hardware. And ease of use and integration. The ramps kits are dirty sheap. And if a controller card ordered from a pcb manufacturer plus components gets down to the pricing of a mega the esp32 hardware Will spread fast.

Regardin spi cs. See it as bit bang spi! The speed would not be an issue.

//Agge (on a Swedish mobile, 3 large beers, and someware in Netherlands doing afterwork. Just hate spell checking)