Raspberry I/O galore in new Gertboard video

I'm puzzled why Gert is using an AVR in his latest design (and earlier, a PIC), given that his board is an accessory to the ARM-based Raspberry Pi.  Programming his board will require yet another toolchain, for AVR, which creates unnecessary hassle and adds a second architecture for people to learn.  (I have the AVR toolchain installed for use with my Arduinos already, but it's a bad idea to force this on everyone.)

He should have used a cheap ARM like a Cortex-M0, which costs roughly the same as AVR but has a much more powerful architecture and instruction set, and consumes less current too.  And it's ARM like the Rpi.

It's also very puzzling on the cost front, as his board is fairly pricy.  Why not use an already existing board like for example the STM32F4-DISCOVERY, which is very cheap because it's manufactured in huge quantities, available everywhere --- here it is at Farnell where I bought mine:

    http://uk.farnell.com/stmicroelectronics/stm32f4discovery/board-eval-stm32f4-discovery/dp/2009276?Ntt=STM32F4-DISCOVERY

This costs under 10 pounds in UK, yet its ARM Cortex-M4 microcontroller is a vastly more powerful device than any AVR in existence, and it's superbly endowed with peripherals.  For motor control one would have to add a little driver board just to handle the power/voltage needs, but that's very inexpensive.  Not all that many people will need DC motor control anyway, and integrating it adds unnecessary cost for everyone.

Not saying Gert's board is bad, but it's rather costly and underpowered as a peripheral for Rpi, and he should have used a cheap ARM to avoid tool proliferation.

Morgaine.

I was a bit confused by the inclusion of a microcontroller - regardless of architecture.  Gert does comment that everything in the demo was done using just the built-in functionality of the Broadcom SoC: http://www.raspberrypi.org/archives/868#comment-17335

I could see my self using a Gertboard and not utilizing the AVR (or not populating if it's just a PCB).  I suppose it allows for extra functionality without having to add yet another board.  He also comments that he approached Atmel about help with the toolchain without success so far: http://www.raspberrypi.org/archives/868#comment-17329

I think the nice part about Pi daughter boards is that anyone will be able to design and make them unlike the Pi itself which is dependent on a hard-to-obtain SoC (even once design files are released).

That STM32 board looks interesting and affordable - how do you image would be the best way to interface it with the Pi?

Thanks,

Drew

You have a couple of options for the Pi. The easiest one is probably serial/UART as Linux already supports it natively. There's also the SPI but the driver for it is still in development.  The AVR or any MCU for that matter is a great addition me thinks because you can theoretically install a firmware on it so that all Linux users have to do is send a command via the serial/SPI port to effect some control on the board  Something in the degree of  #>$SERVO1^180   to control some servo #>LED0^OFF         to turn OFF an onboard LED #>GPIO1^HIGH    to enable a GPIO  I myself have two of those STM32F4 boards and they are quite powerful but harder than usual to program due to the complexity of the ARM architecture

For control purposes the problem with the RPi is that it's general purpose IO is incredibly limited and that it's big bloaty Linux and preferred use of Python (which might change) make it very hard to add IO stuff and get a good response time. Your RPi driving ADC/DAC via I2C or SPI will go like a slug compared with  a little ARM Cortex with on chip ADC and DAC.

So I can imagine why Gert wants a processor but I would have gone for an ARM.

Of course - you then end up with a computer talking to a little processor which does all the fun IO stuff that you can understand  - so it's not so different from a PC and an Arduino - except that one exists and the other is imaginary.

@ Morgaine - why not connect your STM32F4 discovery board directly to a PC and it will all work today (if it's too fast you could control it from an RPi emulation running on a PC :-)

If the RPi ever appears in serious numbers I'll do an STM32F4 based board for IO (but not until Farnell actually have stock)

Michael Kellett

@Drew: I'm not surprised at the inclusion of a microcontroller on the Gertboard at all, because a Linux kernel can't provide high precision realtime control even with the best realtime patches applied.  The realtime patches improve Linux's RT responsiveness a bit (I used to use RT-patched kernels for MIDI and Jack audio), but only in comparison to a non-realtime Linux, not in comparison to a dedicated microcontroller.  Complexity is the enemy of realtime performance, and the Linux kernel is very complex and is doing a hell of a lot concurrently.

In contrast, a dedicated microcontroller for I/O can eliminate software response latency almost entirely if you choose to give it nothing else to do.  It's very sensible to offload a Linux machine's I/O duties onto a cheap micro, and you get not only far better realtime performance but also a ton of extra I/O ports.

I am however surprised at Gert's *choice* of micro.  AVR would be a good choice in other contexts, but not in the context of Rpi because it complicates matters for schools when they have to run an additional toolchain.

PS. Interfacing a board like the STM32F4-DISCOVERY to the Rpi would be identical to interfacing the Gertboard.  All the normal I/O methods of the embedded world are available, including SPI, I2C, UART, USB, USB OTG, and CAN.  Add a cheap PHY and magnetics and the STM can even do Ethernet, as it has a controller on-chip.  And the STM is a DSP with full-duplex I2S in its repertoire as well, so a dedicated audio link to the Rpi would be possible as well.  (Although apparently the Rpi lost its I2S connections during final layout).

@Herson: LeafLabs have reduced the complexity of ARM programming almost down to the level of Arduino.  Check out the Maple which uses an ARM Cortex-M3 plus Arduino-compatible shield headers -- http://leaflabs.com/devices/maple/  and their Maple IDE, which is a slightly modified version of the Arduino IDE -- http://leaflabs.com/docs/maple-quickstart.html . And it's worth noting that the Maple has third party clones too, eg. http://www.olimex.com/dev/olimexino-stm32.html which is very cheap, 17 pounds in UK.

@Michael: It's too dangerous to have external boards hooked electrically into one's main PCs.  Optical would be safe but it adds too much cost and complexity, so the only remaining alternative is Ethernet, which is safe because it's coupled magnetically.  The nice thing about Rpi boards used as "computers" is that their very low cost eliminates the worries associated with direct electrical connections entirely. :-)

Morgaine.

Hello Morgaine,

Are you worried about danger to the PC or danger to the operator ?

Since you mention the low cost of the RPi I assume you mean danger to the hardware.

If the external hardware uses one of the standard PC ports (USB, RS232 or Ethernet) the risk to the PC is low.

Since Ethernet happily combines low cost, fast response and electrical isolation it makes a good choice. There are several low cost ARM Cortex micros with on chip Ethernet. Simple Ethernet communications are probably easier to code than USB. There are several Arduino routes to Ethernet as well. (and .net microframewok stuff too).

Now it will be easy to get the IO system to work with other computers while you wait for the RPi !

Michael Kellett

@Michael:  Danger to the PC hardware versus danger to the operator are just differences of degree.  If you're interfacing to power equipment then any direct electrical connection can have unfortunate consequences when things go wrong. The result can be anything from a mere PC reset pulse through to frying your electronics, all the way up to frying yourself or some unlucky 3rd party.  USB and RS232 are not electrically isolated.

It's best to avoid the most common problems by avoiding direct electrical connections to costly equipment.  The Rpi is excluded from the equipment worry because it's not costly.  What's more, external hardware directly connected to an Rpi network server becomes fully isolated, since Ethernet is isolated.  That's a great way to protect other costlier equipment and people at the same time.

Re Ethernet ... that's what I said. :-)

Re getting I/O to work with other computers, that's what I'm doing already with both Cortex-M3 and M4 boards, but my current connections to PCs are over USB and USB OTG.  I want the Rpi so that the connection can use SPI or I2C for lower latency.  (Ethernet provides high bandwidth but the latency is a tradeoff versus reliability.)

Morgaine.

@ Morgaine

If you are interfacing to power equipment you need to know what you are doing.  I would have thought (hoped) that the typical Gertboard user was in the low power "twinkle a few LEDs class".

The RPi is not very isolated in normal use - it is connected directly to monitor, mouse and keyboard so the operator safetey issue is the same as with a PC.

You can get better latency with SPI than Ethernet but not by much - Ethernet can blow the socks off I2C for rate and latency. (Max I2C 400kBit/s, typical min round trip is 4 bytes = (roughly) 112uS. Ethernet can transfer 11200 bits  = 1400 bytes in the same time, which is enough to send a UDP and get a reply (easily).

Of course SPI can go faster over a few cm of wire ( perhaps a bit more) but signal integrity will soon be problem at anything like 10MHz or above. I'm not sure how well the RPi hardware deals with SPI but you'll need to work at register level to get a reasonable performance.

What are you going to do with your RPs ?

Michael Kellett

@Michael: There is no "normal use" for the Rpi.  You use it as you want to use it.  It's no more "normal" to use it with keyboard and mouse attached than it is to use it attached only via Ethernet.  I said very explicitly that the Rpi is isolated only when used as a networked server, namely headless.  When its sole connection to other computers is Ethernet then it is well isolated since coupling is magnetic, so that is a great way to handle interfacing to external hardware safely.

Re Ethernet bandwidth ... that's what I said.

Re Ethernet latency ... you seem to be confusing network stack RTT with application response latency.  The two are very different.  First of all, raw Ethernet could indeed have very small latency if the communications were at MAC level, but they never are.  Everything uses IP these days, and reliable IP communications typically use TCP on top of IP, since inventing your own reliability layer is one of the worst ideas ever.  As a result, you have the fairly large overheads in the network stack to contend with, and your response latency to incoming "Ethernet messages" goes way up, because they're not really just Ethernet messages.

In addition, in a Unix/Linux/BSD type of operating system your application never runs in kernel space, so there is the additional delay of kernel-user and user-kernel context switching to increase the latency still further since the response is coming from your application.  And as if that weren't bad enough, there is an additional amount of latency contributed by the process scheduler too, since *nix machines are always running multiple processes.  It all adds up to the latency response over Ethernet being fairly poor.

This is why most people recommend linking a microcontroller directly to the Rpi using SPI or I2C, as Gert is doing.  This has the potential to deliver all 3 of low latency, high data rate, and also low timing jitter  You can't get that over USB nor, in practice, over Ethernet.

> What are you going to do with your RPs ?

I have a rather long list of applications, including using it for high-level 3D printer control (I'm currently building a Shapercube -- http://www.flickr.com/photos/morgaines/sets/72157627604533547/ -- which uses an Arduino for low-level control), and playing with clusters of Rpi boards, as concurrency and parallelism has been a long-term interest of mine.  I'll probably also make a media centre like 10 million other people are doing.  But mostly, I want Rpi in order to "network everything".  And that means I need lots of them.

At current rate of appearance of boards and 1-per-person still applying, it's somewhat academic of course, sadly.

Morgaine.

Hello Morgaine,

If you are happy to poke the SPI registers directly why not poke the MAC directly.

Raw Ethernet run point to point is rather better reliability than SPI or I2C if you have more than a few feet of wire but the RPi has only one port.

I2C is a very low data rate so that leaves you with SPI -  is there a register level interface published for the RPi ?

To me the huge downside of the RPi is the Broadcom SOC with its "secret" hardware which is going to make it very hard to get the most out of it's processor.

Michael Kellett