Controlling a RepRap with ESP8266 and no Arduino

Thanks!
But I don't even know how it really performs.
Being a programmer, I don't have any oscilloscope or that sort of stuff. LEDs are my best feedback. (And the serial output)

The Marlin config is untouched for me except the board set to BOARD_ESPEXTRA, and I changed the baud rate to 115200. Nothing else yet.
"pgmspace.h" needs to be hacked, because of the PGMSPACE and PSTR macros give compiler errors.
I've read somewhere that it became a problem since a specific version of the IDE.
But setting them simply to:
"
#define PROGMEM
...
#define PSTR(s) (s)
"
won't cause any problems, there is plenty of RAM even like this.

I could not test it with stepper motors for now.
There are definitely problems with that, because in the Marlin logs there are many lines stating that it wants to change the step pins too fast.

Edited 1 time(s). Last edit at 11/18/2016 05:47AM by Hubberthus.

Nice to hear that, Hubberthus.

If you are using I2S shifter output you may choose to use software PWM. You get 1/192kHz resolution for both pulse width and period. That means 193 possible values for 1kHz PWM, or 193 positions between 1ms and 2ms for a 50Hz servo PWM. I actually implemented this as a class, but had little spare time to work on it further...

I kinda wanted to show off with 32 servos, but the output connectors of the Shift-Out board are not right for direct servo connection (GND and pulse are swapped, if I remember well). Also I don't have 32 servos, just 8.

That sure would be a show-off!

Hmm, I did not think in servos, only steppers. Haven't ever used any servo motors actually.
From what you wrote maybe they would are a better choice to control, as 1 kHz or 50 Hz is way less than what steppers need.

If I understood correctly from the Marlin's code, 10 kHz per motor is the allowed maximum. (More advanced boards go further, Smoothie V2-pro will even go up to MHz)
I'm now doing a 24-bit 10 MHz SPI transaction every single time I change a pin. And 18-bit 4 MHz SPI transaction nearly every 2 milliseconds for analog input.
Having 3 axis (most of the time only 2 of them are moving, but with a delta it is 3), and for example 2 extruders, then the analog inputs from heaters, I am pretty sure that it will be too much for my blocking software SPI-way. And there is also the thing that WiFi and SPI flash reading uses up resources, I only get what the ESP gives me. HSPI is muxed with the flash-reader SPI, and that has higher priority.
Can't wait to push it to it's limits and see it crumble!

Maybe putting all motor step pins on one port and then batch-setting them would help a bit.
And if that is still not good, I should get down from the skies and try it out with servos, maybe that won't be too much.

And if that still will give me a headache, then well, I2S+servo is the way to do it.

@Hubberthus - you probably did not understand correctly.
The current i2s implementation works with 192kHz - so that means, you can control 16 steppers (step + direction) out of it right now with 192kHz update frequency (19x more then ATMega based chips).

@rklauco - Hmm, I shouldn't think when I'm tired.

I still haven't attached any motors to it, because I wanted to show off with the WiFi controls (ESPrinter code merging), and guess what... It crashed with WDT when I tried to open a file from SPIFFS (index.html).
It was a rough ride, and the thing is, when I commented out the usage of timer0, it appeared!

It is actually pretty obvious, since timer0 is actually the system timer, and timer1 is meant for mortals.

Either find a way to use SPIFFS+timer0 together, or I get stuck with only timer1. And I do not want to put the webpage on an SD card, because it can be removed, and has slower and less reliable access.

You don't need any timers for I2S-based PWM generation. Just do something similar to what is below while building the I2S buffer data. Set duty=0 for 0%, and duty=period for 100%. The period variable is measured in 1/192kHz time increments.

// Create a down-counting triangle wave.
if (--counter == 0) counter = period;

// If the PWM should be active then set the bit in the I2S output data.
if (duty >= counter) out |= PWM_BIT;

I suggest a down-counter because it is faster than up-counting. Actually it is the compare with zero that is faster than comparing to period, as the second would need to be loaded from RAM every time. It is not crazy faster, but at 192kHz every bit counts.

Each PWM can have an independent counter, duty and period too.

You don't need any timers for I2S-based PWM generation. Just added sample software PWM and Sigma-Delta modulation to the github repo. Also added example code to reprap_core.cpp (compiles, but untested).

buffered_pwm.h: Software PWM implementation. Buffered means it only updates duty on completed cycles, so that there are no glitches.
sigmadelta.h: Sigma-delta modulator. The step() function returns true d every T samples. Frequency is variable and much higher than PWM, which better for R-C filtered DACs, but probably too fast for high power loads.

Both PWM and sigma delta are missing some optimizations...

• PWM counter should count down and compare to zero. Saves loading period from RAM every time, spares one register.
• PWM shoould probably allow multiple PWMs to share a common counter. Saves more CPU registers and RAM loads.
• Sigma delta should loose the period variable and use integer overflow. Saves another RAM load, and behaves as if period==1<<32.

I will probably see to those things later on.

Edited 1 time(s). Last edit at 11/21/2016 01:30PM by lhartmann.

@lhartmann - Yes, that's true, I2S doesn't need timers for PWM generation.
And even without the optimizations you listed it is way more fast because of the HW support for it.
Also, you don't have the additional Arduino compatibility layer which slows things down for me.
So that's pretty neat what you achieved!
That native approach could lead to the best firmware for the ESP. Any virtualization layer between a firmware and the SDK slows it down.

However timers eventually will be needed for you too, because with their help some "parallel processing" can be done.
If you look at the target, a 3D printer firmware does lots of things. Putting all of them in one big main loop is not the best choice.
At least one ISR is needed for the motor control, it has the topmost priority above all.
In Marlin the ADC has also its own 2 millisec update period timed ISR. This is what I used with timer0, and caused me a headache.
I got rid of it, and am calling it now from the main loop if the time from last update is at least 2 millisecs.
This of course is not good, update period is wibbly-wobbly and always above 2 millisecs, but will do for now. All I need is a proof-of-concept.

Something else:
In the last couple days I've been hacking in the ESPrinter firmware's code into the already hacked up Marlin.
JSON caused another small headache, because the ESPrinter webpage is using AJAX with JSON, which is a quite reasonable choice.
Did you know that the only firmware supporting JSON-style printout is RepetierFirmware? And that is not even a fixed standard, according to the Wiki.
Anyway, I've put in a JSON-style status output to Marlin so it can communicate with the JavaScript.
Next step is taking the board to a 12V source, connect some steppers to it, and control from a smartphone through the webpage.
Controlling the blinking "fan LED" via the webpage is tried out and working.

Quote
Hubberthus
Did you know that the only firmware supporting JSON-style printout is RepetierFirmware? And that is not even a fixed standard, according to the Wiki.

Repetier also supports json output and it is being added to Smoothieware. Json is a self describing format, so it is extensible instead of being fixed.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

My code uses semaphores, queues and threads instead of interrupts, buffers and ISR/main.

I am using freertos, take a look at it. That RTOS is amazing, you can have several tasks all running parallel and coded as of they were all alone in the mcu.

You also don't need an interrupt for the motors because the I2S buffers are already output at a fixed frequency. You can have 192kHz accurate sample rate with only one interrupt every 10ms, if you do desire.

Really, check FREERTOS, realtime operating systems are great!

@dc42 - Yes, that's it! RepRapFirmware (In my last post I meant this, not Repetier) and is under development in Repetier and Smoothie. Officially, there is only one listed here:
http://reprap.org/wiki/G-code#M408:_Report_JSON-style_response
JSON is a very good format, and yet it is barely supported.
And there is the thing, that if you look at this page, you can see an example of this, with field meanings described.
I've searched if anybody tried to implement M408 into Marlin, and got a hit. According to the Wiki page it was good, I just had to fix some issues with renamed variables, since it was made for an older version of Marlin.
Then guess what? The ESPrinter webpage complained about missing "coords" field. You can imagine the surprise when I went to the following link, which is at the bottom of M408's description:
http://reprap.org/wiki/RepRap_Firmware_Status_responses
Soooooo, it was practically thrown out, and completely restructured! And there is a note, that it's not officially released yet. Also, I had to look into the JavaScript to see what it does with some fields, because I couldn't really tell what are they really for, as there are no descriptions for them in the Wiki. And how is the "extended config response" accessed? I now use M408 S4 for that, but is that ok?
This is what I meant by this not being "fixed". What stops anybody from doing further restructuring/renaming to this?

@lhartmann - Well that makes things different, and another good reason to use that instead of the Arduino core. I'm stuck now with ISR+main loop, and having only one timer ISR sucks.
Still, I'll go now with the Arduino+Marlin+ESPrinter combo. It's no use in starting to create an ESP firmware for ESP8266 when we have now the ESP32.
This "fun with ESP8266" is pretty good to reveal what problems I can run into with an actual ESP32-exclusive firmware, and what to use.

Quote
Hubberthus
It's no use in starting to create an ESP firmware for ESP8266 when we have now the ESP32.
This "fun with ESP8266" is pretty good to reveal what problems I can run into with an actual ESP32-exclusive firmware, and what to use.

That is the point of an RTOS, we are not creating firmware for ESP8266, instead we are creating firmware based on FreeRTOS. That makes it incredibly easy to port to other systems that run FreeRTOS, including ESP32 and ARM.

For porting all you need to do is write new driver threads (small percentage of the code). Also note that, with exception of the i2s dma buffering driver, everything else is ready to use on other systems. If you get a system with no I2S then you can simply write a fast timer interrupt and output a sample yourself, and that is it.

I know FreeRTOS has a Linux based emulator... I wonder if the emulator actually runs realtime on Linux PREEMPT_RT... That would make it easily portable to *pi boards too.

Not sure about the status, but this is from 2012... RPi FreeRTOS

@lhartmann - Weeell... It surely can work, I won't say it can't. But I'll rather stick to ESP32 when it comes to creating a firmware for the "family".
The main reason is that looking at specs it is clear that ESP8266 was made to be a slave module. On the other hand, ESP32 was made to act as a master itself.
I won't throw away ESP8266, just won't be my focus. (When I will finally, hopefully receive my module sometime in december...)

A FreeRTOS-based firmware would be an interesting thing. I've searched now a bit, and it's not really used, as far as I see from my quick Googling.
I've found somebody who made one as a 3rd year project in 2012:
https://github.com/mossblaser/makebed

As a matter of fact, I'm actually working with a realtime OS (ENEA's OSE) here at work, so I know this and that about the topic. Only thing is that it's a bit bigger (multi-board, multi-core with PowerPC, ARM and DSP cores, all of them talking with each other on one huge RTOS system)

All-in-all, you can count me in.

Quote
Paliap
The program then runs round the polygons from quad to quad linking the ends up.
When you now have a set of polygons for RepRap to outline and to fill in. But a list of line segments is a very non-robust representation of a polygon for operations like zig-zag infill, and also it's hard to offset. You need to offset the polygons to make smaller ones inside because the stream of polymer is not zero thickness, so - for example - you need to run the write head slightly inside the polygon you're going to create to outline it. Then the zig-zag infill needs to be a zig-zag in a smaller polygon inside the first offset polygon too.

How did we get on to writing a new slicer? Sounds like fun, just not sure how we got here.

Quote
JamesK

Quote
Paliap
The program then runs round the polygons from quad to quad linking the ends up.
When you now have a set of polygons for RepRap to outline and to fill in. But a list of line segments is a very non-robust representation of a polygon for operations like zig-zag infill, and also it's hard to offset. You need to offset the polygons to make smaller ones inside because the stream of polymer is not zero thickness, so - for example - you need to run the write head slightly inside the polygon you're going to create to outline it. Then the zig-zag infill needs to be a zig-zag in a smaller polygon inside the first offset polygon too.

How did we get on to writing a new slicer? Sounds like fun, just not sure how we got here.

Paliap's post bears all the hallmarks of spam except that is doesn't have a link. I've just reported another of his posts that does have a link as spam.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Ah, cut &paste from the reprap wiki. Guess you're right.

Quote
Hubberthus
@lhartmann - Weeell... It surely can work, I won't say it can't. But I'll rather stick to ESP32 when it comes to creating a firmware for the "family".

ESP32 is out already, both as ESP12-like and NodeMCU-like. For that price, though, we would be better off with an Orange Pi Lite. The advantages of the *Pi would be proper fast SD, filesystem, webserver, and we would be able to run octoprint. All we would need to code is a gcode-capable, I2S, motion-control backend. Apart from timelapses, though, we can do pretty much everything on an ESP8266.

I kinda loved the Orange Pi Zero form-factor, that would be great for an embedded solution and is pretty much the same price of a NodeMCU. Unfortunately the Orange Pi Zero's I2S pins are not available (used internally for wifi-enable and something else). :-(

=== On a different subject ===

I was developing/testing some gcode compression code and got some nice results: 5:1 compression on average, 9:1 best case. Braq's wings are my largest GCODE so far, 64MB, 24h print, and compressed they drop to just 12MB. The algorithm is simple enough to run on the ESP8266, and with 3.5MB to spare on NodeMCU we could drop SD cards for most GCODE under 20MB (not Braq's wings, though).

For larger prints maybe use a WEBDAV server somewhere else, and use the flash as a 3.5MB buffer? There are several free servers, box.com gives you 10GB free, or use your owncloud. A dead internet connection could mess the print, but at least you get ~7h to fix your connection before the buffer runs out.

Flash endurance is not really a concern on such an application. We may do simple circular buffering of the 3.5MB (perfect wear leveling), and the flash is rated for 100k cycles, which means we can print 350GB of compressed GCODE before the flash wears out. A few lifetimes, I guess. :-)

Also Sprite_tm made a micro gameboy color based on ESP32, but he replaced the 4MB SPI flash with a 32MB one so he could store ROMs. Such a flash chip goes for $1.3 and is readable directly via the ESP8266 flash APIs, so it could be a nice alternative to SDCARDs. Assuming compression, 32MB is 2.5 times my largest print ever.

Quote
lhartmann
ESP32 is out already, both as ESP12-like and NodeMCU-like. For that price, though, we would be better off with an Orange Pi Lite. The advantages of the *Pi would be proper fast SD, filesystem, webserver, and we would be able to run octoprint. All we would need to code is a gcode-capable, I2S, motion-control backend. Apart from timelapses, though, we can do pretty much everything on an ESP8266.

I kinda loved the Orange Pi Zero form-factor, that would be great for an embedded solution and is pretty much the same price of a NodeMCU. Unfortunately the Orange Pi Zero's I2S pins are not available (used internally for wifi-enable and something else).

There is also another board NanoPi Neo that has a similar price.

Edited 1 time(s). Last edit at 11/30/2016 11:59AM by xebbmw.

Quote
xebbmw
There is also another board NanoPi Neo that has a similar price.

When I saw the NanoPi Neo at aliexpress it was $30+, so I disregarded it. You link says $7 for base, +$2 for 512MB RAM, +$7 for wifi. Cheaper, but still way more than the Oranges.

Either way, checking this schematic I found that the I2S pins (pcm_*) are not all routed on the NanoPi Neo. Like the Orange Pi Zero it may still be useful if you go the Linux+Preempt_RT way, but not for I2S.

@lhartmann: Do you think it would be possible to have SD with i2s running? I would love to have the web interface in internal flash, but the G-code would go to the SD. Honestly, considering the speed of the printer, even slow "SW SD" should be enough to preload the next 16-32 moves in a single batch...
What do you think?

Slow SD interfaces are what we are trying to avoid, not because of the print time but because of the upload time. I just don't want to reach into my printer to take the SD out and pray my USB SD reader works, that's why I was looking into this. Your commenton SW SD made me realize that we could try SD over I2S (word-clock as SD-clock, 2 shifter outputs as CS and SDO, one shifter input as SDI), but this would yield 192kb/s, or 24kB/s max. OK for printing, bad for uploads, and useless for HTTPD.

I believe we can use an SD pin sharing the main SPI, as the HSPI can be internally remapped there. We would just need little glue-logic to hold SD clock still when the main SPI takes over to the read the program flash. I have not tested this yet.

P.S.: Hacked together a webdav client on the esp using esp-open-rtos, lwip and mbedtls. Due to ESP's memory limitation mbedtls can only handle packets up to 4kB, but box.com (and as far as I can tell all servers using openssl) may send up to 16kB, so the connections fail. I worked around it using ranged http requests for downloads, but I can't get ranged directory indexes. I am considering this a wall, at least until openssl servers start supporting negotiable smaller frames.

@lhartmann:
Yeah, I saw sometime ago the Orange Pi, and was considering about buying one to try out, because it was so cheap. Maybe someday
And yes, I know ESP32 has been out for a while, but as I wrote earlier, my colleague who pre-ordered it long time ago did not receive it. And unfortunately I've ordered my ESP32 module from SparkFun back in October, and because of a stupid law they couldn't ship it until November 28th to my country. So it is still incoming...

I can see a bit of an obsession towards I2S in you.
It's like my obsession towards ESP32, so we're even.

And by the way there are 2 available I2S interfaces on ESP32, so that makes it also a compatible platform for your I2S-based shift register solution.
What I'm also very very curious about it is the HW PWM support. Up to now I've only found details about the LED controller in it, but they wrote in documentations that PWM for motor control is also available. And I can see their control registers, but found no further details about the usage yet. (LED control support is impressive by the way, even has HW fade-in fade-out capability)

And the official SDK for it is FreeRTOS-based!
The modularity of an RTOS can make it possible to easily interchange motor control modules. I2S on ESP8266 or ESP32, PWM on ESP32, or something else on another platform, you name it.
Just the interface standard needs to be made with caution, then anything can be connected to it.
It also is a good way for module level testing. Start up the module in a virtual environment, connect to it via the interfaces, then do the automated testing.

Regarding the SD-card problem:
Using the main SPI pins of ESP8266 is a pretty brave act. Moslty what I've found about it is: "Don't try to use it!"
It's because that line is particularly for the SPI flash, or to be used as SDIO with a master MCU to acieve faster WiFi access than via UART.
This is why HSPI was made availabe, muxed together to the SPI line, and the HW does the timing for you. Unfortunately however, those pins are also I2S pins...
If you can harness the power of primary SPI, and do the timing from SW so you don't interfere with the SPI flash, then you're a master Jedi, and I'll bow down before you!

There is another thing with the SPI SD card. It is somewhat unreliable. I've had some bad experiences with it, and my colleague also got his SD card corrupted on an MKS sbase v1.2 (Smoothieware). He told me that he saw on forums other people also complaining about this. Native SD card access is the answer to it, and Smootheboard v2-pro will have that.
Have this also in mind, when trying to figure out the SPI SD access. Because even without writing anything on it, the printer corrupts data on it. I once even had to completely reformat a card.
(And yes, ESP32 has this, too. According to docs, up to 2 SD/MMC can be attached. However I didn't see any example or tutorial on this yet)

Regarding the SPI flash:
ESP8266 can have up to 16MB flash attached to it, as far as I know. ESP32 also has this 16MB limit, but you can connect up to 4 flash ICs to it.
So with a bit of soldering, having the rigth IC (like the one you've linked), the ESP8266 can have 16MB flash, and the ESP32 4x16MB.
I've been thinking about using the flash as a temporary storage for gcode, like you've did. One model at a time can be stored there, and with this caching some info can be stored like number of layers, and so on, to calculate and show more accurately the printing progress.

G-code:
Whoah, a gcode compression! Another fine topic.
There is this ".compg" thread in this forum, and the RepetierFirmware also has its own binary format.
This is something that shoud really need a good standard!
I also was thinking about compression. But I've thrown it out of my head.
With everybody creating their own format, it will soon be a huge mess. I don't know how the standardization procedure should be done, but gcode have been used for some time now without any complains.
The only problem now for us is that it is text-based => Uses way more space than a compressed/binary format.

----

And of course in the meatime I was working with my ESP8266+Arduino core+Marlin+ESPrinter+DuetWifi combo. I had to merge in the DuetWifi's webpage because ESPrinter is 1 years old, and its code is buggy.

It creates a WiFi access point, then I can control it with my phone. Fan PWM, thermistor input, and endstops like a charm. Only stepper motor timing is incorrect, I'm struggling with it. I knew that with this approach it can't do its best, so nothing new for me. Also, the stepper motor I'm working with is faulty. Maybe a better motor would show better results.
The LED attached to the step output pin shows that it is really working. And the motor is moving in the right direction, but with glitches.
Also, sometimes I get a WDT reset.

I think this whole project shows, that the concept is plausible. I can actually control the ESP8266 throug WiFi on a webpage that is on the ESP. It was funny when a colleague of mine asked if the thing was a 3D printer controller App on my phone. I said nope, It's just a web browser.

However I won't continue the Marlin port, would be just a waste of time.
When I will receive the ESP32, and the holidays are over, then I will continue with digging into the module.
And the FreeRTOS-based modular 3D printer firmware should be started out somehow.

Quote
Hubberthus
Regarding the SD-card problem: (...) If you can harness the power of primary SPI, and do the timing from SW so you don't interfere with the SPI flash, then you're a master Jedi, and I'll bow down before you!

Challenge accepted! :-D

Quote
Hubberthus
Whoah, a gcode compression! Another fine topic. (...) With everybody creating their own format, it will soon be a huge mess.

Yup, I know of both those formats. Just let me make it clear that my compressed format is not intended to replace GCODE as an interchange format, it is just designed as an internal storage structure. The firmware is supposed to get ASCII GCODE input, compress it (either via browser-side javascript or printer side C++), and store it in flash. It is never supposed to be downloaded or converted back to ASCII GCODE. Let me clean the code f first, then I'll release it on github.

Quote
Hubberthus
And of course in the meatime I was working with my ESP8266+Arduino core+Marlin+ESPrinter+DuetWifi combo. I had to merge in the DuetWifi's webpage because ESPrinter is 1 years old, and its code is buggy.

I'm not familiar with most webpage technologies... How hard was it to port DuetWebControl? Is it possible to get it working on top of FreeRTOS, possibly with ESPHTTPD?

Quote
Hubberthus
However I won't continue the Marlin port, would be just a waste of time.
When I will receive the ESP32, and the holidays are over, then I will continue with digging into the module.
And the FreeRTOS-based modular 3D printer firmware should be started out somehow.

Definitely. We should probably draft a realtime specification for this system (threads+queues+semaphores).

Gcode:
Pretty good answer.
Have the compressed gcode only for the flash-cache, but still work with the original gcode with the outside world. Nice.

Web control:
It wasn't that hard, because the ESP8266-specific part was already in ESPrinter, and the webpage was there as well, but with a sloppy javascript, which gave me an error when trying to create a slider... But the original DuetWebControl is up-to-date and working.
The webpage itself is very nicely done, I didn't modify anything in it.
Of course the webserver was written using ESP8266 Arduino core libraries, but the Arduino core is just a wrapper around ESP's original functions, it can be removed. The rest is pretty easy.
The hardest part in all of it was to insert the JSON-style status output to Marlin's code.

Spectification:
Hardest thing ever! Writing documentation, instead of writing code

Ihartmann

Really impressive work on the motor controller.

Was wondering if you had come across the Klipper firmware forum link? It splits operation into two tasks, one running python on the host to interpret gcode into stepper moves, and the second running on the MCU.

Was thinking the Python part could be adapted to run on the ESP and interface with your motor controller.

Quote
lhartmann
I believe I found a way to use just an ESP8266 module to control the stepper drivers directly. This post explains how.

Background:

1. Other projects show how to use ESP01 as a wifi-serial bridge to the arduinos, but serial is still a bottleneck and wifi uploads are impractical.
2. Altough ESP8266 does 160MHz at 32bits processing (versus 16MHZ 8-bit from most Arduinos) it has insufficient realtime GPIO for controlling printers.
3. Raspberry pi shared the realtime gpio limitation, but wallacoloo still did reprap control using DMA. Nice! [www.youtube.com]
4. CNLohr did a really cool WS2812 led driver (weird one-wire serial protocol) using ESP8266 I2S audio output and DMA. [www.youtube.com]
5. I2S and SPI look very much alike, and SPI can control shift registers. Hey! Opportunity!

I got the code from CNLohr on github, modified it to output a 32 bit counter (16 bit left + 16 bit right channels) via a circular DMA buffer, and created a small PCB with four cascaded 74HC595 shift registers. wiring is simple:
- I2S Data to '595 input data
- I2S Bitclock to '595 shift clock
- I2s word clock (left/right) to '595 buffer clock.

This is what RAW I2S output signals for the counter look like: word-clock (yellow), bit clock (cyan), data (purple). Notice how LSB of data is output after the word clock rising edge. [www.youtube.com]

Fixed the offset (software shifing) to match the parallel outputs, raised the frequency a bit (just cause), plugged in the shifter board. Now this is what word-clock (yellow) and the 3LSBs (cyan=1, purple=2, blue=4) look like:

Counter%20-%20Word_clock%20and%203LSBs.png

The code and the PCB: (https://github.com/lhartmann/esp8266_reprap)

What this does:

- Allows realtime bitbanging of 32 data bits via I2S and DMA.
- Demo code just outputs a 32bit counter at 185kHz sample rate.
- Reference shifter board is provided.

Limitations:

- 1MSB is actually delayed by 1 sample due to I2S signaling standard. This delay is constant so it could be compensated, but I didn't bother.

Hopes for the future:

- No extra arduino necessary, ESP would control the drivers directly.
- SDcard uploads over wifi would be feasible for large files, no more serial connection bottleneck with wifi-serial bridging.
- Browser-side slicing with slic3r and (http://www.skulpt.org). No software install required on the client!

hi, i have implemented full cnc,laser,3d printer support on esp8266, using WEMOS d1, allow repetier host to connect using USB serial or using TCP ip to control printer.

please check [github.com]

i also make web server and have some cool stuff run directly from the wemos d1 (and browser jabvascript) such as:
- convert picture to gcode (vectorization)
- convert picture to raster gcode (for cnc, laser).
- convert picture to 3d printer wall gcode.

[github.com]

Thx.

the smallest 32bit 3d printer board in the world.


Control directly using repetier host tcp/ip connection

no video? cool but a actual video will help ful to understand movement and print quality .

Quote
ekaggrat
no video? cool but a actual video will help ful to understand movement and print quality .

Sorry take long, busy build many 3d print

[youtu.be]