Comments: Raspberry Pi Stand-Alone Programmer
Looking for answers to technical questions?
We welcome your comments and suggestions below. However, if you are looking for solutions to technical questions please see our Technical Assistance page.
If you've found an issue with this tutorial content, please send us your feedback!
Inspired by this board, I designed something simliar. Please check it our. Open source of course. https://github.com/rbenamotz/LEMPA
Hey 720, Wow, nice work! Your layout is great and I like what you've done with your software reorganization. Our repo has a ton of code included in the "test.py" module, and it makes sense to split it up. Your state machine is a very clean approach. It is really wonderful to see this project grow into another - the true open source success story. Thanks for sharing!
PS I'm curious, what kind of projects are you planning to use your LEMPA on?
THANKS!
I am actually using it quite alot. Even for very small things. For example, it is now Sep. and preping Halloween stuff. Wrote a very small firmware to blink some LED inside pupkins based on proximity. Got about 10 pumpkins to need to program 10 ATTinys.
It is also being used for commecrial app
Can this programmer be used to program the Attiny814 (UPDI 1-wire interface) ?
Hi 358, Sorry, I do not have any experience programming the Attiny814 via UPDI from a raspi, so I'm not sure. It looks like the raspi does have 1-wire hardware, but it is on GPIO 4 (be default), which is currently wired up to a STAT LED on this HAT. If this was possible using this hardware on the Pi, then you'd need to enable the 1-wire hardware on a custom pin, which looks possible here. This could also be helpful for enabling 1-wire.
Also, FWW, I stumbled upon a python based solution for programming UPDI. It looks like using a USB to UART converter, you could potentially pull this off from a raspberry pi.
Hope this helps and good luck!
Thank you Pete. I was able to follow your advice and link to the python solution. I successfully ported to the Raspberry PI and now have my Raspberry Pi Stand-Alone UPDI Programmer . Thanks again. https://github.com/becky001/pyupdi
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
Thanks for all your help!
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.