RAMPS for Arduino Due?

Now that the Due is finally generally available, is anyone working on a compatible RAMPS board? Or even just thinking about it...?

I have a Due on order, I will make a start on a schematic soon.

ETA: oops, obviously this post should have gone to RAMPS forum...

Edited 1 time(s). Last edit at 01/20/2013 10:56AM by bobc.

I'm interested in this myself, as I am awaiting a Due too. As far as board layout goes, the changes are minimal, right? Just need to move all the 5V connections to either 3.3V or Vref, and find a more appropriate MOSFET.

Marlin, Teacup and Repetier all use AVR libraries and won't compile for the Due in Arduino 1.5.1, so I'm assuming the bigger hurdle is getting firmware onto the Due. I know there are some ARM firmwares out there in the world already, but I don't know if any of them are compatible with the Atmel ARM chip.

Previous discussions. Summary: it almost certainly can be done, but will require hardware changes because the Due is 3.3V not 5V.

Quote

Marlin, Teacup and Repetier all use AVR libraries and won't compile for the Due in Arduino 1.5.1

Teacup doesn't use Arduino libraries. Arduino IDE is just used as an easy to set up compile tool chain. This doesn't make matters simpler, though, every part of Teacup has to be reviewed for 32-bit. The effort of doing so has already started.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I saw a couple include statements for avr/interrupt.h, so I had assumed that the libraries were one of the issues for porting. Since I'm very inexperienced with microcontroller programming, what sort of things do you have to check to port over Teacup to 32 bit?

Ok, I have created a wiki page [reprap.org]. I think I have collected all the issues from this and previous threads. Please feel free to add any other issues, or let me know and I will add them.

It might be nice to add any improvements to RAMPS, if that is possible I'm not a RAMPS user, but one issue I have seen mentioned is to put the connectors around the edge.

I started working on a schematic, it looks pretty straightforward, but the unknown factor is what to do with the spare expansion pins, because in principle anything could be plugged into them. I don't know if there any "standard" RAMPS add-ons people use which we should allow for.

Level-translation is easy if the signal is a dedicated input or output, it is more tricky if the signal is bidirectional or could be used as input or output. The I2C data line may be ok because it is open-drain, and if the pullups are to 3.3V.

On the issue of firmware, the biggest changes required are the access to on-chip peripherals, GPIO, timers, ADC etc, and features that are specific to the AVR CPU (e.g. interrupts, assembler sections, linker map) or AVR compiler (e.g memory barriers, macros like PROGMEM).

I believe most of the officially supported Arduino libraries have been ported to SAM3X, but I guess unofficial libraries like LCD will need porting. Teacup mostly uses the AVR features directly.

I have already ported Teacup to an STM32F051 platform (which is also a Cortex M0) using driver libraries included in ChibiOS, and printed successfully. I have ported most of the code to LPC1114, also using ChibiOS, and it responds to GCode commands, but I have no printer attached yet.

Bob, how's the RAMPS for Due converter board going? I'm finally getting a Due and I'm hoping to eventually use it for printing. I looked at bobc_hardware on github, and the RIB looks good (found one minor error; the pins right above 22 and 23 are still 5V, not 3.3V, I'll put it on Github). I'm pretty new to KiCAD, but I think I understand how it all works. The pins and headers are surface-mount, yes? Do you have particular ones in mind? I hate trying to find the right headers on Digikey, I don't know all of the terminology well enough to easily find the right product.

Hi, I've sent gerbers of RIB v0.1 to the fab house, should get them in 2 weeks or so. With the RIB, all the VCC/5V pins on the RAMPS will be 3.3V, so I believe it is not an error.

Connectors are surface mount, I'm not sure how well that will work. I haven't managed to identify parts on Digikey either!

I've been playing with Arduino IDE trying to figure out how to create a multiplatform project, but the Arduino IDE is pretty basic and it does not look possible, certainly not easy. For the moment I will abandon use of the IDE and maybe come back to that idea later. The Atmel Studio software is more advanced, but it is Windows only. In the meantime I will be working on a makefile project.

Yeah, after a good night's sleep and a second look, I now see how it works. Sorry about the extraneous github issue.

So I think I've found headers and pins that would work. Link for headers: [www.digikey.com]
Link for pins: [www.digikey.com]

I think I'm going to try my hand at making my own version, mostly for the KiCAD experience, but also to add an integrated SD reader (since the Due moved the MOSI, MISO, and SCK pins to the SPI header, and since it doesn't need to be level shifted anymore, I think the SD RAMPS card would require serious wrangling to get it working) and a 5V pin to run my Hall sensor. It won't run off 3.3V, and I don't know if the opto endstops can either.

For firmware I'm going to try my hand at getting Smoothie to run on it. Right now Smoothie uses a gcc designed specifically for the mBed chips (which use LPC17xx chips), but it looks like all the mBed libraries are open source, so I should be able to get it all ported over.

TopherMan Wrote:
-------------------------------------------------------
> For firmware I'm going to try my hand at getting
> Smoothie to run on it. Right now Smoothie uses a
> gcc designed specifically for the mBed chips
> (which use LPC17xx chips), but it looks like all
> the mBed libraries are open source, so I should be
> able to get it all ported over.

I just noticed on the Smoothie group that the mBed libraries are now open source (Apache 2.0 license), it's one thing that put me off Smoothieware before. To run on Due the mbed-NXP code would need to be ported, the mBed libraries look pretty good and there is already quite a big mBed ecosystem.

Yup, that was me asking about that. Since they're available I'm hoping I can get Smoothie on Due without too much blood sweat and tears. I really like how Smoothie is structured, and I think you end up with cleaner results when the code is written from the ground up for ARM rather than porting AVR code.

You may be right about the cleaner structure, but there will be a good deal of sweat porting mbed over to SAM3X. It will be easier if you leave out the Smoothie bootloader initially. I don't know how far Kliment got with his SAM3U port, it might be worth looking at that. Atmel have a reasonably good peripheral library, but of course it is not compatible with anything else.

The Arduino based firmwares tend to be heavily invested with AVR features, but it is quite easy to port Arduino-AVR code to ARM chips. The AVR chips are not that complex. It didn't take me long to get Teacup running on STM32F051 and LPC1114 for example.

Okay, I finished my attempt at a RAMPS to Due converter. It's here: [github.com]. The changes I made were fairly small. First, I made a bunch of the headers whose signals were unaltered through-hole (planning to use 10mm lead headers like the stacking headers seen on a lot of Arduino shields), since I figured the through-hole pins would add some rigidity, and I'll be less worried about pulling off the surface mount pins when removing the board from the Due. Second, I added a header to connect Sparkfun's MicroSD breakout board. I took a look at the pins on SD connectors, and realized I'd just make a mess trying to solder them, so I figured this would be a nice easy cheat.

I would appreciate feedback or suggestions, since I did this as much to learn PCB design skills and tools as much as to make a product.

Thanks!

Has anyone looked into the the new Pololu DRV8825 carrier? Since it's a drop-in replacement for the A4988 carrier, but is compatible with 3.3V logic, it seems to me that that it would solve most of the 3.3V vs 5V problems associated with the Due. I could be absolutely wrong, I haven't had a chance to thoroughly research the DRV8825 carrier yet, I just ran across it this morning.


[www.pololu.com]

The A4983/A4988-based Pololus are 3.3V compatible, too.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Jhaubold,

The 5V/3.3V issues are not necessarily a stepper problem, because as Traumflug mentioned, the popular Pololus are all able to do either. The problem is that RAMPS pretty heavily utilizes the 5V line to power things such as the opto and hall endstops, as well as various pull-ups to other lines like the thermistors and the stepper enable lines. (If you check out the schematic here, everywhere it says VCC it's connected to 5V.) This means that there's a whole host of places where a 5V signal could get through to the Due, frying its delicate internals. (If you don't believe me, take a voltmeter and see what voltage is across a thermistor attached to RAMPS at room temperature. For me, it's at 4.80V, much too high for a 3.3V system.) The method bobc has taken (and I have imitated) in the conversion board is to reconnect all the 5V connectors to 3.3V, so that the RAMPS is nowhere using 5V to power or signal anything. A level shifter is included on the endstops, so that if you're using an opto or Hall endstop that returns a 5V signal, it doesn't have to be replaced by switches. One thing I have added on my board, since my Hall endstop doesn't work well under 3.3V, is a pair of pins at a right angle out of the converter board connected to 5V. That will power the endstops, and the level shifter will let the signals go right into the Due.

Hope that helps answer your question!

Oh, and two PSs.

First, it's worth mentioning that an advantage of the Due is that it will likely have much higher stepper rates, so that you could conceivably put in the DRV8825s and set them to full 1/32nd microstepping and not run into any issues, where I suspect that would make the AVRs give up and go home.

Second PS, I've sent off to get my board fabbed, and had a discussion with the Smoothie guys about the porting process, so hopefully soon I'll have some progress to report. I'll probably start a new thread over in the RAMPS section so we stop hogging Gen7's space.

Okay, I officially have my RAMPS 2 Due converter board assembled and functioning! I stacked up all the boards and ran the RAMPS test script. All the mosfets worked properly, and the motor moved back and forth! I've tested all the motor positions and all the power outputs. Pics of it assembled attached, and you can watch it running here: [youtu.be]

Additionally, I checked the endstops. Mechanical switches with pullups work perfectly, as does the Hall-O sensor. Now it "just" needs some firmware.

Additionally, I still have five more PCBs for the converter. If anyone is interested, I would be willing to sell them for the cost of shipping, especially if it means someone else is working on firmware as well (though I will warn you the surface mount headers are not as cheap as I'd like, and the soldering is tricky). Bobc's RAMPS for Due looks like it's going to be very nice, but this is a "good enough for government work" solution for anyone desperate to start playing.

Wouldn't it make more sense to make a new RAMPS board that fits directly onto an Arduino Due instead of a converter board that goes between? Seems like it would be a lot cheaper, and RAMPS isn't really that complex.

Isn't that what bobc was doing originally? I keep getting distracted by Smoothie, but this does have too much potential do just let fall by the wayside...

That is what bobc's working on, and is ultimately the "better" solution, but I liked the idea of a quick-and-dirty conversion, and hoped it would be a cheap stopgap. Unfortunately, those SMD pins are more expensive than I expected, so it's probably all a wash. Plus there isn't really a firmware that's compatible yet (and my software skills are crap) so there isn't a whole lot of advantage to getting by RAMPS plugged into my Due now rather than later.

A converter board might be useful for people who have RAMPS and don't want to buy a whole new board which does essentially the same thing, but it is not ideal as TopherMan mentioned.

I hope to send off Gerbers this weekend, here is how the board looks:



I am also working on porting software, and also considering some other interesting options, like a smoothie-RAMPS mashup. I also hear Panucatt is working on a LPC1769 board, that should be good judging by their Azteeg (sp?) boards. ReprapPro may have something up their sleeve as well...

So there is a lot of stuff going on, by the end of 2013 we should have plenty of ARM boards to choose from, and hopefully some working software.

I have mostly given up the idea of hacking AVR based firmwares to run on ARM, it is really hard to do without making a lot of spaghetti. I think a clean approach is needed, that may mean having to leave AVR behind.

Edited 1 time(s). Last edit at 06/07/2013 08:16PM by bobc.