I recently had an opportunity to check out the Embedded Pi board. I had observed an advertisement when visiting Element 14 one morning and I became intrigued enough to investigate the board. While it is advertised as a “Triple Play Platform” I came away with the idea that it was truly more of a double play.
The board has several modes which are jumper selectable:
1) STM32 (which is built in) -> Arduino shield (You supply the shield)
2) Ras-Pi (you supply) -> Arduino shield
3) Ras-Pi -> STM32 -> Arduino shield
So at first blush, it seems like an interesting concept. Not as freakishly Frankensteinish as you might think.
After receiving the board I decided to check out the CooCox IDE. I normally don’t use windows for anything, but I do have a copy of Windows 8 I run in VirtualBox for just this type of thing. Before I started playing with this in linux, I wanted to try it out in it’s native environment. I installed the IDE and attempted to run through one of the examples. It was a little confusing to get through the demo, but I was able to resolve all the missing dependencies that I was cautioned about and went to program the board. This was where it asked me to setup my JTAG debugger. Everyone has a JTAG debugger laying around, don’t they? No, I don’t think they do. Fortunately I had ordered a couple of STM32 Discovery boards a few weeks previous, and they do have a ST-Link debugger installed that is jumper selectable to work with either the on board chip, or you can route the SWD Pins to a header that you can attach to. I was able to consult the schematics and get the board connected properly and successfully flashed the board and was on my way. The Coo Cox IDE was familiar as it is based on Eclipse. I reviewed a few of the demos, they seemed pretty reasonable. I will say that I was a bit disappointed that I needed an external Piece of hardware to program the board. I would also like to see Coo Cox make the extra effort to add Linux support.
But then it occurred to me, STM32 chips have a built in bootloader so that you can load the chip via the serial port. It was then that I decided to connect the Ras PI to the Embedded PI.
Rather than provide a socket allowing you stack the embedded Pi on top of the Ras Pi you are supplied a flat ribbon cable to connect the two boards together. I didn’t like the orientation of the boards when connected, but that is just my preference. I reviewed the schematics and connected the uart connections on the Pi and the STM32. I downloaded a python script to allow me to program the STM32 via the uart. I tried a simple program to blink one of the led’s on the embedded Pi and attempted to program the chip. I was unsuccessful. I rechecked my connections and tried again. No success. I looked around and found a usb - ttl rs232 controller and tried that. No success. I reviewed the code, checked the connections, it just wouldn’t work. But I wasn’t gonna give up. I looked around my electronics parts some more and found an FTDI based based adapter, plugged it into the Pi’s usb port, and wired up the tx and receive pins. Success!!! I don’t know why. I was able to repeat this feat several times, downloading a slightly modified program that altered the blink speed of the led each time so I could be sure it really succeeded.
I went back to the other usb to serial module, still didn’t work, and I again checked directly from the Pi’s gpio exposed uart. No success. I looked at the signals on a scope and all appears correct. I don’t know why it doesn’t work. The only thing I can think of is the signal levels. The Pi puts out 3.3v while the FTDI chip puts out 5v. But the STM32 is supposed to be 3.3v with 5v tolerant inputs.
If this had been successful I would have been very pleased. But at least I was able to program the board via the Pi even though again it required external hardware.
The concept of the board is pretty much what you would expect. You can directly access all of the typical Arduino pins directly from the STM32 if desired. You can also configure the board to bypass the STM32 and control the pins with the Pi. I guess the biggest benefit in this case is the 5v level conversion (if necessary) and the isolation of the Pi’s GPIO pins from the external circuit. In the third mode you can run a program on the Pi to interface with the user (if desired, it could be an unattended program or anything that you want) and you run a program on the STM32 to receive messages from the Pi to control the device attached to the Arduino pins.
In conclusion, while I find this is a pretty interesting board, it was fun to play with, I’m afraid that it may be too advanced for beginners, and unnecessary for the more advanced user. The same functionality could be accomplished with the Freescale FRDM boards at a lower price.