AVR trivia question

No. This is a FAQ. Yes, it's annoying.

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

"mc" skrev i meddelandet news:%CcBg.14402$ snipped-for-privacy@bignews1.bellsouth.net...

Once you have specified the fuse setting in an AVR studio project, you can use that project as a template.

--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB

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.

You expect production to use AVR Studio and have the whole project, including source files there..?

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.

-Mike

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 ... ;-)

--
Rich Webb   Norfolk, VA

So the STK fuse menu is stored in the project file?

Hear, hear! The .hex file should contain everything needed to program the micro.

that you can't have a

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.

insane that you can't have a

High Voltage Parallel Programming ALWAYS works.

Mit freundlichen Grüßen

Frank-Christian Krügel

y insane that you can't have a

But it takes more than 20 pins to do that, vs 8 for Jtag. For some newer chips, parallel mode can also be disabled by fuses.

that you can't have a

code into their own

for this mess was 'we

manufacturet to define how such

standard.

settings that most users

can screw things up,

that not being able

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.

-jg

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.

-jg

Which ones?

Mit freundlichen Grüßen

Frank-Christian Krügel

Atmel have done this? I couldn't find any documentation. Can you point me to it?

-Mike

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)...

-jg

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.

-Mike