32-bit MCU-family inquiry

[P_B]

Hi everyone!

This is my first post here :)

I'm interested in making a platform which has an 32-bit MCU as the central
component. This platform is supposed to be configurable, i.e. do things
that an 8-bit MCU can handle OR do more advanced signal processing.
What I have come up with is ARM Cortex M. From what I've read on the
internet is that NXP has pin- & software-compatible devices in Cortex M0,
M3 and M4.
In addition, STMicroelectronics will have the same this year, they
currently only have Cortex M3 and M4.

I would like to hear some reviews from you guys on the NXP and ST devices.

What would you recommend if you don't want to recommend these, Renesas,
Microchip etc. I am open to all suggestions.
I don't have special criterias at this point, not more than low cost and
low power consumption. But those are almost always criterias, I guess.

Really appreciate any input!!


/P








---------------------------------------
Posted through http://www.EmbeddedRelated.com

[Rich Webb]

On Mon, 30 Jan 2012 07:24:21 -0600, "P_B"
<patrik.bjorklund@n_o_s_p_a_m.rejlers.se> wrote:

>Hi everyone!
>
>This is my first post here :)
>
>I'm interested in making a platform which has an 32-bit MCU as the central
>component. This platform is supposed to be configurable, i.e. do things
>that an 8-bit MCU can handle OR do more advanced signal processing.
>What I have come up with is ARM Cortex M. From what I've read on the
>internet is that NXP has pin- & software-compatible devices in Cortex M0,
>M3 and M4.
>In addition, STMicroelectronics will have the same this year, they
>currently only have Cortex M3 and M4.
>
>I would like to hear some reviews from you guys on the NXP and ST devices.

They both work. I've used both and will use both in the future. As to
which family is "better" for some definition of better and for a given
application, that's why we get the big bucks to make a sensible choice.
Read the datasheets and errata and look to see if what you want to do
can be mapped onto a given device.

--
Rich Webb Norfolk, VA

[P_B]

>
>They both work. I've used both and will use both in the future.
>

>--
>Rich Webb Norfolk, VA
>

Which compiler(s) did you use, if I may ask?

[Rich Webb]

On Mon, 30 Jan 2012 08:31:26 -0600, "P_B"
<patrik.bjorklund@n_o_s_p_a_m.rejlers.se> wrote:

>
>>
>>They both work. I've used both and will use both in the future.
>>
>>--
>>Rich Webb Norfolk, VA
>>
>
>Which compiler(s) did you use, if I may ask?

I'm using Rowley's CrossWorks now. Handles all the ARM varieties I've
come across (and many that I'll probably never see!) and supports a
large number of JTAG pods, including the old Macraigor Wigglers and the
inexpensive Olimex ARM-USB as well as the "majors" like the Segger
J-Link, plus their own model. It's based on gcc with their own non-GPL
libraries.

[MK]

On 30/01/2012 13:24, P_B wrote:
> Hi everyone!
>
> This is my first post here :)
>
> I'm interested in making a platform which has an 32-bit MCU as the central
> component. This platform is supposed to be configurable, i.e. do things
> that an 8-bit MCU can handle OR do more advanced signal processing.
> What I have come up with is ARM Cortex M. From what I've read on the

> internet is that NXP has pin-& software-compatible devices in Cortex M0,

> M3 and M4.
> In addition, STMicroelectronics will have the same this year, they
> currently only have Cortex M3 and M4.
>
> I would like to hear some reviews from you guys on the NXP and ST devices.
>
> What would you recommend if you don't want to recommend these, Renesas,
> Microchip etc. I am open to all suggestions.
> I don't have special criterias at this point, not more than low cost and
> low power consumption. But those are almost always criterias, I guess.
>
> Really appreciate any input!!
>
>
> /P
>
>
>
>
>
>
>
>
> ---------------------------------------
> Posted through http://www.EmbeddedRelated.com

Currently ST have M3 and M4, NXP have M0 and M3, TI have M3 and R4 (you
probably don't want this) and Freescale have M4. There are others.

The price difference between M0 and M3 in the same footprint is small
and using a low pin count will keep you from using the better M3 and M4s.
If I were you (and bear in mind I don't know the whole story) I would go
for M3/M4 from ST because you can get them now and if you ever hit
volumes where it is worth using M0 you can re-spin the board. (10k off
you can get an ST M3 for <£0.60, so even if the M0 is half the price
(and it won't be that cheap) you can only save £0.3 per board.

When it comes the NXP M4 looks very nice with an M0 in one corner
sharing the memory and peripherals and lots of new and innovative stuff.
Obviously too much new stuff because they seem to be taking a very long
time to get it out to market.

Michael Kellett

[Jim Granville]

On Jan 31, 2:24 am, "P_B" <patrik.bjorklund@n_o_s_p_a_m.rejlers.se>
wrote:

> Hi everyone!
>
> This is my first post here :)
>
> I'm interested in making a platform which has an 32-bit MCU as the central
> component. This platform is supposed to be configurable, i.e. do things
> that an 8-bit MCU can handle OR do more advanced signal processing.

When you say platform, do you mean Chip, or Eval-Module level ?

Many vendors make 32 bit micros, but the cost of entry-level boards
varies quite a lot.

eg On the ARM front ST and Nuvoton have low cost entry level boards;
Microchip have one that comes with Multiple samples, covering more
than one of their cores.
Atmel have a AT32UC3L0-XPLD, for their AVR32....
- and new entrant Infineon have an M4 in release, with what looks (so
far) to be good Software and Eval support.

You might want to look at the peripherals on these variants, as they
can vary more than the cores...

-jg

[P_B]

>>
>> ---------------------------------------
>> Posted through http://www.EmbeddedRelated.com
>
>Currently ST have M3 and M4, NXP have M0 and M3, TI have M3 and R4 (you
>probably don't want this) and Freescale have M4. There are others.
>
>The price difference between M0 and M3 in the same footprint is small
>and using a low pin count will keep you from using the better M3 and M4s.
>If I were you (and bear in mind I don't know the whole story) I would go
>for M3/M4 from ST because you can get them now and if you ever hit
>volumes where it is worth using M0 you can re-spin the board. (10k off
>you can get an ST M3 for <�0.60, so even if the M0 is half the price
>(and it won't be that cheap) you can only save �0.3 per board.
>
>When it comes the NXP M4 looks very nice with an M0 in one corner
>sharing the memory and peripherals and lots of new and innovative stuff.
>Obviously too much new stuff because they seem to be taking a very long
>time to get it out to market.
>
>Michael Kellett
>

Hi Michael!

This gave me a lot to think about!!
I like your arguments.
An ST M3 definitely sounds like the best choice now. In addition, I just
found out that 12-bit ADC is needed, so if I wanted to go for NXP, I would
have to go for an external ADC or use an "overkill" M3.

I have been using IAR compiler for alot of other MCU-families. So using it
for ARM as well, seems like a natural step.
Anyone have something bad to say about the IAR ARM compiler?! If yes, can
you specify?

[P_B]

>When you say platform, do you mean Chip, or Eval-Module level ?
>
>Many vendors make 32 bit micros, but the cost of entry-level boards
>varies quite a lot.
>
>eg On the ARM front ST and Nuvoton have low cost entry level boards;
>Microchip have one that comes with Multiple samples, covering more
>than one of their cores.
>Atmel have a AT32UC3L0-XPLD, for their AVR32....
>- and new entrant Infineon have an M4 in release, with what looks (so
>far) to be good Software and Eval support.
>
>You might want to look at the peripherals on these variants, as they
>can vary more than the cores...
>
>-jg
>

Hi

With platform I mean a platform which can be used for different projects
that have a lot of things in common, but also can have individual things.
This is for professional stuff, just to be clear.

I just come to think about one criteria, an MCU-family, which currently
does NOT have a huge errata-list. So, something that has been around for a
couple of years is better, I think.

[Boudewijn Dijkstra]

Op Tue, 31 Jan 2012 09:26:57 +0100 schreef P_B
<patrik.bjorklund@n_o_s_p_a_m.rejlers.se>:

> I have been using IAR compiler for alot of other MCU-families. So using
> it for ARM as well, seems like a natural step.
> Anyone have something bad to say about the IAR ARM compiler?! If yes, can
> you specify?

Not all architectures that IAR support receive the amount of attention
that you might expect, but I think it is quite likely that ARM is the
architecture that receives most of their attention.


--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/
(Remove the obvious prefix to reply privately.)

[John Devereux]

"P_B" <patrik.bjorklund@n_o_s_p_a_m.rejlers.se> writes:

>>>
>>> ---------------------------------------
>>> Posted through http://www.EmbeddedRelated.com
>>
>>Currently ST have M3 and M4, NXP have M0 and M3, TI have M3 and R4 (you
>>probably don't want this) and Freescale have M4. There are others.
>>
>>The price difference between M0 and M3 in the same footprint is small
>>and using a low pin count will keep you from using the better M3 and M4s.
>>If I were you (and bear in mind I don't know the whole story) I would go
>>for M3/M4 from ST because you can get them now and if you ever hit
>>volumes where it is worth using M0 you can re-spin the board. (10k off

>>you can get an ST M3 for <�0.60, so even if the M0 is half the price
>>(and it won't be that cheap) you can only save �0.3 per board.

>>
>>When it comes the NXP M4 looks very nice with an M0 in one corner
>>sharing the memory and peripherals and lots of new and innovative stuff.
>>Obviously too much new stuff because they seem to be taking a very long
>>time to get it out to market.
>>
>>Michael Kellett
>>
>
> Hi Michael!
>
> This gave me a lot to think about!!
> I like your arguments.
> An ST M3 definitely sounds like the best choice now. In addition, I just
> found out that 12-bit ADC is needed, so if I wanted to go for NXP, I would
> have to go for an external ADC or use an "overkill" M3.

Be aware that internal ADCs tend to be poor performers, in terms of
noise and linearity, compared to external ones. However you have a lot
of processing power available to you so may be able to compensate for
this if important. For example, using signal averaging and/or
linearization. And the STM32 ADCs are the most powerful I have seen in
terms of flexibility and features.

> I have been using IAR compiler for alot of other MCU-families. So using it
> for ARM as well, seems like a natural step.
> Anyone have something bad to say about the IAR ARM compiler?! If yes, can
> you specify?

It's not gcc :)

--

John Devereux

[Hans-Bernhard Bröker]

On 31.01.2012 09:35, P_B wrote:

> I just come to think about one criteria, an MCU-family, which currently
> does NOT have a huge errata-list. So, something that has been around for a
> couple of years is better, I think.

Careful what you wish for. Absence of a huge list of errata list right
now might just turn out to mean that the errata will only be found
later, after you've invested into the platform. Or worse yet, it could
mean you're dealing with a chip maker unwilling to admit their faults in
public.

Likewise, a chip that's been around for a couple of years tends to be
one that will _not_ be around any more next year.

[Anton Erasmus]

On Mon, 30 Jan 2012 07:24:21 -0600, "P_B"
<patrik.bjorklund@n_o_s_p_a_m.rejlers.se> wrote:

The peripherals on the NXP stuff suck big time. They cobbled on OLD
not so good in the first place 8-bit peripherals on to the Cortex
core. I do not know what the state is with their newer devices but
with their first ARM and Cortex devices having more than one
interrrupt caused hardware lockups. I even had a problem with their
UART where my device would suddenly stop transmitting. After wasting
hours it turns out that if you poll the FIFO empty flag in a loop,
then the hardware never updates it when the FIFO goes empty.

The ST peripherals are slightly better.

The Atmel and Freescale peripherals are in a different class. Well
sorted out and properly adapted to the 32-bit core.
There is a reason why there are so many NXP and ST and almost no Atmel
and Freescale forums. Once one has gotten one's head around the
Freescale and Atmel docs, then the hardware works as described, so one
does not need to ask questions.

Regards
Anton Erasmus

[WP]

On 13 Lut, 08:26, Anton Erasmus <nob...@spam.prevent.net> wrote:

> The peripherals on the NXP stuff suck big time.

> [...]

> The ST peripherals are slightly better.
>
> The Atmel and Freescale peripherals are in a different class. Well
> sorted out and properly adapted to the 32-bit core.
> There is a reason why there are so many NXP and ST and almost no Atmel
> and Freescale forums. Once one has gotten one's head around the
> Freescale and Atmel docs, then the hardware works as described, so one
> does not need to ask questions.

I have the same conclusion. Atmel's peripherials are well prepared for
multitasking system, you can do almost everything without guarding
mutexes or disabling interrupts.

Once I and a colleague were doing similar things. I used AVR32, he had
a STM32. We both used FreeRTOS. I got the RTOS from Atmel, enabling it
was not much more work than clicking a checkbox in the framework
configuration. He got a FreeRTOS version which was supposed to be pre-
ported for STM and it took him a month to get it fully working (and he
is a smart guy).

I noticed similar differences in the supplied software drivers.

WP

[Rich Webb]

Is this the "spurious interrupt" issue with the NXP2xxx ARM7TDMI-S
family? It can indeed be a huge pain in the rear if one neglects to
instantiate one's own spurious interrupt handler. There ought to be a
note on the front of the user's manual "Warning! Device will reset
itself at apparently random intervals." (In fairness, the spurious
interrupt issue is mentioned in the manual but it's also easy to miss.)
I'm not familiar with hardware lockups with that family, though.

[Anton Erasmus]

No, was not the "spurious interrupt" issue. I did have a handler for
that. By handling this interrupt and playing with re-writing some
interrupt related registers I could get 2 interrrupts running
simultaneously, but with a very high number of spurious interrupts.
It was very clear that the interaction between the ARM Core's
interrupt handler, and the peripherals had not been sorted out or
properly tested by NXP. The ARM core is nice to work with, but with
writing code mainly in C these days the peripherals should actually be
the driving and deciding factor on choosing a MCU. Working with well
thought out, well implimented and bug free peripherals makes one's
application MUCH simpler to write, much more maintainable and robust.
It also takes a lot less time to write and debug the code.
The best peripherals I have worked with still are the stuff from
Motorola/Freescale. Their stuff is simply in a different class from
anybody elses. If they had 1% of the app notes Microchip has, I think
they would have been the dominant embedded MCU manufacturer by far.

Regards
Anton Erasmus

[Sink0]

>No, was not the "spurious interrupt" issue. I did have a handler for
>that. By handling this interrupt and playing with re-writing some
>interrupt related registers I could get 2 interrrupts running
>simultaneously, but with a very high number of spurious interrupts.
>It was very clear that the interaction between the ARM Core's
>interrupt handler, and the peripherals had not been sorted out or
>properly tested by NXP. The ARM core is nice to work with, but with
>writing code mainly in C these days the peripherals should actually be
>the driving and deciding factor on choosing a MCU. Working with well
>thought out, well implimented and bug free peripherals makes one's
>application MUCH simpler to write, much more maintainable and robust.
>It also takes a lot less time to write and debug the code.
>The best peripherals I have worked with still are the stuff from
>Motorola/Freescale. Their stuff is simply in a different class from
>anybody elses. If they had 1% of the app notes Microchip has, I think
>they would have been the dominant embedded MCU manufacturer by far.
>
>Regards
> Anton Erasmus
>

I have being using STM32F1XX, LPC17XX and Freescale K40 in a few projects.

Between LPC and STM32F1XX, your choice should be about your peripherals. If
you need USB OTG and Ethernet i would go for LPC, they got better price. If
do not need all that stuff, for sure i would go for STM32. In my opinion
STM32 is one of the most wideband microcontrollers i ever used. Lots of
different families. Low cost kits, and reasonable ADCs, very low cost
devices and low power consuption. If you need real good ADCs and math
horsepower you should go for Freescale Kinetis. However they got a crap
documentations, and very expensive devices.

A final thought. I really like Texeas Instruments MCUs like C2000, but i
really think they missed the point with stelaris. They are expensive and
got a 10 bit ADC..

A second final thought. If you really need horsepower you should go for
RX600. They got a 100Mhz flash (most of ARM devices got 25Mhz flash)!!

[Jukka Marin]

On 2012-02-17, Anton Erasmus <nob...@spam.prevent.net> wrote:
> No, was not the "spurious interrupt" issue. I did have a handler for
> that. By handling this interrupt and playing with re-writing some
> interrupt related registers I could get 2 interrrupts running
> simultaneously, but with a very high number of spurious interrupts.
> It was very clear that the interaction between the ARM Core's
> interrupt handler, and the peripherals had not been sorted out or
> properly tested by NXP.

We have been using several NXP ARM chips for years and there have been
interrupt related bugs, yes (some first discovered by us), but we are
using multiple interrupts successfully. (Multiple = serial port, SPI,
timers, PWM's etc.) In some projects, total interrupt frequency is
over 100 kHz and everything's working just fine.

I'm not saying that NXP ARM chips are the best, but they _do_ work.

-jm

[Anton Erasmus]

They have improved their chips, and with sligtly later model units
(when they started getting fractional baud generators), they were
better, but their peripherals haven't improved much. Once one gets
used to the expceptional number of possibilities the peripherals from
Freescale have, then it simply makes no sense using NXP devices unless
one's volumes are such that one can amortize the MUCH larger
development costs of using the inferior NXP devices.
For instance if one has to communicate with multiple SPI devices on
one port, and one wish to do so from different interrupt routines, the
QSPI peripheral from Freescale controls the Chip Select line for each
SPI peripheral directly in hardware, hence one need not wait fro an
SPI transfer to complete so that one can deselect the CS line for one
peripheral before starting a transfer to another peripheral. The QSPI
handles a number of SPI transfers to different SPI devices totally in
hardware. This allows a MUCH slower Freescale device to handle the
same load as a MUCH faster similar device from NXP or ST.

Another example which does not directly reflect the NXP MCU's
capability is the following. If one has a half duplex serial channel
and one need to switch to listen mode after one has transmitted a
message. Then if the MCU supports a status bit that indicates when the
last bit has been transmitted on to the wire as it were, not just that
the transmit FIFO is empty, then it simplifies the code tremedously
compared to an MCU that only has a status bit that indicates when
the transmit FIFO is empty.

One can get around these sorts of things in software, but it adds
complexity, which adds development time and a much greater
chance for bugs.

Regards
Anton Erasmus

[Arlet Ottens]

On 02/17/2012 06:56 PM, Anton Erasmus wrote:

> No, was not the "spurious interrupt" issue. I did have a handler for
> that. By handling this interrupt and playing with re-writing some
> interrupt related registers I could get 2 interrrupts running
> simultaneously, but with a very high number of spurious interrupts.
> It was very clear that the interaction between the ARM Core's
> interrupt handler, and the peripherals had not been sorted out or
> properly tested by NXP.

There's a known restriction in the ARM7 core that disallows removing an
interrupt source before it has been handled. Doing so anyway could
result in spurious interrupts. When you do it with FIQs, I've seen the
ARM7 jump to the IRQ handler, even when IRQs are disabled, corrupting
the IRQ registers.

The problem occurs when you disable an interrupt in a peripheral
register while it is pending. Without modifying the ARM7 core, it is not
so easy for NXP (or other vendors) to solve this issue. I also believe
that ARM does not allow licensees to modify the core, leaving them
without a proper way to solve this issue.

The solution is to avoid deasserting interrupt sources by writing
peripheral registers. To briefly disable interrupts, write to the CPSR
register instead. If you have to deassert peripheral interrupts, first
write to the CPSR register to disable global interrupts, then disable
the peripheral interrupt, wait for pipeline delays, and then re-enable
global interrupts.

[boB]

On Tue, 21 Feb 2012 21:13:53 +0100, Arlet Ottens <usen...@c-scape.nl>
wrote:

That spurious interrupt problem is only in the older NXP parts now.
NXP is the only ARM7 part I have used though, but at least the
LPC23xx parts and above won't have those problems anymore.

Even when it was a problem, it was easy to take care of with a
generic IRQ trap and return routine.

AFAIK, I never experienced a real problem with LPC2103 or LPC2144
parts when I was using them but it is nice just not to have to even
worry about it any more.

boB
K7IQ

[Mark Borgerson]

In article <2op7k79mb3ila70n6...@4ax.com>,
nob...@spam.prevent.net says...

Another thing I like about the QSPI is that you can set it up
to do transfers that are not multiples of 8 bits. This really
helps if you are using an 18-bit ADC or one of the Analog Devices
ADCs that requires 17 clocks for a 16-bit result.

>
> Another example which does not directly reflect the NXP MCU's
> capability is the following. If one has a half duplex serial channel
> and one need to switch to listen mode after one has transmitted a
> message. Then if the MCU supports a status bit that indicates when the
> last bit has been transmitted on to the wire as it were, not just that
> the transmit FIFO is empty, then it simplifies the code tremedously
> compared to an MCU that only has a status bit that indicates when
> the transmit FIFO is empty.

The STM32 UARTs have at Transmit Complete flag and interrupt. This
is very useful if you are doing RS485 comms and need to disable
the driver when the data transmission is done.

NXP LPC4350 UARTs have an RS485 mode that actually controls a direction
output pin. You can set a programmable delay to switch the pin after
the last character is transmitted. This is even better than a flag
or interrupt at the end of transmission (which the LPC 4350 also
has.)

>
> One can get around these sorts of things in software, but it adds
> complexity, which adds development time and a much greater
> chance for bugs.
>

While the peripherals are nice, Freescale is apparently late to
the party with Cortex M4 chips. Apparently, you can only
get M4 with functional FPU in a few places and in small quantities.
The last I heard, the K60 tower dev kits were shipping with chips
that did not have a working FPU.

Mark Borgerson

[Ulf Samuelsson]

Yes, they finally got to copy some functions of the AT91 USART ;-)

>>
>> One can get around these sorts of things in software, but it adds
>> complexity, which adds development time and a much greater
>> chance for bugs.
>>
> While the peripherals are nice, Freescale is apparently late to
> the party with Cortex M4 chips. Apparently, you can only
> get M4 with functional FPU in a few places and in small quantities.
> The last I heard, the K60 tower dev kits were shipping with chips
> that did not have a working FPU.

Yes, but long term it is an advantage to have a consistent family
instead of a mix of M3s and M4s.
If you go with the early M3s, where is the FPU?

>
> Mark Borgerson
>

[Ulf Samuelsson]

Or implement a spurious interrupt handler in the interrupt controller.
The AT91 AIC has been doing this for like 7-8 years..

The Interrupt handler will perform an indirect jump to a vector read
from the AIC. If the CPU reads a vector, when no interrupt is present,
the SPurious Interrupt Vector is returned instead.

>

BR
Ulf Samuelsson

[Arlet Ottens]

The problem is that short glitches on the interrupt inputs violate the
ARM7 specification. Unless the SoC manufacturer guarantees this
workaround works in all cases, I wouldn't recommend it.

On the revision of the ARM7 core I was using, a glitch on the FIQ input
would even cause a spurious IRQ when the CPU was already inside another
IRQ handler (with IRQs disabled). This would mess up the IRQ LR, even if
the spurious interrupt itself was handled correctly. Maybe other
revisions react differently.

[Vladimir Ivanov]

I believe Atmel's AIC handles this and provides stable IRQ/FIQ signals to
the ARM7 core. Any other external interrupt controller should be doing
this as well.

The vectored jump through AIC register that Ulf mentioned is really a neat
solution overcoming ARM7's limitation.

> On the revision of the ARM7 core I was using, a glitch on the FIQ input would
> even cause a spurious IRQ when the CPU was already inside another IRQ handler
> (with IRQs disabled). This would mess up the IRQ LR, even if the spurious
> interrupt itself was handled correctly. Maybe other revisions react
> differently.

This is nasty, even if cause/effect is easy to grasp.
Back when I was using ARM7 this wasn't even documented. Or I missed it
somehow.

Thanks for the interesting tidbit.

[Mark Borgerson]

In article <jii6kd$pdq$1...@speranza.aioe.org>, u...@notvalid.atmel.com
says...
>
<<SNIP>>

> >>
> > While the peripherals are nice, Freescale is apparently late to
> > the party with Cortex M4 chips. Apparently, you can only
> > get M4 with functional FPU in a few places and in small quantities.
> > The last I heard, the K60 tower dev kits were shipping with chips
> > that did not have a working FPU.
>
> Yes, but long term it is an advantage to have a consistent family
> instead of a mix of M3s and M4s.
> If you go with the early M3s, where is the FPU?

I'm not sure what you mean by this. One of the problems that I see
with the Kinetis chips is that they are shipping some nominal M4s
without the FPU and later ones with the FPU.

Are there any Cortex M3 chips with an FPU?


Mark Borgerson