Raspberry Pi Stand-Alone Programmer
QCPete Pain Points w/ the AVR ISP MKII
Overall, the MKII programmers have done quite well, considering how long and how much we've used them. We are careful with our equipment, but after programming tens of thousands of ICs, you have to expect some wonkiness both in the hardware and the software.
My team and I are known as Quality Control here at SparkFun. One of our responsibilities is to design, build, document, and maintain the testing equipment for production. This not only includes the test jigs that we design, but also includes making sure that their windows desktop machines are working and have up to date (or hacked and working) drivers for all our testing needs.
If production sees any issues at all, they call us up, and we try and solve the issue at that moment. It's usually pretty time sensitive, because we run such a lean ship down in production. Whatever build is held up, is probably going to go out of stock in the next few hours, and so it's very important that we get up and programming immediately!
Back in the day (2008-ish), this was an hourly occurrence. When it was just me as the only QC person in production, I remember production issue response would eat up most of my day. A day with only one issue was considered a good one! Now we probably only see a couple issues a month.
So knowing this, it is clear to see that when any problem happens in production, it causes QC much pain.
The main pain points were as follows:
Drivers - Windows updates conflicting with device drivers. All too often, we'd see the following message pop up on our programming batch files:
The cause for this was usually the fact that Windows would do an auto update over the weekend, and then a tech comes in on Monday morning to see this failure in their batch file. UGH!
As a side note, the last workaround that allowed us to use MKIIs on Windows 7 was a great little tool called Zadig. I recommend checking it out if you need to force your computer to use the darn driver you exactly want it to:
AVR Studio Versions - New versions of AVR Studio conflicting with older versions. We started using the Atmel ICE for some programming of SAMD21 chips, and that needs the latest AVR Studio 6 or 7 (which comes with a new program called "ATPROGRAM") All our old batch files call "STK500.exe" so that was an issue. It became a dance on each technician's computer as to which version they had installed, in which order they were installed, and which "actual" un-install happened correctly. No fun.
Ribbon Cables Wear and Tear - The ribbon cables failing to make a connection after too many cycles. Ribbon cables work great for 20, 30, 50? cycles, but after so long, those solder-less razor-blade connections get loose and no longer connect.
Internal Servers Down - This last one was pretty rare, but occasionally our internal servers would go down, and the batch files wouldn't run because there was no access to the network hosted hex file.
Solution: Stand-Alone AVR Programmers
How do we eliminate all of these problems for good? Make the new solution in-house and completely stand alone! No more auto updates!