AC.programmer: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| Line 3: | Line 3: | ||
=AC.programmer= | =AC.programmer= | ||
AC.programmer is | AC.programmer is an [https://www.arduino.cc/en/Tutorial/ArduinoISP Arduino as an ISP] (In System Programmer) with some added bells and whistles. | ||
ISP | ==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. | |||
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, | Why would you do that, adding an ISP programmer to your setup? | ||
# 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. | |||
# 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). | 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. | 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? | What should the programmer offer? | ||
* | * Program Arduinos (duh) | ||
* | * 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. | ||
* | * 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). | ||
* | * 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. | ||
* | * 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). | ||
* | * 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. | ||
Sketching a plan: | Sketching a plan: | ||
Revision as of 16:08, 12 June 2018
AC.programmer
AC.programmer is an Arduino as an ISP (In System Programmer) with some added bells and whistles.
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?
- 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.
- 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)
- 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.
- 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).
- 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.
- 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).
- 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.
Sketching a plan:
- Display log messages on the LCD
- Log IDE/programmer and programmer/target interaction
- First, get the whole thing to work (program a target)
- 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.
- On request, show the signature of the target, fuse bit values.
- Change parameters via the touch screen (like, the SPI speed)
