HELP! What MCU (greater than 8-bits of smarts) is easiest to graduate to?

[22swg]

My 2 cents / peneth worth PIC24HJ128GP502 

[miguelvp]

So based on some code I found on using Keil as a PSoC programmer some where in this link:
http://www.cypress.com/?rID=38050

I was able to achieve (this is a full cycle so both on and off)
1.724 MHz 580.0ns Period at 50% duty cycle in assembler
1.202MHz 832.0ns Period at 50% duty cycle in C

I found this code that access the GPIO ports directly. In this case p0[0]

Code: [Select]

int WriteIO (unsigned int addr, unsigned int data)
{
unsigned int *address = (unsigned int*)addr;
*address = (unsigned int)data;
return (0);
}

int ReadIO (unsigned int addr, unsigned int *data)
{
unsigned int *address = (unsigned int*)addr;
*data = *address;
return (0);
}

//----------------------------------------------------------------------------------
// Custom functions
//----------------------------------------------------------------------------------

void Delay(int ms)
{
int i , j;

for(i = 0; i < ms; i++) {
for(j = 0; j < 3333; j++); //Delay = 1ms, mesured by scope for CY8C41xx (CPU = 48MHz)
}
}

void LED_Write(char value)
{     
WriteIO(0x40040000, value); //GPIO2.GPIO2_PRT.DR
}

//----------------------------------------------------------------------------------
// main() function
//----------------------------------------------------------------------------------
int main (void)
{
char leds = 0x01;     //Initial state of LEDs: P0[0] - On

WriteIO(0x40040008, 0x06); //Set Strong Drive Mode for P0[0] in GPIO2.GPIO2_PRT.PC register

for (;;)
{
LED_Write(leds); //Invert LED state on P[0] in GPIO2.GPIO2_PRT.DR register
Delay(500);
leds ^= 0x01;   
  }
}

Based on that I wrote the following code, if you change USE_ASM to 0 it will use C.
If USE_ASM is 1, then defining USE_INLINE_ASM  to 1 will use inline assembly or if 0 it will use the external .s assembly file.

Code: (main.c) [Select]

// Added delays for 50% duty cycle
// ASM inline or not 1.724 MHz Period 580.0ns (28 cycles?)
// C 1.202MHz 832.0ns (40 cycles?)
#define USE_ASM 1
#if USE_ASM
#define USE_INLINE_ASM 0
#if !USE_INLINE_ASM
// Declare assembler function
void ASMLoop();
#endif
#endif

int main (void)
{
#if USE_ASM
#if USE_INLINE_ASM
    /* Set Strong Drive Mode for P0[0] in GPIO2.GPIO2_PRT.PC register */
    asm("ldr r3, =0x40040008");
    asm("str r3, [r7]");
    asm("ldr r3, [r7]");
    asm("movs r2, #6");
    asm("str r2, [r3]");

    /* Preload P0[0] port into r3 */
    asm("ldr r3, =0x40040000");
    asm("str r3, [r7, #4]");

    /* Preload off and on, into r2 and r4 */
    asm("movs r2, #0");
    asm("movs r4, #1");

    for (;;)
    {
        /* Turn P0[0] off */
        asm("str r2, [r3]");
       
        /* compensate for branch loop time delay */
        asm("nop");
        asm("nop");
        asm("nop");
       
        /* Turn P0[0] on */
        asm("str r4, [r3]");
     }
#else
    ASMLoop();
#endif
#else
    unsigned int *IOaddress = (unsigned int*)0x40040000; //GPIO2.GPIO2_PRT.DR
    unsigned int *MODEaddress = (unsigned int*)0x40040008; //GPIO2.GPIO2_PRT.PC
    // delay variable
    int a = 0;

    /* Set Strong Drive Mode for P0[0] in GPIO2.GPIO2_PRT.PC register */
    *MODEaddress = 0x06;
   
    for (;;)
    {
        /* Turn P0[0] off */
        *IOaddress = 0x00;

        /* compensate for branch loop time delay */
        a=0;

         /* Turn P0[0] on */
       *IOaddress = 0x01;
     }
#endif
}

External Assembly file if you don't want to use the inline assembler:

Code: (ASMLoop.s) [Select]

    .syntax unified
    .text

    .global ASMLoop
    .func ASMLoop, ASMLoop
    .thumb_func
ASMLoop:
    /* Set Strong Drive Mode for P0[0] in GPIO2.GPIO2_PRT.PC register */
    ldr r3, .IOAddr+4
    str r3, [r7]
    ldr r3, [r7]
    movs r2, #6
    str r2, [r3]
   
    /* Preload P0[0] port into r3 */
    ldr r3, .IOAddr
    str r3, [r7, #4]

    /* Preload off and on, into r2 and r4 */
    movs r2, #0
    movs r4, #1

LoopAgain:
    /* Turn P0[0] off */
    str r2, [r3]

    /* compensate for branch loop time delay */
    nop
    nop
    nop
   
    /* Turn P0[0] on */
    str r4, [r3]
   
    /* repeat */
    b LoopAgain

    .align 2
    .IOAddr:
    .word   0x40040000
    .word   0x40040008
    .endfunc

    .end

/* [] END OF FILE */

Btw, you can always export a project into eclipse or uVision and I think there is another one supported.

[miguelvp]

Adding scope capture for anyone that doubts it



Edit: btw, I didn't do the bootloadable/bootloader because I'm using the pioneer as a programmer, so you might need to alter it to use the bootloader/bootloadable combination for the $4 prototype kit.

[miguelvp]

Ok, I did learn something thanks to looking into this.

A Store (str) is 3 cycles
a branch(b) is 3 cycles
a nop is 1 cycle (used 3 to compensate for the branch to keep a 50% duty cycle).

Multiplied by 2 because of 6 cycles for on and 6 for off it should be 12 cycles and my computation was more than double at 28 cycles.

Well so it looks like by default PSoC Creator sets the frequency to 24MHz instead of 48MHz.

It's easy to change, open your cydwr, select the clocks tab and double click on the SYSCLK (it probably says 24.000 MHz on your project), actually I think you can double click anywhere within the clocks.



That will open the Configure System Clocks. Change the IMO to 48 instead of 24



Compile and run and double your pleasure



So now we are at 14 CPU cycles per period, they should be 12 so I'm guessing the port I/O adds 1 cycle per output (2 total) but I guess that will be somewhere in the ARM M0 docs, and I'm really not that curious about where a cycle per I/O went.

But if you want to look here is a link:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0432c/CHDCICDF.html

[true]

Unfortunately, this PSOC chip is truly a POS.
...
Although the chip is full of promises of many functions, it is severely crippled by allowing me to choose only a max of 4  functions(UDBs).

I don't think you understand what the PSoC can do, or what the UDBs are for.

The ADC converter only supports 8-inputs single ended at 11 bits

This is not quite accurate. You can have 8 configured on SARMUX (port 2), but this is to do things like sequential scanning without CPU control. You can also use the two AMUXBUS to get analog into your ADC from almost any pin...you can change these muxes as you wish. Even if you use capsense you can do this (but it isn't as drag-and-drop easy as capsense itself is). This is far more powerful than your PIC, and isn't even the start of what this ADC can do better than your PIC.

I needed 4 PWM's for my MMMMM motor control. I can only get one 16-bit PWM after adding a counter and ADC and boot module.

This is not true. You can get 4 PWMs on many PSoC4 models without even involving any UDBs. Depending on how you want to clock them, it is trivial to get 20 8-bit PWMs on a PSoC4 (but not much else if you need a timer for something ) I think you should read more about the PSoC4 architecture.

The PSOC4 48-MHz clock does not deliver speed. A simple GPIO On--GPIO  Off takes 1.4uSec to toggle one pin. To turn on or off a pin requires a method: GPIOpinWrite(1); GPIOpinWrite(0); iinstead of a simple bitx=1;  bitx=0; using a fast one or two machine language instruction  to achieve.

The API functions may not be the fastest, but they certainly do not require that method. I don't think they're that slow anyway so I think you are doing something wrong here.

The clock is +-2% to +-5% accuracy making an external clock necessary for precise timing.

So does your PIC, no matter what the datasheet says.

But the worst surprise is the 4 UDB limit which makes the chip useless except for the most trivial of useful intent!

This is not true. Far from it. I am using 3 of the 4 UDBs in my project so far and it is significantly reducing code complexity and eliminating extra hardware otherwise needed with any other micro (at least at this cost).

What now?

This might not be correct for your application, but instead of simply jumping into something, maybe try to understand it to see if it fits your specs. It looks like you don't understand PSoC. There is a steep learning curve but it plateaus into a comfortable place pretty rapidly. I don't think you're there yet.

The 16F88x chip is buy far the champion compared to to the PSOC POS. The PIC is yet the best pick!

If you were being punny, yeah, you can save cents, but for complex tasks my dollar is on the PSoC Even for some not complex tasks, with micros at $0.29 in small run friendly quantities...but yeah, we are straying a bit, aren't we?

Didn't you start this topic because your multiple PICs really weren't working out? I think a lot of the responses were to your subject line, not specifically your application. But I am not sure your PIC is your champion if this thread is still relevant to you...

Good luck finding something that works for your application.

[miguelvp]

The API functions may not be the fastest, but they certainly do not require that method. I don't think they're that slow anyway so I think you are doing something wrong here.

I agree with you on all your post other than this. If you use the API functions it has too many layers of indirection that will drive the pins at KHz. But then again there is no need to direct drive the pins. One could make a custom UDB module with verilog that will outperform the CPU. I think that SuzyC is taking the wrong approach on how to best handle what this chip has to offer.

Although I rather they make a cheaper 5LP, but that's just because I'm greedy

Edit: another note the +- 2% is from the chip specs, that doesn't mean your chip is going to fluctuate 2% only that it's going to be clocked higher or lower by that amount. Granted that temperature and running time might alter it as well. But it does have an internal temp sensor to compensate.

[SuzyC]

Here's what I get from an inexpensive 28-pin SOIC 16F886, which allows me to easily create satellite remote MMMMM PCBs 2x as small in size as the Cypress CY8C 44-pin device when used on it's native eval board: This allows me to embed small remote PCB's in the robot that fit in tight places and yet be controlled and communicate with a Master MCU that must have the smarts I need to allow any robotic sophisticated operation.

The 16F886 SOIC package offers an excellent size and DIP pin layout  that advantages me for homemade PCB layout as compared to the intricate PCB required for a 44-pin Cypress square chip's pin layout for my MMMMMs.

6 pins(yet still more avail pins for ADC if I had not needed them for other purposes) 10-bit ADC hi-impedance input requiring no Op-Amp Buffering on each input because of 1.5k input impedance (Cypress)
2 pins I2C for Master-Slave operation of motor control units and robot voice output  (512Kx8 I2C EEPROMs of pre-recorded 8-bit digitized voice storage.)
2 pins Rotary Encoder
2 pins for two10-bit PWMs operating at >19KHz for motor control and shared also for robot voice PWM generated sound output.
8 bit clock for TMR0 ISR for precise counters/timers/delays.
16-bit timer/compare/capture/timer for precision time interval measurement using an ISR.
1 pin high baud rate RS232 Tx for my own debug board that links to a PC computer on the Master 16F886
4 pins for serial LCD module interface.
2 pins precision 20ppm ext. 20MHz clock, (and there is no mod area I can see on the Cypress eval PCB to add a Xtal clock.)
External Xtal Clock allows me to have precise 100uSec to infinite time intervals with 100uSec resolution. And even if I switch over to the internal clock there is a hardware freq. adj. for the internal clock to limit timing error and change freq.  for voice output tone/gender.
1 pin reset that can be HW configed  as GPIO if necessary.
3 pins VDD, VSS VSS
1 pin Enable for optocoupler to isolate battery drain from A2D when robot is turned  off.
remaining pins MTPX'd  for /Momentary P-button "Enter" Sw/ izero-power P-Chan MOSFET turnoff/Turnoff, one pin for PWR ON latch/ HW output pins as debugging flags to precise pgm debugging points.

And since I can breadboard the 16F886 using a 28-pin skinny-dip I regain the use of two PGM clk and data pins on the 16F886 and can put them into  use as (i.e.) LCD control I/O's on the  breadboard and for MTPLX switchover from motor control PWM to enable power to speaker amp chip for voice PWM sound output.

Why the 16F886 PIC is maxed out:  <400 bytes of RAM, 8K of Flash pgm  and I am trying to make a robot that is able to use the data input from many remote analog and digital sensors to intelligently control at least 4 motors, each requiring PWM. There is simply not enough program space for even the very limiting 8-bit computational speed, nor 'nuff RAM left avail. to do any serious evaluation and decision computation, robot voice feedback etc. I cannot best use the wealth of feedback available to me from my robot's sensors even without using float vars. in my control algorithms.

[Kjelt]

Not to bash the Cypress PSoC but after reading the last few pages I can only conclude that it does not match the original posters wish, which was a MCU which is EASY to graduate to.

[SuzyC]

Thanks Kjelt and Miguelvp:

That's exactly the point.

Perhaps what Cypress would be wise to do is to offer a PSOC 5LP board about the same price, the same size as the PSOC4 42xx eval board, even if presented with a caveat that  ADC resolution might be possibly compromised by a cheap 2-sided PCB but without the  severe limitations (4) of UDBs.



There is no desire nor need for me to jump through flaming hoops and play endless guessing games, (nor waste hours or days to search through forums) to exact the programming for proper operation of Cypress UDB's when I am only presented with vague documentation(manuals) lacking even the most common examples of implementations of a functional block.

[SuzyC]

//BTW: I had already had set the Cypress SYSCLK to 48MHz.

uint16 j=0;
int16 V1=0,V2=0,V3=0,B4=0;
int16 a2dRes=0;

int main()
{
 ADC_SetChanMask(0x3F);
 ADC_Start(); //Starts A2D to scan all channels continously
 ADC_StartConvert();
LEDout_SetDriveMode(LEDout_DM_STRONG);
    Sw_ClearInterrupt();
   
    /* Enable global interrupts */
    CyGlobalIntEnable;
 
 PWM_Enable();
 PWM_Start();
 PWM_WritePeriod(2046);
   
start:   

P2_7_Write(1);
P2_7_Write(0);
 ADC_SetChanMask(0x2);//ADC  channel 1 selected

a2dRes=ADC_GetResult16(1);
if(a2dRes>0)
 {
   PWM_Start();
   PWM_WriteCompare(a2dRes);
 }
else PWM_Stop();//else PWMout=1 when PWM_WriteCompare(0) DCyc=0
 
 
goto start;
}

[miguelvp]

Well, the PSoC is easy to graduate, but hard to master.

Meaning it's easy if you want to do easy things, but if you want to push it, then you just have to master it and even if that's not hard, I wouldn't call it easy.

I'll put some links just because:

http://www.cypress.com/?docID=47779

http://www.cypress.com/?docID=42936

But there are many resources out there just for the digging.

SuzyC If you really don't want them I'll get them from you if you eat the shipping.

Edit: I mean I'll pay you the $4 per board if you eat the shipping to Chicago IL

[miguelvp]

BTW: I had already had set the Cypress SYSCLK to 48MHz.

Well I'm getting 3.442MHz switching a pin on and off per cycle

Edit: and it's just another ARM processor, you don't need to use their toolchain, uVision supports them as well.

[SuzyC]

Thanks Again 22swg:

I certainly will take a serious look a these PIC chips.

[dannyf]

Sounds like your issues are with ease of programming and space.

None of the arm chips will be easy to program - the Cypress chip is actually the exception here due to its innovative programming interface. Those arm chips are sold on their capabilities -> that means they are necessarily far more complex than the 8-bit chips.

With a desire for SOIC (very rare in arm land) or TSSOP (mostly low-end chips in the arm land), you don't have much choices but to stay with 8/16 bit chips.

The easier choice is to stay with PIC. The newer PIC16F1xxx chips are bigger, cheaper and faster than the PIC16F88x chips; Alternatively, you can migrate to PIC18F chips, or my favorite PIC24F chips. Some of the PIC24F chips have 5 timers and 5 dedicated pwm generators meaning they don't use any of the timers to generate pwm output.

The choices are abundant but you have to know why you are migrating and what's important to you.

[Spikee]

Explanation of psoc pin speed:

[Corporate666]

Hi Guys! This is an update to my goal to find a mo' better MCU than the PIC16F88x I had maxed-out in performance.

At the time of my last post I had decided on buying (4) CY8CKIT--049-42xx kits as what seemed the best choice among many.

Unfortunately, this PSOC chip is truly a POS.

Although the chip is full of promises of many functions, it is severely crippled by allowing me to choose only a max of 4  functions(UDBs).

Nonsense.  They have the GERBER files right on their website for this board, and they list very specifically the features of the chip.  If you need more than 4 UDB's, why would you buy a chip with 4 UDB's?  That's like buying a chip with 6 GPIO's and complaining it's a POS because it doesn't have 16 GPIO's.

The ADC converter only supports 8-inputs single ended at 11 bits but only offers a 1.5K input impedance, requiring buffer op-amps on each input.

"Only"?  The 4000 series is the low-end PSoC in the $0.29 to $2 range.  The fact that it maxes out at 8 ADC inputs is right in the datasheet, as is the input impedance - why would it be a surprise or a slam against the chip?  If you need more than the PSoC4 offers, then move to PSoC3 or PSoC5.  Both allow adjustable input impedance, up to 20-bit ADC's, and you can sample dozens of channels.  And, you can do it in hardware and write out the results to a memory location using DMA so you don't actually have to do anything in software.  If the specs, as listed right in the datasheet, don't work for your application, then why buy that chip and complain it doesn't do what you need?

I needed 4 PWM's for my MMMMM motor control. I can only get one 16-bit PWM after adding a counter and ADC and boot module.

The board you bought comes with the CY8C4245AXI-483 chip.  I just did a sample project with an ADC, counter and 4 16-bit PWM's and it fit fine.  The boot module is software only and doesn't affect UDB's.  The 4 PWM's use up the 4 UDB's and the counter fits into the dedicated TCPWM block and the ADC fits into the dedicated ADC block.  Not to keep harping on the issue but the datasheet explains all this.

The PSOC4 documentation for most UDB (functional blocks such as PWM ADC etc) are so very vague and poorly explained that it required hours upon hours to experiment,  trying to understand how to get these functional blocks to work.
For instance the PWM requires code to turn off and on the PWM just to set  Duty Cycle to zero, else the DCyC reverts to 100% when it should be 0, (PWM single output compare match for PWM Duty Cycle) for a simple single-output PWM.

I disagree that the datasheets are vague.  If anything, they are excruciatingly detailed, going into clock cycles for various commands, memory usage, interactions with other parts and more.   For example, just the PWM datasheet alone is 46 pages, the ADC datasheet is 30 pages, etc.   They also note in every datasheet that you can get example code and sample projects right from within Creator by clicking "File -> Example Project".  There you can filter by PSoC family, chip range and example type.  There are 3 example projects just for the PSoC4, 4200 family, ADC which show the component in use (and you can compile and use the samples if you like).

The PSOC4 48-MHz clock does not deliver speed. A simple GPIO On--GPIO  Off takes 1.4uSec to toggle one pin. To turn on or off a pin requires a method: GPIOpinWrite(1); GPIOpinWrite(0); iinstead of a simple bitx=1;  bitx=0; using a fast one or two machine language instruction  to achieve.

Once again, Cypress doesn't hide this.  It talks about speed in the pins component and refers you to this document http://www.cypress.com/?docID=42883.  That document explains that the pin API's are there for convenience and even has oscilloscope graphs showing how fast the pins switch using the API's as well as how fast they switch using direct addressing.  It also gives the code to directly toggle any GPIO pin the same way it's done with most other MCU's. 

The clock is +-2% to +-5% accuracy making an external clock necessary for precise timing.

Same with any MCU

But the worst surprise is the 4 UDB limit which makes the chip useless except for the most trivial of useful intent!

Nonsense.  It's a sub-$2 MCU with 32k of flash, a 48Mhz ARM M0 core, 36 GPIO's, that will run down to 1.7V, has dedicated op-amp, communication (UART/I2C,etc) and timer/counter/PWM blocks as well as 4 additional configurable blocks for whatever else you like such as comparators, DAC's, capsense, PRiSM LED color mixing, quadrature decoders, shift registers, LCD drivers, switch debouncers, edge detectors and more.  It's hardly useless for anything beyond trivial uses.

Sorry if I sound harsh, but your complaints are just mostly bullshit.  I'm sorry the PSoC didn't work out for you but I think you brought the wrong board for your application.

[miguelvp]

@Spikee, I'll watch the video later only looked at the beginning until he mentioned release mode.

Well release mode with optimizations for either size or speed makes the chip do nothing I see no activity on the scope at all, I also have an LED hooked to it via a resistor and nothing. I can run release but then I have to turn the optimization off.

Maybe a bug.

Also they are using the 5LP which uses the Cortex M3, on the M0 all branches are 3 cycles and stores are another 3. I will try to inline and try to use the assignment directly out of the generated code and will test if the inline works.

[true]

Not to bash the Cypress PSoC but after reading the last few pages I can only conclude that it does not match the original posters wish, which was a MCU which is EASY to graduate to.

A number of posters in this thread do think it fits this wish. It is pretty easy to use. As an example, having never developed for the product before and only doing this on sleep deprivation after work I got working capsense with almost no fuss in like 10-15 minutes. The toolchain is free and is easy to install (though windows-only, bah), there are examples included that even previews the main source file which is usually enough to see how the code portion works, the parts just work and the APIs are easy. And I came into working with this chip thinking it would be a load of shit for my application but the ease of use has only made it faster to get something working, and even without optimizing it is working really well. It has a steep learning curve but I didn't say a difficult one - the tool is just different. But once one gets the hang of it it is easy. There are also videos provided by Cypress that show how it works. (If you can't figure it out after that, use an Arduino maybe?)

The problem is the original poster didn't bother with any of that and just dove in expecting it to be a PIC or be easier than the PIC.

Thanks Kjelt and Miguelvp:
That's exactly the point.

But I don't think you got the point. Oh well.

There is no desire nor need for me to jump through flaming hoops and play endless guessing games, (nor waste hours or days to search through forums) to exact the programming for proper operation of Cypress UDB's when I am only presented with vague documentation(manuals) lacking even the most common examples of implementations of a functional block.

Then don't use the UDBs. Everything you want to do, except the ADC limitation, can be used with the fixed function hardware. You originally said the easiest to graduate to, not the easiest to fit a precise use case (that came later). The question of opinion was answered many ways, but the problem is you didn't ask the correct question, and you didn't pay attention to the answers either.

Meaning it's easy if you want to do easy things, but if you want to push it, then you just have to master it and even if that's not hard, I wouldn't call it easy.

I think you put it well. Really any ARM micro isn't going to be as "easy" (I would say "simple") as a basic PIC. PSoC isn't difficult, but there is a lot more you can learn, because there's a lot more it can do.

[dannyf]

the very limiting 8-bit computational speed,

I would caution your expectation of substantial gains in "computational speed" going to ARMs, particularly low-end ARMs.

Here is a real life example. An IMU algorithm that I have written for myself - fusing 6 DOF sensors together and calculating the resulting quarternions (not going to euler angles).

Here are some numbers for execution speed on CM0 vs. CM3 vs. PIC24F, all running on 8Mhz (PIC24F on 16Mhz crystals), 100 iterations:

CM0 vs. CM3 vs. PIC24F vs. PIC16F1938
0.286s vs. 0.129s vs. 0.371s vs. 0.727s <- No optimization
0.278s vs. 0.134s vs. 0.232s vs. 0.678s <- Max optimization

I would argue that there is minimum gain between CM0 and PIC24F, for practical purposes. CM3, being a little bit more 32bit-ish, has more of an edge over both.

Granted, the algorithm is highly floating point and not terribly friendly for 8-bit chips - I can run it on some AVRs and PICs - but the basic point stands: if computational speed is what you are going after, don't go after the CM0/CM0+ chips and maybe not even CM3 chips.

CM4F is another story,

edit: added the numbers for PIC16F1938 (8Mhz cpu and 32Mhz EC) - I would expect the numbers to be similar for other PIC16F chips.

[westfw]

If you need more than 4 UDB's, why would you buy a chip with 4 UDB's?

Not fair.  If you're "evaluating" the PSoC, you don't yet have a clear idea how UDBs are related to the peripherals that you can actually implement.  You're told "This is an 8-bit microcontroller replacement, only better", and you expect it to have peripheral capabilities similar to, say, an ATmega chip: UART, SPI, I2C, ADC and several timers.  And it's not "obvious" from the datasheet which of those requires one or more UDBs...

[Kjelt]

I would caution your expectation of substantial gains in "computational speed" going to ARMs, particularly low-end ARMs.
Here are some numbers for execution speed on CM0 vs. CM3 vs. PIC24F, all running on 8Mhz (PIC24F on 16Mhz crystals), 100 iterations:
CM0 vs. CM3 vs. PIC24F
No optimization: 0.286s vs. 0.129s vs. 0.371s
Max optimization: 0.278s vs. 0.134s vs. 0.232s 

I agree that relative to the clockspeed the gain is marginal (although the almost factor 2 between PIC24 and CM3 can be called more than marginal  ).
The point is that with the Arm32's you are not going to be stuck on run them on 8MHz/16MHz but can go easy to 72MHz, 120MHz even higher if you buy the bigger ones. So then you do get significant increases in computational power.

[dannyf]

I agree with the notion that the arm chips have a wider range of speed and consequently offer more raw performance at higher clock rates, especially for the particular chips in discussion here - STM32F0 for CM0 vs. PIC24FJ. The counter example here is the CM3 chip used: STM32F100 which maxed out at 24MIPS.

To be fair, there are PIC24 chips that go to 40 or 60+MIPS. But they become less price competitive.

[paulie]

In my experience unless you are involved with things like digital camera or cell phone very few commercial designs require high speed performance. Virtually zero benefit in hobby world unless the goal is to simply learn new architectures. IMO PIC or AVR will cover 99% of the situations in both cases. None of these can beat STM8 for lowest cost. Dannyf may have gone a little overboard claiming he purchased for 15 cents but the ghetto hype did bring that chip to my attention for which I am grateful. So STM8 for cheapest and PIC/AVR for easiest to work with and most support.

The STM32F103C may be king of the ARMs for features/performance/cost and was a lot of fun hacking but IMO 8 bits still rule for most applications.

[Kjelt]

In my experience unless you are involved with things like digital camera or cell phone very few commercial designs require high speed performance.

Color touch LCD with GUI is already enough to warrant an ARM32. Even IP stack alone would be enough for me to go to ARM32 or you must use third party proprietary implementations that are controlled by some low communication channel but those are usually expensive, and just do not always offer what you need.

For most hobbieist stuff 8 bit rules, but since the ARM32's are going down in price and also start to offer low power alternatives it is becoming a grey area and interesting time.

[westfw]

I've decided that I never want to deal with the "warts" that 8bit CPUs add to address more than 64k of memory (either program or data memory.)  I'd rather spend the time learning a 32bit MIPS or ARM chip than spend it figuring out all the Exxx and Xxxxx banking registers and special instructions, and how to get my C compiler to emit them...
So "speed" is less likely to be a reason to go to ARM than "memory."
GUIs, Filesystems, and Networking sure eat up your memory really fast...