I've been working on the Arduino serial bootloader, and one of the things that has struck me is that all the serial bootloaders I'm aware of use a serial 'protocol' that was actually designed for talking to a programmer. I *think* this tends to make them both larger and kudgier than they ought to be. (For example, the arduino bootloader goes to some length to ignore commands that it doesn't implement in a way that saves code and 'tricks' the host-side software.) Are there any protocols that have been designed and implemented that ONLY support bootloading functionality? Any thoughts on the idea?

(I'm thinking 'get info', 'load flash address', 'load eeprom address', 'program data', and 'quit.' Replacing all the individual parameter and sync check commands with a single 'get info' would be particularly helpful in simplifying the bootloader code, I think.). Quote: Which is pretty much what leads me to ask about better protocols.

While it's an ISP rather than SPM transfer protocol have you looked at the USBtinyISP and the support in avrdude on the PC end? Because the ISP software and a V-USB style USB emulation have all got to fit into a 2K tiny2313 the actual 'protocol' consists of just 4 commands I seem to recall. BTW there are also some serial bootloaders that do the (binary) data transfer by nothing more than Xmodem. That's pretty trivial too I guess.

(the difference between a bootloader and ISP, of course, is the bootloader knows the page size (and other parameters) of the chip it's going to program so those things don't need to be passed across the link while protocols such as AVR109 have commands for passing all those kinds of details). If I only implement subsetting on the target side, I end up needing to 'fake' a fair number of command responses to keep host-side software (avrdude) happy. At some cost and some peril (for instance, optiboot responded to all unrecognized commands with 'yeah, sure, whatever you say' Which ended up sending into a nice communicatons loop if avrdude was trying to talk to it at the wrong speed.) If I'm going to re-write both host and target sides to only use what is absolutely necessary, I might as well see if there is anything better. I don't immediately see a way to rearrange code/commands to condense EEPROM and FLASH writes into common code in a bootloader, but I was hoping that someone else had.

(EEPROM support is not in optiboot (which uses a STK500v1 subset), and adding it looks like it would take more space than it ought to.) (As another example, consider command decoding. An if/elseif chain will take four bytes (cpi/brne) for each possible command. A jump table would nominally take two bytes per command, plus some overhead *IF* the commands are contiguous ('ABCD'). (I guess if I'm under 256 words, I should be able to get by with one byte!) But none of the 'protocols' I'm coming across has contiguous commands (avr109 seems especially fond of using both upper and lower case versions of some character. Bleh.) And the number of commands actually needed might not justify the overhead of a jump table anyway.). The hc11 just loaded the srecord ascii hex file a line at a time, with a fixed delay per line, or the target sent back an '*'.

May 12, 2009 I am working with some kids at local high school that ordered a Sanguino kit to put together just after Makerbot went online. The kit was missing some.

It took 10ms a byte to burn, so who cared about speed? In AVRs, speed doesnt matter much till you start burning lots of 32K or bigger roms, but max speed happens when you can start burning a 'page' of 63 bytes for 5ms, while loading the ram buffer with the next page full. The serial port was the limiting factor back then. Not so much now with USB. I dont think any error check per packet is necessary if there is a verify. Isn't a big issue matching the PC side uploader with the bootloader? If you write your own uploader then you can write your bootloader however you wish inventing your own protocol - and I think this is the way the really tiny bootloaders are implemented.

If however you want to use avrdude as does the Aduino then you are stuck with what avrdude wants to do. Technically since the avrdude code is available you could add a section to avrdude to accommodate a special reduced bootloader protocol. My assessment at one time was that going to all that trouble wouldn't gain enough to get to the next smaller boot section size - I'm not sure this is correct, but I am sure it would be a LOT of work to find out. Quote: My assessment at one time was that going to all that trouble wouldn't gain enough to get to the next smaller boot section size - I'm not sure this is correct, but I am sure it would be a LOT of work to find out. Unless someone has already done it. Although my purpose at the moment is to add more features (EEPROM in particular) at the existing (512b) size. A nice thing about a hypothetical 256byte bootloader is that the amount of work you could possibly expend has inherent limits:-) Danni's bootloader seems to be about the same size and features as the current optiboot.

(though it has a wider range of targets and is apparently faster.).

AVR Bootloaders Bootloaders for the Atmel AVR series Written by Pascal Stang Updated: Saturday March 06, 2010 A brief word about bootloaders: Generally, a bootloader is a small program which runs at boot time and is capable of loading a complete application program into a processor's memory so that it can be exectuted. Note that the bootloader runs on the same processor into which it is loading a new program.

In the case of AVR processors, the bootloader program is usually 256-4096 assembly instuctions long and resides in a special portion of the FLASH memory called the bootblock. At boot time (when the processor has just been reset) the bootloader starts and is capable of communicating with the outside world to retrieve a new program and program it into the processor's FLASH memory. Depending on the bootloader and the available hardware, new application code can be loaded from any source including the serial port, SPI or I2C interfaces, external memory, hard disks, flash cards, etc. Once the programming is done, the bootloader program exits or the processor is reset and begins running the newly loaded code. Only AVR processors with the self-programming memory feature (those that have an SPM assembly instruction) can run a bootloader. Installing an AVR bootloader: Just like regular application code, a bootloader must be loaded into the processor's FLASH memory once when you first begin using it. Instructions on how to do this are beyond the scope of this document because it depends on which processor and hardware you are using.

Download Lagu Padi Menanti Sebuah Jawaban Versi Akustik. To continue you will need to know how to transfer a *.hex file to the AVR's FLASH memory, and how to set the processor's fuse bits. Common ways to load code and change fuse bit settings include using Atmel AVR Studio with an STK500 board, the PonyProg Programmer, UISP, or AVRdude. Use caution when modifying fuse bits. It's possible to render your microcontroller unresponsive.

The procedure for installing a bootloader is indepenent of how the bootloader works: • Program the bootloader *.hex file into your processor using traditional methods (ie. AVR Studio, PonyProg, UISP, AVRdude, etc).

Your AVR processor must match the one for which the bootloader is designed. • Set the size of your processor's bootblock to match the size of the bootloader program. • Set your processor's reset vector to point to the bootblock, not the default 0x0000 address. NOTE: AVR Studio's notation for this is somewhat confusing. When the Boot Reset Vector Enabled box is checked, your processor will run the bootloader after reset.

When this box is unchecked, the processor starts at the default 0x0000 address - ie. Runs your application after reset. Notes: • The bootblock size and reset vector can be changed by modifying your processor's fuse bits. The AVR Studio manual and/or the processor's datasheet has more information about the meaning of fuse bits and how to set them.

• AVR Studio's notation for the Boot Reset Vector is somewhat confusing. When the Boot Reset Vector Enabled box is checked, your processor will run the bootloader after reset. When this box is unchecked, the processor starts at the default 0x0000 address - ie. Runs your application after reset. To enable automatic bootloader operation, this box should be checked. • The size of the bootloader may be listed in kwords or kbytes.

Convert using kwords = kbytes/2. STKLOAD: A STK500-Emulating Bootloader This bootloader is written to emulate Atmel's well-known STK500 AVR development board. The STK500 uses a block transfer protocol to quickly program AVR processors using a standard serial port connection and ordinary RS-232 signaling. With this bootloader installed, you will be able to program your processor from Atmel AVR Studio, just like you would if you were using an STK500 board. For most processors, a complete programming cycle takes 5-10 seconds.

With the bootloader installed, your processor will act like an STK500 board for the first 3 seconds after RESET. If within these three seconds you open an STK500 programming session in AVR Studio, your processor will be automatically detected and you will be able to load new application code.

See the manual or on-line help for AVR Studio on how to do this.it's quite trivial. After loading new application code, you can exit the bootloader by pressing RESET. If no programming instructions are received over the serial port within 3 seconds after RESET, the bootloader will timeout and the currently loaded application will run automatically. NOTE: If there is no currently loaded application (ie.

The FLASH memory is blank), then the bootloader will run repeatedly until programming commands are received. Download STKLOAD: Download an appropriate bootloader for your processor from the list below. The bootloader is already compiled into a *.hex file and is ready to be programmed into your processor. Don't forget to set the fuse bits as appropriate. • Protocol v1 - STKLOAD using STK500 protocol v1 (reasonably proven) • Protocol v2 - STKLOAD using STK500 protocol v2 (alpha testing, known to be buggy) Choose Processor, Interface, and Clock.