Re: [Simulavr-devel] New feature: read in signatue, lock bits and fuses from elf, if available

[ThomasK]

Hi Raphael,

> Let's imagine you instead change the '-d' option behaviour, and make it 
> non-mandatory option :
> - if not present, ELF signature should be present, and will be used to
>   define the AVR. If no signature in ELF : exit and error "can't guess device, use 
> -d"
> - if '-d' given,
>   - (*)if EFL signature found : should match, or exit and descriptive error is fired 'signature 
>     mismatch: ELF says xxx, and you asked for xxx'
>   - if no signature found (that's kinda 'historical' behaviour), '-d' works as
>     before
>
> (*) In that case, as you said, backward compatibility may be broken. An atmel 
> ELF
> production file containing atmega16 (for example) signature that
> previously loaded with '-d atmega32' option would now fail, requiring
> either to fix the ELF, on the command line.
> Never good to break compatibility, I fight for that...but only if it's
> not to fix a 'bug'.

Ok, as nobody else had a objection, I will not implement this "disable 
signature check" option.

But this idea, to guess and choose the device from signature in elf 
file, if available, isn't bad. But I'm not sure, how often avr developer 
 compile and link in signature in elf file. For simulation self its not 
necessary, for building and flashing production code too. (because 
signature can't be flashed) Maybe sometime anybody has a good reason and 
suggestion for this ...

In the moment it's more interresting to find out, which controller has 
which fuses and lock bits, maybe connect some of this bits with 
functionality of the simulator core. Especially documentation for 
ATmega48/88/168/328 is wrong, as I found out. It describes reading of 
signature by program but SPMCSR register hasn't the needed bits for 
that. ATtiny2313A can read signature by program, but ATtiny2313 can't. 
And so one ... I think, I have to write some questions to atmel and to 
wait for answers.

> Yes, I'm interested in trying it, as I'm right now dealing with thoses
> special sections.

I'll upload it and write you, if it's available on the repo. Hold in 
mind, that this is work in progress. So I hold it in a special branch, 
which will be removed, if this change is in production state and 
overtaken in master branch.


cu, Thomas