>> Consecutive accesses to "off-platform" peripherals in the Kirin 3 have
>> up to 12 wait states, but much less (4?) if there is enough time
>> between.
>>
>> GCC delayed all write accesses to the latest possible moment (e.g.
>> function exit) resulting in much slower execution.
>
>Unfortunately, gcc only knows about the core cpu, and (AFAIK) will only
>consider pure cpu cycles and latencies when scheduling. There is no way
>for a compiler to know about off-cpu wait states.
I didn't expect this, but I can imagine a compiler not delaying
accesses without benefit. If the value isn't needed later, what is the
reason to delay writing it?
>People often think they can force the timing and ordering of execution
>and data accesses by using "volatile" - typically, peripherals will use
>"volatile" accesses. But remember that "volatile" only influences
>ordering with respect to other volatile accesses - it does not affect
I'm aware of this.
Oliver
--
Oliver Betz, Munich
despammed.com is broken, use Reply-To:
Reply by David Brown●February 27, 20132013-02-27
On 27/02/13 11:20, Oliver Betz wrote:
> David Brown wrote:
>
>>>> If you like to check out (disassembly or compiler listing) the code produced
>>>> by a C compiler, don't use a 8051. ;-( Well, even if you don't do this,
>>>
>>> and not GCC - I strongly disliked it's output for Coldfire. So much
>>> unneccesary re-ordering. And the mixed output was completely out of
>>> sync (IIRC a long standing bug).
>>
>> Which Coldfire core were you using? For the bigger cores, re-ordering
>
> CF V2 "Kirin 3" (52255).
>
>> can make a big difference to the throughput as instructions can be
>> overlapped in the longer pipelines. gcc does not re-order instructions
>> just for fun - it does it because it considers instruction scheduling
>> and memory access patterns to get the fastest code. And of course, you
>
> Consecutive accesses to "off-platform" peripherals in the Kirin 3 have
> up to 12 wait states, but much less (4?) if there is enough time
> between.
>
> GCC delayed all write accesses to the latest possible moment (e.g.
> function exit) resulting in much slower execution.
Unfortunately, gcc only knows about the core cpu, and (AFAIK) will only
consider pure cpu cycles and latencies when scheduling. There is no way
for a compiler to know about off-cpu wait states.
People often think they can force the timing and ordering of execution
and data accesses by using "volatile" - typically, peripherals will use
"volatile" accesses. But remember that "volatile" only influences
ordering with respect to other volatile accesses - it does not affect
ordering with respect to calculations or non-volatile accesses. So if
you have a write to a peripheral and you want it to be dealt with /now/,
you have to use a memory barrier as well.
>
>> can control the amount of instruction scheduling via optimisation
>> switches (at least to some extent).
>>
>> I found that for some gcc versions (I can't remember which versions or
>> which targets), mixed assembly output could get out of sync - especially
>> with "-fverbose-asm". Using the "-nopipe" option seemed to help, IIRC.
>
> thanks for the hint, although I don't expect to continue Coldfire
> development since Freescale prefers ARM Cortex now.
>
I too used to be a big Coldfire fan (and 68332 before that), but it does
not look like the architecture has a bright future. We use MPC cores
for some parts, and are moving to Cortex for many others (in the 32-bit
space).
> Oliver
>
Reply by Oliver Betz●February 27, 20132013-02-27
David Brown wrote:
>>> If you like to check out (disassembly or compiler listing) the code produced
>>> by a C compiler, don't use a 8051. ;-( Well, even if you don't do this,
>>
>> and not GCC - I strongly disliked it's output for Coldfire. So much
>> unneccesary re-ordering. And the mixed output was completely out of
>> sync (IIRC a long standing bug).
>
>Which Coldfire core were you using? For the bigger cores, re-ordering
CF V2 "Kirin 3" (52255).
>can make a big difference to the throughput as instructions can be
>overlapped in the longer pipelines. gcc does not re-order instructions
>just for fun - it does it because it considers instruction scheduling
>and memory access patterns to get the fastest code. And of course, you
Consecutive accesses to "off-platform" peripherals in the Kirin 3 have
up to 12 wait states, but much less (4?) if there is enough time
between.
GCC delayed all write accesses to the latest possible moment (e.g.
function exit) resulting in much slower execution.
>can control the amount of instruction scheduling via optimisation
>switches (at least to some extent).
>
>I found that for some gcc versions (I can't remember which versions or
>which targets), mixed assembly output could get out of sync - especially
>with "-fverbose-asm". Using the "-nopipe" option seemed to help, IIRC.
thanks for the hint, although I don't expect to continue Coldfire
development since Freescale prefers ARM Cortex now.
Oliver
--
Oliver Betz, Munich
despammed.com is broken, use Reply-To:
Reply by David Brown●February 26, 20132013-02-26
On 25/02/13 10:51, Oliver Betz wrote:
> Jukka Marin wrote:
>
>>> Grown up with 6502, using 68HC-something and Coldfire (rest in peace)
>>> for two decades, I hesitate (but don't refuse) to use 8051 controllers
>>> today. My preferred path is ARM Cortex.
>>
>> If you like to check out (disassembly or compiler listing) the code produced
>> by a C compiler, don't use a 8051. ;-( Well, even if you don't do this,
>
> and not GCC - I strongly disliked it's output for Coldfire. So much
> unneccesary re-ordering. And the mixed output was completely out of
> sync (IIRC a long standing bug).
>
Which Coldfire core were you using? For the bigger cores, re-ordering
can make a big difference to the throughput as instructions can be
overlapped in the longer pipelines. gcc does not re-order instructions
just for fun - it does it because it considers instruction scheduling
and memory access patterns to get the fastest code. And of course, you
can control the amount of instruction scheduling via optimisation
switches (at least to some extent).
I found that for some gcc versions (I can't remember which versions or
which targets), mixed assembly output could get out of sync - especially
with "-fverbose-asm". Using the "-nopipe" option seemed to help, IIRC.
> Can't wait to check the Cosmic compiler for ARM Cortex.
>
> Oliver
>
Reply by Oliver Betz●February 25, 20132013-02-25
Jukka Marin wrote:
>> Grown up with 6502, using 68HC-something and Coldfire (rest in peace)
>> for two decades, I hesitate (but don't refuse) to use 8051 controllers
>> today. My preferred path is ARM Cortex.
>
>If you like to check out (disassembly or compiler listing) the code produced
>by a C compiler, don't use a 8051. ;-( Well, even if you don't do this,
and not GCC - I strongly disliked it's output for Coldfire. So much
unneccesary re-ordering. And the mixed output was completely out of
sync (IIRC a long standing bug).
Can't wait to check the Cosmic compiler for ARM Cortex.
Oliver
--
Oliver Betz, Munich
despammed.com is broken, use Reply-To:
Reply by Jukka Marin●February 24, 20132013-02-24
On 2013-02-24, Oliver Betz <OBetz@despammed.com> wrote:
> Grown up with 6502, using 68HC-something and Coldfire (rest in peace)
> for two decades, I hesitate (but don't refuse) to use 8051 controllers
> today. My preferred path is ARM Cortex.
If you like to check out (disassembly or compiler listing) the code produced
by a C compiler, don't use a 8051. ;-( Well, even if you don't do this,
the architecture isn't good for C. (Very limited stack space, only one or
two pointers for accessing "external" memory etc.) Sure, it works, kind
of, but you can't write "normal C" for these chips.
ARM is good. A 4 GB linear memory space, 32-bit registers, etc. Your C
compiler will thank you. ;-)
-jm
Reply by Oliver Betz●February 24, 20132013-02-24
Rob Gaddi wrote:
>NXP LPC111x is a 50 MHz Cortex-M0. It's available in a 5x5mm QFN and is
I prefer visible solder joints if possible. The LPC111x are avaliable
also in TSSOP20.
>+/-1% over -40 to 85. It's got a 10-bit ADC that will do 400ksps and
>has an 8 channel mux out front.
Yes, that's great, but they seem to be rather picky regarding power
supply: "The device might not always start-up if the power supply (on
the VDD pin) does not reach 200 mV. The minimum voltage of the power
supply ramp (on the VDD pin) must be 200 mV or below with ramp-up time
of 500 ms or faster". That's very bad.
Another disadvantage (especially for small cases) is that the cyrstal
oscillator pins can't be used for I/O.
Oliver
--
Oliver Betz, Munich http://oliverbetz.de/
Reply by Oliver Betz●February 24, 20132013-02-24
Jon Kirwan wrote:
[...]
>The C8051F5xx is surprising, having the 0.5% internal timer.
>Looking over the selection guide, I see that the C8051F381
>datasheet says "Internal Oscillator: �0.25% accuracy with
>clock recovery," and elsewhere, "Internal oscillator with
Silabs has several products with internal oscillator being
synchronised to USB, e.g. an USB - UART interface running from the
internal RC oscillator. Very nice!
Grown up with 6502, using 68HC-something and Coldfire (rest in peace)
for two decades, I hesitate (but don't refuse) to use 8051 controllers
today. My preferred path is ARM Cortex.
Oliver
--
Oliver Betz, Munich http://oliverbetz.de/
Reply by Jon Kirwan●February 22, 20132013-02-22
On Sat, 23 Feb 2013 01:50:28 +0100, Oliver Betz
<OBetz@despammed.com> wrote:
>j.m.granville@gmail.com wrote:
>
>>> any suggestions for small (e.g. TSSOP20) microcontrollers with a good
>>> on-chip oscillator?
>>>
>>> One of the best I found is the 9S08 with 1% max. drift in the 0..70�C
>>> range. The 9S08 would do the job but is at it's speed limit.
>>
>>The SiLabs C8051F5xx series, spec 0.5% over –40 to +125 °C, and they are faster than the RS08 ?
>
>Thanks for you rsuggestion.
>
>The frequency stability is even better than their CM3 controllers.
>
>But the TSSOP types have very little memory, and I'm not sure whether
>they are faster than a 9S08 (not RS08). The ADC is much slower.
>
>Oliver
I've used SiLabs' C8051F061. It has two 1MHz 16 bit ADCs on
it -- nobody has them that fast on-chip. But it's internal
osc is 2%, sadly. (You absolutely MUST use the DMA to get the
data into memory fast enough.)
The C8051F5xx is surprising, having the 0.5% internal timer.
Looking over the selection guide, I see that the C8051F381
datasheet says "Internal Oscillator: ±0.25% accuracy with
clock recovery," and elsewhere, "Internal oscillator with
±0.25% accuracy supports all USB and UART modes."
http://www.silabs.com/Support%20Documents/TechnicalDocs/C8051F38x.pdfhttp://www.silabs.com/Support%20Documents/Software/C8051F380-USB-MCU-overview.pdf
The 10-bit ADC is "up to 500 ksps."
Jon
Reply by Rob Gaddi●February 22, 20132013-02-22
On Sat, 23 Feb 2013 01:50:28 +0100
Oliver Betz <OBetz@despammed.com> wrote:
> j.m.granville@gmail.com wrote:
>
> >> any suggestions for small (e.g. TSSOP20) microcontrollers with a good
> >> on-chip oscillator?
> >>
> >> One of the best I found is the 9S08 with 1% max. drift in the 0..70�C
> >> range. The 9S08 would do the job but is at it's speed limit.
> >
> >The SiLabs C8051F5xx series, spec 0.5% over –40 to +125 °C, and they are faster than the RS08 ?
>
> Thanks for you rsuggestion.
>
> The frequency stability is even better than their CM3 controllers.
>
> But the TSSOP types have very little memory, and I'm not sure whether
> they are faster than a 9S08 (not RS08). The ADC is much slower.
>
> Oliver
> --
> Oliver Betz, Munich http://oliverbetz.de/
NXP LPC111x is a 50 MHz Cortex-M0. It's available in a 5x5mm QFN and is
+/-1% over -40 to 85. It's got a 10-bit ADC that will do 400ksps and
has an 8 channel mux out front.
--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.