AC.programmer

Tools, My IoT Projects

AC.programmer

AC.programmer is an Arduino as an ISP (In System Programmer) with some added bells and whistles.

Version 1 - Just a plain ISP programmer

ISP Programming

• does not use the serial interface of the Arduino and
• does not require a pre-installed boat loader

Instead, the programmer uses the SPI interface to communicate which the target that has been switched into serial programming mode on reset. The work normally performed by the boot loader is offloaded to the programmer.

Why would you do that, adding an ISP programmer to your setup?

1. It frees up the serial interface for communications with the ESP8266 WLAN chip. This was the main reason for me to use an ISP. SoftwareSerial is slow, and even at slow speeds it means asking for trouble (lost characters, in example). Seriously, SoftwareSerial is unusable for this purpose.
2. It frees up the 2kB of flash memory that the boot loader occupies, all yours to use. This is the only way to get to access to the full 32kB of flash memory the smaller Arduinos have to offer. Here (todo: provide link) is an entry for boards.txt of the Arduino IDE that reflects the gain in memory.

There is one disadvantage, though: Without having the serial interface connected to your computer, you loose that option for logging. I developed a logging facility called "Logsury" that, amongst other channels, supports logging via I2C. That does NOT block the I2C interface as many addressable devices may be connected. AC.programmer forwards log information received via I2C to its own serial interface (connected to the computer), and/ or displays it on its large LCD display, or logs it to a file store on a SD Card (or any combination thereof).

Building AC.programmer

LCDs for Arduino often use up pretty much all port pins. Plugging the display directly into an Arduino Uno is convenient but makes all the decisions for you (like, using up the SPI connections to communicate with the SD card often found on the display).

Plus, not all connections are needed. If you have only one LCD, "chip select" can simply be tied to 5V. If you don't need to read from display RAM, you don't need the "read mode" pin. What you really need is pins for "command/data", "write mode", and "reset".

And, of course, 8 data pins - unless you use a shift register. This is quite a bit slower (by a factor of about 4), but it saves you 6 port pins as you only need "data" and "clock" to operate the shift register. By clever placement of parts this even saves quite a bit of wiring as well. That's what I did!

Requirements

What should the programmer offer?

• Program Arduinos (duh) - DONE
• Speed. It is possible to crank up the speed between computer and programmer to 115200baud and between programmer and target to whatever the target can handle. - DONE
• Information on the programming process. "Arduino as ISP" uses 3 LEDs to provide status information. We have a whole LCD display. If something goes wrong, I can say exactly what. During programming, I can display what is written where (pages of flash and EEPROM memory). - DONE
• A way to load data into EEPROM memory, if my application needs it. Preconfigured WLAN settings for multiple SSIDs come to mind...
• Run on battery power. When I'm "in the field", I want to be able to update devices without connection to the grid. - DONE (can be powered via USB or externally using a built-in voltage controller)
• Power the target. I have fried a number of Arduinos by connecting them and the programmer to different power sources in ways that were clearly less than optimal ("no common ground" is what you want to avoid). - DONE
• Upload programs from SD card. Again, when I'm "in the field", I don't want to lug around a whole laptop just to program devices the memory of which could not even hold one of the colorful desktop icons.
• Some fun, like information on what exactly the Arduino IDE is sending to and receiving from the programmer. - DONE (though this slows down programming to a crawl)

Sketching a plan:

• Display log messages on the LCD - DONE
• Log IDE/programmer and programmer/target interaction - DONE
• First, get the whole thing to work (program a target) - DONE
• Visually display the programming progress. In example, display bars or rectangles that represent the flash and EEPROM pages and show what is being read and being written. Ditto the fuses. - DONE
• On request, show the signature of the target, fuse bit values - DONE
• Change parameters via the touch screen (like, the SPI speed)

Version 2 - With LCD and I2C log facility

Future Ideas

These are items that once on my to do list; not sure if I will follow up on them:

• Write complete STK/SPI log to SD card (CTP-1045). Why would I do that? That out of curiosity how the Arduino IDE interacts with the programmer.
• Program to SD (the IDE thinks it's programming an Arduino but the programmer just record what is being done, for later replay; CTP-1047)
• Program from SD card (the replay mentioned above; CTP-1049)
• Record Logsury output on SD card (CTP-1050)
• Program EEPROM (in example, to configure WLAN settings; CTP-1051)
• Save EEPROM contents to SD card (CTP-1052)
• Save Flash to SD card (in example, for duplicating a configured Arduino; CTP-1053)
• Reset target via touch screen (in example, if the reset button can't be accessed easily; CTP-1067)

Tools, My IoT Projects