Smoothie on Arduino Due

Hey all,

While I'm patiently awaiting my conversion board so I can plug RAMPS into my new Due, I'm trying to get some firmware ready. I'm really a big fan of the setup and structure of Smoothie, and I think the way the mbed libraries are set up it should be possible to port it over for SAM chips. I've read [mbed.org] about how the mbed libraries work, and I've dug through the ASF (Atmel Software Framework) to try to get a better handle on the Due. However, I think the task is just a bit too much of a reach for me, so I wanted to make an open invitation(/beg) for someone to help me out and get Smoothie running on Due. I need someone to answer stupid questions and guide me through the code. If you're interested, please either post here or PM me.

Thanks!

There is quite a learning curve if you haven't done this sort of thing before. It will seem like a big task at first but the approach I use is to break it into smaller steps. I use stub definitions to get the thing building, and then fill them out module by module. Trying to compile everything at once leads to a million errors and takes a long time before you see anything running.

I will answer questions if I can, we probably have similar goals here.

Cool, thanks Bobc.

I've been trying to port the mbed library, and I keep running into issues due to poor documentation. At the moment I'm working on the CMSIS, as (theoretically) I already have a CMSIS for both the mbed chips and the Due chip. Unfortunately, their setup is quite different, and NXP did a TERRIBLE job commenting what their wide variety of acronymic variables represent (like in the PWM_typedef, what's IR? TC? PC? CCR?), so I'm thinking I'll try porting Smoothie to ASF, rather than writing Due mbed libraries, unless you (or any other volunteers) happen to be good at guessing acronyms and don't mind slogging through uncommented code with me. But, maybe translating Smoothie will be just as frustrating, who knows.

Bobc, what approach are you using for your firmware? Adapting Teacup like you did with the LPC1114, or something else? And are you using Arduino for all the libraries, or are you using ASF?

I've been trying to use ASF, but I think it's a little out of my reach. Just getting the Smoothie kernel working is beyond my ability, but it looks like Arduino already has all the IO streams implemented in a way I might be able to get working.

TopherMan Wrote:
-------------------------------------------------------
> Hey all,
>
> While I'm patiently awaiting my conversion board
> so I can plug RAMPS into my new Due, I'm trying to
> get some firmware ready. I'm really a big fan of
> the setup and structure of Smoothie, and I think
> the way the mbed libraries are set up it should be
> possible to port it over for SAM chips. I've read
> [mbed.org]
> about how the mbed libraries work, and I've dug
> through the ASF (Atmel Software Framework) to try
> to get a better handle on the Due. However, I
> think the task is just a bit too much of a reach
> for me, so I wanted to make an open
> invitation(/beg) for someone to help me out and
> get Smoothie running on Due. I need someone to
> answer stupid questions and guide me through the
> code. If you're interested, please either post
> here or PM me.
>
> Thanks!

Wow for those of us
<<<<
less informed can you please tell me where we can learn more about this? Or is this your hack to get a ramps working with DUE. Last I inquired the forum about this, ramps runs on 5V and due runs of 3.3V and cant be compatible without some PCB changes?

Also, while cool, whats the advantage over atmega?

My PCB design is here, based on a similar design by bobc. The idea is that surface-mount pins on the bottom go into the Due, and surface-mount headers go on top into the RAMPS. Since the pins and headers are surface-mount, and therefore not connected, I could decide what connects to what. Most of the pins can pass right through, connecting from the RAMPS to the Due, but some of the paths needed to be redirected or not connected at all. Paths were chosen to do three things:

1. Disconnect any and all 5V signals. The 5V line is used for some pullups, the thermistors, etc. Instead, the RAMPS pins intended for 5V are connected to 3.3V so as not to overload any pins on the Due.

2. Add a signal mosfet. The 3.3V output from the Due is not quite enough for the RAMPS mosfets. So, the heater output pins from the Due go to trigger a small signal mosfet that's powered by VIN, which then is redirected to the RAMPS mosfet, so they are now receive a 12V signal to open them.

3. Add a level shifter for endstops. This is so that if you're using some sort of electrical endstop (opto, hall, etc) which gives a 5V signal, it gets passed through the level shifter to give the Due a 3.3V signal.

In addition to these changes which bobc's board does, I've added a spot for a card reader, since the Due uses the SPI pins in the middle of the board for this. I've also added a 5V pin coming out at a right angle so that I can still power my Hall endstop properly.

The advantage over the 8-bit proccessors is raw power. It's not totally necessary in most cases, but I am eventually going to be building a Rostock, and the atmegas can barely handle the calculations for that. With the ARM processor, it'll be able to run it as fast as I'd like. In addition, the Smoothie folks are working on some cool stuff, like integrated ethernet, so it acts as its own webserver. Plus, it's fun to be on the cutting edge.

TopherMan Wrote:
-------------------------------------------------------
> My PCB design is here, based on a similar design
> by bobc. The idea is that surface-mount pins on
> the bottom go into the Due, and surface-mount
> headers go on top into the RAMPS. Since the pins
> and headers are surface-mount, and therefore not
> connected, I could decide what connects to what.
> Most of the pins can pass right through,
> connecting from the RAMPS to the Due, but some of
> the paths needed to be redirected or not connected
> at all. Paths were chosen to do three things:
>
> 1. Disconnect any and all 5V signals. The 5V line
> is used for some pullups, the thermistors, etc.
> Instead, the RAMPS pins intended for 5V are
> connected to 3.3V so as not to overload any pins
> on the Due.
>
> 2. Add a signal mosfet. The 3.3V output from the
> Due is not quite enough for the RAMPS mosfets. So,
> the heater output pins from the Due go to trigger
> a small signal mosfet that's powered by VIN, which
> then is redirected to the RAMPS mosfet, so they
> are now receive a 12V signal to open them.
>
> 3. Add a level shifter for endstops. This is so
> that if you're using some sort of electrical
> endstop (opto, hall, etc) which gives a 5V signal,
> it gets passed through the level shifter to give
> the Due a 3.3V signal.
>
> In addition to these changes which bobc's board
> does, I've added a spot for a card reader, since
> the Due uses the SPI pins in the middle of the
> board for this. I've also added a 5V pin coming
> out at a right angle so that I can still power my
> Hall endstop properly.
>
> The advantage over the 8-bit proccessors is raw
> power. It's not totally necessary in most cases,
> but I am eventually going to be building a
> Rostock, and the atmegas can barely handle the
> calculations for that. With the ARM processor,
> it'll be able to run it as fast as I'd like. In
> addition, the Smoothie folks are working on some
> cool stuff, like integrated ethernet, so it acts
> as its own webserver. Plus, it's fun to be on the
> cutting edge.


I still don't understand why we re-invented the computer (from arduino to ARM) when we have 8 core processors out there. I guess they aren't reprogrammable in the same way.

8-core ATmegas? I'm not aware of such a thing. ARM CPUs are faster, mostly because they're 32 bit and the majority of step code generation requires 32 bit computations.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

... it's a pity, that the Transputers and other processors, dedicated for massive parallel scalar grids, were dropped for common processors

In 1986-1990 I was busy with benchmarks and simulations, to decide, which computer technology is best for simulating high complex physical systems - with the ATW (Atari Transputer Workstation) and some Transputer-blades for together around 250kDM we would have reached nearly the same scalar 'number-chrunching' power (maybe 10% less) of a Cray X-MP (then around 7 millions DM!) ... and there were some 4bit-processors in development for lowcost-scalars, that would have even more 'numberchrunching'-capability per money/counts

Modern processors with actual parallelizing/hyperthreading and GPU's have now even more MIPS/FLOPS per chip (mainly for tact rates - compare 3GHz now to 20MHz then), but with the pace of development and price-dropping since then this sort of massive parallel grids with Transputers or smaller chips would gain much higher powers with lower prices than common computers ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Sure, graphics processors are great parallel computing devices. That's why OpenCL and CUDA exists. [en.wikipedia.org]

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

cross posted for those that don't read google groups

I’ve just recently gotten interested in smoothie and porting to Arduino Due really appeals. (even though I've contributed to the smoothieboard kickstarter)
It looks like there has been no progress on this so..

I've started [github.com] in the hopes that others will contribte their expertise to the project

From the read me.

"An attempt to Port Smoothie to ATSAM3X8E (in particular Arduino Due)
I'm Publishing this in the hopes that others will join in on this project

First Hurdle: Smoothie seems to use mbed, there is no mbed for ATSAM3X8E
Status: Added mbed/src/vendor/ATMEL/cmsis/ATSAM3X8E, seems correct. From asf-3.12.1
Added mbed/src/vendor/ATMEL/capi/ATSAM3X8E, this is basicly a empty shell.
added mbed/src/mbed-atsam3x8e.mk, this is just a guess, needs checking.
eddited mbed/src/Makefile to include mbed-atsam3x8e.mk

mbed for ATSAM3X8E compiles and links. But Since all file in capi are basicaly empty it will not run. Maybe enough to start exploring the next hurdle while these files are filled out.

Second Hurdle: Port Smoothie code

Status: Not started"

Now that I have some Due compatible hardware, I would like to take another look at this.

I think you are working off the Smoothie master branch, but that is way out of date (like 3 months). The edge branch is really the main development area, I'd strongly recommend working off that.

I've been writing a HAL for Due with some ASF code as the underlying layer, so I may be able to provide some input for you

I've been looking into this, and the mbed code in Smoothie is quite different to the latest mbed code pulled from their repository. I guess that Smoothie are using an old version of the mbed code. I think if I was doing a Due port I would start with the latest mbed code.

Another potential issue for me at least, is that to submit a port for inclusion in mbed it needs to be submitted under Apache Contribution Licence, which means it must be code you have authored or have rights to. The ASF code is copyright of Atmel, with a non-Open licence, so I don't think it could be submitted without their agreement.