There isn't a way to specify the fuse bit settings of the Atmel AVR as directives in the assembly language program, is there? Have I overlooked something? It seems awkward to have to begin every program with a comment telling me what boxes to check on the STK500 "Fuses" menu.
I wrote a small Java program to maintain batchfiles for the command line version of the programmer. I just select the correct batchfile and then programm lots of processors :-).
Regards, Kurt
--
Kurt Harders
PiN -Präsenz im Netz GITmbH
mailto:news@kurt-harders.de
http://www.pin-gmbh.com
No - this is one the dumbest things Atmel have (not) done - it is truly insane that you can't have a single hex file that contains ALL the info for a chip. As a consultant who writes code for customers who then have to integrate the code into their own production systems it is an utter nightmare and always causes problems. With PICs I give them one file - Job Done.
When I talked to an Atmel guy at a seminar a while ago, their primary excuse for this mess was 'we don't make production programmers'. What nonsense. It is up to the manufacturet to define how such things shold be done, so that third-party suppliers can all use the same standard.
It may have been less of a problem when AVRs had a small handful of fuse settings that most users didn't need, but on the current devices theer are so many fuse settings that can screw things up, some in somewhat subtle ways (e.g. osc options that work but draw more power), that not being able to embed them is just totally brain-damaged.
I ended up making my own. As you say, it doesn't follow any standard but allows all settings including the EEPROM in a single production file. Runs on Windows 98/2000/XP using a parallel port and programming is a single button press.
The same program becomes my dev programmer when switched to development mode.
Well, if we're going to list ugly workarounds that don't work for gang-programming and shouldn't be necessary anyway, the way I do it is to use avrdude as my programming software, and embed the fuse settings in my Makefile.
Ulf, this really sucks. For every other micro I use, I can give a single HEX (or .TXT, for MSP430) to test engineering, and a checksum that covers every byte of the device including the fuse settings.
It's not like Atmel would have to make any silicon changes; just tell vendors a standard method for adding a fake memory segment to the end of the .HEX file with a magic start address that means "here be fuses". While you're about it, roll the EEPROM data in there as well.
Same here. Well, almost -- I did it up with Perl. Handles the program & fuse setting and verification, squawks to the user if there's a problem with communication or either verification pass. Saves me from those embarrassing lapses of memory when shifting from programming the duty lab bench processor to the tube of new ones for production. Not that
*I've* ever forgotten to switch from the internal clock to the external crystal, I've ahhh just heard about it, yeah, that's it ... ;-)
No, that's the second dumbest things. IMHO, the dumbest things is to disable Jtag (or other programming modes) with the fuses. Once it's messed up, there is no way to reset them to factory defaults.
Correct. What Atmel should do (have done), is simply specify a HEX file mapping that INCLUDES the fuses, in the data sheets. Some other vendors do this.
As Mike says, it then creates a standard everyone follows. It also solves the OP's question, of how to control the fuses from the Source, and get a COMPLETE programming spec into ONE HEX file, for production. Anything less, is poor version control.
The programmer I have here, has a save-project option, that includes all the fuse settings, ( and other controls ), but there is no way to LOAD that fuse setting from a new design, other than manually. The programmer vendor has done all they can, without a HEX file spec on Fuses.
There already IS something of a defacto standard on EEPROM appended Data - but it would be good to make that more documented.
The Fuse info should go into spare space at 'Code-top', and in those rare cases where the Chip code, and assembler MAX are identical, a separate hex segment needs to be (optionally?) used - slightly more effort, but still do-able.
OOps, [Sorry to get your hopes up..... ] Re-reading that, I should have more correctly written (have done?) or this What Atmel should do (_should_ have done)...
Ah, ok. In that case I propose that my system becomes the standard. ;-)
If anyone wants my program and the circuit of the simple hardware you are welcome to it. Just ask. I have already given it to a couple of people. If there is some interest I'll put it up on a web page.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.