# Comments: Raspberry Pi Stand-Alone Programmer

Pages

• Looking at making one of these, in the Pi_Grammer setup instructions it references a generic Pi_Grammer image but I can’t find this on the GitHub, is it available somewhere else?

• Hi There, thanks for your interest. Sorry, we do not yet have a standard image hosted online somewhere. Is there a service for this?

It’s fairly quick to get from the noobs image to a pi_grammer image though:

1) copy a few files to “\home\pi” directory: test.py, pi_program.sh, avrdude_gpio.conf, your_firmware.hex.

Note, it’s a good idea to open up permissions on all of these files to avoid access errors in debug. To do this navigate to \home\pi, then type use the command “sudo chmod 777 test.py pi_program.sh your_firmware.hex”

2) enable SPI hardware tutorial here

3) replace the standard RC.LOCAL file with the one from the repo. It is located here: “\etc”

4) install avrdude. A single command will do this: “sudo apt-get install avrdude” but you can read more about it here adafruits gpio tutorial

I’m about 99.9% sure that’s all you need to do, but I will run this from a fresh noobs and get back to ya.

Also, is there a better way to host a pi image? I’d be happy to get that available for download, although our “master” image for production models is 8GB, and seems a little large to deal with.

• Thanks for the quick reply! I didn’t imagine it would be such a large file, I will set it up myself.

• You’re welcome!

I did just come across one more thing that is necessary (edited my comment above). It is important to use the avrdude_gpio.conf file. This includes the GPIO programmer (“pi_1”), but also the “linuxspi” programmer and defines the reset pin (which is default 26 on our design).

See Kevin Cuzner’s tutorial for more info on setting up SPI in avrdude:

http://kevincuzner.com/2013/05/27/raspberry-pi-as-an-avr-programmer/

• Managed to get everything setup and working. I am trying to use the serial upload functionality on a 32u4 board but having huge reliability problems, works about 20% of the time. Just wondering if you have tried this particular functionality?

• That’s good that most things are working, but sorry to hear about the 20% successful serial uploads.

No, we do not have any procedures currently that include serial upload to a 32u4 based board. All of our current 32u4 tests include only a verification of com port enumeration.

We have plenty that do a serial upload to 328 based designs (usually an FTDI or CH340 bridge IC), and see great reliability, so I’m not sure what’s going on here.

Could you post the failure message from avrdude? (It should be accessible in the “serial_upload_results.txt” file after a failure).

• Yes, it is very strange because Arduino 1.8.5 is able to upload every time without fail. I am now using the same command as Arduino to initiate a serial upload:

sudo /opt/arduino-1.8.5/hardware/tools/avr/bin/avrdude -C/opt/arduino-1.8.5/hardware/tools/avr/etc/avrdude.conf -v -p$DEVICE -cavr109 -P/dev/ttyACM0 -b$BAUD -D -Uflash:w:\$firmware:i 2>/home/pi/SERIAL_UPLOAD/serial_upload_results.txt

When it fails it gives the following output:

avrdude: ser_open(): can’t open device “/dev/ttyACM0”: No such file or directory

• Sorry, I haven’t been able to try this out yet, but I did think of one thing. It might be that after programming the bootloader, your 32u4 has not had enough time to enumerate the serial port. Try adding in a slight delay into test.py just before it calls program_serial(). Maybe even just 1 second should do the trick. Here is the line in the code where I would add it in:

test.py#L432

The code for a 1 second time dleay in pythong is like this:

time.sleep(1)

If you wanted to really go for it, I suppose you could put in a function that looks for that com port and times out, but adding in the delay would be the first step to see if this is really the problem.

Yet another option might be to read the entire hex from a known good board (this would include the bootloader and the sketch code). Then you could program that entire “combined hex” over SPI nice and fast. We also erase the “blanks writes” in the middle of the hex to shrink it down. That’s how we do it in production.

More about hex file snipping here, if you like:

HEX_FILE_SNIPPING_Instructions.pdf

• The delay seems to work, just ran through the entire sequence 10 times with no issue. Thankyou!

• That’s awesome! Thanks for working through this issue. If we end up doing some serial programming to 32u4 (or any other micros with USB capability), this will be really helpful to know ahead of time!

I’m gonna add in the delay to the standard test.py (and comment it out, with a note to use for 32u4s). This seems like it might be kind of buried in the code. Is there another place you might have looked for help?

I suppose this comment thread is good, but I’m wondering if a general troubleshooting section would be a good idea… any other issues you came across?

• It’s very handy to be able to test the serial upload functionality and program the device in one go!

Yes, could it go in the serialupload.sh file to make it easier to change? Not really.

The link to Kevin Cuzner confused me a little as all you need to do is run the sudo apt-get for avrdude and then move the .conf file to the pi directory. Other than this and the serial upload stuff it was plain sailing!

• Hey there QCPete. Most of those 8GB is probably empty space. I have a small script that should image and resize an SDcard exactly for this usecase :)

https://github.com/Duckle29/resize_SD_image

people who use the image just have to run sudo raspi-config raspi-config --expand-rootfs, hell if you place a small bash-script in your home directory that runs on boot, it could auto-do it. Just have the script make a file (touch /home/pi/.first_run) and test if that file exists. If it doesn’t exist, this is the first boot of the image, and the image should be expanded.

If you've found a bug or have other constructive feedback for our tutorial authors, please send us your feedback!

In 2003, CU student Nate Seidle fried a power supply in his dorm room and, in lieu of a way to order easy replacements, decided to start his own company. Since then, SparkFun has been committed to sustainably helping our world achieve electronics literacy from our headquarters in Boulder, Colorado.

No matter your vision, SparkFun's products and resources are designed to make the world of electronics more accessible. In addition to over 2,000 open source components and widgets, SparkFun offers curriculum, training and online tutorials designed to help demystify the wonderful world of embedded electronics. We're here to help you start something.