Note, I had to install arduino onto the Pi. And then I just watched
verbose debug while using the IDE and copied the avrdude calls. See
/SERIAL_UPLOAD/readme.txt for more info.

Also adjusted/added to the test.py module. It now has a proper
parse_results_serial() function to verify that the target was written to
(although I omitted actual hex read-back verification to save time).

Also, There is support for Serial upload pass/fail LEDs, however I have
not yet tried this with hardware... just getting ready for when
Pi_grammer v2.0 is built up.

No change to design, just did a replace to correct parts in library.

Note, I also had to manually adjust the PROD_ID for the RA header,
because I didn't want to muddy up the device for this part.

Added in LOCK_BITS_PASS variable so that I can avoid attempting a serial
upload if there is any failures upstream.

Also, started checking a "temp" copy of readout from serial program, to
adetify if it's looking hopeful. If it's going to fail, then it usually
takes about 30 seconds to timeout, and can appear to the tech that the
pi_grammer has frozen. This helps avoid this illusion.

Also, this is still not killing the subprocess, and I'm not sure how to
do that properly. So even though I move on in the python module, the
serial upload bash file is still going and timeing out again and again
until it's totally done in about 30 seconds.

If you are not using the SERIAL_UPLOAD feature, it will no longer try to clean up that file.

Note, previously, it would try to truncate a file that doesn't exist and lock up the program :(

fixed now!!

Added a "CHIP" variable to the script that holds the chip to be
programmed. Saves us a small amount of time not updating both fush and
flash individually. Changed in both linuxspi folder and in the main file
structure.

I added a device and baud rate to the top of this script similar to the
pi_upload shell script. I changed the programmer command (-c) to default
to arduino instead of wiring, the default device to atmega328p, and the
baud to 115200. I also put notes in the script to pick a slower baud
rate for slower clock speesd ( <= 8mHz)

If you put a new test.py file on a media device, then plug it into the pi_grammer, it will now pull that in and overwrite the local test.py file.

Still need to create a RE-launching of python with the new test.py... coming soon.

Note, I had to add in a file compare, so that it wouldn't keep updating every relaunch. This might be worth adding into the other auto updates stuff (pi_program.sh and *hex)

must be saved in the home/pi/ folder

My idea here is to be able to swtich the lines to completely disconnect the pi_grammer from the target.

*This stemmed from a programming procedure on the lilypad MP3 where the SPI lines are used by the product's ATmega328 to take to the uSD card, so the pi_grammer is stopping that. I hope to free up those lines after programming and let the product do it's thing.

Note, I was seeing some errors being thrown in the raspi when I tried to run pi_program.sh - it was showing that the command "sleep 0.1\r" was an invalid value for sleep. I'm assuming that the "\r" is some annoying carrage return from editing the file on a windows machine.

Added comments around the device variable

I find myself typing in these three commands a lot, so I turned them into double-click-able "links" that you can copy to the desktop.

The shell files themselves (the ".sh" files) must live in /home/pi/Pi_grammer_utililties

And you must copy the desktop link files to you desktop.

When serial upload fails, it will take FOREVER for avrdude to attempt (like 10 times) to serial upload, and it will timeout on each of those attempts. Rather than waiting for that to finish (which looks like the pi is frozen to the user), I take a snapshot of the results and parse them a bit. I can tell that it's going south, and then kill it. Previously the "process.terminate()" wasn't working  - and I think it still doesn't do much. But the call to "sudo killall avrdude" really does the trick.

Also note, in the previous test.py, even though the python module would move on, the avrdude instance would continue. This would lock up the com port and cause more failures down the road.

Seems to be working pretty darn well now. wahoo!

I found while deving the FJ, that sometimes the serial upload would need a bit more time to indicate success or failure. 1.5 seconds seems to do the trick.

Add tutorial link. =)

note, this is not tested yet, but I'm 99% sure this is all you need to do. Will test ASAP.

Note, this is commented out by default, but will be needed for doing any serial programming to micros that need a sec to enumerate the com port. See the following comment thread on the tutorial for more info about how the problem was discovered/fixed

[https://learn.sparkfun.com/tutorials/raspberry-pi-stand-alone-programmer/discuss#comment-5ab2d42d7e7fa89f378b4567](https://learn.sparkfun.com/tutorials/raspberry-pi-stand-alone-programmer/discuss#comment-5ab2d42d7e7fa89f378b4567)

Note, this is controlled via GPIO (36) in test.py. It allows you to "totally" isolate the target from the programmer.

Added in isolation switch

These are now baked into the MAIN board v21

cerberus cable tip

This needed a default target logic select. It is now closed (selected) via paste on the "TARGET VCC" option.

-Added open source hardware logo
-sparkfun flame
-"product" board name
-schematic cleanup
-removed rounded cornders for easier board de-panelization
-lengthened board to eliiminate overhaning parts
-moved to SMT parts for easier assembly

-moved to RA SMT 1x6 header for programming lines to cable, had to re-route a few things, MISO and MOSI have a much better direct route now.
-Enlarged most silk to standard 0.05
-changed text silk on "blank boxes" to more generic use case terms - project name, version, date etc.
-added prod ID to switch IC
-updated copper and sch version number to v22
-added large sparkfun logo to bottom side silk
-removed passive component values silk - this is only used during QC testing hardware assembly (when we build them by hand)

…ary dev

also updated all libraries and the LEDs silk changed to updated versions of 1206 packages

manually adjusted from the old package part in sparkle to the new UDFN

Note, this flag was for the 3.3V hitting the resistor for the "POWER" LED.

The previous call to bash using 'sh' limits what the given bash script can execute. Changing it to 'bash' (superset of 'sh') allows for a greater range of functions available to use in executed script.

Also updated all silk to sweet buzzard style labels

Note, I kept "BASH" option commented out to have nearby for reference with comments.

Due to inverted sPlace (silk), it was hard to see that the hatched GND was actually gone. I must have ripped up a "floating" GND trace that connects the hatched GND polygon to the main GND polygon on the botton copper.