Oh, I'll accept "not 10x faster", but I think "not remotely close to 10x faster" is too harsh. I see "almost always faster, and 12x faster for some pretty common operations. "I think I could come up with non-contrived code that would be significantly more than 12x faster (say by using an array of 32bit constants in flash.)

Of course I'm also in the group that believes an AVR is "fast enough" almost all of the time.

The peripherals are much slower than the mcu: it takes the same time to do 400khz i2c on a 72Mhz CM3 as it does on a 1Mhz avr. Or it takes the same amount of time to wait for a person to press a button, etc.

So the raw speed comparison on a mcu really isn't that meaningful.

I would venture a guess that the CMx chips are no more faster than an avr than their system clocks suggest.

Obviously, that conclusion changes if you are using those chips for some 32-bit intensive tasks (fft for example, or dsp on the cm4s).

Also the ADC for LPC1114FN28/102 is at least 5 times faster than the one on Atmega328p, (for the ARM I am not seeing the maximum conversion time at full resolution which is needed for a more precise comparison).

ARMThe LPC1110/11/12/13/14/15 contain one ADC. It is a single 10-bit successiveapproximation ADC with eight channels....• Measurement range 0 V to VDD.• 10-bit conversion time >= 2.44 us (up to 400 kSamples/s).

I wonder if the fact an ADC could be required to charge up to the higher VDD on the 328, if that is responsible for some of the time difference?

I haven't looked into the ARMs directly, but the ADC sampling time is usually related to the size of the sampling cap on the front-end of the ADC, as well as the the value of the external source resistance.

Slower ADCs usually have a sampling cap in the 20-120 pF range, while for the fast ones it's more like 4 pF. Also, the faster ones will say something like "source impedance must be 500 ohms max for maximum sampling rate", while the slower ADCs will say something like 10K max. So, max sampling rate mainly comes down to RC charging.

It's an interesting chip, but the wide package and "only" 32k of flash make it less than compelling. A PIC32MX150F128 in narrow 28-dip with 128k of flash is more interesting, even if it's $2 more.

Sigh. It's really clear that NXP is serious about trying to displace 8bit CPUs. I wish they were more obviously "on target" with their attempts. 16pin micoBGAs, 28pin wide DIPs, ... nice tries, but not quite what I was hoping for. I can't quite tell whether they're clueless, or whether it really IS that hard to figure out what is really wanted in this nebulous "hobbyist/small manufacturer/mindshare" market space.

whether it really IS that hard to figure out what is really wanted in this nebulous "hobbyist/small manufacturer/mindshare" market space.

It is quite possible that nxp has studied the market and come to the conclusion that this super-duper red-hot "hobbyist" niche is not where they can make sufficient profit to float their boat. Instead, they want to focus instead on this much larger non-sexy industrial applications market for this chip.

Just try to a get a board with through-hole-parts made today and you will understand.

I have not studied it too much but the LPC Xpresso IDE, designed for ARMs produced by NXP, seems quite easy to work with.

The IDE hides the internal registers and you work mainly with easy to understand functions that set timers, IO ports, etc.. However, there may be traps, complications. LPC Xpresso IDE does not have a simulator, for instance, like Keil. You need the real hardware to test your code.

/**************************************************************************** * $Id:: PWM16_32test.c 3635 2010-06-02 00:31:46Z usb00423 $ * Project: NXP LPC11xx 16-bit/32-bit PWM example * * Description: * This file contains PWM test modules, main entry, to test PWM APIs. * **************************************************************************** * Software that is described herein is for illustrative purposes only * which provides customers with programming information regarding the * products. This software is supplied "AS IS" without any warranties. * NXP Semiconductors assumes no responsibility or liability for the * use of the software, conveys no license or title under any patent, * copyright, or mask work right to the product. NXP Semiconductors * reserves the right to make changes in the software without * notification. NXP Semiconductors also make no representation or * warranty that such application will be suitable for the specified * use without further testing or modification.****************************************************************************/

The ide does not hide anything: you can always code the mcu by writing to the registers.However, in this case, they use a set of libraries from nxp to operate the peripherals. That's not unusual: ST has a set of its own libraries.

Without those libraries working with ARM peripherals is really not practical.

If indeed one have to write all these lines of code to initialize a timer I imagine that not many people would dare to attack ARMs.

#if CONFIG_TIMER32_DEFAULT_TIMER32_1_IRQHANDLER==1 /* Enable the TIMER1 Interrupt */ NVIC_EnableIRQ(TIMER_32_1_IRQn);#endif } return;}Maybe not all the code above is necessary for a particular application. I do not know.

There is another problem, sometimes you have to change the parameters of a timer on the run as fast as possible between two events that are 10-20 clock cycles apart.It seems like functions as "init_timer32" need more than 20 clk. ticks. Is there workarounds?

/* Blink Turns on an LED on for one second, then off for one second, repeatedly.

This example code is in the public domain. */

// Pin 13 has an LED connected on most Arduino boards.// give it a name:int led = 7; // different pin on the LPC Xpresso board

// the setup routine runs once when you press reset:void setup() { // initialize the digital pin as an output. pinMode(led, OUTPUT); }

// the loop routine runs over and over again forever:void loop(void) { digitalWrite(led, HIGH); // turn the LED on (HIGH is the voltage level) delay(1000); // wait for a second digitalWrite(led, LOW); // turn the LED off by making the voltage LOW delay(1000); // wait for a second}

Without those libraries working with ARM peripherals is really not practical.

If indeed one have to write all these lines of code to initialize a timer I imagine that not many people would dare to attack ARMs.

I guess I and folks I work with are one of those people,

Once you build up your own blocks / functional modules by operating on registers, you have built up your own library: once you have written tmr1_set(1000);, you can call it next time to set a period of 2000 or 50199, without knowing much about how it did it, just that you know with confidence that it will do it right.