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.
32-bit MCU-family inquiry
Started by ●January 30, 2012
Reply by ●January 31, 20122012-01-31
Reply by ●February 13, 20122012-02-13
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. > >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!! >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
Reply by ●February 13, 20122012-02-13
On Mon, 13 Feb 2012 09:26:25 +0200, Anton Erasmus <nobody@spam.prevent.net> wrote:>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. >> >>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!! >> > >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.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. -- Rich Webb Norfolk, VA
Reply by ●February 13, 20122012-02-13
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
Reply by ●February 17, 20122012-02-17
On Mon, 13 Feb 2012 09:03:26 -0500, Rich Webb <bbew.ar@mapson.nozirev.ten> wrote:>On Mon, 13 Feb 2012 09:26:25 +0200, Anton Erasmus ><nobody@spam.prevent.net> wrote: > >>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. >>> >>>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!! >>> >> >>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. > >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.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
Reply by ●February 17, 20122012-02-17
>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 http://www.EmbeddedRelated.com
Reply by ●February 18, 20122012-02-18
On 2012-02-17, Anton Erasmus <nobody@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
Reply by ●February 21, 20122012-02-21
On Sat, 18 Feb 2012 09:16:20 +0000 (UTC), Jukka Marin <jmarin@pyy.embedtronics.fi> wrote:>On 2012-02-17, Anton Erasmus <nobody@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. >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
Reply by ●February 21, 20122012-02-21
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.
Reply by ●February 21, 20122012-02-21
On Tue, 21 Feb 2012 21:13:53 +0100, Arlet Ottens <usenet+5@c-scape.nl> wrote:>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. >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
