Reply by John Devereux●September 23, 20072007-09-23
linnix <me@linnix.info-for.us> writes:
> On Sep 21, 4:04 pm, John Devereux <jdREM...@THISdevereux.me.uk> wrote:
>> "Wilco Dijkstra" <Wilco_dot_Dijks...@ntlworld.com> writes:
>> > "John Devereux" <jdREM...@THISdevereux.me.uk> wrote in messagenews:87k5qjhgc2.fsf@cordelia.devereux.me.uk...
>> >> The ST product page says that the M3 (and the STM32) is a Harvard
>> >> architecture.
>>
>> >> Does anyone know if this fact is "transparent" to code? Or do you need
>> >> different instructions to access code and data spaces? On the AVR, for
>> >> example, this causes a *lot* of problems when keeping constant data in
>> >> flash.
>>
>> > Most Harvards use a unified address space and so don't have any issues
>> > with accessing code as data. The term is used when there are instruction
>> > and data buses that can be used in parallel.
>>
>> Thanks Wilco, that's what I hoped for.
>>
>> > Pure Harvards that also have separate address spaces are rare.
>>
>> Well they are not *that* rare in microcontrollers - I thought it was
>> worth checking (and couldn't tell for sure by skimming the
>> documentation).
>
> Linear uniform address space for sure. In fact, you can run from
> flash to write new codes on sram, jump to run from sram and rewrite
> the flash. Flash, sram and I/O are all memory addresses.
>
> We have the LMI Cortex M3 for months, the STM32 is very similar,
> except for better low power modes. Power consumption is the major
> reason holding us back on using the LMI.
The STM32 does look really good. Although there are none at Digikey
yet - and I would need new debugger hardware I guess.
--
John Devereux
Reply by linnix●September 22, 20072007-09-22
On Sep 21, 4:04 pm, John Devereux <jdREM...@THISdevereux.me.uk> wrote:
> "Wilco Dijkstra" <Wilco_dot_Dijks...@ntlworld.com> writes:
> > "John Devereux" <jdREM...@THISdevereux.me.uk> wrote in messagenews:87k5qjhgc2.fsf@cordelia.devereux.me.uk...
> >> "Wilco Dijkstra" <Wilco_dot_Dijks...@ntlworld.com> writes:
>
> >> [...]
>
> >>> Running from flash is typically slower than running from SRAM (Luminary
> >>> parts being the exception). But this is not due to bandwidth limitations.
> >>> 192MBytes/s provides more than enough bandwidth for running a 16/32-bit
> >>> instruction set at 72MHz. An average instruction is ~2.7 bytes and takes
> >>> ~1.3 cycles, ie. 2.7 * 72 / 1.3 = 150MBytes/s bandwidth required.
>
> >>> So bandwidth is not an issue. The real issue with waitstates is that branches
> >>> become more expensive.
>
> >> The ST product page says that the M3 (and the STM32) is a Harvard
> >> architecture.
>
> >> Does anyone know if this fact is "transparent" to code? Or do you need
> >> different instructions to access code and data spaces? On the AVR, for
> >> example, this causes a *lot* of problems when keeping constant data in
> >> flash.
>
> > Most Harvards use a unified address space and so don't have any issues
> > with accessing code as data. The term is used when there are instruction
> > and data buses that can be used in parallel.
>
> Thanks Wilco, that's what I hoped for.
>
> > Pure Harvards that also have separate address spaces are rare.
>
> Well they are not *that* rare in microcontrollers - I thought it was
> worth checking (and couldn't tell for sure by skimming the
> documentation).
Linear uniform address space for sure. In fact, you can run from
flash to write new codes on sram, jump to run from sram and rewrite
the flash. Flash, sram and I/O are all memory addresses.
We have the LMI Cortex M3 for months, the STM32 is very similar,
except for better low power modes. Power consumption is the major
reason holding us back on using the LMI.
>
> --
>
> John Devereux
Reply by John Devereux●September 21, 20072007-09-21
> "John Devereux" <jdREMOVE@THISdevereux.me.uk> wrote in message news:87k5qjhgc2.fsf@cordelia.devereux.me.uk...
>> "Wilco Dijkstra" <Wilco_dot_Dijkstra@ntlworld.com> writes:
>>
>> [...]
>>
>>> Running from flash is typically slower than running from SRAM (Luminary
>>> parts being the exception). But this is not due to bandwidth limitations.
>>> 192MBytes/s provides more than enough bandwidth for running a 16/32-bit
>>> instruction set at 72MHz. An average instruction is ~2.7 bytes and takes
>>> ~1.3 cycles, ie. 2.7 * 72 / 1.3 = 150MBytes/s bandwidth required.
>>>
>>> So bandwidth is not an issue. The real issue with waitstates is that branches
>>> become more expensive.
>>
>> The ST product page says that the M3 (and the STM32) is a Harvard
>> architecture.
>>
>> Does anyone know if this fact is "transparent" to code? Or do you need
>> different instructions to access code and data spaces? On the AVR, for
>> example, this causes a *lot* of problems when keeping constant data in
>> flash.
>
> Most Harvards use a unified address space and so don't have any issues
> with accessing code as data. The term is used when there are instruction
> and data buses that can be used in parallel.
Thanks Wilco, that's what I hoped for.
> Pure Harvards that also have separate address spaces are rare.
Well they are not *that* rare in microcontrollers - I thought it was
worth checking (and couldn't tell for sure by skimming the
documentation).
--
John Devereux
Reply by Wilco Dijkstra●September 21, 20072007-09-21
"John Devereux" <jdREMOVE@THISdevereux.me.uk> wrote in message news:87k5qjhgc2.fsf@cordelia.devereux.me.uk...
> "Wilco Dijkstra" <Wilco_dot_Dijkstra@ntlworld.com> writes:
>
> [...]
>
>> Running from flash is typically slower than running from SRAM (Luminary
>> parts being the exception). But this is not due to bandwidth limitations.
>> 192MBytes/s provides more than enough bandwidth for running a 16/32-bit
>> instruction set at 72MHz. An average instruction is ~2.7 bytes and takes
>> ~1.3 cycles, ie. 2.7 * 72 / 1.3 = 150MBytes/s bandwidth required.
>>
>> So bandwidth is not an issue. The real issue with waitstates is that branches
>> become more expensive.
>
> The ST product page says that the M3 (and the STM32) is a Harvard
> architecture.
>
> Does anyone know if this fact is "transparent" to code? Or do you need
> different instructions to access code and data spaces? On the AVR, for
> example, this causes a *lot* of problems when keeping constant data in
> flash.
Most Harvards use a unified address space and so don't have any issues
with accessing code as data. The term is used when there are instruction
and data buses that can be used in parallel. Pure Harvards that also have
separate address spaces are rare.
Wilco
Reply by John Devereux●September 21, 20072007-09-21
> Running from flash is typically slower than running from SRAM (Luminary
> parts being the exception). But this is not due to bandwidth limitations.
> 192MBytes/s provides more than enough bandwidth for running a 16/32-bit
> instruction set at 72MHz. An average instruction is ~2.7 bytes and takes
> ~1.3 cycles, ie. 2.7 * 72 / 1.3 = 150MBytes/s bandwidth required.
>
> So bandwidth is not an issue. The real issue with waitstates is that branches
> become more expensive.
The ST product page says that the M3 (and the STM32) is a Harvard
architecture.
Does anyone know if this fact is "transparent" to code? Or do you need
different instructions to access code and data spaces? On the AVR, for
example, this causes a *lot* of problems when keeping constant data in
flash.
--
John Devereux
Reply by Ulf Samuelsson●September 21, 20072007-09-21
>> ST can run up to 24 MHz with zero waitstates.
>> At 72 MHz, they need to run with two waitstates so any load from flash
>> will be slow. The preliminary datasheet does not mentions any
>> memory accelerator, so max bandwidth to flash is in this case
>> (24 MHz * 4 bytes) = 96 MB/s.
>
> You mean 192MBytes/s as the flash is 64-bit wide. Ie. similar to the
> 200MBytes/s of the Luminary parts.
As I said, the (brief) datasheet did not make it obvious that there was a 64
bit memory.
>
>> I really doubt you can support 90 MIPS with 96 MB/s flash bandwidth,
>> so either the datasheet brief is not telling the complete story,
>> or the 90 MIPS is only when executing from SRAM
>
> Running from flash is typically slower than running from SRAM (Luminary
> parts being the exception). But this is not due to bandwidth limitations.
> 192MBytes/s provides more than enough bandwidth for running a 16/32-bit
> instruction set at 72MHz. An average instruction is ~2.7 bytes and takes
> ~1.3 cycles, ie. 2.7 * 72 / 1.3 = 150MBytes/s bandwidth required.
>
> So bandwidth is not an issue. The real issue with waitstates is that
> branches
> become more expensive.
And fetching data from flash will also be more expensive.
>
> Wilco
--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB
Reply by Wilco Dijkstra●September 21, 20072007-09-21
"Ulf Samuelsson" <ulf@a-t-m-e-l.com> wrote in message news:fcuqh0$1kd$1@aioe.org...
> "FreeRTOS.org" <noemail@address.com> skrev i meddelandet news:Ta6Ii.16975$c_1.8267@text.news.blueyonder.co.uk...
>>> Have you looked at the STM32 Cortex M3 parts from ST?
>>
>> Yep - http://www.freertos.org/portstm32iar.html
>>
>> A very nice system too. My support so far is limited to IAR. For the Stellaris parts I have a nice Eclipse setup
>> now as well as GCC, Rowley and Keil. These will be extended to cover the STM32 parts too.
>>
>>> Much smaller
>>> geometry and much lower power consumption, up to 72 MHz,
>>
>> I'm not sure that is with zero wait states though.. The Stellaris parts work at 50MHz with zero wait states. It
>> would be good to do a comparison.
>>
>
> ST can run up to 24 MHz with zero waitstates.
> At 72 MHz, they need to run with two waitstates so any load from flash
> will be slow. The preliminary datasheet does not mentions any
> memory accelerator, so max bandwidth to flash is in this case
> (24 MHz * 4 bytes) = 96 MB/s.
You mean 192MBytes/s as the flash is 64-bit wide. Ie. similar to the
200MBytes/s of the Luminary parts.
> I really doubt you can support 90 MIPS with 96 MB/s flash bandwidth,
> so either the datasheet brief is not telling the complete story,
> or the 90 MIPS is only when executing from SRAM
Running from flash is typically slower than running from SRAM (Luminary
parts being the exception). But this is not due to bandwidth limitations.
192MBytes/s provides more than enough bandwidth for running a 16/32-bit
instruction set at 72MHz. An average instruction is ~2.7 bytes and takes
~1.3 cycles, ie. 2.7 * 72 / 1.3 = 150MBytes/s bandwidth required.
So bandwidth is not an issue. The real issue with waitstates is that branches
become more expensive.
Wilco
Reply by FreeRTOS.org●September 21, 20072007-09-21
"Ulf Samuelsson" <ulf@a-t-m-e-l.com> wrote in message
news:fcuqh0$1kd$1@aioe.org...
> "FreeRTOS.org" <noemail@address.com> skrev i meddelandet
> news:Ta6Ii.16975$c_1.8267@text.news.blueyonder.co.uk...
>>> Have you looked at the STM32 Cortex M3 parts from ST?
>>
>> Yep - http://www.freertos.org/portstm32iar.html
>>
>> A very nice system too. My support so far is limited to IAR. For the
>> Stellaris parts I have a nice Eclipse setup now as well as GCC, Rowley
>> and Keil. These will be extended to cover the STM32 parts too.
>>
>>> Much smaller
>>> geometry and much lower power consumption, up to 72 MHz,
>>
>> I'm not sure that is with zero wait states though.. The Stellaris parts
>> work at 50MHz with zero wait states. It would be good to do a
>> comparison.
>>
>
> ST can run up to 24 MHz with zero waitstates.
> At 72 MHz, they need to run with two waitstates so any load from flash
> will be slow. The preliminary datasheet does not mentions any
> memory accelerator, so max bandwidth to flash is in this case
> (24 MHz * 4 bytes) = 96 MB/s.
> I really doubt you can support 90 MIPS with 96 MB/s flash bandwidth,
> so either the datasheet brief is not telling the complete story,
> or the 90 MIPS is only when executing from SRAM
>
> The AVR uC3 series, as a comparision, supports 33 MHz on first
> access and 66 MHz access on subsuquent accesses for a
> min throughput of 132 MB/s and a max throughput of 266 MB/s
> from flash.
On Sep 20, 2:41 pm, "Ulf Samuelsson" <u...@a-t-m-e-l.com> wrote:
> "FreeRTOS.org" <noem...@address.com> skrev i meddelandetnews:Ta6Ii.16975$c_1.8267@text.news.blueyonder.co.uk...
>
> >> Have you looked at the STM32 Cortex M3 parts from ST?
>
> > Yep -http://www.freertos.org/portstm32iar.html
>
> > A very nice system too. My support so far is limited to IAR. For the
> > Stellaris parts I have a nice Eclipse setup now as well as GCC, Rowley and
> > Keil. These will be extended to cover the STM32 parts too.
>
> >> Much smaller
> >> geometry and much lower power consumption, up to 72 MHz,
>
> > I'm not sure that is with zero wait states though.. The Stellaris parts
> > work at 50MHz with zero wait states. It would be good to do a comparison.
>
> ST can run up to 24 MHz with zero waitstates.
> At 72 MHz, they need to run with two waitstates so any load from flash
> will be slow. The preliminary datasheet does not mentions any
> memory accelerator, so max bandwidth to flash is in this case
> (24 MHz * 4 bytes) = 96 MB/s.
> I really doubt you can support 90 MIPS with 96 MB/s flash bandwidth,
> so either the datasheet brief is not telling the complete story,
> or the 90 MIPS is only when executing from SRAM
>
> The AVR uC3 series, as a comparision, supports 33 MHz on first
> access and 66 MHz access on subsuquent accesses for a
> min throughput of 132 MB/s and a max throughput of 266 MB/s
> from flash.
>
> If you compare power consumption, the STM32F103 will use 22 mA at 36 MHz
> and the uC3B will use 14 mA.
>
> The uC3B does not have the CAN yet, so that has to wait for the uC3C
> coming next year.
>
> The biggest drawback of the ST parts seems to be the memory configuration.
> Very few ARM7 customers are looking for less than 32 kB of SRAM.
> I see the typical size starts at 128 kB and many people want
> to migrate abnove 256 kB.
> With 6-20 kB of SRAM, and 32-128 kB of flash ST must be focusing
> more on replacing 8 bitters, than replacing other 32 bitters.
I would rate it somewhere between AVR8 and AVR32, depending on the
function. It's a much improved design than the LMI, with better power
and clock options. The 1 MSPS 12 bits A2D is a bonus. Overall, not
a bad deal for $1.80@10K for the 36MHz version.
Reply by Ulf Samuelsson●September 20, 20072007-09-20
"FreeRTOS.org" <noemail@address.com> skrev i meddelandet
news:Ta6Ii.16975$c_1.8267@text.news.blueyonder.co.uk...
>> Have you looked at the STM32 Cortex M3 parts from ST?
>
> Yep - http://www.freertos.org/portstm32iar.html
>
> A very nice system too. My support so far is limited to IAR. For the
> Stellaris parts I have a nice Eclipse setup now as well as GCC, Rowley and
> Keil. These will be extended to cover the STM32 parts too.
>
>> Much smaller
>> geometry and much lower power consumption, up to 72 MHz,
>
> I'm not sure that is with zero wait states though.. The Stellaris parts
> work at 50MHz with zero wait states. It would be good to do a comparison.
>
ST can run up to 24 MHz with zero waitstates.
At 72 MHz, they need to run with two waitstates so any load from flash
will be slow. The preliminary datasheet does not mentions any
memory accelerator, so max bandwidth to flash is in this case
(24 MHz * 4 bytes) = 96 MB/s.
I really doubt you can support 90 MIPS with 96 MB/s flash bandwidth,
so either the datasheet brief is not telling the complete story,
or the 90 MIPS is only when executing from SRAM
The AVR uC3 series, as a comparision, supports 33 MHz on first
access and 66 MHz access on subsuquent accesses for a
min throughput of 132 MB/s and a max throughput of 266 MB/s
from flash.
If you compare power consumption, the STM32F103 will use 22 mA at 36 MHz
and the uC3B will use 14 mA.
The uC3B does not have the CAN yet, so that has to wait for the uC3C
coming next year.
The biggest drawback of the ST parts seems to be the memory configuration.
Very few ARM7 customers are looking for less than 32 kB of SRAM.
I see the typical size starts at 128 kB and many people want
to migrate abnove 256 kB.
With 6-20 kB of SRAM, and 32-128 kB of flash ST must be focusing
more on replacing 8 bitters, than replacing other 32 bitters.
>> USB and CAN,
>> but no Ethernet. I was at a one-day seminar they put on last week.
>
>
> ....but the USB and CAN cannot be used simultaniously. This was one of
> the discussion points of the original thread to which I refered. The
> Stellaris parts had CAN and Ethernet, but not on the same device. The
> STM32 parts have USB and CAN, but cannot be used simultaniously.
>
> --
> Regards,
> Richard.
>
> + http://www.FreeRTOS.org
> 13 official architecture ports, 1000 downloads per week.
>
> + http://www.SafeRTOS.com
> Certified by T�V as meeting the requirements for safety related systems.
>
--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB