NXP Cortex-M chips, which ones are popular? - Page 1
Forum section: electronics / general

author: richardman
author_rank: Frequent Contributor
timestamp: June 22, 2016, 08:41:07 pm
content: Looks like there is a lot of love for STM32F chips on this forum. We love them too ;-)How about NXP Cortex-M? Which ones are popular with people. Do their -M0 chips have similar peripheral subsystems as their -M3/M4/M7 chips?Experience, gotchas? Pearls of wisdom?

author: dannyf
author_rank: Super Contributor
timestamp: June 22, 2016, 08:43:39 pm
content: The hottest is 1114. Just the right compromise between features, packaging and price.Like stm32f103.

author: nctnico
author_rank: Super Contributor
timestamp: June 22, 2016, 09:17:29 pm
content: Quote from: richardman on June 22, 2016, 08:41:07 pmI have been using NXP ARM controllers for almost a decade. The peripherals are basically the same across the entire ARM7TDMI, M0 and M3 line (perhaps also M4 and M7 but I never really looked at those). There are some small differences though. Some chips don't have specific set/clear bits for the GPIOs and some have a toggle function. On newer devices (like the 11U6x / 11E6x) NXP replaced the extra UARTs with non 16550 compliant ones. But overall there is much less variation between the devices than you probably got used to when dealing with ST. When choosing a device for a design I don't have to care whether I can use existing code because I know it will work or will need very minor changes.

author: mubes
author_rank: Regular Contributor
timestamp: June 22, 2016, 09:25:02 pm
content: EDIT: Its just struck me that by saying NXP you might mean 'old' NXP (LPCxxxx) or 'new' NXP (which incorporates the Freescale CORTII). You might need to clarify which you mean, but I can only comment usefully on the LPCs...below;LPC1549 is the unsung hero of the M3s. For some reason they badge it as a motor controller but it's got a great mix of peripherals and the configurable switch matrix (which also exists on the LPC81x and LPC82x) is a killer feature. Probably my fave chip at the moment.I am actively using LPC433x and LPC437x is various designs. Quite powerful but a few 'gotchyas' like specific pins not having GPIO functionality and the fact you can't use a couple of peripherals at the same time because of a decode bug in the silicon (one of the CAN busses, if memory serves). The serial flash effectively gives you virtually unlimited memory and the embedded M0s give you a couple of spare processors for drudge tasks when you've got other things to keep the M4 busy with.The LPCExpresso platform (==Eclipse + GCC for ARM) is powerful and the JTAG/SWD well integrated with features like profiling.The LPC40xx'es are newer kids on the block, but not too sure what they bring to the party. They have the secondary M0 but when I glanced at them they didn't look compelling....didn't look too deeply.The future of a LPCs is a bit cloudy with the Freescale takeover though...hopefully they'll clear the air a bit soon.DAVE

author: richardman
author_rank: Frequent Contributor
timestamp: June 22, 2016, 10:06:42 pm
content: Yes, I do mean the "old"LPC lines. I know the Kinetis lines are very different.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: June 22, 2016, 10:13:00 pm
content: I think LPC1768/1769 were and still are very popular. They lack some features of the newer derivates though and LQFP100 is a bit on the big side.LPC1347 was also pretty popular but has been superceded by the LPC1549 -which is also my current favorite.The only thing I really miss compared to the LPC1768 is the more powerful "general purpose" DMA of the LPC17xx. And yeah, the maximum frequency is a bit lower.

author: dannyf
author_rank: Super Contributor
timestamp: June 22, 2016, 10:26:33 pm
content: Specing lpc chips now can be a risky business, and in my view will likely put you on the losing end of the stick. I suspect that nxp is going To rationalize it's mcu offering around freescale parts and framework.

author: dannyf
author_rank: Super Contributor
timestamp: June 22, 2016, 10:39:13 pm
content: On the freescale deal, it shows something people like new have been arguing for a long time. The mcu business is a software business for the most part.Once you are specd in, it is very difficult to get kicked out and that customer is a cashhcow for you.To get specd in, however, you have to win by software going forward - renaisas is an exception giving it's root in auto and it's roll up history. The single bigger hurdle in getting designed in is software, or ease of development. PE was absolutely best in class and for the most part got freescale where it iss today.Soo I think for guys like St to be successful, they have tobright thee software side of theiir business.That bring me to cypress. Of all the vendors, those guys are the only one who is doing absolutely innotive things on the software side (also hardware side as well).Given their small size, they would be a perfect acquisition target for someone with a wide product offering.

author: nctnico
author_rank: Super Contributor
timestamp: June 22, 2016, 11:00:17 pm
content: Quote from: dannyf on June 22, 2016, 10:26:33 pmWhy would they do that? That would basically kill the business around their LPC line-up. The LPC line is much older than the Kinetis line so it is likely they have more customers for the LPC line than the Kinetis line. Ofcourse it depends on the volume but I strongly doubt NXP sells more Kinetis devices than LPC. Besides that the LPC line looks way more polished with shorter errata sheets. A quick glance at the peripherals shows me Freescale has re-used many 8 or 16 bit peripherals where you'll find more real 32 bit peripherals in the LPC line. It is very easy to be able to load a timer with a 32 bit value instead of needing pre-scalers. Also for programming the Kinetis parts you'll need to use JTAG or SWD dongles which are a major pain in the ass (drivers, USB incompatibilities, susceptibility to pulses) compared to the (UART) serial bootloader in the LPC series.

author: TheDirty
author_rank: Frequent Contributor
timestamp: June 23, 2016, 01:41:49 am
content: Quote from: dannyf on June 22, 2016, 08:43:39 pmLPC1114 is my goto, but timed sleep mode and power saving in deep sleep have been a pain in the ass and I still haven't got them perfect. This is one of their early chips and it shows.LPC1769/1759 for larger work.LPC812/824 chips are great and I'm using them whenever I can. The peripherals are different, but pretty simple. That SCTimer peripheral is amazing. I implemented an AC dimmer trigger just using the SCTimer and no other code or interrupt. Just need to change one reload value to change the dimmer. Super flexible, wish this was in every chip everywhere. Easy flexible peripheral to pin assignments as well.I have not tried newer mid-range chips, but I might go try the LPC15xx chip mentioned above. Just don't like paying for features I'm not using.Also find it difficult to believe NXP would standardize on the Kenetis line, which is not as well formed.

author: richardman
author_rank: Frequent Contributor
timestamp: June 23, 2016, 02:14:56 am
content: Well, as a 3rd party vendor, we do have to make the right bet, so it's important to have a good crystal ball to know whether NXP will settle on LPC or Kinetis. Too bad my crystal ball isn't very clearAnd of course similar worry abound for Atmel SAM stuff. Will Microchip kill it? Probably not, but...?Ugh.

author: dannyf
author_rank: Super Contributor
timestamp: June 23, 2016, 10:01:38 am
content: The good thing about the lpc line, from a programming perspective, is the similarity of peripherals from one chip to another. Surprisingly, gpio is the least similar.

author: Kjelt
author_rank: Super Contributor
timestamp: June 23, 2016, 01:32:15 pm
content: The bad thing is that they don't have such a large portfolio as ST on their micro's so say you choose one type then ST has them with 128kiB,256kiB,512kiB,1024kiB and a lot of different packages, ideal to tweak and choose for your purpose.

author: nctnico
author_rank: Super Contributor
timestamp: June 23, 2016, 01:54:12 pm
content: Quote from: Kjelt on June 23, 2016, 01:32:15 pmI don't see it that way. Due to the peripherals being (very) similar on the NXP LPC devices you can easely move code from one to the other. I do this code mix&matching all the time.

author: cgroen
author_rank: Unknown
timestamp: June 23, 2016, 02:31:30 pm
content: I have used a lot of NXP (LPC) chips, both professionally and for my own stuff.On the top of my list right now is LPC1549, LPC824 and LPC11c24.The 1549 is brilliantly with regards to its peripherals (SCT, SWM, CAN etc)(I have also been using a lot of LPC2148, LPC2458 and LPC1778)

author: ebclr
author_rank: Super Contributor
timestamp: June 23, 2016, 02:45:51 pm
content: http://www.cypress.com/products/32-bit-arm-cortex-m0-psoc-4

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: June 23, 2016, 03:48:38 pm
content: My preferences are the LPC1768 and the LPC4337 or 4357. The 43xx series is dual core--there's an M4 and an M0 on the same die--but tools support for the M0 is somewhat lacking.NXP are late to the game with the M7. They don't have any in their lineup and as far as I know they haven't announced any either.

author: jnz
author_rank: Frequent Contributor
timestamp: June 23, 2016, 08:59:36 pm
content: I haven't used it yet, but I like that some of the NXP 1100's have built in transceivers, like for CAN. I very well may use that.Otherwise, I've been using STM32 and Nordic's nRF52.

author: doobedoobedo
author_rank: Regular Contributor
timestamp: June 23, 2016, 10:52:57 pm
content: I've just started with an LPC11U35. I really like it. Mind you I've only used AVRs before. Porting my arduino code to LPCOpen was easier than I thought it was going to be too.I decided to go ARM and this particular chip for reasons of:Flash spaceUSBPerformance64k flash vs 30k usable flash (328p) - no contest, my ported code compiles smaller too.I tried using a 32U4 for USB but lost too much flash space and my code didn't fitPerformance is stellar in comparison, including the peripherals like ADC. Timers are much nicer to use. 32bit and higher clock rates , I wish I'd swapped over sooner.

author: ebclr
author_rank: Super Contributor
timestamp: June 24, 2016, 10:34:36 am
content: You don't even need to port, Already have a Arduino compatible who compiles for arm from several difference projects

author: Jeroen3
author_rank: Super Contributor
timestamp: June 24, 2016, 10:58:46 am
content: There are also mbed compatible chips. Mbed library is made open source, so you can use them for free.

author: doobedoobedo
author_rank: Regular Contributor
timestamp: June 24, 2016, 02:04:04 pm
content: Quote from: ebclr on June 24, 2016, 10:34:36 amIf that's a SAMD, I need real eeprom.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: June 24, 2016, 04:09:56 pm
content: How about the robustness of the peripherals on NXP versus STM32 MCUs? Which is better under typical error conditions? I'm particularly interested in I2C, SPI, and CAN.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: June 27, 2016, 04:03:55 pm
content: One of the things I find annoying about the NXP LPC user's manuals is how they depict bits in a register. Here's what an example looks like. It's hard to visualize the layout of the bits easily.Here's how ST does it in the STM32 user's manuals. It's much easier to visualize the bits.

author: Jeroen3
author_rank: Super Contributor
timestamp: June 27, 2016, 04:10:37 pm
content: I don't agree with that. Nxp has a shorter overview. You'll be using shifts or defines anyway, so you don't need to visualize the bits. Or at least, I don't.Or are you using magic numbers?

author: cgroen
author_rank: Unknown
timestamp: June 27, 2016, 04:12:39 pm
content: A matter of taste I guess,I simply love the way NXP datasheets and users guides are done! They are perfect in my eyes and very easy to navigate and read.Something that can'r be said about Atmel, TI (CC11xx) etc

author: nctnico
author_rank: Super Contributor
timestamp: June 27, 2016, 04:15:13 pm
content: Quote from: Jeroen3 on June 27, 2016, 04:10:37 pmBit shifts are the way to do it. Writing hex numbers into registers makes code hard to read.CONSET = (1<2) | (1<<5)or even nicer:CONSET = CONSET_AA | CONSET_STAwith CONSET_AA defined as (1<<2)

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: June 27, 2016, 04:15:26 pm
content: Quote from: Jeroen3 on June 27, 2016, 04:10:37 pmI agree with that--when I'm writing code. Where I strongly disagree with your point is when I'm debugging code and see the content of a peripheral register displayed by the debugger as hex or binary. Then it's important to be able to visualize the bits.

author: Kjelt
author_rank: Super Contributor
timestamp: June 27, 2016, 04:26:06 pm
content: With STs notation you at least know it is big endian and which way to shift

author: andersm
author_rank: Super Contributor
timestamp: June 27, 2016, 05:21:06 pm
content: Quote from: Kjelt on June 27, 2016, 04:26:06 pmDoes anyone beside IBM number their bits the other way around?

author: jnz
author_rank: Frequent Contributor
timestamp: June 27, 2016, 06:49:52 pm
content: Quote from: andersm on June 27, 2016, 05:21:06 pmSometimes Motorolla depending on application. Sometimes ON Semi.It's really not that uncommon.

author: nctnico
author_rank: Super Contributor
timestamp: June 27, 2016, 07:07:14 pm
content: Quote from: Kjelt on June 27, 2016, 04:26:06 pmThat doesn't matter. Besides all the ARM microcontrollers I have encountered so far are little endian.

author: Kjelt
author_rank: Super Contributor
timestamp: June 27, 2016, 09:21:12 pm
content: With the standard Arm core there is a register to choose between little or big endian, most manufacturers have locked this AFAIK

author: dannyf
author_rank: Super Contributor
timestamp: June 27, 2016, 10:07:50 pm
content: "most manufacturers have locked this AFAIK"Would have been interesting to code otherwise,

author: nctnico
author_rank: Super Contributor
timestamp: June 27, 2016, 10:18:16 pm
content: Quote from: dannyf on June 27, 2016, 10:07:50 pmA very long time ago I worked with a MIPS SoC which started in big endian. In order to set it to little endian you had to set a register. However: how do you mix big endian code with little endian code? This ended up with adding the big endian instructions as 32 bit constants with the bytes reversed. -I want to barf emoticon-!

author: Jeroen3
author_rank: Super Contributor
timestamp: June 28, 2016, 06:17:43 am
content: ARM is little endian. You can switch it in the core. But the AHB can't change. It will perform conversion on the bus interface iirc.8051 is big,x86 is big, ethernet is big. Lot of things are big, yet is does not make sense to use use big imho.But it should not affect how you shift. It only changes the way it is mapped in memory, which is an issue when performing byte reads with pointers and unions. Doing auint32_t reg = reg << 8. Is endian invariant. Word read, registers shift, word write.Registers don't have an endian sensitive since they are not memory mapped.I was mistaken, x86 is little.

author: Kjelt
author_rank: Super Contributor
timestamp: June 28, 2016, 07:20:15 am
content: Quote from: Jeroen3 on June 28, 2016, 06:17:43 amNo Intel started with little endian because Motorola had big endian AFAIK, the whole ****** of little endian started with Intel.

author: Xenoamor
author_rank: Regular Contributor
timestamp: June 28, 2016, 12:24:12 pm
content: I enjoy the K20 line. They're stable with +100% overclocking and have very good DMA controllers which allow you to off load a lot of workThe ST line of chips don't allow you to shift 16bits from one place and 8 from another and have them all packed contiguously. At least the STM32F4 doesn'tAlso their datasheets have got a lot better:https://www.pjrc.com/teensy/K20P64M72SF1RM.pdf

author: coppice
author_rank: Super Contributor
timestamp: June 28, 2016, 02:49:55 pm
content: Quote from: Kjelt on June 28, 2016, 07:20:15 amBoth big and little endian systems were in use long before Intel made its first CPU. If by Motorola you mean Motorola Semiconductors (other parts of Motorola had developed their own processors earlier) Intel would have had to predict what Motorola would use, since Intel started making CPUs first.

author: Howardlong
author_rank: Super Contributor
timestamp: June 28, 2016, 04:47:13 pm
content: I, on the other hand, do agree! I find the NXP datasheets quite hard to read in that respect. Having said that, I prefer having the entire datasheet in one or two documents than dozens, like Microchip do for their 16 and 32 bit platforms.