It is early 2020 AD and I am developing some Arduino firmware for a friend. I chose Arduino for several reasons, one of them is that the friend in his 70's can program Arduino clones using a legacy PC that runs Windows XP. You know, HAM and electronics enthusiasts have a bunch of equipment that requires software/drivers that have never been updated/ported to newer operating systems: so why change it, when it works?!
My computer runs a supported Ubuntu distribution and the latest Arduino IDE. Actually our Arduino IDEs are not too far apart version-wise, so I started sending him updated .ino source code.
First problems appeared with I2C LCD driver libraries that misbehaved: there are too many with the same name and you can't know which one is being used at compile time. This forced me to find an I2C LCD library with a different name than LiquidCrystal_I2C, which is actually better than others:
My computer runs a supported Ubuntu distribution and the latest Arduino IDE. Actually our Arduino IDEs are not too far apart version-wise, so I started sending him updated .ino source code.
First problems appeared with I2C LCD driver libraries that misbehaved: there are too many with the same name and you can't know which one is being used at compile time. This forced me to find an I2C LCD library with a different name than LiquidCrystal_I2C, which is actually better than others:
#include <hd44780&.h> // main hd44780 header
#include <hd44780ioclass/hd44780_i2cexp.h> // i2c expander i/o class header
This solved it, but the same firmware worked differently on his hardware than mine. What broke was a function that picks a random value and looks it up in a static table, which went out of bounds. This happened at the second iteration of the main loop() and then the firmware basically crashed.
Since it didn't happen on my side, one solution was to send him the compiled firmware (.hex) and burn that directly. It is fairly easy: have Arduino IDE print out the avrdude programmer command and replay it with the .hex that you want to load. I planned to do it over TeamViewer, as I had done few years ago.
Second problem: his WinXP has TeamViewer 10 and cannot be upgraded, while on my Ubuntu I got TeamViewer 15. They don't talk to each other. Fair enough. TeamViewer guys let you download old versions (excellent!), so I installed 10 on my Ubuntu, but it still refused to connect. No time to troubleshoot that, so I switched to Plan B which required a bit of preparation: blindly write down the instructions and have my friend do it without my real-time assistance.
Once I got from him the complete avrdude command (in form of screenshots because you cannot copy the debug output in Arduino IDE!), I needed the safest way to get him on the right track. Consider that I do not have a Windows machine to try the procedure beforehand.
So, I produced a DOS batch file hoping that the Arduino board would end up always on the same COM port. The simplest thing was to put everything in C:\ so to avoid long paths. A .bat file cannot be sent over email, so it was a .txt then renamed. Once I explained to click on the batch file, nothing happened: the DOS window just flicked quickly. I needed to see the error message.
We worked out together an old DOS trick: pause the execution of the batch. He remembered the right command was "pause", so he did everything on his own to edit the file, rename and run again. I could now see (a screenshot) that I had misread an avrdude flag in "1" rather than "i". So, one more edit and run and .... mission accomplished! DOS saved us.
Even better, he managed to program a second Nano board that ends up on COM10 simply editing the batch file.
My binary firmware works as expected on his hardware, no more array out-of-bound and firmware crashes. His Arduino installation probably has stale libraries or doesn't work properly on the experimental now-dead WinXP 64 bit.
For the next updates I will send him the .hex microcode and all will be fine. And if something else goes wrong, there is always DOS!
Since it didn't happen on my side, one solution was to send him the compiled firmware (.hex) and burn that directly. It is fairly easy: have Arduino IDE print out the avrdude programmer command and replay it with the .hex that you want to load. I planned to do it over TeamViewer, as I had done few years ago.
Second problem: his WinXP has TeamViewer 10 and cannot be upgraded, while on my Ubuntu I got TeamViewer 15. They don't talk to each other. Fair enough. TeamViewer guys let you download old versions (excellent!), so I installed 10 on my Ubuntu, but it still refused to connect. No time to troubleshoot that, so I switched to Plan B which required a bit of preparation: blindly write down the instructions and have my friend do it without my real-time assistance.
Once I got from him the complete avrdude command (in form of screenshots because you cannot copy the debug output in Arduino IDE!), I needed the safest way to get him on the right track. Consider that I do not have a Windows machine to try the procedure beforehand.
So, I produced a DOS batch file hoping that the Arduino board would end up always on the same COM port. The simplest thing was to put everything in C:\ so to avoid long paths. A .bat file cannot be sent over email, so it was a .txt then renamed. Once I explained to click on the batch file, nothing happened: the DOS window just flicked quickly. I needed to see the error message.
We worked out together an old DOS trick: pause the execution of the batch. He remembered the right command was "pause", so he did everything on his own to edit the file, rename and run again. I could now see (a screenshot) that I had misread an avrdude flag in "1" rather than "i". So, one more edit and run and .... mission accomplished! DOS saved us.
Even better, he managed to program a second Nano board that ends up on COM10 simply editing the batch file.
My binary firmware works as expected on his hardware, no more array out-of-bound and firmware crashes. His Arduino installation probably has stale libraries or doesn't work properly on the experimental now-dead WinXP 64 bit.
For the next updates I will send him the .hex microcode and all will be fine. And if something else goes wrong, there is always DOS!
