Moving code from ESP8266 to ESP32

A while ago I made a mashup of Dan Royer's code CNC 2 Axis Demo with my own code for trapezoidal motion stepper and servo control for ESP8266.

I assumed porting the code to the ESP32 would be trivial, and that was true for the most part: changes like library name being Wifi.h instead of Wifi8266.h were not a problem. UDP now does not like multicharacter writes but you can use print instead. So far so good.

However, when it came to the interrupt code I was stuck with the stepper interrupt causing an exception sometimes. And to make things weirder, the servo interrupt worked flawlessly (both of them had the IRAM_ATTR directive if you ask me).

Going little by little, I could narrow down the culprit to a floating point operation during the interrupt, that would cause problems sometimes but not always. Browsing around I found this post. Where the solution was simple: do not use floats within the interrupt routines but doubles. The reason was the float calculation would be performed by…

Speeding up my CAM

A while ago, I created from scratch a CAM software. It has been consistently working ok with a minor problem of occasional wounds in some parts, which I narrowed down to a bad condition.

But solving the math was only part of the problem. A problem my students found too difficult to crack. So I have to provide them a solution (this was for a ball end mill).

The computing time of the algorithm depends on how many calculations are done. And the brute-force approach of checking every single point, edge and triangle for each sample point is just too slow (but works flawlessly).

I have used a dual approach to speed up the code. On one hand, I am selecting only a few elements to be checked for each vertical scan line, that reduces significantly the number of checks to those that are relevant for the current scan line. The second idea is to write multi-threaded code that can handle different scan lines using a different thread, that in turn will run in a different core of the processor if I do not launch too many.

But what took me a while to realize is that I need to wait till all the threads are finished before closing files, otherwise I may miss some of the output data of the latest running threads.

Going from [brute-force case, single thread] 26 minutes to [selective checks, multithreaded 4 cores] 8 seconds was a significant improvement. My guess is that offloading code to the GPU could make it even faster, but so far I can live without that.


Popular posts from this blog

VFD control with Arduino using RS485 link

4xiDraw: Another pen plotter

Software I2C for Arduino