hello again,
here some details:
ADC_DR read:
- procedure: toggle GPIO, wait 1ms, measure ADC at connected GPIO, display IO
state and ADC result on LCD
- code snipped (correct order);
uint16_t a,b, result;
a = (uint16_t) (ADC_DR.bytel);
b = ((uint16_t) (ADC_DR.byteh)) << 8;
result = a+b;
- result for different access order:
- L+H —> 1 1023 0 0 1 1023… —> ok
- H+L —> 0 768 1 255 0 768… —> nok
As mentioned below, for ADC_DR there is actually a note in the STM8 reference
manual, so that’s ok (though for me unexpected).
TIM3_CCR1 write (TIM3 used for sleep()):
- procedure:
- init GPIOs and TIM3 with 1kHz clock
- set IO=1, sleep 1000ms, set IO=0 —> measure high duration via oscilloscope
- code snipped (correct order);
uint16_t val;
val = 1000;
TIM3_CCR1.byteH = (uint8_t) ((uint16_t) val >> 8);
TIM3_CCR1.byteL = (uint8_t) val;
…
- result for different access order:
- H+L: duration 1s —> ok
- L+H: duration 250ms —> nok
here are some more interesting observations:
- if IO is toggled in an endless loop every 1s, only the 1st period seems to be
too short
- if I sleep with alternating 256ms(=0x0100) and 255ms(=0x00FF), the IO doesn’t
toggle at all
—> I suspect that writing the low byte triggers the latching of the 16b
register by the timer hardware. So if I write in wrong order, the high byte is
latched from one period to the next. IMHO this would explain all above
observations. However, I found no respective documentation in the STM8
reference manual.
I now use the following macros for read/write of 16b SFRs, which take care of
the correct order:
// 16b register r/w access (note: order of access is important!)
#define read_SFR16(reg) ((uint16_t) (reg.byteL)) + (((uint16_t)
(reg.byteH)) << 8)
#define write_SFR16(reg, val) { reg.byteH = (uint8_t) ((uint16_t) val >>
8); reg.byteL = (uint8_t) val; }
As for other 16b registers: the above are (so far) the only ones I use which
are directly debuggable (via wrong behavior). And reading back the byte
registers gives correct values —> how can I debug this other than by strange
STM8 behavior…? Any idea would be welcome! :-)
Regards,
Georg I.
Am 18.04.2014 um 16:08 schrieb Georg Icking-Konert <ick...@onlinehome.de>:
> Hello Maarten,
>
> so far I observed it only for the ADC result register (ADC_DR) for read, and
> timer 3 compare register (TIM3_CCR) for write. The way I realized was simple:
> the ADC the result was skewed, and the TIM3 period was wrong. However, I
> didn’t dig deeper after I found out that changing the sequence helps.
>
> At least for ADC_DR there is a hint in the STM8 reference manual
> (http://www.st.com/web/en/resource/technical/document/reference_manual/CD00190271.pdf,
> page 425): "The conversion results from ADC_DRH and ADC_DRL data registers
> must be read in a specific order to guarantee data coherency. This order
> depends on the data alignment“. For TIM3_CCR I couldn’t find any such hint :-(
>
> As for automatically supporting it in SDCC I am skeptical:
> 1) apparently changing the alignment in the ADC also changes the read
> sequence (see above). And for the other registers I just don’t know —> how
> could you account for that?
> 2) if at all, I’d only support WORD read/write. Because when somebody
> performs bytewise r/w operation, he/she expects the compiler to do exactly
> that. They might be doing some advance trick (which is beyond me), and
> changing the sequence might do more harm than good
> In my STM8 header file I will now implement WORD read and write macros for
> convenience. And if someone e.g. changes ADC alignment he/she can easily swap
> the order in the macro. However, that requires that this "feature“ is
> understood and well documented...
>
> Talking of understood: do you have any idea how I can check any register
> without a debugger, let alone all? For the above mentioned it was plain
> obvious, because the STM8 clearly didn’t behave as expected. But there are
> too many 16b SFR registers with sometimes minute effect on the STM8 behavior
> to check them via their functionality alone. Any idea is appreciated!
>
> Regards, Georg I.
>
>
>
>> ------------------------------
>>
>> Message: 7
>> Date: Fri, 18 Apr 2014 09:49:36 +0200 (CEST)
>> From: "Maarten Brock" <sourceforge.br...@dse.nl>
>> Subject: Re: [Sdcc-user] r/w order for STM8 16b registers
>> To: sdcc-user@lists.sourceforge.net
>> Message-ID: <42447.82.161.160.72.1397807376.squir...@www.dse.nl>
>> Content-Type: text/plain;charset=iso-8859-1
>>
>> Hello Georg,
>>
>> Is this behaviour true for all 16 bit SFR's? Or is it different for every
>> other SFR? If it's always the same then maybe SDCC could take this into
>> account.
>>
>> Maarten
>>
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
