>> Well, in the copy of slau049f I just downloaded, the description
>> got changed. It now says
Lucky me, I used Rev.D. D like Dooh :)
To detect and correct this problem was quite simple - I just want to
share this discovery with someone who might be interested. But it looks
like Rev.F fixes this - except the SA/DTC order...
>> Ooh! I just spotted the source of confusion! 18.2.7 shows ADC10SA
>> being written before ADC10DTC1. I bet a lot of people copied that...
I think so too - but they will realize that nothing will happen :-)
waiting for Rev.G,
matthias
m...@horizon.com schrieb:
and the ADC10DTC0 Register Description says:
ADC10B1 - ADC10 block one.
This bit indicates for two-block mode which block is filled
with ADC10 conversion results. ADC10B1 is valid only after ADC10IFG has
been set the first time during DTC operation. ADC10TB must also be set
0 Block 1 is filled
1 Block 2 is filled
my software test showed up that the Two-Block Transfer Mode section is
correct and the ADC10DTC0 Register Description seems to be wrong.
In my understanding these two descriptions are conflicting.
What do you think ?
Well, in the copy of slau049f I just downloaded, the description
got changed. It now says
ADC10B1 Bit 1 ADC10 block one. This bit indicates for two-block mode which
block is filled
with ADC10 conversion results. ADC10B1 is valid only after
ADC10IFG has
been set the first time during DTC operation. ADC10TB must also
be set
0 Block 2 is filled
1 Block 1 is filled
But the state machine makes it obvious that 0 means "Block 1 is BEING
filled", while 1 means "Block 2 is BEING filled". That bit is which
block (which I'd rather call 0 and 1) the hardware is working on.
Software gets to look at the other block (which HAS BEEN filled).
I prefer that definition because it also makes overflow behavior clear; if
you take too long to read the output block, the bit will be toggled again.
It also doesn't require that confusing bit about "valid only after
ADC10IFG has been set the first time". Yes, until the first interrupt,
*neither* has been filled, but the bit *is* valid. It's not like
you don't have to initialize it properly.
But, more importantly, after staring at the state machine for a bit,
I can see the designer's intentions, so the foibles of the documentation
are less important.
I'd document it as
ADC10B1 Bit 1 ADC10 block one. This bit indicates, for two-block mode,
which block is being filled with ADC10 conversion results.
When the block is complete, it is toggled by hardware at
the same time as ADC10IFG is set, after which it can
be used to infer which block has been filled.
0 Block 1 is being filled (block 2 has been filled)
1 Block 2 is being filled (block 1 has been filled)
Ooh! I just spotted the source of confusion! 18.2.7 shows ADC10SA
being written before ADC10DTC1. I bet a lot of people copied that...
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
