Raspberry Pi based electronics ideas

I've recently received my Raspberry Pi and I've been thinking about how it could be used for controlling a RepRap. The SPI port on the RPi is very scalable (it can be clocked over 100MHz, though you'll never see that data rate due to signal degradation), but the interrupt latency in the linux kernel could be a problem. As a result, I think the best bet is to stick a peripheral onto the RPi, either an FPGA or a microcontroller.

This may seem nonsensical--using a processor plus an FPGA or microcontroller to replace electronics where typically only a microcontroller is used--but I think the build has a place next to projects like RAMPS; the base cost of a RPi is $25 (or $35 with ethernet), and the base cost of an Arduino Mega 2560 is $75 (digikey). That leaves a lot of (financial) space for an FPGA and an SD card.

Since the goal of the either the FPGA or the MCU is to provide I/O expansion and simple low latency processing, the FPGA seems like the best option, though it doesn't have ADC's built in.

I plan to use TB6560AHQ stepper drivers and allow control of everything including the step size, decay rate and torque via the FPGA.
For the heater controllers, I plan to run a PWM controller from the FPGA.
The endstops are just buffered digital inputs to the FPGA.
For thermistor sensors, I plan to use an external ADC, with an option to use MAX6675 sensors and thermocouples instead.

I'll add all the same expansion connectors as are present on RAMPS.

With a Spartan 6 XC6SLX9 available for $12, this should all be doable in a reasonable price.

Please let me know if you have any suggestions or comments!

Why not ditch the OS to get real time performance rather than add more hardware?

---

[www.hydraraptor.blogspot.com]

TI provide a no OS option for the OMAP series dev-boards BeagleBone/BeagleBoard, but they are a bit pricier than the Pi's ~$80, though they have better I/O options.
I have one I've been messing with here, the issue is I want to use the GPU and all of that documentation is missing and the linux driver is based on a closed source binary.

The OMAP processors however have an interesting feature, 2 I/O coprocessors (called PRU's) that have access to all the I/O pins and could be used to drive the steppers while still running linux on the ARM. Of course the documentation on them is at best scant, they are assembler only and the assembler for PRU2 is not actually available (they will run PRU1 code).

What I would like to do is provide an all in one solution with a touch screen, by all in one I mean including slicing on the ARM, the idea is to use the GPU with OpenGLES and OpenCL to do the bulk of the hard work in slicing, I am just at the experimentation phase, it may end up being too difficult to get sufficient accuracy on large prints because of maximum render target size limitations.

@nophead:

I guess I wasn't particularly clear. Take a look at [elinux.org]. The RPi doesn't have a lot of I/O, but it does have a fast UART, SPI port, and I2C port. Some kind of I/O expander will be necessary. Whether that's done with discrete logic or with an FPGA, CPLD, or MCU is the question.

Discrete logic will be no less expensive than a small MCU.
The advantage of an MCU is that it could have a built-in ADC and PWM.
The advantage of an FPGA is that it can operate in parallel, while the disadvantage is that it has no ADC.

The FPGA is, without question, the more complex solution, but it is also the more flexible one. The RPi will need to be able to program the FPGA, and the FPGA will need a fair bit of code itself. It will also need a clock generator and a 1.2V regulator that none of the other solutions would require. Again, it may not be the cheapest I/O expander, but it is the most flexible and MCU's with comparable I/O counts cost the same price anyway.

I lean towards the FPGA since the RepRap hardly needs any ADC channels and I'd rather use thermocouples with a MAX6675 instead of thermistors anyway.

@Polygonhell, I had a similar idea in mind, but with a minimal price tag. A Spartan 6 LX9 is large enough to host a small soft processor, so even running a coprocessor is an option.

I don't think you'll save anything going with the PI over the Beagleboard.
You'd be looking at the Pi $35, the FPGA ~$12 some sort of board that would have to include ADC's.
The Beagleboard already provides ENET and USB connections along with enough I/O including the ADC's with PRU's to operate in parallel for ~$90, I was just going to build a shield similar to RAMPS and use Pololu's.

I have a 7inch touchscreen on mine, which really pushes the price out of the reasonable range, but something could probably be done with either the DS screen or the PSP one, they can be had on EBay for very reasonable prices, but that sort of sourcing isn't really practical for any sort of production.

Either way most of this is moot to me if I can't get the slicing operation running fast or accurate enough to make it worth while, and that will take a while with my current amount of spare time.

I used FPGA's in my former day job, but I don't regard them as suitable for RepRap because a) I don't know of any opensource FPGA tools and b) it raises the knowledge required to participate much higher.

---

[www.hydraraptor.blogspot.com]

The Raspberry Pi has got everyone buzzing wondering what they can do with it.

If you go bare-metal, it is a fast but cheap ARM board. It is grossly overpowered to drive steppers, but for £30 that doesn't matter. Without Linux, you lose a lot of goodies - network, USB, GPU which need work to replace.

With Linux, you have the real time problem, but you probably only need a custom device driver to drive the steppers. Gcode processing can be done in user space. Then you get all the Linux connectivity, and maybe also run slicers etc. Also a nice big screen.

An alternative to a device driver is to use a stripped down firmware with a tiny Arduino, or even a Cortex M0. There is an STM ARM board now for £5...

Perhaps I'm going about this the wrong way. I think I'll do the design with a LPCXpresso and I might make it standalone later on.

A cheap alternative to adding I/O to the Raspberry pi would be to use the Cortex M0, they are less than $2.00 and can be used to expand the I/O of the Pi. The discovery board for the M0 is around $12.00 and there is a good amount of I/O that could be exposed and use SPI to communicate with the Pi.

gvigelet Wrote:
-------------------------------------------------------
> A cheap alternative to adding I/O to the Raspberry
> pi would be to use the Cortex M0, they are less
> than $2.00 and can be used to expand the I/O of
> the Pi. The discovery board for the M0 is around
> $12.00 and there is a good amount of I/O that
> could be exposed and use SPI to communicate with
> the Pi.

Yes, that is the one I was referring to. I have got one from RS, but haven't done anything with yet. It's 48MHz M0 with 64KB Flash and 8KB RAM. The board is quite large, almost the same size as the R.Pi, but has over 60 IO pins on 0.1 headers, and an onboard ST-LINK debugger. Unlike the Nxpresso, you can' cut off the ST-LINK part.

These boards are great for the price, its a pity they bundle them with their own debug instead of a standard SWD header. I have got SWD JTAG adapters and a gcc tool chain, I don't need to be force fed proprietary software - a strange way to promote hardware. Hopefully I can hack the SWD connector like I did with the Nxpresso boards.

bobc Wrote:
-------------------------------------------------------
>
> These boards are great for the price, its a pity
> they bundle them with their own debug instead of a
> standard SWD header. I have got SWD JTAG adapters
> and a gcc tool chain, I don't need to be force fed
> proprietary software - a strange way to promote
> hardware. Hopefully I can hack the SWD connector
> like I did with the Nxpresso boards.

The two jumpers at CN2 can be removed to let you use the SWD header to connect to another target instead of the onboard STM32F0. Currently it's supported by a couple of open source tools (stlink, openocd) for flashing and interfacing with gdb. $8 for a fully functional debug tool is a big win.

pokey9000 Wrote:
>
> The two jumpers at CN2 can be removed to let you
> use the SWD header to connect to another target
> instead of the onboard STM32F0. Currently it's
> supported by a couple of open source tools
> (stlink, openocd) for flashing and interfacing
> with gdb. $8 for a fully functional debug tool is
> a big win.

Everything you say is true, but I wanted to go the other way round I wanted a SWD header on the target board, so I can use my open JTAG interface.

Turns out I probably don't need to, my debugger of choice should support ST-LINK, so I now have another JTAG interface for the collection

$8 is a pretty good price however you look at it.

If you have got STM32 for the IO, why not use STM32 for everything that the AVR does. (Leaving the RPi does what the PC does, STM32 does including GCode parsing and downward)

I would rather keep it very simple and basic, so i could have a chance to understand it, so i would do smth like this.

GPIO minimal count: 4xDIR 4xSTEP, so can stay in the default free 8xGPIO without touching the other connectivity options.

Separate card with an atmega168, probably via I2C for:
- temperatures and fets; no need for anything realtime, perhaps not even pid, just on-off.
- 1xEnable (common enable on all cartesian axis and hard wired on extruder).
For the above, i guess the old reprap extruder controller v2.2 could be usable, or even a simpler similar setup.

sam0737 Wrote:
-------------------------------------------------------
> If you have got STM32 for the IO, why not use
> STM32 for everything that the AVR does. (Leaving
> the RPi does what the PC does, STM32 does
> including GCode parsing and downward)

I think there is a good argument for what you are suggesting. If we have Pi plus some other small/MCU, then the question is where do you split the functionality. If we let the MCU do all the real-time stuff, then we need a protocol to tell the MCU what to do - move to X,Y, control the heater to 210deg, etc, which is pretty much what the GCode is. We already know we can do that on a 16MHz AVR pretty well. So the question is what is the cheapest MCU that could do that. A Cortex M0 certainly has the power, cheap hardware and cheap/free tools.

The only off the shelf board I know less than $8 is the MSP 430 launchpad at $4.30, but ARM is more widely supported I think.

I think it would be interesting to port some firmware to a Cortex M0, if I didn't have a bunch of other projects I would look into that. I want to build a serial Control Panel, I might use the M0 board for that.

Having said that, as a lerning exercise starting simple is a good way to go.

Well, the more I look at this, the more I think that the RPi is unecessary. I'm in the process of hacking together a 6-axis motor control board, based on the TB6560AHQ--why six? Because I want to experiment with multiple extruders. Rather than step, decay, and torque select jumpers, I've decided to use three MCP23S17 GPIO expanders, since they actually occupy less board area, and I'm trying to fit this in a 10cm x 10cm footprint so that I can use iteadstudio for the manufacturing.

I still need a control board, so I'm going to try and port the Marlin firmware to an Arm Cortex-M0/3. I'm partial to the LPCXpresso, particularly the LPC1769 variant for a number of reasons, most of which aren't important to the discussion, but I'm concerned that the Marlin firmware has some dependencies on C++, which will mean that I can't use the LPCXpresso (CodeRed) toolchain without purchasing it. This means I'll probably just build YAGARTO, but I don't know whether I'll be able to get LPC-Link support for a non-CodeRed toolchain. Are there any ARM boards out there which work with open source tools?

Annirak Wrote:
-------------------------------------------------------
> I still need a control board, so I'm going to try
> and port the Marlin firmware to an Arm
> Cortex-M0/3. I'm partial to the LPCXpresso,
> particularly the LPC1769 variant for a number of
> reasons, most of which aren't important to the
> discussion, but I'm concerned that the Marlin
> firmware has some dependencies on C++, which will
> mean that I can't use the LPCXpresso (CodeRed)
> toolchain without purchasing it. This means I'll
> probably just build YAGARTO, but I don't know
> whether I'll be able to get LPC-Link support for a
> non-CodeRed toolchain. Are there any ARM boards
> out there which work with open source tools?

I have been buying a whole bunch of ARM boards, with the goal of using them with open source tools. I really should get around to writing a blog post on the available boards and toolchains etc.

To keep things short and specific, the LPCXpresso 1769 is a good one. It can be easily modified to bypass the LPC link part and accessed directly by SWD. With careful cutting, the LPC-link and target parts can be separated. I have been using the Codesourcery Lite toolchain, at the cost of a few marketing emails from Mentor. In the past I have used Yagarto, this now seems to be no longer maintained having served its purpose.

Building ARM toolchain from scratch is quite easy too, I used a "summon arm " script, not being too great with Linux building.

The NXP LPC chips in general are nice to use, with an onboard USB mass storage bootloader, you don't need a JTAG/SWD adapter. I have built an LPC1343 board from open source design. You might just be able to make it out hidden behind the nest 'o wires [www.flickr.com]

The M3 parts have a wide range and have a hardware multiply which the M0 lacks. The M0 has lower power and for large quantities the M0 has a lower price, but for small q's the M3 can be had for a few dollars, so it's easier to use M3 across the board. I hate to use marketing buzzwords but the M3 has a great "ecosystem".

If you need more horsepower there is the M4, and above that for $35 the Raspberry Pi can be run bare metal with easily the best/price performance. The imx233 is also quite easy to use, not much cheaper for a board but the chip has the advantage of being available and usable in custom designs. A 100Mhz M3 though has oodles of power for small projects.

I work with/on the firmware for the R2C2 board which is based on LPC1758, you might also want to look at Smoothieware which is C++ oriented and has been run on several different boards such as mBed and LPCxpresso I think.

bobc Wrote:
-------------------------------------------------------
> Annirak Wrote:
> --------------------------------------------------
> -----
> > I still need a control board, so I'm going to
> try
> > and port the Marlin firmware to an Arm
> > Cortex-M0/3. I'm partial to the LPCXpresso,
> > particularly the LPC1769 variant for a number
> of
> > reasons, most of which aren't important to the
> > discussion, but I'm concerned that the Marlin
> > firmware has some dependencies on C++, which
> will
> > mean that I can't use the LPCXpresso (CodeRed)
> > toolchain without purchasing it. This means
> I'll
> > probably just build YAGARTO, but I don't know
> > whether I'll be able to get LPC-Link support for
> a
> > non-CodeRed toolchain. Are there any ARM
> boards
> > out there which work with open source tools?
>
> I have been buying a whole bunch of ARM boards,
> with the goal of using them with open source
> tools. I really should get around to writing a
> blog post on the available boards and toolchains
> etc.
>
> To keep things short and specific, the LPCXpresso
> 1769 is a good one. It can be easily modified to
> bypass the LPC link part and accessed directly by
> SWD. With careful cutting, the LPC-link and target
> parts can be separated. I have been using the
> Codesourcery Lite toolchain, at the cost of a few
> marketing emails from Mentor. In the past I have
> used Yagarto, this now seems to be no longer
> maintained having served its purpose.
>
> Building ARM toolchain from scratch is quite easy
> too, I used a "summon arm " script, not being too
> great with Linux building.
>
> The NXP LPC chips in general are nice to use, with
> an onboard USB mass storage bootloader, you don't
> need a JTAG/SWD adapter. I have built an LPC1343
> board from open source design. You might just be
> able to make it out hidden behind the nest 'o
> wires
> [www.flickr.com]
> 16/in/photostream
>
> The M3 parts have a wide range and have a hardware
> multiply which the M0 lacks. The M0 has lower
> power and for large quantities the M0 has a lower
> price, but for small q's the M3 can be had for a
> few dollars, so it's easier to use M3 across the
> board. I hate to use marketing buzzwords but the
> M3 has a great "ecosystem".
>
> If you need more horsepower there is the M4, and
> above that for $35 the Raspberry Pi can be run
> bare metal with easily the best/price performance.
> The imx233 is also quite easy to use, not much
> cheaper for a board but the chip has the advantage
> of being available and usable in custom designs. A
> 100Mhz M3 though has oodles of power for small
> projects.
>
> I work with/on the firmware for the R2C2 board
> which is based on LPC1758, you might also want to
> look at Smoothieware which is C++ oriented and has
> been run on several different boards such as mBed
> and LPCxpresso I think.

Only the LPC13xx & LPC11uxx have the USB bootloader, the LPC11/12/17 have UART bootloader. Uncertain on the LPC18xx.

Looking at the STM32F4Discovery, it seems like a reasonable solution, but I'm concerned by the license which comes with it: [www.st.com]

Annirak Wrote:
-------------------------------------------------------
> Looking at the STM32F4Discovery, it seems like a
> reasonable solution, but I'm concerned by the
> license which comes with it:
> [www.st.com]
> AL_AGREEMENT/LICENSE_AGREEMENT/EvaluationProductLi
> censeAgreement.pdf

Yes, I have seen that . In my non legal opinion that "license" is completely bogus and should be ignored. If they sell dev boards for less than the price of the chip that is their choice but they can't invent new laws to cover themselves.

However, companies with such stupid ideas should perhaps be avoided, there are plenty of other ARM vendors to choose from!

bobc Wrote:
-------------------------------------------------------
> Yes, I have seen that . In my non legal opinion
> that "license" is completely bogus and should be
> ignored. If they sell dev boards for less than the
> price of the chip that is their choice but they
> can't invent new laws to cover themselves.
>
> However, companies with such stupid ideas should
> perhaps be avoided, there are plenty of other ARM
> vendors to choose from!

Yeah, I don't think that license would hold up to scrutiny. You can't just arbitrarily make up rules about how people can use something you sell. Particularly if they have to agree to the rules *after* the sale.

I'm going to continue work on developing arm-based electronics. The thread is in the Gen N+1 forum: [forums.reprap.org]

(The following is mostly what I just posted to the RasPi forum.)

After learning that it can't (yet) serve as a MythTV front end, my Pi was feeling depressed. Then I suggested that it might find gainful employment as the brains of the Better 3D Printer that I would build by standing on the shoulders of my first RepRap, and it cheered up a bit.
Unfortunately, while it beats Arduino hands down on raw number-crunching power, poor old Pi has insufficient I/O pins to talk to all of the hardware devices (motors, switches, sensors, heaters, etc.) that the task requires.

Thus was conceived the Raspberry RepRap (or RRR).
At the moment it exists inside my head and in some scribbled notes, while I get back up-to-speed with schematic-capture software.

tl;dr Are you, or do you know someone who might be, interested in (using/ building/ collaborating on design of/ discussing) a modular GPIO expander? What features do you think it (should/ should not) include?

Original Concept

* Pi's GPIO plugs into RRR
* motors, switches, sensors, heaters, etc. plug into RRR
* PC power supply plugs into RRR, and powers everything including the Pi
* software runs on the Pi to control anything plugged into the RRR

Constraints

* circuit board(s) must be simple enough to make at home (e.g. toner transfer and etching, or milling with a RepRap)
Thus:

* 2 layers at most,
* little if any surface-mount,
* each board no bigger than 150mm on a side
* components must be easy to source, and cheap - ideally, cheaper than the Arduino-based boards this is to replace
* expandable, to accommodate things like extra extruders, fans, pulsing light arrays ...

Sub-projects

* RRR baseboard, with Pi GPIO interface, power, and some digital I/Os
* stepper motor, PWM + ADC (and PID loop control) daughterboard, controlled by I2C
* other ? daughterboard, controlled by I2C
* physical stacking layout for daughterboards (same sort of thing as Arduino shields)
* command/response protocol for Pi <-> daughterboards
* firmware(see below) for the daughterboards
* driver software for the Pi, to talk to the daughterboards
* interface/protocol for Pi driver

You'll notice I mention I2C and firmware - to get the extra pins I need I've decided to use a microcontroller on each daughterboard that is commanded by the Pi over its I2C bus. The particular microcontroller I'm looking at is the Microchip PIC18F27J13, which has (among other things) multi-channel PWM, multi-channel ADC, plenty of digital I/O pins, and I2C, and costs about the same as a dedicated I2C port-expander chip that lacks the other goodies. With intelligence on the daughterboard I can also delegate some control out there to get around the speed limitations of I2C, e.g. PID loops running on the same chip that has the PWM and ADC hardware - the Pi can concentrate on higher-level stuff (that isn't so dependent on real-time response).

Please post any suggestions for must-have or must-not-have peripherals. A basic RepRap needs 4 stepper motors and 1 PWM + ADC control loop, but (a) I want more, and (b) I want to make something that's usable for applications I haven't imagined.

mlp

I think an expander board is a great idea, especially one that could be used by other CPU boards.

I'm a bit puzzled by the conflicting philosophy here, you have a design goal to make it easily DIYable, but the Pi is very far from that.

However, the main conundrum I see is that of using a cheap MCU to do low level real time control stuff. If you are sending commands to the MCU, you need a protocol and a serial connection. Isn't that what RepRap controllers do already with Gcode and UART?

You might save a few $ by using a smaller MCU, but you could do that with an AVR board too. Just a question of removing unnecessary features from an existing firmware.

I'm just unclear why there needs to be a new hardware specifically for the Pi, there appears to be hardware already that does 105% of the job.

(tl;dr I haven't yet found anything that can do what I want at a pleasing price point, so I'm trying to make something that can.)

bobc Wrote:
> I'm a bit puzzled by the conflicting philosophy
> here, you have a design goal to make it easily
> DIYable, but the Pi is very far from that.

I'm looking at the Pi as a vitamin, just like the AVR is.

> You might save a few $ by using a smaller MCU, but
> you could do that with an AVR board too.
...
> I'm just unclear why there needs to be a new
> hardware specifically for the Pi, there appears to
> be hardware already that does 105% of the job.

Why new hardware for the Pi?
Because I have a Pi, and I like the exercise of designing and building hardware and software.

Save $ with an AVR board?
Microchip will sell me the PIC18 above for AUD 3.60; Atmel won't sell me a chip, and the cheapest AVR from element14 is close to AUD 10.
My Pi cost under AUD 42 delivered to my door. My aim is to put this together for a total cost (including the Pi) that's similar to the AUD 150 to 200 I've seen RAMPS, Sanguinololu etc. available for. This looks like it might be possible - the most expensive component appears to be stepper drivers (whether Pololu or something at least as capable in through-hole package from China).

Hardware already that does 105% of the job?
Hardly. Apparently a 20MHz AVR can't step a single motor to the limit of the mechanical system's abilities, and it certainly can't drive 4 (or more) that fast, while simultaneously running 4 PID loops; a 40MHz PIC should step a single motor at least as well as the AVR while running a single interrupt-driven PID loop, and there'll be at least 4 of them. Existing RepRap electronics are mostly limited to 5 or maybe 6 steppers; I2C allows 127 distinctly-addressable slaves, although my first daughterboard will only support 16 units. And I have a 700MHz ARM just ticking over, that I can ssh into from the other side of the house (or planet).

Feel free to constructively criticise.

mlp

A 40 MHz PIC only runs instructions at 10MHz and they are very primitive instructions, whereas a 16MHz AVR actually runs instructions at 16MIPs and they are more powerful instructions, so it is a lot faster. The same applies to MSP430 which has a very small instruction set but they map very well to C (unlike PIC) and execute in one clock cycle.

---

[www.hydraraptor.blogspot.com]

nophead Wrote:
> A 40 MHz PIC only runs instructions at 10MHz and
> they are very primitive instructions

Understood. (In a former life I worked for a maker-of-C-compilers-for-PIC, and spent a great deal of time grovelling through those instructions. Thankfully PIC18 is vastly nicer than midrange and baseline.)

Regardless, a single stepper and PID loop per 8-bit MCU will make for a nippier machine than 4 steppers and multiple PIDs on 1 MCU.

I'm open to suggestions for alternatives to the PIC18F27J13 with comparable features at a comparable price:

• at least 2 10-bit PWM channels (this chip has 10)
• at least 2 10-bit ADC channels (this chip has 10)
• at least 10 other digital I/O pins (this chip has 19 total, shared across all peripheral devices)
• at least 4 timers
• at least 64KB of writable Flash (this chip has 128K and/or EEPROM

per AUD 3.60 of price, that is as easily available, which

• runs on 3.3V
• has I2C
• comes in a through-hole DIP
• has a C compiler and debugger with simulator that run under Linux that are at least free-as-in-beer

I can't see an AVR chip that meets this, but I'd love to be shown what I've missed.

mlp

Quote

Apparently a 20MHz AVR can't step a single motor to the limit of the mechanical system's abilities

Depends on the microstepping. At halfstepping, it can do that easily.

Quote

it certainly can't drive 4 (or more) that fast

The Bresenham algorithm is simple, so the above applies to 4 motors, too.

Quote

while simultaneously running 4 PID loops;

Actually, they do. Well, two PID loops, because that's always sufficient. PID loops are no threat, because they have to run only 10 times a second or so.

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.

Quote

I can't see an AVR chip that meets this, but I'd love to be shown what I've missed.

You should look again. The good old ATmega644, in RepRap use since several years, does all this. Available in SMT and DIP packages.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

mlpappin Wrote:
-------------------------------------------------------
> tl;dr Are you, or do you know someone who might
> be, interested in (using/ building/ collaborating
> on design of/ discussing) a modular GPIO expander?
> What features do you think it (should/ should not)
> include?

Short answer is yes. However, I would add the additional constraint that the RPi must be able to program, from bare metal, with no bootloader, every daughter card. And thus, we are left with only MCUs that have boot ROMs; most of the low cost ARMs fit this requirement. Take a look at LPC111x's, STM32F0xx's, and STM32F1xx's.

@Traumflug A cortex-M3 or above would solve the acceleration problem; they have 2-12 cycle hardware 32-bit divide. Perhaps we should revisit this point in this thread.

> However, I would add the
> additional constraint that the RPi must be able to
> program, from bare metal...
> every daughter card.

As the RPi has GPIOs, that doesn't require a bootloader, only that the native programming mode uses only 3.3V signals, which is the case for most of the newer PICs (including the 18F27J13; there are several existing open source programs to do this, e.g. here, but they would require porting to the RPi), and wiring from the RPi to the daughters' programming pins.

However, I don't see the point of such a complicated setup for this application.

If you want to eliminate the division bottleneck, there are plenty of 32-bit options that don't need the complication of this extra layer: either the PIC32 (now available in DIP packages), or a more microcontroller-oriented version of ARM (as in R2C2, which easily reaches the motors' physical maximum speed).

If you want to replace the host PC (slicer, networking, user interface), the RPi would be a sensible choice, but I'd have it communicate in G-code over USB or UART for compatibility with existing RepRap electronics, and consider this the main advantage of using an RPi rather than a smartphone (the cheaper ones are close in price and speed to an RPi+screen, but are USB device-only, while a PC or RPi is a USB host).

rebecca.palmer Wrote:
-------------------------------------------------------
> > However, I would add the
> > additional constraint that the RPi must be able
> to
> > program, from bare metal...
> > every daughter card.
>
> As the RPi has GPIOs, that doesn't require a
> bootloader, only that the native programming mode
> uses only 3.3V signals, which is the case for most
> of the newer PICs (including the 18F27J13; there
> are several existing open source programs to do
> this, e.g. here, but they would require porting
> to the RPi), and wiring from the RPi to the
> daughters' programming pins.
>
> However, I don't see the point of such a
> complicated setup for this application.
>
> If you want to eliminate the division bottleneck,
> there are plenty of 32-bit options that don't need
> the complication of this extra layer: either the
> PIC32 (now available in DIP packages), or a more
> microcontroller-oriented version of ARM (as in
> R2C2, which easily reaches the motors' physical
> maximum speed).
>
> If you want to replace the host PC (slicer,
> networking, user interface), the RPi would be a
> sensible choice, but I'd have it communicate in
> G-code over USB or UART for compatibility with
> existing RepRap electronics, and consider this the
> main advantage of using an RPi rather than a
> smartphone (the cheaper ones are close in price
> and speed to an RPi+screen, but are USB
> device-only, while a PC or RPi is a USB host).

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