32-bit MCU-family inquiry

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.

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

/P

--------------------------------------- Posted through

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.

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

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.

--------------------------------------- Posted through

Op Tue, 31 Jan 2012 09:26:57 +0100 schreef P_B :

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.

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.

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

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

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)!!

--------------------------------------- Posted through

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

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

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.

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

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.

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.)

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