[quote:d316352a1c="Evert :-)"]But the other conclusion we can make is that the Bascom simulator does not handle it good.
It's shows the correct value instead the wrong.[/quote:d316352a1c]
So does AVR-Studio's simulator from 4.1 to 6.1
So what?
[quote:d316352a1c]$regfile = "m328pdef.dat".
Dim Dummy As Word
Icr1 = 4096
!LDS R17, {ICR1+1} ' read ICR wrong, high byte first
!LDS R16, {ICR1+0} ' read ICR wrong, low byte second
!STS {Dummy+0}, R16 ' save it to Dummy
!STS {Dummy+1}, R17
' now you'll find &h01000, &b0001000000000000 in SRam at &h0100..0101
' which would be the desired value, only if reading of ICR would have been done right
end[/quote:d316352a1c]
I wouldn't put higher standards on Bascom, than Atmel does itself.
You may have noticed from the old thread, that the TO uses the ICR-register in way, which may work or not, see my quote from the data sheet:
[quote:d316352a1c]The ICR1 Register can only be written when using a Waveform Generation mode that utilizes the ICR1 Register for defining the counters TOP value.[/quote:d316352a1c]
The TO does not use a waveform mode, in fact he doesn't use the timer at all. So how does this translate?
From the logic statement of this sentence, it translates that: no waveform mode where ICR is top = no write to ICR.
No such waveform mode was used, which results in: no write to ICR, the TO didn't care and did it anyway.
Was this undefined? Imho no.
But if undefined - how would you believe, a simulator should handle undefined behaviour?
Step down to the tiniest bits and handle things on an quasi sub-atomar base, only because the user doesn't read the data sheet?
The positive thing is, such details often show up by the way, while something's done wrong or in an unusual way, which was the case here.
Beyond that insight, it isn't worth making too much buzz about it.
↧
