Something else in the ARM [but not quite an Arduino] line - dual-core

I ran across this, and thought I'd pass it along. Has a UNO-form factor, but otherwise, not Arduino-compatible in any way that I can tell.

http://www.coridiumcorp.com/prod-specs11.html
http://www.coridiumcorp.com/prod-directory.html

Is programmable in C, and does have a serial bootloader for uploading programs via FTDI cable, although this info was not easy to come by.

I was most intrigued by the mention of dual-core M4/FPU and floating point hardware accelerator. Can someone put light on this last bit? I've been looking for something to use for a neural net simulation, so FP is handy.

Can someone put light on [dual-core M4/FPU and floating point hardware]

It uses the NXP LPC4330, which is an interesting chip with "asymetric" dual cores. One core is a Cortex M4 ARM cpu with floating point hardware, and the other core is a "more primitive" Cortex M0 (integer only, no divide instruction, etc.) (Both cores are standard ARM cpus; it's mixing them together in this fashion that is unusual.)

That is an interesting looking device.

Coridium concentrates on Basic language, but there is also a GNU C compiler. It's a little difficult to know how to program the dual-core without actually doing it - allocate code, select M4 for FP ops, &etc, but very intriguing. Parallel-processing on one embedded chip.
http://www.coridiumcorp.com/cHELP/
http://www.coridiumcorp.com/technical_support.html

Programming two cores on one chip is "interesting", shall we say :slight_smile: A nice feature is that both cores run at 200MHz. Multicores work in some applications, generally one fast CPU is a lot easier to manage than two cores.

For Cortex M4 with FPU, I would look at the STM32F3 or F4 series, the top of the range is 180Mhz and there are several cheap boards around.

The STM32 boards work well with em:blocks and a cheap STLINK JTAG or onboard USB-STLINK.

Next year ST will have a Cortex-M7 out as well, interesting to see how it is priced.

generally one fast CPU is a lot easier to manage than two cores.

I guess this sort of thing makes the most sense to use one core for number-crunching and the other for datacq, general I/O, and buffering. So you're not trying to actually 'parallelize' code. Of course, you're stuck with the problem of transferring data between the 2 cores.