Raspberry Pi based electronics ideas

I recently found the L6470 motor drivers. These are highly integrated, highly configurable drivers with interesting features like internal position counters, acceleration profiles, and 1/128 microstepping. Since they can be daisy-chained and they work over SPI, they sound like an excellent fit for an RPi solution. I shall have to do some more research, but they might work well for a no-processor solution to RPi daughter cards.

Annirak Wrote:
> This makes excellent sense. A PIC32 sounds like a
> good choice for a linear upgrade path for the Gen7
> electronics.

I'm not sure what "linear upgrade path" means here. There are some PIC32 in a 28 pin packagge, they are 3.3V, and of course not register compatible with AVR, so not exactly a seamless transition.

NXP have announced some Cortex M0 parts in a DIP package, also SO and TSSOP. I don't see any 40 pin versions.

DIP packages are sure to be popular with hobbyists who are still scared of SMT, but it is only [one] aspect of compatibilty.

Edited 1 time(s). Last edit at 07/27/2012 07:43PM by bobc.

bobc Wrote:
-------------------------------------------------------
> I'm not sure what "linear upgrade path" means
> here. There are some PIC32 in a 28 pin packagge,
> they are 3.3V, and of course not register
> compatible with AVR, so not exactly a seamless
> transition.
>
> NXP have announced some Cortex M0 parts in a DIP
> package, also SO and TSSOP. I don't see any 40 pin
> versions.
>
> DIP packages are sure to be popular with hobbyists
> who are still scared of SMT, but it is only aspect
> of compatibilty.

I simply mean that if you want hardware divide in a DIP package, that's your option.

Annirak Wrote:
-------------------------------------------------------
> bobc Wrote:
> --------------------------------------------------
> -----
> > I'm not sure what "linear upgrade path" means
> > here. There are some PIC32 in a 28 pin
> packagge,
> > they are 3.3V, and of course not register
> > compatible with AVR, so not exactly a seamless
> > transition.
> >
> > NXP have announced some Cortex M0 parts in a
> DIP
> > package, also SO and TSSOP. I don't see any 40
> pin
> > versions.
> >
> > DIP packages are sure to be popular with
> hobbyists
> > who are still scared of SMT, but it is only
> aspect
> > of compatibilty.
>
> I simply mean that if you want hardware divide in
> a DIP package, that's your option.

The main issue with PIC's is the toolchain, yes I know there are free compilers out there, but in my experience they haven't been very good.

ARM and AVR have well established GCC based toolchains.

PIC32 is MIPS32, which has gcc support.

Annirak Wrote:
-------------------------------------------------------
> PIC32 is MIPS32, which has gcc support.

Well, this has been a pretty one-sided discussion.

In my experience, when people say "let me know what you think", they actually mean "I want you to just agree with me so I can convince myself I am right".

I'm still doing some work towards a RPi solution with the L6470. I know it's not very DIY friendly, but I've concluded that Gen7T is about as DIY friendly as we need to be. No sense in me reinventing that. Instead, I'm trying to work a design so that I can take all the stepper management and timing out of the system and remove the MCU entirely.

I don't know if that counts as one-sided. Maybe I don't understand what you mean. Maybe the issue has been confused--when I got the impression that the RPi was replacing the host instead of the controller, I started another thread, in the Gen N+1 forum. Eventually, I had R2C2 pointed out to me. Since it did pretty much what I was trying to design, I stopped work on designing new electronics; figuring that I'd just follow that instead.

Perhaps you think this was one-sided because after all that I'm back looking at a RPi solution. Well, if that's the case, you misunderstand me. I've accepted all the commentary--I just think that using the RPi as a controller is a fun project and might be useful to someone. Do I think it should be the next generation of electronics? No. It might find a small niche, but I suspect there won't be many of us using it, and I'm okay with that.

Edited 3 time(s). Last edit at 07/31/2012 06:30PM by Annirak.

As for using the PIC32 as an option, it seems like the only DIP or PLCC package MCU with hardware DIV support. Since DIV is a bottleneck for path planning, and MIPS32 is a gcc-supported architecture, that seems like a sensible solution. Personally, I'm not going to spend any effort on that--either I'll build something with L6470's for my own interest, or I'll buy a R2C2 build.

Upon some reflection, I'm probably not the right person to design mainstream electronics for RepRap. I think that QFP is solderable as long as you have lots of flux, some solder wick and a PCB with solder mask; consequently, I have no qualms about using QFP parts. I've even done power pad QFN with a heat gun in the past, so I don't see a huge problem with those either. As a result, I recognize that designs I produce won't be as interesting to hobbyists. People, like Traumflug, who have more of an interest in making the easiest to assemble board should be designing the mainstream electronics.

Quote

I think that QFP is solderable as long as you have lots of flux, some solder wick and a PCB with solder mask

It likely is, perhaps even on an isolation milled PCB (no solder mask, but grooves between the pins). Everybody has a cooking plate and getting a magnifying glas isn't too much to ask for.

The actual problem is: people have to believe this. They have to trust they can do this them selfs, getting something working before they get frustrated. Applies for soldering a much as for firmware configuration/uploading.

Similar problem with the PIC32: everybody waves for ARM chips, so a PIC32 has to have (at least) a demonstratable killer feature where the ARM can't keep up with. MIPS is undoubtly an excellent architecture, I have an SGI Octane (MIPS R10000) in my own basement. This heavy brick easily calculated [email protected] packages in 8 hours at times when Wintel boxes required some 60 hours to do the same. Still ... you see what everybody is using these days

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Annirak Wrote:
-------------------------------------------------------
> PIC32 is MIPS32, which has gcc support.

But is the PIC32 supported as a result? And if so, how well is it supported?

annodomini2 Wrote:
-------------------------------------------------------
> But is the PIC32 supported as a result? And if so,
> how well is it supported?

AFAIK, that's the benefit of using a standardized core. The core itself is well supported (MIPS32 M4K). I can't speak to the support of the peripherals, but that's something that's not too bad to overcome. A quick google brought up this forum thread where someone learns to build GCC for PIC32: [www.microchip.com]

Again, I'm not suggesting that a PIC32 is necessarily the best option for future development--it's just the only DIP MCU with a hardware divider.

Personally, my interest leans more towards a configuration where the MCU is just a segment buffer/stepper driver and all other processing is done on a host PC.

There are some DIP Cortex-M3's and M0's

http://www.digikey.co.uk/product-detail/en/LPC1114FN28%2F102,12/LPC1114FN28%2F102,12-ND/3430860

Luminary micro did a dip unit, but I'm struggling to find a reference.

I looked at those but I could never find one which was actually in stock. The Stellaris (Luminary) ones seemed better--Cortex M3 vs M0 for the NXP ones--but the ones I could find are SOIC, not DIP.

@Annirak

Did you get anything working with the L6470 motor drivers? I've been looking to add a stepper motor controller to the raspberry pi and the L6470 looks a good match.

@TonyD
I'll be working on that this week; I'll post here either with updates or a link to a more suitable thread.

Edit: Please scrap the post below - It's already been done apparently... LOL

Looks like this thread is a little stale, but there MIGHT be some interest?
Digilent have a PIC32 board that is basically an Arduino Mega form factor. (They call it a MAX32)
Link to MAX32
Sure, it's a 3.3V processor, but from what I can see, a standard RAMPS1.4 will work just fine at 3.3V.
The A4988 polulu stepper drivers are already 3.3V / 5V parts.
I don't envisage any problems with mechanical end stops.
The thermistor inputs will still produce readings at the 3.3V supply (although obviously different code is needed)
There _MIGHT_ be some issues trying to drive the heater/fan FETs from only 3.3V, but I'm already intending externally mounted FETs for these. (While the STP55NF06L datasheet seems to indicate it could still handle around 45A with a 3.3V Vgs, I doubt I'd 'risk' it above 15A or so)

Can anyone here tell me why I wouldn't be able to piggyback a RAMPS1.4 straight on top of a MAX32?
Obviously, the software aspect is COMPLETELY different and it'd be a big hurdle to overcome, but my simplistic brain seems to think that the hardware aspects are 'non-existant' in this case.

Aside from the software aspect (which I accept are HUGE), I think this would be quite an impressive 'upgrade path' for those who already have a RAMPS1.4 board...
An 80MHz PIC32 (which is a MIPS R4k core) should have ample 'grunt' and it DOS have a hardware divide instruction which should help overall execution speed.

Edited 1 time(s). Last edit at 05/18/2013 06:54PM by TheRevva.

The default mosfet of RAMPS BOM mightnot work well for 3.3v but as said planning for using an external one already...
The SD extension board designed for RAMPS might not work because of the voltage translator.

Other than that, it should work.

Though dont understimitate the software issue, u might end up rewriting the whole firmware, not an easy job.

p.S. I am working on writing a firmware for Arduino Due.

Had a quick peek at those L6470 drivers, and I just have to say wow! Seriously, those are some sexy drivers. And they do look perfect for a Pi based system. The programmable acceleration and single command constant speed commands would make most of the "real time OS" worries go away, and the SPI interface makes the limited pins of the Pi a non issue as well.

But to coordinate all axes, and make sure they accelerate the same fashion and such...is complicated.
I think it's easier to be done in the software, at least it has been done.

Guys, seriously don't bother with the Pi,

It's I/O is laughable.

If you want something to replace the Arduino and be the computer at the same time look at a lot of the Pi's competitors.

BeagleBone would be a good example.

http://beagleboard.org/Products/BeagleBone%20Black

You may be able to get more inputs by doing something like this RPi cluster. The video shows how this guy synchronizes them together.

I had a spare rPi that I wanted something to do with and stumbled onto Repetier-Server. It allows you to have a web interface to control your RepRap and ques up gcode that you may want to print, even has a simple model store if you are printing out the same thing over and over.

For me it takes advantage of what the rPi's strengths are - able to run complex interface and web control applications while leaving the real-time low level stuff to any existing RepRap electronics. Plus, as Repetier-Server only needs about 5MB of RAM while sending gcode to the printer you can run several off of one Pi.

It means that you can monitor how far a print has got, temperatures etc. from any web browser on your network (even a phone browser). I have port forwarded through my router so that I can check on things if I have to pop out for a bit or am out of range of my wireless network in the garden.

Eventually it should also allow custom scripts that would enable the Pi to control the power supply of a given printer (or other functions) so you could be leaving from work, want to print something and have the bed heating up ready for your arrival home (purely as an example ).

The Beaglebone Black at $45 has two PRU microcontrollers built-in that can be used for real-time control, and there is provision for code on the main processor to talk with the PRU processors.

Detailed information on the two Beaglebone Black PRU real-time processors can be found here
[github.com]

Hi Annirak,

Just a question about the L6470 Driver you mention (much) earlier in this thread

Did you actually hook it up?

Looking for code to use this driver with a Mega

Thx

Coolerooney

JohnDH Wrote:
-------------------------------------------------------
> Detailed information on the two Beaglebone Black
> PRU real-time processors can be found here
> [github.com]
> blob/master/Documentation/01-AM335x_PRU_ICSS_Overv
> iew.pdf


Ah, I had no idea; I hadn't looked into the Beaglebone Black particularly closely.

There's still a fundamental problem with any of these solutions: they will not, they cannot compete on price with Gen7. That's just because replacing a $6 part with a $45 part is a bit of a non-starter. I think I could bring the electronics in under $100 with a beaglebone black. That makes it more affordable than RAMPS, but still more expensive than Gen7.

They're not the same target, I know, but the comparison will be made.

Coolerooney Wrote:
-------------------------------------------------------
> Just a question about the L6470 Driver you mention
> (much) earlier in this thread
>
> Did you actually hook it up?


No, I didn't in the end. I'm trying to cost-reduce/performance increase from pololus, and it doesn't really accomplish that.

Hold the presses. I didn't notice if anyone else has mentioned it, but there is now a product called "Embedded Pi" available at the element14 site. It's especially for this purpose. It has the header layout for Arduino shield, so you can directly attach RAMPS 1.4 to it, with the SD/LCD package and all.

[www.element14.com]

That should speed the porting process! The price is US$39

Depending on the jumper placement on the Embedded Pi, you can select each of the three modes of operation:

STM32/Standalone Mode: The Embedded Pi works as a base platform, the STM32 controls the Arduino™ shields directly without the use of Raspberry Pi. It can interface with outside world and can control surroundings by sending & receiving input/output using wide variety of sensors; like controlling lights, motors, and other actuators.

A quick & easy embedded project can be built in C using CooCox development tools, a FREE and easy-to-use ARM development tool environment for Cortex-M MCU with flash programming & debugging capability (CoIDE, CoFlash, CoLinkEx etc), along with the integrated abundant reusable code shared by CooCox team and CoFans.

ST-Adapter Mode: The Embedded Pi STM32 controls the Arduino™ shields, and the Raspberry Pi works as the GUI or command line console to send commands/data to and receive data from Embedded Pi. This is an advanced mode which extends and strengthens the automation control capability of the Raspberry Pi, taking the advantage of STM32F103 NVIC (Nested Vectored Interrupt Controller), GPIOs, and more peripherals like ADC and PWM.

Raspberry Pi Mode: The Embedded Pi works as a hardware connection bridge between Raspberry Pi and Arduino™ shields, allowing the Raspberry Pi to interface directly with existing Arduino™ shields, having a number of sensors & control to interact with external environment. It offers all the possibilities of connecting digital and analog sensors using the Arduino™ shield but with the power and capabilities of Raspberry Pi.

---

|
| Lead Developer of Marlin Firmware
| Help support my work at Patreon and Elsewhere.
|

Thinkyhead Wrote:
-------------------------------------------------------
> Hold the presses. I didn't notice if anyone else
> has mentioned it, but there is now a product
> called "Embedded Pi" available at the element14
> site. It's especially for this purpose. It has the
> header layout for Arduino shield, so you can
> directly attach RAMPS 1.4 to it, with the SD/LCD
> package and all.

I don't think so, it has the Uno layout not the Mega layout.

This still doesn't solve the problem. You're replacing a $6 part with a $39 part and a $35 part. $6 < ($39 + $35). That is the problem with Raspberry Pi-based electronics. As long as you're trying to compete with Gen7, you're not competitive.

Thinkyhead Wrote:
-------------------------------------------------------
> Hold the presses. I didn't notice if anyone else
> has mentioned it, but there is now a product
> called "Embedded Pi" available at the element14
> site. It's especially for this purpose. It has the
> header layout for Arduino shield, so you can
> directly attach RAMPS 1.4 to it, with the SD/LCD
> package and all.

Now, don't get me wrong, the Pi would offer some benefits that Gen7 doesn't have and nor does RAMPs; but I (currently) can't get over that price premium.