Arduino travails and rabbit holes

Last time we heard, I was looking into the practicalities of implementing the pulsing and movement functions for a motorised welding torch. This stared out innocently enough with a revisit to the Arduino IDE and its associated Arduino microcontroller family. Since it first started out with Atmel micros, the family has expanded to include a whole range of different form factors, micro suppliers etc.

Too many choices!

Obvs this triggered a spate of unprovoked purchases of all manner of possible options for this application. From right to left:

• ESP32 C3 "Super Mini" ("half nano" format)
• Arduino Nano Every (Atmel  Mega4809)
• Arduino Nano ESP32 (ESP32S3-based)
• diymore "ESP-WROOM-32 Dev Board Type-C 1.96 inch OLED Module"
• (and previously) Arduino Uno R4 Wifi (32-bit microcontroller RA4M1 from Renesas, with ESP32 for Wifi and BluetoothLE)

I previously got my torch pulsing feature working on the Uno R4 - but the processor load seemed to be enough to interfere with the travel (stepper motor drive) so that the stepper was very lumpy. I guess the thread duration was long enough to delay the ideal pulse output. This might be an argument for a dual core processor or perhaps a more powerful device, Having said that, the Uno R4 has a reasonable powerful 32 bit Renesas processor.

Note for reference:

• The ESP32 C3 is single core. 
• The ESP32 S3 is dual core. 
• The WROOM and WROVER modules are dual core
• The ublox NORA W10 used in the Arduino nano ESP32 is based on the ESP32 S3 (dual core).

Graphics complications:

The reason for getting the "diymore ESP32 ESP-WROOM-32 Development Board Type-C1.96 inch OLED Module" was the excitement of possibly being able to display some form of info about the pulse and speed settings. That might be rather daft, as the simpler the torch controls the better and there are no brownie points for coding machismo last time we looked. Furthermore, there's very little info about the part - it's not recognised on the diymore website. 

One point to note is that this is not an OLED display at all - it's a backlit TFT LCD display. The driver IC is an ST7789 and the interface is a fairly standard "12 pin" arrangement.

This github page offers ESP32 1.9" LCD code but after wasting several hours of my life wondering why the display was permanently black, I was finally able to figure out that it requires the backlight at pin 32 to be enabled!! I inserted a couple of lines to turn on digital output 32 ("D32" as identified in the pic above) and "there was light".

I couldn't find the exact display but it looks very similar to this Similarly, although this device has fewer pins, it has some useful(?) inks 

Finally, to generate a suitable "C style data array" for the device driver, there's a handy tool for converting JPG files to the correct format. Note the required settings are shown in the code linked above ie:

a. Palette mod: 16bit RRRRRGGGGGGBBBBB(2byte/pixel)

b. Resize:  170x320

c. Data type： uint16_t

d. Keep the default settings for other parameters

e. Copy the result into the following imageData array

The code that came with the board turns out to be the same as on the github page, showing some form of Sci Fi spaceship.

Do I really want to bugger about with fancy graphics on this gadget? On reflection, although it's interesting from a geeky POV, I think I just need to behave myself and focus on the knitting. 3 pots and no display would be perfectly fine.

Unresponsive ESP32 boards

Some of these boards have the Nano or Super Mini ("half Nano"?) form factor but come with no documentation to speak of. The pin mapping seems to be a mystery and the USB driver gets upset with the Arduino IDE. This resulted in much swearing and hair pulling. 

The resolution is to avoid these "off piste" Chinesium products if there is no documentation. The onboard LED for the "C3 Super Mini" is on pin 8, FWIW. But confusingly, it seems there are quite a few apparently similar products out there with different pin mapping, so be careful where you look for code and which board you select in the IDE Board Manager. For reference, that one responds OK to being addressed as "LOLIN C3 MINI".

Painfully slooooow compiling on the Dell laptop - RESOLVED

This was another vast waste of my life. The record was set when it took 20 mins to compile a really simple program (below). Something was up - but what exactly? Although the Dell, laptop is getting on abt (9 years?), it's got an i7 9550 processor, 16BG of RAM, 500GB of SSD and a graphics card, so shouldn't be struggling with a simple Arduino program. Interestingly, it also ground to a near halt when running PlatformIO within VSCode. WTF??

As an aside, this was another (aborted) experiment aimed at implementing the stepper speed control without ending up in a fight with the pulse function. Turns out the accelStepper functions also suffer from contention with the pulse functions. Given the complexity of the accelStepper library and the poor, almost nonexistent documentation for the STP/DIR implementation, I gave it up as a bad job. Although the software is apparently quite powerful and reasonably well written, the author is clearly a twat, as he couldn't be arsed to write it up and doesn't take well to requests for help. Sod him.

After a lot of buggering about, searching etc, I finally found a post about interference of the Arduino IDE by the IBM "Trusteer" security app. I think I installed this some years ago after being invited to do so by my bank and it's stayed there ever since, periodically notifying me of the current security status. Sure enough, uninstalling Trusteer transformed the compilation time for both Arduino IDE and PlatformIO/VSC. Thank god I spotted that post. To be fair, most "slow compilation" posts refer to anti virus as the root cause but as I already eliminated the core AV app, I'd discounted that line of thought.