I've noticed, with regards to microcontrollers, there are several way to program them. I am sorta familiar with USB as my Arduino's can be programmed via USB.
What is a JTAG or SPI interface?
Ultimately I know that these interfaces provide a means to flash the chip with new instructions but how do they differ? Are there any advantages of one over another?
ATMEGA microcontrollers like the one in the arduino that are coming straight from the factory can only be programmed using the SPI or JTAG interface.
SPI stands for Serial Peripheral Interface and is a way for microcontrollers to communicate with each other or with the outside world. It's also called 3-wire sometimes because it uses three wires to communicate. To program a chip, you will need a special programmer which reads commands from USB to drive the SPI lines to program the chip. A popular one seems to be the USBTinyISP from Adafruit. A very good introduction into SPI programming is at SparkFun. The most popular applications for programming Atmel AVR chips are avrdude (cmd line), ponyprog (doesn't work with newer programmers) and in some cases AVR Studio (if your programmer supports it). The advantage of SPI programming is that you can program any Atmel chip straight from the factory so you wouldn't always need an Arduino in your projects.
Where SPI is "just another" serial protocol, JTAG is a protocol which is especially designed to program and debug microcontrollers. Not all Atmel micro's support JTAG but the ones that are used in the Arduino do. The JTAG protocol can be used for cool things like "in circuit emulation" and debugging which means that it enables you to see the state of the program in your microcontroller while it's actually running. To do this you'll need a special programmer. Seen my answer for another question.
To program a chip using USB, you'll have to program it first with a "bootloader" using SPI or JTAG. Once loaded with the bootloader, the system will be programmable from any PC using a USB-Serial converter. The downside is that the bootloader takes up some memory space and this method does not allow you to see the state of the chip while it's running.
While I would love to dive into the various programming methods available, someone else already has. Here is Dean Camera's tutorial on AVRFreaks, AVR Programming Methods:
There are many ways to program AVR microcontrollers. Since many people ask about different ones at one time or another, I thought I'd outline them here so that their questions can be answered quickly and efficiently. Please forgive me if I miss a method or make an error.
METHOD 1: In System Programming (ISP)
Supported By: Vast majority of AVRs (see below posts)
Supported Programmers: AVRISP MKI/II, JTAG MKII, STK500, STK600, Dragon, AVRISP clones, AVR910 Programmers, AVRONEIn System Programming is perhaps the most common method of programming the flash, EEPROM, fuse and lockbytes of the entire AVR line. ISP can program AVRs at extremely high clock rates (assuming the target AVR is running at a high frequency and the programmer supports it) and is the method of choice for almost all AVR hobbyists. There are many, many AVRISP clones and AVR910 programmers on the market in addition to simple do-it-yourself dongles which connect to your computer's parallel port.
Recent new dongle designs may use the computer's serial port, however anecdotal evidence has said that this method is extremely slow due to technical limitations.
ISP requires that the target AVR is running at a clock rate of at least four times that of the ISP clock. This is a common pitfall and a source of confusion to many new to AVRs.
METHOD 2: JTAG
Supported By: See AVRStudio Tools help for MKI and MKII device support
Supported Programmers: JTAG-ICE, JTAG-ICE MKII, Dragon, JTAG-ICE clones, AVRONE, STK600 (programming only)Technically JTAG is a debugging system, not a programming method. Still, the JTAG interface allows for the programming of an AVR which supports it.
JTAG is an in-system debugging tool which allows you to manipulate and examine the status of a supported AVR while it is running in a circuit. JTAG allows the user to stop execution at any time, the manipulation of the AVR's internal registers and much more.
The official JTAG-ICE units from ATMEL have been superseded by the JTAG-ICE MKII, which supports the newer and more widely supported across the AVR range DebugWire debugging protocol as well as programming via the ISP method (see above).
JTAG-ICE clones are available for low prices, however their limited compatibility with only a handful of AVRs limits their usefulness. Regardless of this, if your AVR supports the JTAG interface the JTAG-ICE remains a very nice and effective debugging method and programmer.
METHOD 3: DebugWire
Supported By: Many smaller AVRs
Supported Programmers: JTAG-ICE MKII, Dragon, AVRONEAgain DebugWire is a debugging rather than a programming interface, but can be used to load in programs into supported AVRs. The dW interface uses a single AVR pin (the /RESET line) for all communications, making it ideal for the low-pin count AVR devices.
METHOD 4: Bootloader
Supported By: Most newer AVRs
Supported Programmers: N/AAgain technically not a programming method. A bootloader is a small AVR program which sits in a user-settable reserved section of the regular flash. Bootloaders make use of the flash self-modification features available in the newer AVRs to allow the AVR to program itself via program data loaded from an external source. Bootloaders may source their data from any location (eg external dataflash or SD card) however by far the most common type of Bootloader communicates with a PC via the AVR's RS-232 (serial) port.
Bootloaders are limited in that they do consume flash space (limiting the size of the flash available to the AVR's application) and they are unable to change the AVRs fusebits.
Bootloaders are widely available on the internet for download, but they suffer from a "chicken and egg" problem; you need another type of programmer listed here to program in the bootloader in the first place. This is usually solved by the construction of a simple parallel port dongle (See ISP section) or by the purchase of an AVR already preloaded with a bootloader (eg the AVRButterfly board).
METHOD 5: High Voltage Parallel Programming (HVPP)
Supported By: Most non-TINY AVRs (with exceptions)
Supported Programmers: STK500, STK600, Dragon, Homebrew Dongles, AVRONEHigh Voltage Parallel Programming is a method of programming which is rarely used, because of the hassle it requires to set up. Despite this, HVPP programming is commonly used to "resurrect" AVRs whose fusebits have been mis configured via another programming method.
Both the STK500 and the Dragon supports HVPP. During HVPP, the target's /RESET pin is raised to the unusually high value of 12V which engages the internal parallel programming circuitry. The /RESET pin is the only pin of the AVR (on HVPP supported AVRs) which can be safely raised to this level.
You can make your own HVPP dongle using online plans such as this one.
METHOD 6: High Voltage Serial Programming (HVSP)
Supported By: Many TINY AVRs (with exceptions)
Supported Programmers: STK500, STK600, Dragon, Homebrew Dongles, AVRONEHVSP is similar to HVPP, except the data transfer is performed serially rather than in parallel. This is the alternate programming method used on many TINY series AVRs who lack enough pins for HVPP.
METHOD 7: PDI
Supported By: XMEGA AVRs
Supported Programmers: STK600, AVRONE, JTAG MKII, Dragon, AVRISP MKIIPDI is the new programming interface based on the debugWire protocol, for the XMEGA line of AVRs. It's not currently used on any other 8-bit AVR microcontrollers.
METHOD 8: TPI
Supported By: 6-Pin TINY AVRs (ATTINY10, etc.)
Supported Programmers: STK600, Dragon, AVRISP MKIITPI is a very tiny programming interface for the newer TINY line of AVRs with limited pins, like the 6 pin ATTINY10. Like dW, TPI uses the device's /RESET line as part of the communication interface, but there the similarity ends. Since the pint-sized TINY AVRs lack a on-chip debugging circuit, the TPI protocol uses a new programming interface of three pins, in a half-duplex protocol. Because the /RESET line needs to be raised to +12V for programming when the device's RSTDSB pin is set, this is currently only supported by the newer STK600 programming board.
Bonus FAQ Section!
Which is the best method?
There is no universal "best" method. ISP programming is simple and extremely popular, however all the above methods will work. The two high voltage programming modes (whichever is applicable to your device) are the most feature rich, as they allow for the repair of an AVR which has had its fuses misconfigured. However, those methods are a pain to set up, hence the reason most users go with with ISP.I've made a parallel port dongle. Can I use it with AVRStudio?
I'm afraid not. AVRStudio cannot interface with any "dumb" dongles - it requires a smart programming device - containing a microcontroller itself - to decipher the communication protocol it sends. Simple dongles without a microcontroller must be "bit-banged" (ie. the appropriate signals simulated through the dongle via the computer) itself.So my dongle's useless then?
No. You can still program through a home made dongle with a third party programming software tool. AVRDude is a good, known, free command line utility - and it comes included with the WinAVR package.What are my options if I want my programmer to work with AVRStudio?
Choose a programmer that uses an AVRStudio-supported protocol. This can be the simple "AVR910" protocol (deprecated) or a custom implementation of the protocol used by the STK500/AVRISP. Note that these programmers require a micro controller in them, leading to a catch-22 situation. This may be solved by having the programmer's AVR pre-programmed at time of purchase with the appropriate firmware, or by having the AVR pre-programmed with a bootloader.Ok, I want to use a bootloader. How do I get it in there in the first place?!
To use a bootloader in an AVR, you first have to have the bootloader programmed in. If you do not have an existing programmer (even a simple dumb dongle will suffice for the initial programming), you can alternatively purchase AVRs pre-programmed with a bootloader from several suppliers.
Atmel also manufactures the Butterfly demo board, whose MEGA169 AVR comes pre-loaded with an AVR-Studio compatible bootloader.Help! I've messed with the fuses and knackered my AVR while using ISP! The most common mistake is changing the clock selection fuses to an invalid setting. Try putting an external clock on the AVR's XTAL1 pin and see if that helps.
Failing that, if possible use one of the high-voltage methods. These will fix any misconfiguration, including ones involving the clock source as the high-voltage methods provides its own clock to the AVR for programming.How do I interface with my programmer?
Which software you use to interface with your programmer depends on the type of programmer you are using.
Simple "dumb" dongles require third party software, such as PonyProg or AVRDude. These may be command line or GUI tools - look around on the web and you will fine one to fit your needs.
Programmers and bootloaders based on the AVR910 protocol can be used within AVRStudio. From the Tools menu, select the "AVRProg" option to open up a GUI screen to interface with your programmer. As an alternative, third party tools such as AVRDude are also AVR910 compatible.
Official tools are tightly integrated into AVRStudio, especially in the case of the debugging variants (JTAG/Dragon/etc). From the AVRStudio Tools menu, select the "Program AVR..." submenu and click the "Connect" item. From the new window, select your tool and its connection interface and click ok.
As is the case with the dumb dongles and AVR910 programmers, the official tools may also be used with third party programming software.(C) Dean Camera, 2009. All rights reserved. Not for reproduction on any website other than AVRFreaks.net without prior explicit permission.
Reproduced with prior explicit permission, of course!
I would like to add one more thing to the discussion.
SPI is a very common interface for chips. The allusion to 3-wire is the mode of SPI where you do not use the chip's select pin.
I2C is the main contest for interface as it only uses 2-wires no matter the number of chips, while the SPI requires another wire per interface, but is slower.
When teaching I consider teaching about interfaces one of the most important tasks.
Community wiki available for those that want to expand on my information.
From an overall point of view these interfaces only differ in which programmers and which micro-controllers support them. As long as you have a match between the programmer and the micro-controller I wouldn't worry.
As you get into it more you will find that it is the pins the interface uses on the micro-controller that matter more - if you are using these pins for sensors then the signals can interfere when you are programming the device. The simplest solution should this be a problem is to disconnect the sensors during programming.
Some interfaces (including JTAG) allow for debugging the device - but then you need a programmer (and software to drive it) that also supports this. In a previous question I was pointed at the Dragon for debugging AVR devices - I intend to get one and play when my current round of projects nears completion.
As you mention serial, spi (2 wire, 3 wire?), usb, jtag, swd, etc are all used.
Yes there are pros and cons. Jtag for example is for all the cases I know about built into the hardware, originally and primarily used for something other than processor debugging, but they happen to use it for that as well. if jtag is available it is generally the best interface for that reason, but there are exceptions. For example if the pins are not dedicated to jtag, you could have a bug in the code and/or intentionally use one of those pins for something else making it not possible to access the chip using jtag (if it boots the software in flash that repurposes those pins). Another exception is if the processor core can be hung by a bug in the software in the flash and a hung core is not debuggable via jtag. I would call that a bug in the hardware design, but have recently dealt with this on a commercial part.
On the AVR for example the PDI, which I think folks might be calling spi here, maybe not. it appears at least on the xmega that the pdi and external jtag feed into a common pdi interface internally. So the pdi pins give you direct access to this instead of the jtag overhead. so long as this interface works when software in flash has hung the core, then this would be the ideal interface for this family. The protocol is published and relatively simple, and built into hardware. it does have the disadvantage of a bidirectional data bus, like i2c.
Arm has a jtag with fewer wires called swd which they are not necessarily wanting openly published. the open source tools are implementing it though. this is in theory a serial jtag, the different jtag signals are sent sequentially on one wire somehow instead of in parallel on many wires. inside the part I assume it gets parallelized again and feeds normal jtag logic. This has the disadvantage of ARM wanting to keep it a semi-secret, and ARMs jtag debuggers being a royal pain to use anyway. So this is a lot of work. If/when openocd gets it working then it may be a different story. You also have to still worry about repurposed pins and what happens with a hung core.
A number of the vendors use a solution where they have one or more boot flash areas, depending on which way a pin or two or three are pulled depends on which flash you boot from. So you might boot from the user flash, or you might boot from a flash that at least from the factory has a serial port based bootloader, or one that has a usb based bootloader. For each vendor, these software solutions can and do vary, the serial protocol changes in subtle or more than subtle ways, the usb solution can change quite a bit. The good and bad is that some of these flashes you can get at, so you may choose to change the serial bootloader, this is both good and bad, good in that you might choose to customize it to your product, bad that it is possible to erase it accidentally and brick the part, at least brick it for that interface.
Jtag tools used to cost thousands of dollars, now they dont, for about $15 you can get an ftdi breakout board and repurpose it with openocd. For $50 plus or minus some you can get an ftdi based usb solution that works out of the box with openocd. You can get a non-commercial j-link for like $75-$80. And then there are the multi thousand dollar ones which are fast, sure but not worth the money in general. You buy those when you are a huge corporation with lots of cash to blow and want to pay for support. When you pay those prices you get the product you want and you get answers to tech support questions immediately. Like free linux vs windows or RHEL for example, linux support is free but you get what you get. Anyway this makes jtag much more attractive, being the most powerful solution in general I advise getting these tools when and where you can (where affordable).
You should have in your debugging and development arsenal jtag tools when and where affordable. sparkfun has ftdi based usb to serial boards and the ftdi parts can be repurposed into big bangers, you can use these for spi or i2c or pdi or jtag or other interfaces. Ideally getting boards that are made for the bus/part you are interested in and using the free/open source software that goes with it. Also using these serial boards, ideally having a supply of 3.3V and a 5V (about $15 each the one you use for lillypads and arduino minis, etc) for connecting to serial ports for the various micros that have some sort of serial protocol. I find it easier to write my own loader based on those protocols, esp like the arduino/avr folks where the bootloader source is published and is a considerable subset from the supposed standard they support. YMMV.
In short, there is no one good solution, they all have pros and cons. Be prepared to support at least two of them. usb and serial or usb and jtag or jtag and serial, etc. Just lay down pads or pin holes on the board and not necessarily populate. For your personal or lab development have a full suite of tools and be prepared to switch from one to another as you brick chips and have to recover boards or as you develop your own bootloader, usb firmware, etc.
