AVR trivia question

"larwe" <zwsdotcom@gmail.com> wrote in message 
news:1154872927.566773.5910@m79g2000cwm.googlegroups.com...

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

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

"larwe" <zwsdotcom@gmail.com> skrev i meddelandet 
news:1154872927.566773.5910@m79g2000cwm.googlegroups.com...
>
> Ulf Samuelsson wrote:
>
>> > 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
>>
>> Once you have specified the fuse setting in an AVR studio project,
>> you can use that project as a template.
>
> 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 is definitely on the wishlist, and regularily comes up in internal 
communications,
but there are a lot of things on the wishlist unfortunately

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

Feel free to send suggestions like this to avr at atmel dot com.
If enough complain, then priority may eventually be raised.

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

Mike Harrison wrote:
> On Sat, 5 Aug 2006 22:38:53 -0400, "mc" <look@www.ai.uga.edu.for.address> wrote:
>
> >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.
> >
> 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.

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.

On 6 Aug 2006 11:46:56 -0700, "linnix" <me@linnix.info-for.us> wrote:

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

High Voltage Parallel Programming ALWAYS works.

Mit freundlichen Gr&#4294967295;&#4294967295;en

Frank-Christian Kr&#4294967295;gel

Frank-Christian Kruegel wrote:
> On 6 Aug 2006 11:46:56 -0700, "linnix" <me@linnix.info-for.us> wrote:
>
> >> No - this is one the dumbest things Atmel have (not) done - it is trul=
y insane that you can't have a
> >> single hex file that contains ALL the info for a chip.
> >
> >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.
>
> High Voltage Parallel Programming ALWAYS works.

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.

>=20
> Mit freundlichen Gr=FC=DFen
>=20
> Frank-Christian Kr=FCgel

Mike Harrison wrote:
> On Sat, 5 Aug 2006 22:38:53 -0400, "mc" <look@www.ai.uga.edu.for.address> wrote:
> 
> 
>>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.
>>
> 
> 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. 

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

larwe wrote:
> Ulf Samuelsson wrote:
> 
> 
>>>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
>>
>>Once you have specified the fuse setting in an AVR studio project,
>>you can use that project as a template.
> 
> 
> 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.

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

On 6 Aug 2006 12:35:30 -0700, "linnix" <me@linnix.info-for.us> wrote:

>                                                           For some
>newer chips, parallel mode can also be disabled by fuses.

Which ones?

Mit freundlichen Gr&#4294967295;&#4294967295;en

Frank-Christian Kr&#4294967295;gel

Jim Granville wrote:
>  What Atmel should do (have done), is simply specify a HEX file
> mapping that INCLUDES the fuses, in the data sheets.

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

-Mike

Mike Warren wrote:
> Jim Granville wrote:
> 
>> What Atmel should do (have done), is simply specify a HEX file
>>mapping that INCLUDES the fuses, in the data sheets.
> 
> 
> Atmel have done this? I couldn't find any documentation. Can you
> point me to it?

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