Support for Arduino Due (ARM processor)

[alexborro]

Hey guys, sorry using this channel to ask something like this, but did someone try to port Marlin to Arduino Due (ARM processor)??

If not, any guess about what should be done and how much effort??

Thanks.

Alex.

[nothinman]

What should be done? A complete re-write ;) I remember someone was working on this a while ago... but quite frankly -- what's the point in having that on ARM?

m.

[alexborro]

Are you sure about a complete rewrite?? Since the C code can be compiled for ARM (arduino IDE has support to DUE), I was thinking about a low effort...

[nothinman]

We only use arduino, because 1) it's easy to program avr -- no need for ISP programmer, 2) open source soft/IDE (or "IDE") and 3) because it's trendy ;-) If we were only using Arduino functions then yes, it'd be easy. But Arduino libraries (mostly) suck, and a lot of stuff had to be re-written, written from scratch and timed... Maybe not a complete re-write, but nothing trivial. Again. What for? :-)

[alexborro]

Hi Nothinman,

Deltabots uses a lot of 32 bits computation, mainly square roots and multiplication. The 8 bit AVR is a bottleneck for improving features, like precision and speed.

For example, the speed limit is about 320mm/s... yes, it is fast... but not that much for a delta capable of 800mm/s... maybe not for extrusion, but desirable for travels.

About your points: 1) According to Due documentation, one doesn't need an ISP programmer as well. It's similar (but not equal) to program an AVR. Just plug the USB cable in the USB programming port, open Arduino IDE and click upload.

2) Same for Due.. it is still an Arduino, but just other more powerful processor.

3) Due is the new trending ;-) The reason?? Same price and really more powerful.. Actually the SAM3X is cheaper than Atmega2560.

I still do not understand the need for rewrite.. In the Marlin there are just 2 functions using ASM, exactly to do more than 8 bits maths.. it is simply unnecessary for a native 32 bits processor. All the remaining code are written in C/C++... the Arduino compiler probably can generate the binary code from them. As far as I know, Marlin have no pre-compiled binaries for AVR...

By the way, Repetier already has native support to Due.

Best Regards,

Alex.

[bkubicek]

There are loads of reasons to go to a faster microcontroller. ) The major one is not that its faster, but that one does not require that much optimization, and hence the code can be more modularized/librarized. This libraries can be shared between multiple firmwares, and progress is simultaneous in more than one firmware. So is bug-fixing. Collaboration is easier for the community, because your code change does help more than just a single producer of a monolithic electronics board. The next step is that the code would be much easier to read and maintain if it were not as optimized. ) Then the second important step is to have more sophisticated step and path generation. Instead of having the jerk-velocity jumps as measure at direction changes, higher order methods (constant jerk, or 4th order) can be applied (look for the youtube video of tinyg and ultimaker). Also, was increasingly necessary is to have real nonlinear moves for better support of non-cartesian systems, and round shapes. Splines or similar would be really nice. Personally I think its also necessary to abandon the idea of syncronized acceleration in all axes, but to have asynchronous control of each axis. So while the movement is decelerating, one can retract filament e.g. )Also, allowing for path deviations in the planning can be extremely promising, because then corners can be cut.

The major challenges to go to nicer controllers (e.g. beagle bone black, teensy3 or similar) are the very strange libraries with quite confusing licensing, e.g. USB, SD, Filesystem, Ethernet.

Personally, I would not go for the DUE anymore nowadays, I had a lot of really bad experiences with it. E.g. the SPI ports for no apparent reason only being available on the male ISP headers and not on the female outside headers, the analog outputs being unable to output <1/6 VCC and more than 5/6 VCC and similar things that are quite surprising.

There were loads on discussions with multiple people about these topics 1-2 years ago. The conclusion was that a direct port of marlin to ARM is not very useful. Because its a lost chance to have something better.

I gave free consulting to a palo alto based company that was thinking about going to DUE one year ago, and as far as I understand their printer will make it into space quite soon. Anyhow, thats approximately what I told them (please consider the age of > 12 months, some things I currently see slightly differently):

There are a couple of options as you are aware off [for having a faster microcontroller].
I would personally go for ARM Cortex 3, AKA SAM3U. Why? Because there is some basis to start.
https://github.com/kliment/4pi-firmware
and some boards: https://github.com/kliment/reup

Also, I think for the reprap community. And Reprap will never have as stable systems as commercial machines, since the last 5% of bugs nobody wants to fix without being forced to.
However, what reprap can be for the next couple of years, is to be the technological leader.
[Yes, I will come to the point]
For that, there need to be developer boards electronics that are easily hackable, easily repairable and modular. I think that this should be also applicable for space, with the focus on repeatability. Solderable without reflow. So this puts dramatic limitations on the chip. Or the way the controller is connected to everything else.
And this is why I believe in Arduino DUE, with its SAM3U chip. The connector system is not great, but allright, and the boards are reasonably replaceable. Also, you need no programmer, just USB. Also, the bootloader, however ever strange the second Atmel168 is, works. Please note that I am not talking about the ARDUINO SDK, which is not optimized sufficiently. Just the hardware, not the SDK.

ARM Cortex 4 would also be a nice choice, especially for Floating point support was his reason, 

There is an uncertainty in this hardware preference, and this should be taken into account.
The way to go in my mental map is the following:
a) the FW should be quickly portable to a different controller. Why? Because all commercial, monolithic boards will have their "own" controller maybe. And you want still to have a community working together to find bugs and create features. Split firmwares are not good enough very soon.
b) From a) follows, that their will be variants, and with variants, the proven way to go is to have externaly hosted libraries. E.g. for gcode interpretation. E.g. for Communication. E.g. user interaction. E.g. Trajectory Planning. E.g. Step Generation.  These libraries are as hardware-independent as possible.
This libraries all access the actual Microcontroller using a standardized interface. E.g. "set heater pin high" "set PWM to 50% on the fan pin" or: "do a step".

c) How to achieve this?
)Create a clean Hardware interface.
)Decide the library boundaries and its interconnections.
)Split marlin into Non-interwoven parts to fill the libraries.
)Milestone: First working librarized port.
) Then: use the new performance to add superior features.

Why is this better than smoothie firmware approach?
Nobody will contribute to libraries that are hosted within a different firmware. They are not neutral. And egos count in community-based software.

Also, you can create unit test for each library. And use a nomal computer with a validation suit by having a PC based hardware interface. (Easier debugging and validation)

[ErikZalm]

Porting marlin to a due is easy. But it is will not add new functions. (I did a port to a STM32F4 in a week) Using the added processing power is the difficult part. You can use it for modularity like smoothie does. But I want to use it for better motion control. Better feedback to the user. Network and GUI, etc.

I also do not believe in making libraries for reprap related functions. Libraries are nice for generic functions, But are limiting if you need more performance or are not perfect for your application. (Look at the arduino libs. Most of them are replaced by local functions because the arduino performance was not good) I am working on a new HW platform with a faster MCU and better stepper drivers. This gives many new possibilities. If the libraries need to be portable then it is not possible to use 100% of the new functions.

In my opinion there are two types of boards. The hackable version Bernhard likes. And the plug and play version 90% of the printer users will like. I want to serve the 90% that want a working board and working firmware. The users that have a printer for the technical part are limited. (I am one of them)

[alexborro]

Erik, the initial reason for using Due is speed increase for deltabots. Of course with more processing power the firmware can have more features in the future.

BTW, let us know a little bit more about this board you are working on ;-)

Alex.

[JustAnother1]

@alexborro You might be interested in Minnow https://github.com/minnow-pmc/Minnow

Minnow is a Firmware for Arduino. The trick is to move the complicated calculations to the host.

[ErikZalm]

@alexborro https://github.com/ErikZalm/Marlin-II/blob/master/electronics/photos/Marlin_electronics.jpg

STM32F417 mcu. Ethernet. USB host for usb-stick 6x TMC260 stepper drivers Good diagnostics Good protection Optional 4.3" TFT screen with capacitive touch.

[nothinman]

@alexborro I wouldn't personally like my printer to run at 800mm/s, even for travel. Optimize your gcode, and there will be really little travel :) But yeah, you've convinced me, although I don't have a delta, and not planning on building one either.

@ErikZalm oh yeah, I remember you were working on that. so where's the code? ;) planning on making that open source?

[alexborro]

Common Erik, there is just a single picture about the electronics!!!! Are you really gonna tease us like that????

Are there more docs we can see about the board?? - I suppose it will be open source, right

And what about that ChibiOS?? New firmware for such board??

Thanks.

Alex.

2013/10/17 nothinman notifications@github.com

@alexborro https://github.com/alexborro I wouldn't personally like my printer to run at 800mm/s, even for travel. Optimize your gcode, and there will be really little travel :) But yeah, you've convinced me, although I don't have a delta, and not planning on building one either.

@ErikZalm https://github.com/ErikZalm oh yeah, I remember you were working on that. so where's the code? ;) planning on making that open source?

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/626#issuecomment-26551168 .

Mit freundlichen Grüßen - Best Regards - Saudações.

Alex Borro

[ErikZalm]

@alexborro I have no more documentation. The board will be open sourced when it is released.

ChibiOS is a RTOS. I use it for the new firmware. ChibiOS has a good HAL for the STM32F4 and the RTOS features makes it easier to communicate and synchronize between the different tasks.

At this moment I can print with the new firmware. I have a TCP stack running. I want a websocket interface. But that is not implemented yet. I can print from a USB stick. (I think it is easier to use an USB-stick compared to a SD-card)

The code needs much cleaning. The g-code parser needs a lot of work. I want to change the motion code. Now it is stepped based like the current atmega Marlin. I want to go to a fixed update rate. (~20kHz) The GUI implementation is far from complete. (I am waiting on input from the graphical/gui designers)

Lots of things to do but I think it will be great.

[nothinman]

@ErikZalm why not put it on github and let everyone work on it?

[bkubicek]

most likely because thats the only realistic option to get any compensation for the development costs. See the current discussion on reprap-dev. http://reprap.org/pipermail/reprap-dev/2013-October/thread.html#4679

Bernhard

On Fri, Oct 18, 2013 at 2:14 PM, nothinman notifications@github.com wrote:

@ErikZalm https://github.com/ErikZalm why not put it on github and let everyone work on it?

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/626#issuecomment-26590975 .

[ErikZalm]

@bkubicek It is not an compensation issue. The code is not stable and messy at the moment. And because the hardware is not available it is difficult for others to collaborate. The g-code part can be coded on a discovery board. But the motion part is difficult to change without the real hardware.

The development costs. (Prototypes and layout tooling) are payed by Ultimaker. My time in this project is free.

Ultimaker gave me only one restriction. They want to be the first to sell the boards. (In the Ultilabs shop) And some features (PT100 temperature sensor for example) are requests from Ultimaker.

[alexborro]

Hi guys,

Now we have a RAMPS-FD available for Arduino Due: http://www.geeetech.com/new-pololu-shield-rampsfd-for-arduino-due-3d-printer-controller-p-770.html

@ErikZalm , what about that porting for Due?? ;-) Some friends are chasing me for it ;-)

Thanks.

Alex.

[nothinman]

Huh? Friends are chasing YOU for it? Then go ahead and port it :-)

[alexborro]

Nothinman, unfortunately I don't have that knowledge about atmega/avr specially on core things like ISR and timers to do such port confidently. I'm afraid to mess something up...

And Erik told some days ago it is not that difficult..

2013/11/17 nothinman notifications@github.com

Huh? Friends are chasing YOU for it? Then go ahead and port it :-)

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/626#issuecomment-28660885 .

"Não é o mais forte da espécie que sobrevive, nem o mais inteligente. É aquele que se adapta melhor as mudanças" ( Charles Darwin )

Alex Borro

[ErikZalm]

Hello Alex,

It is not difficult. But I do not have the time for it. And porting the current marlin would be stupid imho. The DUE has much more processing power. Why not use it.

[freebstm]

Hello ErikZalm. There is an error when checking
soft Arduino 1.0.5

Marlin\ConfigurationStore.cpp.o: In function _EEPROM_writeData(int&, unsigned char*, unsigned char)': C:\Program Files\Arduino\libraries\Marlin/ConfigurationStore.cpp:7: multiple definition of_EEPROMwriteData(int&, unsigned char, unsigned char)' ConfigurationStore.cpp.o:C:\Users\User\AppData\Local\Temp\build8804507701001461901.tmp/ConfigurationStore.cpp:7: first defined here c:/program files/arduino/hardware/tools/avr/bin/../lib/gcc/avr/4.3.2/../../../../avr/bin/ld.exe: Disabling relaxation: it will not work with multiple definitions Marlin\ConfigurationStore.cpp.o: In function _EEPROM_readData(int&, unsigned char_, unsigned char)': C:\Program Files\Arduino\libraries\Marlin/ConfigurationStore.cpp:17: multiple definition of_EEPROM_readData(int&, unsigned char*, unsigned char)' ConfigurationStore.cpp.o:C:\Users\User\AppData\Local\Temp\build8804507701001461901.tmp/ConfigurationStore.cpp:17: first defined here Marlin\ConfigurationStore.cpp.o: In functionConfig_ResetDefault()': C:\Program Files\Arduino\libraries\Marlin/ConfigurationStore.cpp:240: multiple definition ofConfig_ResetDefault()' ConfigurationStore.cpp.o:C:\Users\User\AppData\Local\Temp\build8804507701001461901.tmp/ConfigurationStore.cpp:240: first defined here Marlin\ConfigurationStore.cpp.o: In functionConfig_PrintSettings()': C:\Program Files\Arduino\libraries\Marlin/ConfigurationStore.cpp:98: multiple definition ofConfig_PrintSettings()' ConfigurationStore.cpp.o:C:\Users\User\AppData\Local\Temp\build8804507701001461901.tmp/ConfigurationStore.cpp:98: first defined here

thank you.

[alexborro]

If you are trying the port, the Due has no EEPROM, so it should be disabled/removed.

2013/11/25 romanikq notifications@github.com

Hello ErikZalm. There is an error when checking

soft Arduino 1.0.5

Marlin\ConfigurationStore.cpp.o: In function _EEPROMwriteData(int&, unsigned char, unsigned char)': C:\Program Files\Arduino\libraries\Marlin/ConfigurationStore.cpp:7: multiple definition of_EEPROMwriteData(int&, unsigned char, unsigned char)' ConfigurationStore.cpp.o:C:\Users\User\AppData\Local\Temp\build8804507701001461901.tmp/ConfigurationStore.cpp:7: first defined here c:/program files/arduino/hardware/tools/avr/bin/../lib/gcc/avr/4.3.2/../../../../avr/bin/ld.exe: Disabling relaxation: it will not work with multiple definitions Marlin\ConfigurationStore.cpp.o: In function _EEPROMreadData(int&, unsigned char, unsigned char)': C:\Program Files\Arduino\libraries\Marlin/ConfigurationStore.cpp:17: multiple definition of_EEPROMreadData(int&, unsigned char, unsigned char)' ConfigurationStore.cpp.o:C:\Users\User\AppData\Local\Temp\build8804507701001461901.tmp/ConfigurationStore.cpp:17: first defined here Marlin\ConfigurationStore.cpp.o: In function Config_ResetDefault()': C:\Program Files\Arduino\libraries\Marlin/ConfigurationStore.cpp:240: multiple definition ofConfig_ResetDefault()' ConfigurationStore.cpp.o:C:\Users\User\AppData\Local\Temp\build8804507701001461901.tmp/ConfigurationStore.cpp:240: first defined here Marlin\ConfigurationStore.cpp.o: In function Config_PrintSettings()': C:\Program Files\Arduino\libraries\Marlin/ConfigurationStore.cpp:98: multiple definition ofConfig_PrintSettings()' ConfigurationStore.cpp.o:C:\Users\User\AppData\Local\Temp\build8804507701001461901.tmp/ConfigurationStore.cpp:98: first defined here

thank you.

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/626#issuecomment-29196824 .

"Não é o mais forte da espécie que sobrevive, nem o mais inteligente. É aquele que se adapta melhor as mudanças" ( Charles Darwin )

Alex Borro

[JustAnother1]

@alexborro Another solution for the EEPROM is to emulate it. Atmel hat a Application Note on how to do that. Basically what it does is it uses Flash pages to store the EEPROM data.

[T3P3]

I know its not the port of Marlin you are looking for but RepRap Firmware (https://github.com/reprappro/RepRapFirmware/tree/duet) runs on the Duet board (http://blog.think3dprint3d.com/2013/12/Duet-Arduino-Due-compatible-3DPrinter-controller.html). based on Arduino Due.

It will give some hints on how to use the Due and it is under development to add more features.

[bobc]

There are several ARM based controllers now, in fact R2C2 has been out there and working since 2012. Now you could also consider Smoothieboard, Due + RADDS, Duet as well as RAMPS-FD (which I designed btw).

These all have working firmware, so my question is there any particular features of Marlin you want to use, or is it just a case of staying with something familiar?

I have ported Teacup to an ARM controller, but after unpicking all the AVR specific stuff, adapting it for LPC1769 or whatever, you get something that is not very pretty and compromised by the original architecture. I could port Marlin for Due, but I fear it would become an unmaintained fork. Unfortunately, I really dislike the Arduino IDE, so that is a disincentive. :(

Starting from a blank sheet is therefore an attractive option. All the other major ARM offerings are using new firmware (Duet, Smoothieware).

I think the only AVR firmware that is making the transition to Due is Repetier, and the author is committed to supporting it. Repetier runs ok on Due + RADDS, I am still working on RAMPS-FD version.

An extra thought, you could try putting up a bounty for a Marlin port.

[sakunamary]

I try the arduino due +RAMS-FD .I have some issue on LCD controller ，it seem that due can not give the current signal of lcdRS,so that LCD can not work .... for detail pls visit http://forums.reprap.org/read.php?13,326622

I am 200% support marlin for 32bit!!!!

[hetral712]

Would be really nice to have 32bit supported

[leseaw]

+1 :)

no one working on it? so whats the price for this? anybody want work on it for money to port this to due?

[galexander1]

Please pardon the newbie question, but:

Is there already RAMPS (or similar) for Arduino Due?

Thanks,

• Greg

On Mon, Jun 30, 2014 at 06:33:39AM -0700, leseaw wrote:

+1 :)

no one working on it? so whats the price for this? anybody want work on it for money to port this to due?

---

Reply to this email directly or view it on GitHub: https://github.com/ErikZalm/Marlin/issues/626#issuecomment-47531539

[leseaw]

Hi,

yes :) http://reprap.org/wiki/RADDS works fine with repetier firmware are not with marlin.

regards axel

Please pardon the newbie question, but:

Is there already RAMPS (or similar) for Arduino Due?

Thanks,

• Greg

On Mon, Jun 30, 2014 at 06:33:39AM -0700, leseaw wrote:

+1 :)

no one working on it? so whats the price for this? anybody want work on it for money to port this to due?

---

Reply to this email directly or view it on GitHub: https://github.com/ErikZalm/Marlin/issues/626#issuecomment-47531539

---

Reply to this email directly or view it on GitHub: https://github.com/ErikZalm/Marlin/issues/626#issuecomment-47532917

[JustAnother1]

@leseaw How much money are you willing to spend on this?

If you offer just some Euros that might convince someone who has something like this on his list already to finally start working on it.

But I have to agree with what was said here. A 1:1 porting makes little sense. So having the bigger processor power would have an effect on the implementation. Current solutions could be optimized, new functions could be added. And things like the missing EEPROM need to be addressed.

But that makes this a big project. So do you have a 3d printer company or something like that to offer real compensation for a few months full time work of an embedded software expert?

[nicolas-rambaud]

Thanks for the tip, i never saw this board.

De : leseaw [mailto:notifications@github.com] Envoyé : lundi 30 juin 2014 15:53 À : ErikZalm/Marlin Objet : Re: [Marlin] Marlin for Arduino Due (ARM processor) (#626)

Hi,

yes :) http://reprap.org/wiki/RADDS works fine with repetier firmware are not with marlin.

regards axel

Please pardon the newbie question, but:

Is there already RAMPS (or similar) for Arduino Due?

Thanks,

• Greg

On Mon, Jun 30, 2014 at 06:33:39AM -0700, leseaw wrote:

+1 :)

no one working on it? so whats the price for this? anybody want work on it for money to port this to due?

---

Reply to this email directly or view it on GitHub: https://github.com/ErikZalm/Marlin/issues/626#issuecomment-47531539

---

Reply to this email directly or view it on GitHub: https://github.com/ErikZalm/Marlin/issues/626#issuecomment-47532917

— Reply to this email directly or view it on GitHub https://github.com/ErikZalm/Marlin/issues/626#issuecomment-47533732.[image: Image supprimée par l'expéditeur.]

[leseaw]

I think im not alone. So we only need people who have the skills to do this. i can spend hardware for testing. For more is better to make an new group, or?

[bobc]

I've been thinking of this for a while and finally got round to doing something! There are many ways to do this, but I was impressed with the KISS approach taken by Repetier firmware.

So far I have set up a new directory structure and confirmed the AVR code builds without errors on Arduino IDE v1.5.4. The next step is to identify which modules can be made common and which are device dependent. Before I do that, I will push the changes so far to a new fork in github.

I've taken a baseline from the Marlin_v1 branch, is that the right place to start from?

[leseaw]

Better use 1.5.6r2. with 1.5.4 i had problems.

i think, yes first we need a new fork .

[Drakelive]

So you're talking about adding support for Arduino Due or create a generic Marlin 32bit ? The new branch should have a generic code for ARM 32bit to support other ARM processors. For a long time we talk to have a performance increase. This might be a good way.

[leseaw]

mhh i think first only due.

[bobc]

Creating a portable ARM architecture would be great, there are new fast and cheap chips coming every day it seems.

However, creating a generic ARM version is not as easy as a generic AVR version, because all ARM chips vary significantly in the peripheral registers even if they are using the same core CPU. The Arduino libraries currently only supports the Atmel SAM3X chip used in Due. The Mbed libraries are supported on a wider range of ARM chips (NXP, ST, Freescale), but not the Atmel chips!

So generic ARM support is a definite goal, but may take some time to achieve. For the moment, I would like to concentrate on supporting Due, then we can see where to go after that.

[leseaw]

+1 ;) and if you need hardware, tell me that.

[JustAnother1]

@bobc Isn't that what CMSIS (http://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-interface-standard.php) is all about?

So programming to the CMSIS API would be better than to solve to the Atmel API, right?

[bobc]

I still haven't quite figured out what CMSIS really provides, it seems to promise a lot more than is actually delivered. The ARM spec appears to be a template for silicon vendors to provide functions, it's up to the vendors to provide the code. There is no guarantee that application code will be portable from Atmel to NXP say, but there should be similar functions available if writing an application from scratch.

The CMSIS spec doesn't seem to include any functions for handling GPIO, which is pretty essential!

To be portable it seems to need another wrapper on top of CMSIS, which is not ideal. Atmel have a huge framework library but the CMSIS support appears limited to very basic core functions, so we would probably have to write our own CMSIS compliant functions. There may also be some license issues including code from vendors if they are not open source compatible.

It's something to look at anyway.

[JustAnother1]

CMSIS is only a document. It defines the names and parameters for the functions. It does not implement them. The Silicon Vendors need to implement them.

For example: CMSIS defines the functions or better the API for the UART. So if your code uses the UART only by using the CMSIS defined Functions then this code can be compiled for all the processors that have CMSIS files. Each vendor needs to implement these functions, and you need to recompile for each processor. Therefore the positions of the control bits in the Special Function Registers may be chosen by the vendor.

A wrapper on top of CMSIS is not needed. CMSIS is only an API

If functionality is missing you could define that yourself. An extended CMSIS to to speak. You would only have to implement these few functions yourself for the processor you use. Porting to another processor would then be a job of creating these implementations for the new processor. So others that want to use your code on other processors could do so easily.

I don't get your argument about license issues. I have seen that Atmel license code to be only used on Atmel processors (so not open source) but even that would be OK if this only applies for the CMSIS functions. Because on ST Processors ST would provide the CMSIS functions. As this is also in the interest of the vendors (why should they make it hard for CMSIS applications to move to their processors) I would not expect problems there. On the other side the "huge framework library" that Atmel has could be a bigger issue. Here I would expect Atmel to only license it for use on their processors only. As again this would be in their interest (keeping you bond to their processors). This would make porting to another Processor (arduino xyz- who knows) a license nightmare.

Keep in Mind that for example ST has a lot of interesting Development boards. Some even cheaper than the Arduino Due, but with an debugger included. So with a CMSIS based application someone doing software for an ST board could port your code and help you move it further, as with the Atmel Lib and Atmel proprietary coding he could not. And it will never be easier to go for CMSIS as at the start of the project. NXP has also interesting boards,...

There are other ARM based boards already out there, that are not Atmel processors,..

Just my 2 cents thou.

[xyxxl]

Probably would want an arm with a PRU.

see: https://www.adafruit.com/blog/2014/07/01/real-time-programming-with-beaglebone-prus-by-jason-kridner-at-chicago-hackerspace-ps1-beagleboneblack-txinstruments-beagleboardorg/

[JustAnother1]

For those not wanting to watch a 4 and a half hour youtube: PRU = TI proprietary 32 bit 200MHz processors on the Beagle Bone Black. The BBB has 2 of them. Details are here: http://elinux.org/Ti_AM33XX_PRUSSv2

So if someone wants to port Marlin to Linux putting the Real time stuff into a PRU might be the way to make that work.

But if you want to replace the AVR with a Cortex-M3/4 then PRUs are not an option.

[bobc]

I've made some good progress, I've got a Due version building and replying to serial comms. The next step will be endstop detection and motor movement.

The Due and AVR versions both build ok using Arduino 1.5.6-r2, but I have not tested build via that route, I am developing using Eclipse with Arduino plugin. It should give the same results as the Arduino IDE, but could be different.

If anyone is interested in following progress my repo for this is at https://github.com/bobc/Marlin Be aware the Due port is very incomplete. Hopefully you will get the gist of how the multi-platform support will work, I guess over 95% of the code will be common, some common files require ifdefs to identify the target, and a few files will be target specific.

Currently common files have identical copies in the two target directories, this is required for Arduino IDE, and I haven't found any good way to avoid that.

The AVR version has minimal changes and should work ok, but I have no hardware set up to test AVR builds with yet.

[leseaw]

it works with 1.5.6r2 i can upload and see the firmware only one problem, ramps-fd only :) So radds is on the way.

[Salandora]

@bobc maybe this is helpful for you, it actually helps me create my own firmware for the Due. https://github.com/ivanseidel/DueTimer

[leseaw]

i send the new pins.h to bobc its working with radds/due. stepper are working correct, printer move the right ways :+1:

[bobc]

Thanks to a donation of hardware by Axel (aka leseaw) I now have the Due version running on RADDS!

Haven't quite got a print out yet, still trying to set up a new printer, but I think I have the code ready to print.

I will set up another printer with a RAMPS-FD to test that out soon. I also haven't tested the AVR branch at all.

So if any brave souls want to try it out, there is plenty of testing to do!

[T3P3]

Bc awesome work. Pm me for a duet On 23 Jul 2014 23:50, "Bob Cousins" notifications@github.com wrote:

Thanks to a donation of hardware by Axel (aka leseaw) I now have the Due version running on RADDS!

Haven't quite got a print out yet, still trying to set up a new printer, but I think I have the code ready to print.

I will set up another printer with a RAMPS-FD to test that out soon. I also haven't tested the AVR branch at all.

So if any brave souls want to try it out, there is plenty of testing to do!

— Reply to this email directly or view it on GitHub https://github.com/ErikZalm/Marlin/issues/626#issuecomment-49941228.

[XayOn]

Ok, here the brave soul to try it. I'm going to try it now with due and ramps-fd @bobc any news on your side?