Moving code from ESP8266 to ESP32

Image
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…

Useful uses of screen command

Every now and then I am using command-line tools. I work with daily with OSX and Linux and they both have in common the availability of a powerful command line tool.

The same could be said about Windows, but that would be an overstatement, as CMD.EXE provides not the efficiency level that can be achieved with other systems. But even if it could, they chose to make it different.

Anyway, many times I am working over remote terminals on other's computers command line tools and one thing that may not be welcome is for a program to destroyed your temporary data or to just stop working whenever the connection is broken.

If you are using a so-called broadband router you may realize than some remote terminal sessions die for no good reason. (The real reason is that after a few minutes without seeing any traffic through a TCP connection your home router will kill the connection without you knowing it). Let say you are editing a text file on a remote computer through an ssh connection when you get a telephone call that keeps you a few minutes away from the computer and, when you are back, your terminal session dies with an error message. It might mean the changes you did to that file are lost forever. That would be a bad thing.

There is one command that can help here, keeping the text editor program and your session frozen but alive while your ssh connection is destroyed summarily by your broadband router. The screen command allows you to create a terminal that does not go away when the connection is broken. A terminal session you can safely return to later.

Other usage case that I face from time to time is that I want to launch a program, maybe a long simulation, on a remote computer. If I do not keep the terminal open all the time, the program running on the remote server will be killed by the system. But even if I decide to keep my computer connected, still the connection may be killed by (you are guessing ...) your home router. And the worst thing is the next morning you will not have the results of the simulation and you will need to start from scratch.

Once again, you can connect to the server and start a screen session before starting the simulation, this way you can cancel the remote terminal session at any time with the confidence that your simulation will keep on running till the end. Next morning you can connect again to see the results and, if desired, finish that screen program.

Even better is that screen command is not limited by one terminal per user but you can have as many as you need. And switching from one to the next is as simple as pressing Ctrl+A and next pressing N.

 Yet another scenario is when you launch a program on your office computer (let's say you love simulations and it is just another one). Now that you are home you would like to check the intermediate data the program is printing to the screen but you cannot do that (unless you have some remote desktop software running on your computer).  However, if you started a screen session before launching your program, then that session can be detached from the original terminal and attached the new with the screen -D -r command.

It is a really interesting tool with only on drawback: that you will loose your terminal's scroll mechanish. So now, when you attach to a certain screen instance, you can see the content of the current screen but you cannot scroll back to see the lines that were printed before. Other than that, it is pretty useful.

Comments

Nasrin Akhther said…
Excellent tutorial article.
clipping path service

Popular posts from this blog

VFD control with Arduino using RS485 link

4xiDraw: Another pen plotter

Software I2C for Arduino