Going back to an old topic regarding the mix of peripherals on Stellaris parts, see:
-- Regards, Richard.
On Tue, 18 Sep 2007 12:51:32 GMT, "FreeRTOS.org" wrote in comp.arch.embedded:
Have you looked at the STM32 Cortex M3 parts from ST? Much smaller geometry and much lower power consumption, up to 72 MHz, USB and CAN, but no Ethernet. I was at a one-day seminar they put on last week.
One thing I don't like about Luminary is that you can't view or download PDF data sheets without registering.
Yep -
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.
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.
....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.
Again, yes :o)
Yes I do comparisons, I used to publish some but it is very difficult to draw any conclusions from them as different people want different things (and the arguments go on for days). What in particular are you interested in?
Out of curiosity, have you tried the Codesourcery gcc builds? I gather that the latest release has Thumb-2 and Stellaris support.
Do you ever do any comparisons between compilers, or do the commercial compilers' EULAs prevent you for saying anything about them?
mvh.,
David
I'm not looking for anything specific, I'm merely curious as to what sort of a difference the Thumb-2 changes in gcc make to code size and speed. We don't use ARM's at the moment (I use Codesourcery for their ColdFire gcc - and some day, I plan to try out the FreeRTOS MG5234 port), but ARMs are always something to consider for new projects. And of course, these arguments about compilers can be entertaining!
mvh.,
David
"FreeRTOS.org" skrev i meddelandet news:Ta6Ii.16975$c snipped-for-privacy@text.news.blueyonder.co.uk...
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.
meddelandetnews:Ta6Ii.16975$c snipped-for-privacy@text.news.blueyonder.co.uk...
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.
Did I mention that FreeRTOS.org also supports the UC3? :o)
news:Ta6Ii.16975$c snipped-for-privacy@text.news.blueyonder.co.uk...
Stellaris parts I have a nice Eclipse setup
STM32 parts too.
at 50MHz with zero wait states. It
You mean 192MBytes/s as the flash is 64-bit wide. Ie. similar to the
200MBytes/s of the Luminary parts.
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
As I said, the (brief) datasheet did not make it obvious that there was a 64 bit memory.
And fetching data from flash will also be 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
Thanks Wilco, that's what I hoped for.
Well they are not *that* rare in microcontrollers - I thought it was worth checking (and couldn't tell for sure by skimming the documentation).
messagenews: snipped-for-privacy@cordelia.devereux.me.uk...
branches
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.
messagenews: snipped-for-privacy@cordelia.devereux.me.uk...
The STM32 does look really good. Although there are none at Digikey yet - and I would need new debugger hardware I guess.
Have something to add? Share your thoughts — no account required.
Ask the community — no account required