RaspberryPi + P2?
David Betz
Posts: 14,511
I just saw this video of a Parallela board connected to a RaspberryPi. I wonder if we could do something similar with P2? I guess P2 could even drive the video display and not require OpenGL commands to be sent back to the RaspberryPi for rendering. Could the P2 produce this level of graphics? This Parallela board costs $99 though and I think an equivilent P2 board should be a lot cheaper.
http://www.youtube.com/watch?v=-lCWlu1EnsM&feature=youtu.be
http://www.youtube.com/watch?v=-lCWlu1EnsM&feature=youtu.be
Comments
Damn that is cool.
For sure the P2 is not going to match the Raspi's GPU, "impossible" I say.
Now, Raspi and P1 or P2 does appeal to me as the Raspi has all the Linux running power, networking, USB, graphics etc whilst the P1/2 has the I/O and real-time interfacing potential.
If the main thrust of your pondering was "how might we use OpenGL from the P2", I wonder if it could be done with a second P2. In other words, one P2 would provide nothing but OpenGL capabilities (1 cog input, 1 cog output video, 6 cogs processing), while another P2 would do everything else. Or maybe 200MHz just won't be fast enough. Or maybe OpenGL is just too heavy for truly embedded application. I don't suppose there are any inexpensive, standalone OpenGL GPU ICs out there...
Sources are open
http://forums.parallella.org/viewtopic.php?f=34&t=708...
http://www.xmos.com/startkit
I strongly disagree. The Raspi and the PII are not even comparable.
The Raspi is a board, the P2 is a chip.
Putting that aside, the Raspi is a Linux machine with very little in the way of I/O support apart from the standard ethernet, USB etc. Certainly not a machine for real-time, real world interfacing.
The Props are micro-controllers built for real-time, real-world, interfacing.
I don't know who augments who but the combination of Pi + Prop (1 or 2) seems like a great idea. There are many Pi users on the Pi forums running into issues of insufficient I/O and non-existent real-time operation. They need a P2 !
There are 2 million Pi users out there. We should embrace them, not fight against the Pi.
I absolutely agree with this statement! Augmenting the RPi (and ARM processors in general) with the P2 makes a lot of sense, and said so in my original post. I was only arguing that using an ARM to add functionality to the P2 was much less enticing (even if this distinction is only a matter of perception). If I were a hardware manufacturer that is new to the P2 and saw demos that showed the use of an ARM to "make it complete", I'd quickly start to wonder why I shouldn't be using the ARM altogether! On the other hand, if the demos focused on how the P2 "makes the ARM complete", then you have access to a market that's much bigger than the 2 million Pi users.
Clearly you can go "bare metal" on the Pi like any other machine but what does that offer? The reason one might want to use a Pi is to get easy networking, USB, SD card and accelerated graphics. A major reason for wanting to use a Pi is to make use of the huge amount of programs and libraries that are available. Throw the OS away and you now have to write all those hardware drivers and other software yourself.
I was over stating my case when I said "Raspi is a Linux machine", there are other operating systems for it, but for most cases some variety of Linux is what you want.
I'd want to keep Linux on the Pi just so I can run SimpleIDE/propgcc/openspin on it thus being able to do Prop development on the attached Pi itself.
That makes a lot of sense! I know one of the original goals of the P2 was to have a self-contained IDE, but the cost of an RPi (or Beagle or Intel's offering) gives another low-cost approach that just wasn't available when the P1 was released (or when the P2 was originally conceived).
I wonder if it would make sense to build a Pi board that you could plug the P2 reference board into. Since RPi has two SPI CS lines on GPIO, the Pi board could have two slots (with a jumpered bridge). This would allow for a lot of add-on power for the RPi, as well as a convenient development platform for inter-P2 communication.
I would go as far as to say Parallax should release a P2 board that is a Raspberry Pi "plate" by itself. Two million potential customers out there don't forget, three million by the time the P2 comes out. Having Parallax design and build it would ensure it becomes a "standard".
As a minimum such a "plate" should have:
1) A Prop 2 and support components.
2) The 32MB RAM.
3) Pads for an optional Real time clock chip. (The Pi does not have an RTC)
4) Pads for an optional VGA connector. The Pi cannot drive VGA.
5) Lot's of I/O on headers of course.
6) Parallax supported SimpleIDE/Openspin/propgcc for the Pi.
People moan and whine about how the GPU firmware "blob" is closed source and undocumented. As far as I'm concerned that is on the hardware side of the fence so it should not be an issue. It's no different than needing to load firmware into a WIFI adapter or whatever.
They care because they could be prevented from doing something they are legally and ethically permitted to do by code in the BLOB. That's the core issue. And Larry Lessig wrote a lot about this in his freely available book, "CODE."
Some random thoughts about the Raspberry Pi and it's GPU BLOB...
1) Larry Lessig is right in a way, but wrong.
There is nothing preventing you changing that binary blob. You can change it any how you like. Or make your own. It might me a bit hard to do as we don't know how the GPU works. Call it a challenge in reverse engineering.
The code in that blob could just as well be cast into ROM in the SoC. Or even built as random logic within the chip. Then we would call it "hardware". We would not be able to change it at all. Would Larry like that better?
2) The entire Raspbian Linux kernel source and all the it's drivers are Open Source Software. The ARM processor never need run any closed source binary only driver code. Contrast with the closed source binary Nvidea drivers that need to be loaded into kernel space at run time.
3) I read somewhere that the Free Software Foundation would not bless Raspian Linux as "Open Source Software" because of the GPU blob. However if that code were cast into ROM in the GPU then the FSF would be OK with it. Personally I find that perplexing as the code is not ever run by the operating system and it seems logically the same to me whether you have to load it to the GPU as firmware or it's blown into the GPU ROM.
4) I do hope all the people arguing passionately against the closed source undocumented GPU firmware are also careful not to:
a. Use any PC with a closed source BIOS.
b. Use any peripheral devices like WIFI adapters and many others that rely on being loaded with firmware before they can be used.
c) Use any modern Intel processor that is capable of updating it's micro code from, wait for it, a binary blob.
5) Turns out that the blob is more than just a firmware for a GPU. It's all to do with boot sequence. On the Raspi the blob is the first thing that gets loaded to the Soc at boot up. The GPU executes the code it finds in the blob which then takes over and loads the ARM user code. It then starts the ARM running that user code. Normally the first user code is a Linux boot loader which goes on to start Linux.
6) Adding on to 5). It follows that the GPU blob has total control over the machine at boot time potentially it can backdoor and trojan your Linux before it is even started. Being the closed source of an undocumented machine it's hard to know what is going on there.
7) I guess, thinking about it, the blob has control of the Pi at all times, it has total access to all RAM at all times I believe. It is free to monitor and backdoor anything.
Hey, dammit, I'm starting to question my own stance on the blob now...
But wait...The Raspi boots from an SD card. That SD card has a processor of it's own. That SD card is also perfectly capable of modifying your OS before it is run. That SD card powns you. This of course also applies to any system using a modern day HD or SSD.
That GPU blob seems like the least of our worries.
If you want to use the GPU, you have it ready when Pi starts and you can control it via its mailbox mechanism. Then you can use a Pi for example as a powerful, HDMI, OpenGL capable framebuffer for the Propeller.
At boot the GPU loads the BLOB, which then has total control of the Pi, the BLOB is responsible for loading a boot loader which then loads your OS.
This means the BLOB owns your machine from the very beginning. It can modify any ARM code that it loads prior to running it. This may be hard to do but at least in theory it can mess with your code such that it always has control of your machine and can hide that fact from you.
I'm not sure about the details but I suspect the GPU and the BLOB have access to all memory in the Pi all the time. It's not clear to me that disabling interrupts from GPU to ARM or doing anything else actually stops the GPU dead. AND how would you know anyway without source code to the BLOB and /or GPU hardware documentation?
I'm sure from a security perspective this whole Raspi GPU/BLOB set up would not be trusted.
Given all the revelations recently regarding government ordered back doors in computers and crypto standards and government created malware you should not be surprised if you read one day that GCHQ coerced Broadcom into placing a trojan into that BLOB so as to be able to snoop on all those terrorists that use Raspberry Pi's to by pass the snooping they suffer on regular Windows PCs, phones and tablets.
Why do you think there have been 2 million Pi's sold all around the world? You think they are all going to innocent teenagers to learn programming?
I have hinted that Parallax itself should be jumping on this idea but they seem to be more interested in pandering to the rich kids with iPads.
A Parallax P1 Raspberry "plate" would set some kind of standard with a lot more chance of attracting wide adoption.
A quote from jamesh on the RPi forums "As for Herman Hermitage - his work is truly impressive. We originally though it was an ex-Broadcom/Videocore engineer as he was produced such good work, but it turns out he isn't, which makes his work all the more impressive."
If Parallax doesn't target the Raspberry at the minimum with a bare bones P2 board the way Xmos and Digilent are, I think they are seriously missing out.
Is the P1 really capable enough? It would add some processing power, but it's still only a digital device. So it could provide some additional computer power and digital signalling interfaces. To make it really useful for the RPi, you have to add some external A/D circuitry (at the very least). And that circuitry will be pretty severely limited due to the number of I/O lines available on the P1, some of which would be taken up by the data bus with the RPi. I'm not saying it's a bad idea, but I just don't see what would make it enticing enough to capture the imagination of even a small percentage of those 2 million RPi users, at least as a general-purpose experimenters add-on.
Purpose-built propeller plates are a whole different story, however. If a purpose-built propeller plate meets a specific need (with a broad-enough demand), you can use it to introduce people to the P1 in a meaningful way. For instance, suppose you were to create an IMU (Inertial Measurement Unit) board that captured some accelerometers, gyros, etc. Then, and this is the important part, the P1 is pre-programmed to handle the interfacing to the sensors, the interface to the RPi, AND an ability to load one or more spare COGs with custom code (e.g. kalman filters, data interpolation, logging, etc.). The big selling point is that the plate users can "rewrite" the behavior of the plate itself (if the default/packaged behavior isn't enough).
In any case, better to work now with what is at hand than simply sit idle while the world moves on.
Agreed, another segment to possibly exploit.
The same I think goes for a P2(when it comes out), I'd even think a P2 Cape for the BeagleBone Black would be cool. The P2 just screams fast I/O.
I echo all of this. There may have been a time I saw RPi as competition, but that would have been before owning and using the RPi. The Prop and the RPi are excellent adjuncts of one another for just the reasons Heater articulated. I really do encourage everyone to get involved with both! It's a killer combination.
There's no reason why the Propeller 1 couldn't easily be tasked to the Pi for pretty much the same reasons.
Jeff
Edit: Looks like the only prototyping plate is from AdaFruit and it doesn't really have enough space for a 40 pin DIP. Oh well.
Except there are many VGA only monitors around that could be used as console terminals to Pi's if there were a Propeller with VGA out plate.