EmbeddedRelated.com
Forums

ST ARM versus Atmel ARM?

Started by John-Smith May 18, 2014
Ulf Samuelsson <ulf@notvalid.emagii.com> writes:
> As for longevity, the AT91M40800 was released in 1997-8, and is still > in production.&#836; (Actually this was the AT9140400, but they added > an additional 4 kB of RAM)
Do you mean the AT9140400 was introduced in 1997-8 and quietly replaced with a larger part sometime between then and now?
> ... Atmel has released pincompatible AVR devices with more features, > and when those are in production, the older devices has been > obsoleted. This philosophy has been changed a couple of years ago...
Yes, I'd have thought "longevity" means you get the exact same part.
"Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> wrote

>> IAR >> compilers used to be good but they did contain some really bad details >> e.g. an incredibly slow sscanf() where they were doing multiple >> floating point ops for every single input digit. > >I'm curious which target processor and which version that was, but AFAICS >recent libs don't use floating point math when dealing with integers and >you can choose between different printf/scanf formatter features.
It was their Z80/Z180 compiler. In that case we were using sscanf() to parse strings like 123.45 into 32-bit floats. The code was profiled with a real hardware ICE (those were the days!) and we found it was spending ~99% of its time in the function, which was doing a float add and a float mult (by 10!) for every digit.
What about code and fixed data security?

On chip flash ought to be reasonably good for that. This is not a high
security application but it would be nice if I could protect the on
chip stuff from a casual code dump.
2014-05-20 17:44, Paul Rubin skrev:
> Ulf Samuelsson <ulf@notvalid.emagii.com> writes: >> As for longevity, the AT91M40800 was released in 1997-8, and is still >> in production.&#836; (Actually this was the AT9140400, but they added >> an additional 4 kB of RAM) > > Do you mean the AT9140400 was introduced in 1997-8 and quietly replaced > with a larger part sometime between then and now? > >> ... Atmel has released pincompatible AVR devices with more features, >> and when those are in production, the older devices has been >> obsoleted. This philosophy has been changed a couple of years ago... > > Yes, I'd have thought "longevity" means you get the exact same part. >
Yes, Same process/package etc so it was more like a revision of the chip. BR Ulf Samuelsson
2014-05-20 22:45, John-Smith skrev:
> What about code and fixed data security? > > On chip flash ought to be reasonably good for that. This is not a high > security application but it would be nice if I could protect the on > chip stuff from a casual code dump. >
On chip flash is of course more secure than off chip flash. Then again, the extra security is going to be quite expensive. There are micros with AES/3DES crypto engines which can be used to encrypt external data. Some of those chips have export restriction, but the XMEGA does not. If you want STM32 witrh M4F (FPU) core, then Digikey only sells maximum 256 kB versions. Atmel has 512kb/1MB versions. BR Ulf Samuelsson
Ulf Samuelsson <ulf@notvalid.emagii.com> writes:

> 2014-05-18 12:18, John-Smith skrev:
[...]
>> >> I' be very interested in hearing peoples' views on this. I really want >> a 10 year life of the actual device. >> > > > Hi John, > As a former Atmel FAE, I can give you a little info on the Atmel part. > > As for longevity, the AT91M40800 was released in 1997-8, and is still > in production.&#836; (Actually this was the AT9140400, but they added > an additional 4 kB of RAM) > The ARM devices has had much longer life time than the AVRs. > This is mostly because Atmel has released pincompatible AVR devices > with more features, and when those are in production, the older > devices has been obsoleted. This philosophy has been changed > a couple of years ago, so expect longer lifetime even on AVRs. > > I would still expect longer lifetime on ARMs still. > > With Atmel, you have the gcc based Atmel Studio, which is free of charge > and supports both AVR, AVR32 and ARM. This is more like Visual Studio > than Eclipse. They connect to low cost JTAG-ICE or SAM-ICE which is > a lower priced version of the Segger J-Link used by IAR. > The low price is good, but they will only work with Atmel parts, > and when Atmel releases a new part, you will have to update > the firmware. > > If you need floating point, then the AVR32 UC3C is quite nice > due to its internal floating point unit. There are some SAM4's with > floating point unit as well. > > Both the SAM4s and the AVR32s has I2S support, and each I2S is > connected to dual buffered DMA both on transmit and receive sides. > You should have ZERO problem maintaining 100 kbps on I2S. > > Also each serial port is connected to dual buffered DMA controllers > in each direction, with some nice additions like idle detection. > > You can easily run the serial ports at megabit speed without problems. > > Flash is generally quite expensive while onchip, and an external > dataflash or SPI flash will be quite small, and much cheaper.
Hi Ulf, Trouble with dataflash is that Atmel sold the product line to a company whose fab went bust -> instant unobtainium. How do I know this I hear you all ask... :( I don't think they have any significant advantages over normal modern SPI flash anyway, just twice the price and vendor-lockin to a non-existent product. -- John Devereux
Ulf Samuelsson <ulf@notvalid.emagii.com> writes:
> If you want STM32 witrh M4F (FPU) core, then Digikey only sells > maximum 256 kB versions. Atmel has 512kb/1MB versions.
I think that http://www.digikey.com/product-detail/en/STM32F407VGT6/497-11605-ND is the part on the STM M4 Discovery board. It has 1M flash, 192k ram, and some crypto acceleration and secure boot IIRC.
Paul Rubin <no.email@nospam.invalid> writes:

> Ulf Samuelsson <ulf@notvalid.emagii.com> writes: >> If you want STM32 witrh M4F (FPU) core, then Digikey only sells >> maximum 256 kB versions. Atmel has 512kb/1MB versions. > > I think that > > http://www.digikey.com/product-detail/en/STM32F407VGT6/497-11605-ND > > is the part on the STM M4 Discovery board. It has 1M flash, 192k ram, > and some crypto acceleration and secure boot IIRC.
RAM FLASH Clock Temp. Price P/N (KB)(KB) MAC PHY Crypto UARTS CAN I2C ADC (MHz) Range (USD) http://tinyurl.com/oakwg9t MK60FN1M0VLQ12 256 1024 y y y 6 2 2 4 16-bit 120 -40 to 105 6.69 (10KU) http://www.newark.com/freescale-semiconductor/mk60fn1m0vlq12/mcu-32bit-cortex-m4-120mhz-lqfp/dp/89T6229 -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
Randy Yates <yates@digitalsignallabs.com> wrote:
> Paul Rubin <no.email@nospam.invalid> writes: >> Ulf Samuelsson <ulf@notvalid.emagii.com> writes: >>> If you want STM32 witrh M4F (FPU) core, then Digikey only sells >>> maximum 256 kB versions. Atmel has 512kb/1MB versions. >> I think that >> http://www.digikey.com/product-detail/en/STM32F407VGT6/497-11605-ND >> is the part on the STM M4 Discovery board. It has 1M flash, 192k ram, >> and some crypto acceleration and secure boot IIRC. > RAM FLASH Clock Temp. Price > P/N (KB)(KB) MAC PHY Crypto UARTS CAN I2C ADC (MHz) Range (USD) > http://tinyurl.com/oakwg9t MK60FN1M0VLQ12 256 1024 y y y 6 2 2 4 16-bit 120 -40 to 105 6.69 (10KU) > > http://www.newark.com/freescale-semiconductor/mk60fn1m0vlq12/mcu-32bit-cortex-m4-120mhz-lqfp/dp/89T6229
Might be worth pointing out that the Kinetis parts don't have hardware floating point (ie. Cortex-M4 as opposed to Cortex-M4F). -a
John Devereux <john@devereux.me.uk> wrote

>Hi Ulf, > >Trouble with dataflash is that Atmel sold the product line to a company >whose fab went bust -> instant unobtainium. How do I know this I hear >you all ask... :( > >I don't think they have any significant advantages over normal modern >SPI flash anyway, just twice the price and vendor-lockin to a >non-existent product.
Great! Anyway, I can do all I need with 1MB on chip flash. It needs to be secure enough that somebody can't just read it straight out. Presumably that must be possible - even the little micros have such a mode.