DIP8 Cortex-M0+ from NXP

Leon · 2012-11-13 10:49

NXP has just announced the LPC800 - a 32-bit Cortex-M0+ in a DIP8 package:

http://www.nxp.com/news/press-releases/2012/11/nxp-revolutionizes-simplicity-with-lpc800.html

I should be getting some samples in two or three weeks.

mindrobots · 2012-11-13 11:29

It looks interesting. I like the Switch Matrix feature so you can reconfigure 6 of the 8 pins. In the bigger sizes, that gives you quite a lot of peripheral flexibility without a bazillion different versions of the chip. Almost as good as a Propeller!!

May have to try some DIP-8, just because I can!

Looking forward to your reports back.

Leon · 2012-11-13 11:56

I'll design a PCB when I find out which package will be available first, and get some made.

User Name · 2012-11-13 19:50

I think this is an absolutely fabulous move by NXP! This may finally get more hobbyists involved. It puzzles me to no end that people are still using Atmel AVR chips in ESCs and flight controllers when a Cortex M0 would be more powerful, smaller, less expensive, lower power, and much more C-capable. An LPC1114 is less than half the price of the Mega324PA used in the KK2.0. And Rolf Bakke could have written the code in C instead of assembly.

With respect to the LPC800 family, though, I wonder when NXP will get around to adding an ADC.

rwgast_logicdesign · 2012-11-13 22:37

his is pretty darn cool but if they wanna compete with avr and pic there gonna need a dip with mpre pins, unfourtantely i think the pin count only really knocks out the attiny family. im hoping these chips cause a flood of intro material to arm and something like coocox

jazzed · 2012-11-14 00:26

So it bothers no one that this 32 bit chip only has 16KB of flash?
What apps do you plan to squeeze into that?

mindrobots · 2012-11-14 01:48

That's why it got an "interesting"! I'm curious to see what is done with that big processing engine wrapped in a tiny package with just a splash of memory. I'm not sure of the code density of the M0 or how much our gain with the hard peripherals but there's a lot of processor to crunch something.

Tubular · 2012-11-14 02:06

jazzed wrote: »

So it bothers no one that this 32 bit chip only has 16KB of flash?
What apps do you plan to squeeze into that?

Prop2 SD card bootloader and power manager

Sorry couldn't resist.

Leon · 2012-11-14 03:09

jazzed wrote: »

So it bothers no one that this 32 bit chip only has 16KB of flash?
What apps do you plan to squeeze into that?

The PICs and AVRs it will be competing with have far less flash - the PIC12F675 only has 1024 words. ARM C code is very efficient.

David Betz · 2012-11-14 08:23

jazzed wrote: »

So it bothers no one that this 32 bit chip only has 16KB of flash?
What apps do you plan to squeeze into that?

For a chip that only has 8 pins it seems like it might be possible to squeeze the code into 16K. I wonder if ebasic would fit? :-)

rod1963 · 2012-11-14 09:09

Well PicAx has a basic interpreter on a 8 pin PIC chip.

I'd guess it would be possible, but it really depends on how hobbyist friendly the tool set for these ARM chips are and how difficult it is to configure these particular ARM chips. But if it takes 2-4 hours just to illuminate a LED, it ain't worth it.

For me I'll stay with a PicAx if I need a 8 pin micro.

David Betz · 2012-11-14 09:29

rod1963 wrote: »

Well PicAx has a basic interpreter on a 8 pin PIC chip.

I'd guess it would be possible, but it really depends on how hobbyist friendly the tool set for these ARM chips are and how difficult it is to configure these particular ARM chips. But if it takes 2-4 hours just to illuminate a LED, it ain't worth it.

For me I'll stay with a PicAx if I need a 8 pin micro.

Does PicAxe have an self-hosted Basic interpreter or does it just have the Basic runtime and require a PC-based compiler?

Leon · 2012-11-14 11:00

Here is a simple test program for the LPC2114 that flashes an LED:

/* Flasher.c
** Test program for LPC1114 (DIP28)
** LED flasher
** LED on PIO1_0 (pin 9)
*/

#include <LPC11xx.h>

void delay(void);

int main(void)
{
  //clkout 48Mhz main clock / 48 = 1MHz
  LPC_SYSCON->SYSAHBCLKCTRL |= (1<<16);     //enable IOCON
  LPC_IOCON->PIO0_1          &= ~0x3F;        //reset FUNC/MODE/HYS
  LPC_IOCON->PIO0_1          |= ((1<<7)|(1<<0));//set FUNC=CLKOUT, ADMODE: DIGITAL
  LPC_SYSCON->CLKOUTCLKSEL = 0x03;        //clock source 0:IRC 1:SYSTEM 2:WD 3:MAIN
  LPC_SYSCON->CLKOUTDIV    = 48;         //set divider
  LPC_SYSCON->CLKOUTUEN    = 0;
  LPC_SYSCON->CLKOUTUEN    = 1;             //enable clkout
  while (!(LPC_SYSCON->CLKOUTUEN & 0x01));


  LPC_IOCON->R_PIO1_0 = 0x0041;   // Select PIO1_0, Mode inactive, no hysteresis, ADmode digital, standard GPIO output
  LPC_GPIO1->DIR  = 0x00000001;   // Make PIO1_0 output
  LPC_GPIO1->DATA = 0x00000000;   // Start with it low
     
  while(1) 
  {			
    LPC_GPIO1->DATA = 0x00000000; // LED off
    delay();                      // Wait a while
    LPC_GPIO1->DATA = 0x00000001; // LED on
    delay();                      // Wait a while
  }
  return 0;
}  

// Delay routine
void delay(void)
{
   volatile long i;
   for (i = 0; i < 500000; i++)
    ;
}

A similar program for the new LPC800 will be somewhat simpler.

Heater. · 2012-11-14 13:46

Leon,

Good example. I start to realize why the Arduino is so popular and why we love the Propeller so much.

By the way how long is "delay();" ?

Leon · 2012-11-14 13:53

About 0.5 s, with a 48 MHz clock.

Heater. · 2012-11-14 13:59

OK, but how do we know that from a quick glance of the code?

Leon · 2012-11-14 14:13

The CrossWorks simulator and debugger can provide a cycle count between two points in the code. I get 3,500,018 instructions for the delay routine.

Heater. · 2012-11-14 14:22

Yes, yes, but what on earth is the definition of "delay()" ?

Written like that it has no obvious meaning. If I port that code to some other machine what is "delay()" there?

Leon · 2012-11-14 14:23

It will depend on the compiler, processor, and clock rate. A better way to do it would be to use a timer, but I just wanted something quick and dirty.

rwgast_logicdesign · 2012-11-14 14:30

i read the nxp page and somehow missed that the chip was only 16k. attinys have much more space, and avr is designed around C.

my question is in genral can you execute code from an eeprom or some type of nvram? im really intrested in 8 pin chips for some tasks like power managment or an intermediate chip to simplfy reading of sensors for a host chip like the propeller. i dont know much about avr, and im thinking the skills id accquire using these over attinys would be more beneficial in the long run, but 16Kb is fairly limited if code cant be stored somewhere else. ive also been looking into 8051/2s but like i said this may be a more beneficial if i need to learn a whole new platform

Leon · 2012-11-14 14:37

ATtinys have less storage, and are not as efficient at running C code.

rwgast_logicdesign · 2012-11-14 14:45

hmm guess your right this chip is double an attiny85.

still do you know if code can be ran from an eeprom? are these using thumb to compact instructions?

Leon · 2012-11-14 14:45

Code is run from flash memory or SRAM. It uses Thumb instructions.

Heater. · 2012-11-14 14:51

Sorry, Leon. Didn't notice that the delay() function is defined in your example. Still all that setup part is quite intimidating.

Leon · 2012-11-14 15:03

Iinitialisation of ARM chips can be complex, even with CMSIS making it largely manufacturer-independent. As I said, it will be a lot easier with the new chip.

User Name · 2012-11-15 00:17

Leon wrote: »

Code is run from flash memory or SRAM. It uses Thumb instructions.

A subset of Thumb 2, to be more specific. The original Thumb instruction set was 16-bit, and ARM7 TDMI processors allowed you the choice of either ARM (32-bit) or Thumb instructions. With the Cortex family, they got rid of this choice and instead enhanced the Thumb instruction set with certain 32 bit instructions. M3 chips get the full Thumb 2 set, and M0 processors get a subset of Thumb 2.

Still, none of this should be viewed as a liability. Thumb 2 is a great compromise between execution speed and code compactness. I've been quite amazed at how much program can fit into the limited code space of an ARM Cortex M chip.

Perhaps it should also be pointed out that the M0 is miraculous in how much processor you get for so few gates, and so little power consumption. Still, it is noticeably slower than the M3 family. In very rough terms the M0 is half-as-fast, after accounting for clock rate differences, according to some comparisons I made a couple years ago.

jmg · 2012-11-15 01:24

User Name wrote: »

With respect to the LPC800 family, though, I wonder when NXP will get around to adding an ADC.

Exactly - what were they thinking releasing a new micro, with no ADC ?!
The small 8 bit alternatives leave this for dead.

You can get ADC, and Wide Vcc, and smaller packages.

DIP8 is a gimmick : who is going to volume produce using DIP8 ?

Why make a 32 bit controller, with 16 bit timers ?

The Nuvoton Mini51 is a much better pitch into 8 bit space, : this family has similar price, but include ADC and 2 x 32 bit timers, and Wide Vcc.

See
http://www.nuvoton.com/NuvotonMOSS/Community/ProductInfo.aspx?tp_GUID=5dbf7d7a-b6df-4fe1-91c9-063449500ce7
and
http://www.coocox.org/Cookie.html

John A. Zoidberg · 2012-11-15 08:49

I don't know, but I felt weird thinking an ARM 32-bit processor with only 8-pins.

It's like having a Harley Davidson fitted with Ferarri engine.

Cluso99 · 2012-11-15 17:18

ATTiny167 16KB Flash, TSSOP20

FredBlais · 2012-11-15 21:27

jmg wrote: »

Why make a 32 bit controller, with 16 bit timers ?

I have a dev board with a STM32F107, all the timers are 16 bit too. I suppose the prescalers replace the larger width of 32 bit timers. These timers generally pack a lot of functionality, maybe 32 bit would require "too much" chip space.

jmg · 2012-11-16 00:43

FredBlais wrote: »

.. These timers generally pack a lot of functionality, maybe 32 bit would require "too much" chip space.

16+16 more registers is not "too much" on a chip with thousands...
Some TI parts have 32/64 bit timers, but really, one of the reasons you move to more bits, is to leave saturation and granularity problems behind.
If the CPU made the move, is it just skewed to leave some peripherals at 16 bits.

DIP8 Cortex-M0+ from NXP

Comments