Adventures in AVR ISP Programming

[radhoo]

I had a DIY lpt1 programmer too, was among the first things I built when I started with AVRs . But newer computers have no parallel port so I wanted something easier to use.

Next was the usbAsp which I use a lot these days too.

It costs only 2-3 USD and supports both 3.3V/5V.

I also use a MKII clone that is great, as it support 3.3V/5V and ISP, PDI and TPI (so can be used with XMEGAs too)

[westfw]

All a very entertaining example of how annoying it can be for even an EE professional to try to do something uncommon, based on fuzzy memories of outdated procedures and environments.   This is one reason why Professionals can be enthusiastic about something like Arduino, even with its annoying toy-like simplicity - sometimes (OFTEN!) all you need is something simple.  And having something that's easy to install, whose development is "tracking" recent changes in the world and with lots of online community, is frequently ... nice.

FWIW:

• The Atmel Studio 7 install is much better than the AS 6 install.  Yes, it still takes a very long time, but with 7 it doesn't stop every <inconvenient time> asking to to checkbox some license for some sub-piece.  (On the minus side, AS7 doesn't run on WXP.)
• WINAVR is long obsolete and no longer being updated.  It's closest logical replacement is probably the Atmel command line toolchain download ( http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORWINDOWS.aspx )  Unfortunately, this is a much smaller set of tools (doesn't include make, doesn't include avrdude, doesn't include the unix shell utilities, etc.) (because even OSSW licenses are a pain, not to mention having to track a half-dozen different projects.)
• Arduino provides a one-place download and install of a pretty complete and modern toolchain for AVR.  It's buried deep inside a convoluted directory structure, but it IS there.
• There were some Atmel tools that were famous for needing different drivers depending on whether you wanted to use the Atmel tools with them, or the open source tools like avrdude.  :-(
• W8 and W10 have introduced a set of relatively annoying security features that can make unsigned drivers harder to install.
• AVRDUDE has a fairly high update rate.  Not all of the updates have been wonderful things :-(  There are some GUI front ends that make using AVRDUDE a lot easier.  (AVRDUDESS is one, I think?)
• The 6-pin vs 10-pin programming connector thing is indeed a thing.  More recently, you can add the 1.27mm pitch connectors to the mix, plus SWD and JTAG.  And the connectors that look the same aren't necessarily compatible.  You'd almost be better off with a set of jumpers that you ALWAYS need to fiddle with.
• a STK500 is a swell thing, if you've got a serial port and a 12V power supply.  Similarly parallel port programmers.  If you've got the right computer and have it all set up, you're in good shape.  if you have to find a modern computer/OS/hardware/instructions set, you're NOT in good shape...  (I'm not even sure that AS7 still supports the STK500.)

[james_s]

As simple as the Arduino is, I found it very frustrating when I first started messing with them and that's coming from years of experience using AVR microcontrollers. There are multiple versions of the Arduino IDE which for some reason cannot be installed concurrently on a system and some of the later versions break large amounts of older code, spitting out cryptic errors. I find this absolutely absurd for a platform aimed at beginners.

[sleemanj]

Getting off topic, but

which for some reason cannot be installed concurrently on a system

Don't know about Windows, but on my Linux box

Code: [Select]

$ ls -ltrd /usr/local/stow/ard*
drwxrwxr-x  8 boffin boffin 4096 May 18  2013 /usr/local/stow/arduino-1.0.5
drwxrwxr-x  8 boffin boffin 4096 Sep 17  2014 /usr/local/stow/arduino-1.0.6
drwxr-xr-x 10 boffin boffin 4096 Aug 28  2015 /usr/local/stow/arduino-1.6.5-r5
drwxr-xr-x 11 boffin boffin 4096 Nov  4  2015 /usr/local/stow/arduino-1.6.6
drwxr-xr-x 11 boffin boffin 4096 Dec 18  2015 /usr/local/stow/arduino-1.6.7
drwxr-xr-x 11 boffin boffin 4096 May 10  2016 /usr/local/stow/arduino-1.6.9
drwxr-xr-x 10 boffin boffin 4096 Dec 13 00:02 /usr/local/stow/arduino-1.6.13

though to be fair since they all use the same preferences directory, it's a bit iffy to go backwards (usually if I need to check something in an older version I'll move my prefs out of the way first).

some of the later versions break large amounts of older code

Well you can't maintain 100% backwards compatibility all the time, things have to change.  But that said the Arduino IDE release QC process is.. well they don't have one, some releases of the IDE (eg 1.6.10) caused all sorts of problems. 

I wish they would have a proper release cycle, with beta releases, so that the people who are capable of debugging problems can do so, before it got to a stable release for the masses.

The whole development of the IDE is a bit... weird really, for a high profile project, I think it boils down to a few "gate keeping" egos in there doing things their way, a lot of good ideas get pooh-poohed, they do IMHO crazy-ass things like writing it's build system (arduino-builder) in what really is a pretty obscure language (Go), the afore-mentioned lackadaisical release cycles...

[james_s]

I see no reason why they couldn't maintain 100% backward compatibility, even if it's at the expense of some forward progress. The Arduino platform is aimed at beginners, and a large part of the draw to the platform is the huge library of existing code. When someone downloads code someone has published and it doesn't work and spits out some cryptic error it's frustrating. A beginner friendly platform should first and foremost "just work" and not require a bunch of screwing around and troubleshooting to use code that was working for someone else. If they are going to change how something works, there should at least be a compatibility mode. I never really got into it but I do keep the IDE around for building/modifying some of the many projects that are out there and I ended up staying at an earlier version.

[westfw]

a large part of the draw to the platform is the huge library of existing code. When someone downloads code someone has published and it doesn't work and spits out some cryptic error it's frustrating.

yeah, infinite backward compatibility is a nice theory.  Come back and tell us how you did when you've tried to support a large project with significant development for 10 years or so...
Don't forget that over this time period avr-gcc, java, windows and macos have all changed in ways that have not beenvery backward compatible...

[james_s]

yeah, infinite backward compatibility is a nice theory.  Come back and tell us how you did when you've tried to support a large project with significant development for 10 years or so...
Don't forget that over this time period avr-gcc, java, windows and macos have all changed in ways that have not beenvery backward compatible...
[/quote

Well I'm still using 1.0.6 that I rolled back to and it works just fine, it seems most people are on the older versions still because I don't remember the last time I downloaded a library or code that didn't work. When I originally tried a newer version almost nothing worked without rewriting portions of it and I couldn't really find anything different about the newer versions except that it broke a bunch of existing code.

So if they can't maintain backward compatibility, they shouldn't make changes. At the very least have a compatibility mode so it works with the existing libraries and code, and failing that, make the installations portable so that it's trivial to install multiple versions. I have two different versions of Xilinx ISE to support different generations of their FPGAs and those coexist just fine, but I can't have two versions of the Arduino IDE installed on Windows? That's ridiculous. This is a *beginner* platform, and it's a fragmented mess. When I first started playing with it there were two completely different entities, both proclaiming to be the "real" Arduino, I haven't even looked to see if that's still the case. It's so much more hassle than using Bascom or even standard C bare metal on an AVR. The *only* thing that makes the Arduino stand out is the huge collection of libraries and code. If that gets broken regularly by new releases then the the platform has failed at the very thing that makes it worthwhile to have in the first place.

[westfw]

Well I'm still using 1.0.6 that I rolled back to and it works just fine
if they can't maintain backward compatibility, they shouldn't make changes.

People can stay at the old version if they want...  You can always install new drivers for new OSes manually, and update specific tools that stop working one at a time, and so on.  Just like Dave had to do for the simple task of putting a new .hex file on a piece of turn-key hardware, causing all that pain and frustration...

make the installations portable so that it's trivial to install multiple versions.

I don't understand the problem.  I have multiple versions (on mac.  I've also done it on windows, though I don't know whether I've used it enough there to see any problems.)  There are some problems with "extensions" because the format of various things have changed (1.0.6 only supports AVR.  The latest supports AVR, SAM3X, SAMD, ESP8266, and more), but the base install shouldn't have much of a problem.

Oh, and modern versions support a "portable" option that should help.  Download the .zip instead of the installer, unzip to \Program Files\Arduino-1.8.0 or wherever, and create a directory \Program Files\Arduino-whatever\portable before the first time you run the IDE.  Then, when you run it it will put all its normal per-user and per-installation files under "portable" instead of the normal places in the windows environment (which are weird.)  I guess this might qualify as a not-backward-compatible change, though...

[Gustavo-ar]

Hi!, this is my first post here, recently I have to program an atmega328p and make an programmer using an arduino nano, is very useful.
I can use it in two ways: by putting the AVR in the socket, or by connecting it to a cable (leaving the socket empty).

http://www.martyncurrey.com/arduino-nano-as-an-isp-programmer/

[westfw]

Quote

modern versions support a "portable" option

Sigh.  In Windows10, at least, you don't want to put an Arduino tree with "portable" configured into the normal ProgramFiles area, because W10 won't allow it to write anything there, and it won't work (unless you want to run it "as administrator.")
It'll be OK in your personal area, or somewhere that isn't protected.

Look: 1.6.13 and 1.8.1 not only both installed, but both running simultaneously!

[westfw]

I went ahead and wrote a little windows batch script that will add the tools included with an Arduino install to your "command prompt" path, so that you can use avrdude, avr-gcc, and so on.   Enjoy...  (copied from other posts; may have some redundancies.)

With WINAVR becoming unmaintained, various people including myself are starting to think that the easiest way of getting a basic set of avr-gcc tools installed on your Windows system is to install Arduino, and use the tools that it includes.
 But they're buried rather deeply, and a bit of a pain to get to.
 So I wrote this batch script to go out and look at your Windows (XP, 7, 8, 10) system, find the Arduino tools (1.0.x, 1.6.5+, 1.8.x), and sticks them in the search path for that "Command Prompt" session.  It gets avrdude too.  It doesn't copy or actually install anything, so it's pretty quick.  Now, command-line access to the bare compiler isn't a particularly wonderful development environment, but it might be good for a quick start...
 
 >C:\Users\User>e:install-avr-tools
 
No avr-gcc currently installed.
 At least one Arduino install found.
 
Looks like C:\Program Files\Arduino1.8.0 has version
 avr-gcc.exe (GCC) 4.9.2
 Use C:\Program Files\Arduino1.8.0 ? [y/n]>y
 Found avr-gcc
 Checking tool versions
avr-gcc (GCC) 4.9.2
 Copyright (C) 2014 Free Software Foundation, Inc.
 This is free software; see the source for copying conditions.  There is NO
 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
avrdude: Version 6.3, compiled on Dec 16 2016 at 13:33:19
          Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
          Copyright (c) 2007-2014 Joerg Wunsch
          System wide configuration file is "C:\Program Files\Arduino1.8.0\hardware\tools\avr\etc\avrdude.conf"
C:\Users\User>

  https://hackaday.io/project/19935-install-avr-tools
 

[rrinker]

  I just have my library and sketches folders pointed to my OneDrive, that way I can access my projects from any computer, either my main desktop or the workbench computer, or even my lappy at work if I get an idea and want to put it in code while still fresh in my mind. I've done this with other programs as well, like KiCad and my model railroad CAD.

[Nobody2]

First thing I thought when i saw the image on twitter and the video title was: "Yep, that's why I am still using AVRStudio 4". Using the visual studio base makes it just too bloated in my opinion. Also just talking to a programmer with the newer version is too convoluted imho, but the biggest issue I have with it, is that they removed the ability to use self-build programmers like the ones I use.
I'm not use about WinAVR though, I'm pretty sure my version is newer than 2010?

[SingedFingers]

Argh this thread makes me angry. Sorry for the rant...

About a year ago I needed to program an old PIC16F684 with some code that was lying around that I wrote back in the late 1990s. Didn't want to invest in a programmer for a one off so I dug an Arduino out of the junk box and set up a bodge rig on a breadboard with the software and hardware here: http://rweather.github.io/ardpicprog/ . That took about an hour to get working. I had to download and install MPLAB and fix a few things in the code but it all worked which took about an hour. Not too terrible.

Then about 9 months ago I needed to use an AVR to replace a bit of relatively complex discrete logic (nothing fancy just PLC grade logic which was trivial to implement in C) in something so I grabbed a cheap USBasp programmer from a local supplier and a couple of AVRs from RS and got to work.

5 hours later I was still trying to get bloody Atmel studio working. Now the day job is mainly mud wrestling with Visual Studio, which may have contributed to it because I already had VS2015 installed, and I've been using it for about 15 years now for C++ and C# and I've even built addins for it so I'm no noob when it comes to this sort of stuff. But FMH it just didn't want to work.

Eventually I fired up a VirtualBox VM with Debian on it, connected the USB device to that and wrote the code with vim in about 30 minutes, compiled it with avr-gcc, burned it with avrdude and I was done. Joy to platform agility on my part 

None of this was ISP programming - I didn't want to bite that one off but I can imagine the difficulty that adds.

[Fungus]

If it's just a quick job then use the Arduino IDE. It's designed for noobs.

Atmel Studio is a huge fail unless you really need to program in assembly language or whatever.

[SingedFingers]

It's OK until you hit something they bastardised. Do they run it through a transpiler or something before they compile it to the final language? It feels like C++ but it's not.

[Ian.M]

The Arduino IDE runs it through a pre-preprocessor (or bastardizer)  that inserts forward declarations for functions etc.   Unfortunately it frequently gets stuff wrong if you are trying to use the more advanced features of the GCC C++ language.  The easy fix is to ONLY use <sketch_name>.ino to provide a list of headers to include to MAKE as the bastardizer doesn't parse any other files in the sketch.  Don't put any code or declarations in the .ino file! 

You can then create a normal C++ project structure with all .cpp and .h files in the Arduino sketch folder, with a normal main() function and without the Arduino's enforced setup() and loop() functions.   You must avoid using the filename <sketch_name>.cpp as the bastardizer will overwrite it. Also don't use the filename main.cpp.

See Gammon.com.au: How to avoid the quirks of the IDE sketch file pre-preprocessing for details.

Project headers listed in the .ino file should be 'pure' (i.e. only declare or #define stuff, not create/initialise any C objects).  See Gamedev.net: Organizing Code Files in C and C++

[SingedFingers]

Thanks for the info - explained. I used a pointer once and it shit itself so I gave up and just used C

[Ian.M]

N.B. if you are using the ArduinoIDE and are getting mysterious build errors for perfectly good code that go away if you insert a dummy function call or some other crap just before the line with the error, its because the build process can fail randomly if the path to the temp folder is too long or contains spaces,

The fix is to give the IDE a temp folder in the root of the drive. Open the Arduino preferences.txt file, close the IDE, then add the line

Code: [Select]

build.path=C:\tempand create the corresponding temp folder on C, with full access for your username.

[rrinker]

 I am so stealing westfw's script. Doing a one-off it's not so bad drilling through the Arduino install to find the bits, but after the first time, a script like that is a lifesaver.

 As for the install of the Atmel Studio - at least part of that HAS to be something they've (Atmel) has done, because I've been using Visual Studio for a long time and while the install can be time consuming, it certainly doesn't take hours.

 Good tip on the temp path Ian. I've come across strange hard to debug issues like that in many other unrelated things and it can be very frustrating to find the cause when everything looks just fine. My favorites are when the software reports something like "file not found" but you can manually open the path and see the file sitting right there in plain sight.

[Fungus]

It's OK until you hit something they bastardised. Do they run it through a transpiler or something before they compile it to the final language? It feels like C++ but it's not.

They do one thing before it runs: They search the files for function prototypes and insert them at the top of the file. This allows you to call functions below you in the file without adding explicit prototypes. It's usually invisible in practice.

Also: The way the IDE works it's best not to try and write separate header/object files for everything. You can do it if you want but all you achieve is double the number of open files in the IDE so it gets messy. The way I do it is to just make everything as .h files (all code inlined in classes) then #include them in the main file. Separating interface from implementation doesn't gain you much in programs this size, so... 

Apart from that it's perfectly standard C++.

PS: If you want to write in assembly language with Arduino IDE you can do that, too, but only in libraries. The IDE doesn't look for .asm files in sketch folders, only in library folders. If you put them library folders it will look for them and assemble them just fine. You have to use an external editor because the IDE won't load them in your sketch, but... you can do it.

[HwAoRrDk]

As for the install of the Atmel Studio - at least part of that HAS to be something they've (Atmel) has done, because I've been using Visual Studio for a long time and while the install can be time consuming, it certainly doesn't take hours.

I suppose it could take hours if you've downloaded the stub 'web' installer and you have a crappy internet connection. The web installer has to download hundreds of MB of stuff, and it's not very good at giving you feedback on progress.

(As an aside, personally, I have a real dislike of 'web' installers. The only advantage I can see for them is it saves on download time in cases where the user is not going to be installing a significant portion of optional modules. And they have a huge downside for if you want to archive the installer, but the vendor does not deign to make a 'full' package available. On more than one occasion I have had to hunt through temp folders to find the actual full installation files. )

Another reason that just occurred to me that explains prolonged installation - Atmel Studio and Visual Studio alike - is that the installer creates a system restore point before it begins, which can be a lengthy process sometimes.

[Fungus]

(As an aside, personally, I have a real dislike of 'web' installers. The only advantage I can see for them is it saves on download time in cases where the user is not going to be installing a significant portion of optional modules.

Sure, but Visual Studio doesn't actually give you any install options at all*. No matter what happens you're in for a 5Gb download.

(*) If they did that then people might not install the Windows Phone development platform 

The best part of Visual Studio is when you're on site with a client and it suddenly asks you to reconfirm your Microsoft account before it'll compile anything. And you don't have an Internet connection. Yes this happened to me. 

[rrinker]

 Since when? I have 2012 Professional on this machine but I just went and ran the online installer for 2015 Professional and you do not have to install the Windows Phone crap. There are a lot of optional components you don't have to install if you don't need.

 And the whole ISO is only 3.8GB

[Fungus]

Since when? I have 2012 Professional on this machine but I just went and ran the online installer for 2015 Professional and you do not have to install the Windows Phone crap. There are a lot of optional components you don't have to install if you don't need.

And the whole ISO is only 3.8GB

Maybe the "Pro" version is different... 

Most of the Visual-Studio-based development systems install VS Community though. I don't know about Atmel Studio but I've used a couple of others (eg. Unity) and that requires the full 5Gb-with-Windows-Phone version of VS 2015.