ARM variant electronics

I've been considering this for a while, and it seems to me that an ARM CPU would provide some benefits on a reprap. The chief among these actually being the availability of well priced development tools--see LPCXpresso and STM Discovery--as well as the GNU toolchain, though that works with AVR's too.

In addition, many newer ARM CPUs support USB OTG or USB Host mode which could allow plugging a USB drive straight into a reprap, which seems more useful than SD cards to me. The CPU performance plays into this as well. With an ARM Cortex-M4 with floating point support (e.g. STM32F4Discovery/STM32F407), you could probably do slicing right on the CPU, in real time.

In short, there's a lot of potential for some more interesting things being done with the electronics. The price increase is small, starting from the Gen7 electronics, and it should be a reduction, starting from RAMPS.

There are several problems with using ARM devices in Reprap.

First, the packages: virtually no ARM devices come in SOIC or DIP, and those that do lack the features described above and have little I/O. This leaves us with TQFP and BGA packages. BGA's are technically feasibly with a toaster SMD oven, but I don't think this is a good idea for a hobbyist project. TQFP is solderable by hand provided that the user is experienced at soldering and has flux available. Boards with solder mask are probably necessary too. This drives us into the realm of commercially produced PCBs. The least distasteful way of handling this seems to be using header boards, such as the Olimex STM32-Hxxx/LPC-Hxxxx boards.

The second problem with ARM devices is the toolchain and library. GCC works for ARM, but requires some setup and careful handling in makefiles, particularly on Windows. When it comes to boards like the LPCXpresso, there's some concern about the integrated debugging tool, as it doesn't have OpenOCD support, which could make it difficult to use--the LPCXpresso toolchain's free version has a debug limit of 128kB and the ARM/ version of STM32's toolchain is limited to 32kB, for example.

Finally, there's the issue of the existing Reprap firmware. Much of it is based on Arduino libraries, which may or may not work on ARM Cortex-Mx. It seems that Leaf Labs has done some porting or rewrite work on this for their maple platform.

There are a few tradeoffs to make in choosing how to approach the host CPU card: The best option I can see would be for someone enterprising to start selling a ARM MCU + FT2232 header board at some shockingly low cost. Since that's not an option yet, the solutions I've found are:

Olimex header boards:

LPC-H1343 (8.95 EUR, Cortex-M3 @ 72MHz, 42 IO ) ***Only has 32 kB Flash, 8kB RAM
STM32-H152 (14.95 EUR, Cortex-M3@32 MHZ, 65 IO)

Leaf Labs Arduino-esque boards

Maple ($44.99, Cortex-M3 @ 72MHz, 43 IO)
($34.99, Cortex-M3 @ 72MHz, 34 I/O)

The MikroElectronika EasyMx Pro CPU cards: (click the CPU card tab). These ones have Ethernet Phys on-board. $24, Coretex-M4 @ 168MHz with FPU, 65 IO.

EmbeddedArtists LPC1343 quick start board (16.90 EUR, Cortex-M3 @ 72MHz, 26 IO ) ***Only has 32 kB Flash, 8kB RAM

Now, for the boards with integrated debugging hardware.

NXP's LPCXpresso series: I have actually removed these from the comparison because of the code size limitations, restriction against using C++ code without buying their environment, and the lack of support for LPC-LINK in OpenOCD.

STM32 Discovery series

STM32F0DISCOVERY ( $7.99, Cortex-M0 @ 48MHz, 55 IO ) ***Only 8kB RAM
STM32VLDISCOVERY ($9.90, Cortex-M3 @ 24MHz, 80 IO ) ***Only 8 kB RAM
STM32L-DISCOVERY ($10.50, Cortex-M3 @ 32MHz, 83 IO)
STM32F4DISCOVERY ($14.90, Cortex-M4 @ 168MHz, 82 IO)

With all of that information, the STM32F4DISCOVERY looks like the best option to me. The debugger is supported by OpenOCD and the full GNU toolchain is useable and the examples can be built with some tweaks. There is one little hiccup with this plan, however: The STM32F4DISCOVERY supposedly comes with a strange license which states that it cannot be included in a product and is for evaluation purposes only, however Adrian Bowyer doesn't think this is a problem.

Edited 2 time(s). Last edit at 07/20/2012 03:04PM by Annirak.

The advantage of the Arduino is that it presented a pretty standard platform to work from. There are so many options with ARM, and people will have their own preferences, I think it might be difficult to build consensus.

I would favour a design with a CPU module approach, so that people can plug in their own CPUs as they wish, but getting a standard there could be nigh impossible too. Then of course, there is a problem with software compatibility, defining a common HAL would be quite doable, the extra power of ARM allowing a little extra overhead, but getting people to adopt a common architecture suffers from the same problems.

I'd probably be happy to settle on an STM32 platform, but so far I have been using LPC1758 (R2C2 board) and LPC 1343. The Smoothieware code runs on LPC1769, but is less tied to hardware, since there is no smoothieboard yet. People have been porting to STM and Atmel chips I think.

However, the Arduino Due is just around the corner, which I guess will have a set of libraries which provide some compatibility with Arduino AVR. I guess that will be a much more comfortable path for existing Arduino users. The Due is based on an Atmel chip. I suspect the Due will be popular because it has the Arduino name.

The Raspberry Pi has got considerable mind share, and is also cheap and powerful, and will be available in quantity probably around the same time the Due comes out. The R.Pi lacks IO and would need an IO expander, but for $35 is probably still a more attractive proposition than a less powerful CPU ( I am assuming that Linux is an optional benefit of R.Pi, it can be run bare metal at the loss of some features).

So I think at this point a plan that doesn't factor in Due/Pi may be difficult to get traction for. I think that any ARM firmware that succeeds is going to be the most portable one, not necessarily the one with best performance on a particular platform.

Quote

(8.95 EUR, Cortex-M3 @ 72MHz, 42 IO ) ***Only has 32 kB Flash, 8kB RAM

Currently, Teacup builds to some 16'000 bytes binary size, using about 700 bytes RAM (movement queue set to only 4 movements), so this looks doable. Don't know how this translates to a 32-bit CPU, though, even if much of the Teacup code uses 32-bit integers.

Perhaps there's a reason why all the currently ongoing ARM efforts progress slowly only (except for the R2C2): the only real gain you can get is a faster step rate while doing acceleration. There's about zero interest in a look-ahead algorithm better than this "jerk"-approach. Complex displays and such stuff are a "nice to have" only, and G-code compilation on the controller is out of reach for simple ARM CPUs, too.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

The R2C2 firmware was derived from Teacup, I looked back at some earlier versions and the usage was approx 32K program and 4K RAM. Our attempts to bloat it out with extra features have not succeeded, we have only got it up to 45K program and maybe 20K RAM. The LPC1758 has 512K Flash and total of 64K RAM, so we are somewhat overspecced. We allocate 64KB just for the USB bootloader, I think it actually uses about 15K.

I have been working on adding a TCP/IP stack, but as Traumflug says there isn't really many more features to add. The Raspberry Pi and similar are a bit of a game changer, it is much easier to add network, GUI support with a wide range of drivers through that route. In which case we could remove SD, LAN and use a much smaller chip. 32K certainly feasible, for a little extra headroom and a USB bootloader maybe 64K.

Having said that, the difference in cost for small q's is a few $, and for $15 the STM32F4 is a big chunk of power for not a lot of $!

The way I see it, there are four ways for the community electronics to go from where they are now.

1. Stick with existing DIP ATMega solution (Gen7). This has enough power to do the job, can accept SD cards via SPI. It's not fancy, it's not expensive, it gets the job done. (Perhaps Traumflug can elaborate on the minimum BOM cost of this solution)

2. Switch to Arduino Due when available. It doesn't seem to be hitting its deadlines so it's not even certain that it will become available. Based on current Arduino Mega prices, I expect it to add significantly to the system cost. I'm not certain what it adds in terms of functionality other than increased step speeds--perhaps easier USB connectivity? This seems to me like it's an evolution of RAMPS more than it is the next generation of the mainstream electronics. I would anticipate the cost of this solution being, at minimum, equivalent to RAMPS--$200 is the kit price I have seen.

3. Raspberry-Pi electronics. Due to the lack of I/O, the Raspberry-Pi will require a coprocessor. Most processors which are capable of acting as I/O expansion for the RPi would be capable of doing the same job as the current Gen7 electronics, so I'm not sure what the advantage to this approach is. It could add USB host and ethernet capability or it could remove the dependency on a PC, but that makes the RPi replace the PC, rather than the electronics. That said, a RPi with a relatively weak coprocessor to handle I/O expansion and critical timing could make a good solution. Approximate cost would be Gen7 cost + $35 for the RPi.

4. Gen7 with ATMega replaced by ARM CPU card. There are a number of attractive CPU card options, ranging from a STM32F0DISCOVERY board at $8 to the mbed at $64, with several open source options in between. Many options allow Ethernet and/or USB Host and/or USB OTG. The advantages I see are a wider range of suppliers, an onboard debugger (in many cases), more I/O options (more motor controllers and/or more PWM channels and/or more ways to connect to the PC). Depending on the CPU card selected (e.g. one with a STM32F407 target CPU) there's the advantage of being able to process the STL file directly--at least I think that should be possible with a 210MIPS CPU with a FPU. The majority of these options come in at lower cost than RAMPS, which is part of why I find them attractive. The minimum cost of using an ARM CPU card + Gen7 is the cost of Gen7 - ATMega644 + ARM CPU card. With the STM32F4DISCOVERY CPU card, that works out to an additional cost of about $10.

One possibility for a RPi-based solution would be small modules connected together with RS485, all controlled by the RPi. I think I could fit two stepper drivers, a PWM output, a SPI header and a small microcontroller on a 5 x 5cm board. I know that older-gen reprap electronics used a token-ring network and that was dropped. I'm thinking of something a little closer to a star network with a RPi central controller. I don't know if that idea would get much traction.

I'd consider the RPi to be more a replacement of the host than a replacement of the controller.

Quote

1. Stick with existing DIP ATMega solution (Gen7). This has enough power to do the job, can accept SD cards via SPI. It's not fancy, it's not expensive, it gets the job done. (Perhaps Traumflug can elaborate on the minimum BOM cost of this solution)

That's currently about EUR 85.- including tax, StepSticks and USB-TTL converter. US$ 85.- without tax for non-european citizens. A different stepper driver chip, like the TB6560 or THB6064 can save a few additional Euros, but not many.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> The bottleneck of the ATmegas is acceleration
> calculation. This requires a 32-bit integer
> division, people talk about 800 clock cycles or
> more for this single thing. No better algorithm in
> sight, unfortunately.

But there are better processors in sight. In fact, they have been available for over 10 years. Looking at the present, however, any ARM Cortex-M3 or above can handle this with a 2-12 cycle 32-bit hardware divide.

Edited 1 time(s). Last edit at 07/24/2012 11:31AM by Annirak.

Traumflug Wrote:
-------------------------------------------------------
> I'd consider the RPi to be more a replacement of
> the host than a replacement of the controller.

Generally speaking, I'd agree. However, the possibility of using several inexpensive microcontrollers essentially as PID controllers with segment buffers, all driven by a RPi is interesting. It separates the tasks into low latency/low processing power--PID & segment buffer--and high latency/high processing power: user I/O, file system handling, file parsing, slicing, path planning, coordinate translation (for delta bots), path segmentation, etc.

Of course, all of that, except maybe the slicing, could be handled by a single Cortex-M4, so the cost of the RPi may not be justifiable. It does, however, make networking, USB handling, etc. very easy since it can run Linux. Using an RPi as the primary controller would also allow the use of high level languages for most of the firmware--which would become software. Only timing-critical code would need to be run on the MCUs

Annirak Wrote:
-------------------------------------------------------

> process the STL file directly--at least I think
> that should be possible with a 210MIPS CPU with a
> FPU.

Yes, but 128K RAM and an SD card, compared to 3GB and a HD!

I think you have skewed the pros and cons quite a lot to favour your preferred solution, but your hopes for the STM32F4 are overly ambitious.

Realistically, ethernet interface would be a nice addition, though not essential, and USB hard drive is also a nice to have but not essential. There is also quite a lot of work on the software side to support those solutions, AFAIK there are no portable open source USB host stacks around.

bobc Wrote:
-------------------------------------------------------
> Yes, but 128K RAM and an SD card, compared to 3GB
> and a HD!
>
> I think you have skewed the pros and cons quite a
> lot to favour your preferred solution, but your
> hopes for the STM32F4 are overly ambitious.
>
> Realistically, ethernet interface would be a nice
> addition, though not essential, and USB hard drive
> is also a nice to have but not essential. There is
> also quite a lot of work on the software side to
> support those solutions, AFAIK there are no
> portable open source USB host stacks around.

Thank you for the feedback. I honestly don't know enough about the various requirements of the 3D printing software/firmware stack and I need to know if I'm skewing the pros & cons of any solution--in other words, I value everyone's input.

With the point that Traumflug made recently regarding acceleration calculations in ATmegas, I would suggest that the next gen electronics support hardware divide. For ARM, that means Cortex-M3 or above. For AVR, that means AVR32. For PIC, that means PIC32. For a RPi-network solution... it's irrelevant.

Neither Ethernet UDP or USB mass storage need much code. I have coded simple implementations of both from scratch. Linux is a sledgehammer to crack a nut IMHO.

---

[www.hydraraptor.blogspot.com]

Quote

But there are better processors in sight.

Are they? So far I'm not aware of a chip with hardware divide in a PDIP or other through hole package.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> Are they? So far I'm not aware of a chip with
> hardware divide in a PDIP or other through hole
> package.

The important question is not whether a package is through-hole, it's whether it's hand-solderable. PLCC packages are easily hand solderable or can be used with through-hole sockets. SOIC packages are easily hand-solderable.

What is wrong with a carrier board? Your design uses carrier boards for SMD motor drivers. How is this different?

You could make the argument that we don't want to makers to have to depend on a company to provide the carrier boards, but we're already almost there, since the MCUs we're using require a bootloader to be programmed in advance. So makers depend either on someone else to program that bootloader or a company to ship it to them preprogrammed.

Quote

SOIC packages are easily hand-solderable.

Are they? What I see is people shying away as soon as "SMT" is seen somewhere. Generation 3 electronics was partly SMT already, a culture of making them DIY didn't happen.

Quote

Your design uses carrier boards for SMD motor drivers.

This is exactly the part which is going to go away next.

Quote

So makers depend either on someone else to program that bootloader or a company to ship it to them preprogrammed.

RepRap electronics can be used as a programming device, just like an Arduino.

Perhaps simple CPU carrier boards will happen at some time, currently the demand is apparently not high enough.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

P.S.: please don't get me wrong, it's always a good idea to think about the future, to examine improvements. It's just, well, the makers of the available electronics variants aren't stupid either. Designs are done for a reason, even in the details.

So, to advance things, you have either to do small steps or you face a huuuuge amount of work (new board, new assembly instructions, new programming stack, new firmware!) along with a loooong breath to convince people your stuff is better. So much better they want to trash their existing, working setup. And looking at the current habits in this community, you're likely alone with your new pet until you have something almost as ready as what's available now.

That said, let's continue to discuss the future

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I have a lot of respect for the designers of all of the generations of the reprap electronics (to be clear, that includes Gen 7).

I think that we just have two very different approaches. There are three metrics we can judge hobbyist electronics by: price, performance, ease of manufacture. You have chosen ease of manufacture and price as priorities over performance. I'm choosing performance and price over ease of manufacture... coarsely speaking, anyway.

But as far as ease of manufacture goes, I want to understand your reasoning on carrier boards. I don't understand why chips are okay, but carrier boards are not. That seems to me like an awfully arbitrary line to draw. What's the reasoning behind it? In the Reprap parlance, why is an ATmega644 a vitamin and an LPCXpresso not a vitamin?

In any case, I don't think that the electronics I'm desining and your solution actually fill the same niche. I'm trying to eliminate the processor as a bottleneck. I don't think that the electronics should, in any way, limit the performance of the mechanical hardware, but that's a design philosophy that we don't share. Consequently, my design will fill a different niche in the Reprap userbase than yours--provided anyone even wants what I'm working on.

Have you looked at R2C2?

[reprap.org]

Is there something you wanted out of an ARM reprap controller he's not doing?

R2C2 has nearly all of what I want to see out of ARM electronics. In fact, it is what I want for plain reprap operation.

What would I change? I'd like to see provision for MAX31855 thermocouple readers. I'd like provision for more stepper motor drivers, but that's because I want to do some work with multi-extruder systems.

Quote

But as far as ease of manufacture goes, I want to understand your reasoning on carrier boards. I don't understand why chips are okay, but carrier boards are not. That seems to me like an awfully arbitrary line to draw. What's the reasoning behind it? In the Reprap parlance, why is an ATmega644 a vitamin and an LPCXpresso not a vitamin?

When Gen7 started over a year ago, almost everybody was running a Gen3 with halfstepping and me myself ran a Gen2 with an ATmega168. Printer printed, people were mostly satisfied. This Pololu carrier was the new guy in town, mysteries about it's performance were there, but only few had actually tried it. Obviously, a situation different from today. So my goal was to use something people recognized already, which was reasonable future proof and allowed me to concentrate on other parts, like the manufacturing process.

One of Gen7's new, unique features was (perhaps still is) it's 20 MHz clock crystal. 25% performance increase, costing no money, but requiring firmware and bootloader changes. Guess what happened: instead of cheering about this cheap win, people almost shouted at me. "How stupid can one be to not use a 16 MHz clock?", "16 MHz is more than we'll ever need!", and so on. A whole lot of people reverted back to 16 MHz instead of running Teacup firmware (which allowed 20 MHz from the beginning) or instead of fixing their preferred firmware. Especially the most vocal RepRappers simply refused to accept it. Just two days ago one of the experienced guys on IRC said Gen7 would be incompatible with common firmwares.

Looking at R2C2, the picture appears similar. While I'm pretty sure this board works well, it's simply ignored away. Nobody recommends it, nobody talks about it, ... instead they talk about these not-yet existing smoothieboards and 4pis on IRC and even recommend them to newbies sometimes.

That's the harsh RepRap world. Not everything bad, though, a year after the above, Gen7 apparently has found it's place. Not because it's faster, not because it's cheaper, mostly because it's the easiest to do DIY.


Oh, this post got a bit long ...

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Annirak Wrote:
-------------------------------------------------------
> R2C2 has nearly all of what I want to see out of
> ARM electronics. In fact, it is what I want for
> plain reprap operation.
>
> What would I change? I'd like to see provision
> for MAX31855 thermocouple readers. I'd like
> provision for more stepper motor drivers, but
> that's because I want to do some work with
> multi-extruder systems.

I also want to play with dual extruders, I am planning to create an r2c2 "shield" to support a second extruder. It would be nicer if it was an integrated solution of course.

Traumflug Wrote:
-------------------------------------------------------
> One of Gen7's new, unique features was (perhaps
> still is) it's 20 MHz clock crystal. 25%
> performance increase, costing no money, but
> requiring firmware and bootloader changes. Guess
> what happened: instead of cheering about this
> cheap win, people almost shouted at me.

I guess this is a problem when a design is successful, it creates inertia to further improvement.

> Looking at R2C2, the picture appears similar.
> While I'm pretty sure this board works well, it's
> simply ignored away. Nobody recommends it, nobody
> talks about it, ... instead they talk about these
> not-yet existing smoothieboards and 4pis on IRC
> and even recommend them to newbies sometimes.

I am not sure why there is such a buzz around smoothie/4pi etc and not R2C2. Perhaps partly because it is seen as more of an open development, partly because Arthur is an enthusiastic salesman. I think a good part of it is that a design on paper always appears to have more potential than a realised design. In reality, its about fixing hardware issues and ironing out bugs that makes a system useful.

I bought an R2C2 board, because it was the only complete ARM printer board available at the time (I think still is), and I have been quite happy with it. I am more into the software side than mashing together mBeds and pololus.

I had a crazy idea though, if we had a Cortex M3 on a 40 pin carrier/header, it could plug into an existing Gen7 board and provide extra oomph, but is easily swapped with an AVR. I think the 5V/3.3V levels can be handled on the ARM carrier board. When I have a moment, I might have a play with a design.

Of course, software compatibilty is a different kettle of fish, but it might provide a migration path that retains investment in existing hardware. It is possible to emulate some of the Arduino libraries, but any direct references to AVR registers would need rework.

After looking at R2C2, smoothieboard, and 4pi, there doesn't seem to be much sense in my continuing down this avenue. Several other people have already done essentially what I intended to do.

I don't know if anyone has interested in .NET Micro Framework (running C# on ARM with no OS, could debug with Visual Studio). AFAIK it was ported to STM32 architecture recently. That said, developing C# on Linux/Mac might not be fun at all, I havn't try.

I would love to have my electronics run on Ethernet, even UDP. (After all you need those checksum and application level keepalive check even with TCP...). For ARM there would be plenty of CPU cycle and hardware support. Does anyone try this with AVR yet - I wonder how much CPU time were left on the AVR for that?
It's better than USB/UART for 1. Speed 2. Cable length limit 3. Avoiding ground loop.

sam0737 Wrote:
-------------------------------------------------------
> I don't know if anyone has interested in .NET
> Micro Framework (running C# on ARM with no OS,
> could debug with Visual Studio). AFAIK it was
> ported to STM32 architecture recently. That said,
> developing C# on Linux/Mac might not be fun at
> all, I havn't try.
>
> I would love to have my electronics run on
> Ethernet, even UDP. (After all you need those
> checksum and application level keepalive check
> even with TCP...). For ARM there would be plenty
> of CPU cycle and hardware support. Does anyone try
> this with AVR yet - I wonder how much CPU time
> were left on the AVR for that?
> It's better than USB/UART for 1. Speed 2. Cable
> length limit 3. Avoiding ground loop.

.Net Microframework isn't designed for realtime operation.

We are hacking a lot R2C2 and we will add Wifi to it using IMX233 Linux board. We have already a prototype and we may produce and sell it later. If anyone wants to go ahead and test, it is just only 4 wires from Olinuxino-micro and R2C2 expansion header:



Read more here.

---

---
New cutting edge RepRap electronics, ARM 32 bits @ 100MHz runs RepRap @ 725mm/s:

[www.3dprinting-r2c2.com]

Not to take away from r2c2 - but for hackers who like to play and not have all-in-one boards (stepper drivers blow), or 4pi or any of the other projects...

Teensy 3.0 started shipping:
[www.kickstarter.com]

Maple mini's looking fun
[www.sparkfun.com]

And found this interesting maple mini Reprap controller project on github - [github.com]

There is also Galago on Kickstarter... but really there is no shortage of ARM dev boards, I have made a couple myself! For what is basically an ARM in a DIP package, $35 is a bit pricy to me, seeing as you can get an STM32F100 board for $10...

Even with an ARM in a DIY friendly format, one still needs the external electronics to drive all the features on a printer. I am currently reworking Sanginolou to use an ARM Cortex M0/M3 ("sango-bc"), I'm hoping to create a really low cost controller that is also DIY friendly.

The other problem is software - toolchains, IDEs, porting, compatibility etc. Nearly all the firmwares are designed for Arduino/AVR platform, so require porting to different on-chip peripherals, and every ARM vendor has a different set of peripherals, so we have the porting effort being duplicated and no particular common platform. Then there is the issue of bootloaders, and JTAG interfaces... nearly all different.

The Arduino Due finally seems about to launch, so maybe that will help with creating an Arduino compatible set of libraries to help porting, and also provide a common ARM platform for people to build on. Unfortunately, the Atmel ARMs would not be my choice, but it is probably better to have a common platform than the "best" ARM, whichver that it is.