Paths toward more CPU capability, yet retain Arduino compatibility?

Greetings all,

I like the ease of use of Arduino, but (like others), I find Arduino somewhat limiting in CPU speed and I/O. The Arduino mega provides more I/O pins, but the processor is still not that fast. Several folks here (my self among them) are experimenting with 32-bit processors, but doing that requires breaking with the Arduino code base.

It appears there are a couple projects porting the Arduino development env to support the Cortex-M3 architecture. This is IMHO very attractive, because it would give considerably more processing power, yet retain the use of the existing reprap codebase. Here are the two projects I know of:

[www.leaflabs.com]
[code.google.com] (browsable svn repository)


[www.xduino.com]
[www.xduino.com] (Code, but without the IDE)

Please reply to this thread if you know of any similar efforts.

FYI, I have pre-ordered one of leaflab's maple boards, and I filled out the reg form to (try to) get the Xduino download link. I have heard back from the leaflab folks, but not from Xduino. Leaflabs is local to me (walking distance from work), and I may see if I can drop in to see how they're doing.

There's also a loosely related project (seemingly sponsored by ARM), that looks interesting, but isn't Arduino-compatible:
[mbed.org]

This one uses a an NXP version of a Cortex-M3 , running at 100 MHz. The catch/feature is that you don't get the compiler, you use their compiler, over the web. They also support an arm7 version. One the other hand, they've done some interesting work, that apparently makes their board(s) act like a thumbdrive. So, the way you download code is to copy the binary (produced with their web-based tool) onto the "thumbdrive" and then either reset or power-cycle it -- sounds pretty slick.

---

Larry Pfeffer,

My blog about building repstrap Cerberus:
[repstrap-cerberus.blogspot.com]

Because the arduino environment effectively maps i/o operations via a Hardware layer interface in software this is quite easy to do, you just replicate the environment for your target hardware.

The problem comes in embedded systems when processes have been optimised for performance on a specific microcontroller. Which may cause compiler errors or runtime issues on the new target.

I have an mbed on order, the bootloader uses the NXP secondary bootloader, which makes the device flash behave like a usb memory stick so no external programming software or hardware is required. This is the main reason I've bought one, as its a much more capable device than the Arduino, additionally they are much cheaper at about $7. The ATMega644 is very expensive for its capabilities.

Compiler is not an issue, the Cortex M3 variant of the ARM GCC compiler is supported, its not a requirement to use the online system.

Another benefit of this device is that it has Ethernet (MAC is on the chip, PHY is on the back of the board)

It also has 4 Serial ports, USB and CAN More flash and ram and is a hell of a lot faster.

Its a win-win situation in my book.

Using a web-based proprietary tools seems as far from open source and GPL software as possible. The Arduino environment uses GCC as compiler, and the Cortex chip is supported by GCC as well. No need for proprietary software. The main issue in porting the Arduino environment and Wiring language is to port the libraries and essentially implement a small abstraction layer for the board.

Going to a "big" system, like the Cortex M3 one, also means the controlling software will end up being a lot heavier. You'll have to worry about caches and interrupt handling is far more complicated. So, before you know, you'll be running a load of libraries, a TCP/IP stack and because of the increased complexity of the software, you'll need a real executive. Building this all on your own may be fun, but unless you're planning on reusing an existing real-time kernel, you'll spend years reinventing the wheel.

The advantage of using Arduino/AVR is that the hardware and software is so simple, it really is very hackable. Also, the AVR doesn't use cache memories, different protection levels etc. So, every instruction will always take the same amount of time (mostly: 1 cycle), so doing timing by counting instructions is trivial.

If we'd end up using a RepRap motherboard based on the Cortex/M3, I'd suggest we use a full operating system, such as a version of Linux. This will give you all the well-tested libraries, TCP/IP stacks, device drivers etc, you need to take full advantage of these complex chips. However, for low level stuff like the extruder controller, and likely a stepper motor controller, I'd still prefer using the Atmel AVR chips.

Using a little extra hardware, you'd be able to avoid a lot of complexity in the software. I know it is possible to do everything with one big chip, but it will be so much harder to get guaranteed interrupt latency when you're having to handle SD card I/O, a USB host protocol, TCP/IP and other stuff in combination with stepping 3 or 4 steppers a couple thousand times a second.

So, while I think the Cortex M3 would be OK to essentially add a small computer to the RepRap (or a RepStrap), I don't see them really replacing the AVRs.

-Geert

GeertB Wrote:
-------------------------------------------------------
> Using a web-based proprietary tools seems as far
> from open source and GPL software as possible. The
> Arduino environment uses GCC as compiler, and the
> Cortex chip is supported by GCC as well. No need
> for proprietary software. The main issue in
> porting the Arduino environment and Wiring
> language is to port the libraries and essentially
> implement a small abstraction layer for the
> board.
>
> Going to a "big" system, like the Cortex M3 one,
> also means the controlling software will end up
> being a lot heavier. You'll have to worry about
> caches and interrupt handling is far more
> complicated. So, before you know, you'll be
> running a load of libraries, a TCP/IP stack and
> because of the increased complexity of the
> software, you'll need a real executive. Building
> this all on your own may be fun, but unless you're
> planning on reusing an existing real-time kernel,
> you'll spend years reinventing the wheel.
>
> The advantage of using Arduino/AVR is that the
> hardware and software is so simple, it really is
> very hackable. Also, the AVR doesn't use cache
> memories, different protection levels etc. So,
> every instruction will always take the same amount
> of time (mostly: 1 cycle), so doing timing by
> counting instructions is trivial.
>
> If we'd end up using a RepRap motherboard based on
> the Cortex/M3, I'd suggest we use a full operating
> system, such as a version of Linux. This will give
> you all the well-tested libraries, TCP/IP stacks,
> device drivers etc, you need to take full
> advantage of these complex chips. However, for low
> level stuff like the extruder controller, and
> likely a stepper motor controller, I'd still
> prefer using the Atmel AVR chips.
>
> Using a little extra hardware, you'd be able to
> avoid a lot of complexity in the software. I know
> it is possible to do everything with one big chip,
> but it will be so much harder to get guaranteed
> interrupt latency when you're having to handle SD
> card I/O, a USB host protocol, TCP/IP and other
> stuff in combination with stepping 3 or 4 steppers
> a couple thousand times a second.
>
> So, while I think the Cortex M3 would be OK to
> essentially add a small computer to the RepRap (or
> a RepStrap), I don't see them really replacing the
> AVRs.
>
> -Geert


Yes there is more to do with more capability, but if you added ethernet or other features to the arduino you would have the same situation.

There is no cache as would find on a desktop cpu. The peripherals will require buffers as with any other system. In this setup the ethernet is actually much easier as you're not messing around with an SPI bus and the secondary bus management. Secondly for CAN. RS485 still requires its massively inefficient processor overhead as it does with the AVR.

Additionally, not everything needs to run in a 500 microsecond loop, so you can run multiple schedulers its all dependant on what's required of the system.

If its necessary for a real-time operating system, FreeRTOS is available.

The ease of use, cost and capability of this system far outweighs the AVRs by a mile.

No external programming tools and hardware makes it much simpler for users to get up and running, there must be several posts a month with people struggling to program the hardware.

The AVR's obviously work, but this offers a much more scalable solution.

Guys, try this link,

pretty nice extension of the Arduino enviroment to work with an M3 Cortex Stamp.
STM 32 Arduino

There's also Cortino

Cortino

The NXP devices are cheaper, and have a better pin layout, the STM devices with CAN (one of the reason's I'm looking at this device) are on the same channel as USB. which is badly thought out IMO.

Having already started my own custom STM32 CortexM3 board earlier this year, I have some experience in it already. I'm not using any arduino clone.

The cortex M3 does have a multi channel memory management unit, very handy for tasks like ethernet, serial and memory card.

I'm finding the STM build environment pretty nasty to work with, but the chip is great. Partly, I'm new to C on this project, but also, the libraries are big, and the raisonance toolchain I've been using is somewhat haphazardly documented, in my opinion.

As annodonnomi2 states, the cache issue is not relavent. I think GeertB might be thinking about DRAM and it's need for refresh? It's not an issue unless you have a big need for off-chip RAM, which is unlikely unless you want to do on board 3D processing of the CAD source files.

I'm not sure what the fixation is on needing an RTOS or equivalent, the interrupts can run so fast on an ARM, even running out of flash, that you can spin through several tasks or portions thereof in each interrupt cycle, I just use a select case and counters to pick the important stuff each time through.

I'm sending the step information direct to L298's, and PWM, and I can monitor load via ADC, and this is on 4 stepper motors, + a lot of other fast interrupt driven stuff. For those who want to cheat, and send out up/down, step-clock signals, and have other hardware convert to the step phases, it's even less overhead for an ARM. In my case, I've had to hack one of the library files to get the speed I want on certain I/O transactions.

The only thing I'm having issues with at the moment, is properly keeping 32 bit values correct in and out of interrupt.

---

My CNC/extruder creation: [grael-minifactory.blogspot.com]

grael:

C made little to no sense to me until I'd built large (multi file, multi library, relocatability, etc) projects in assembly. Now I understand how C short-cuts most of the details while still remaining very close to the machine architecture, and can write clear and effective microcontroller-suitable C with ease.

If you want to give this path a go, probably best to do it on a small chip like an atmega or attiny rather than something necessarily more complex like the cortex. I cut my teeth on the m68hc11, and all those skills translated surprisingly readily into atmega-land

I wrote a cross assembler on an amstrad CPC664 many years ago, to program 68HC11 via my custom serial port, in assembler. I've done very large programs in assembler, and certainly C is less longwinded in comparison with assembler. Most of it is going fine for me, but I've not yet got ambitious on pointers. I'm also unsure how C handles 32 bit variables behind the scenes on an ARM, I think I'll have to manually disable interrupts briefly while I'm tweaking some shared values then re-enable. It can be mystifying what does, and what does not get done automatically in C

---

My CNC/extruder creation: [grael-minifactory.blogspot.com]

grael Wrote:
-------------------------------------------------------
> I wrote a cross assembler on an amstrad CPC664
> many years ago, to program 68HC11 via my custom
> serial port, in assembler. I've done very large
> programs in assembler, and certainly C is less
> longwinded in comparison with assembler. Most of
> it is going fine for me, but I've not yet got
> ambitious on pointers. I'm also unsure how C
> handles 32 bit variables behind the scenes on an
> ARM, I think I'll have to manually disable
> interrupts briefly while I'm tweaking some shared
> values then re-enable. It can be mystifying what
> does, and what does not get done automatically in
> C

Many Safety critical Embedded software design standards, suggest avoiding pointers as much as possible.

Cortex M3's are 32bit ALU. Cortex-M3 Description

annodomini2 Wrote:
-------------------------------------------------------
>
> Many Safety critical Embedded software design
> standards, suggest avoiding pointers as much as
> possible.


It's very hard to use C without using pointers.
From "The C programming Language", second Ed., p. 99 (AKA K&R 2nd, by the language designers, themselves):

> In evaluating a(should be square brackets surrounding the letter i), C converts it to *(a+i) immediately;
> the two forms are equivalent.

So, doing anything with arrays in C uses pointers, whether one realizes it or not. Pointers can be used safely (in most contexts, see below), but it takes considerable care.

The MISRA standard [www.misra.org.uk]
forbids use of non-const function pointers:
> Rule 104 (required): Non-constant pointers to functions shall not be used.

I don't know exactly what DO-178B does/doesn't allow re pointers

Edited 1 time(s). Last edit at 11/17/2009 02:17PM by Larry_Pfeffer.

---

Larry Pfeffer,

My blog about building repstrap Cerberus:
[repstrap-cerberus.blogspot.com]

I didn't say don't use pointers, just avoid, where possible of course

You are right though, MISRA states no function pointers,

This is a useful point for inexperienced users, to point out (no pun intended) that there are different types of pointers.

Edited 2 time(s). Last edit at 11/17/2009 02:42PM by annodomini2.