Howdy, Stranger!
We are about to switch to a new forum software. Until then we have removed the registration on this forum.
Categories
- All Categories 25.7K
- Announcements & Guidelines 13
- Common Questions 30
- Using Processing 22.1K
- Programming Questions 12.2K
- Questions about Code 6.4K
- How To... 4.2K
- Hello Processing 72
- GLSL / Shaders 292
- Library Questions 4K
- Hardware, Integration & Other Languages 2.7K
- Kinect 668
- Arduino 1K
- Raspberry PI 188
- Questions about Modes 2K
- Android Mode 1.3K
- JavaScript Mode 413
- Python Mode 205
- Questions about Tools 100
- Espanol 5
- Developing Processing 548
- Create & Announce Libraries 211
- Create & Announce Modes 19
- Create & Announce Tools 29
- Summer of Code 2018 93
- Rails Girls Summer of Code 2017 3
- Summer of Code 2017 49
- Summer of Code 2016 4
- Summer of Code 2015 40
- Summer of Code 2014 22
- p5.js 1.6K
- p5.js Programming Questions 947
- p5.js Library Questions 315
- p5.js Development Questions 31
- General 1.4K
- Events & Opportunities 288
- General Discussion 365
GSOC 2015 proposal: Raspberry Pi and armv7hf support
Hallo all,
Happy to see Processing again accepted for Google Summer of code. I've been toying around with this idea for a while, but I think now all the stars are in correct alignment for this to actually work, so here is my proposal:
The Raspberry Pi (RPi) has been around for a while, and has proven to be a viable platform for many applications in education, media arts, prototyping etc. The initial model featured an ARMv6 CPU and a custom graphics core with open specs. As most Linux distributions settled on using ARMv7 (and higher) for their efforts on ARM, this made mainstream software support initially a little bit problematic and sure slowed adoption of the RPi for many use cases. Nevertheless, a dedicated flavor of Debian taking best advantage of the RPi's hardware capabilities called Raspbian was born (targeting the armv6hf ABI), and Oracle also released a version of Java optimized for this hardware.
Besides the RPi there exist also other affordable mini computers running on ARM, such as the Beagle Bone Black (BBB), some of which are also quite popular. A common trait amongst those are that they're generally using the more powerful ARMv7, and hence can make use of many upstream Linux distributions with little effort. All of them however lack a sufficiently open graphics core with graphics support in the Linux kernel & Mesa. Two recent developments make me want to work on enabling Processing on the Pi: the Raspberry Pi 2 was released, now featuring ARMv7 cores - which makes it a much more future-proof part in terms of software support, since it's now much more closer aligned with the other players. And the Raspberry Pi 2 is still using the same (3D OpenGL ES 2.0) graphics core, for which Eric Anholt is developing an open source, to-be mainlined driver, under the wings of the hardware manufacturer (Broadcom), which will work on both the RPi and RPi 2.
What could this mean? With a choice between many flavors of Linux, an open graphics driver coming together, and support from Oracle for ARM, this could well be the $35 computer that can be used for running Processing, working on sketches and run them in your studio, or in an exhibition - without having to part ways with one's laptop or having to buy a $600+ Mac Mini. It has always bugged me that the cost of materials for digital arts is so that students and young practitioners are constantly re-purposing and salvaging their artworks for the next ones. The Arduino is already at a price point where you might get a away with burying one in or with a piece. But this could get us a step closer to this for graphics and interaction.
Proposed steps
- Add support for armv6hf (RPi) and armv7hf (potentially RPi2, and other ARM boards) to the Processing Core
This should be fairly straightforward, and involves mainly downloading the correct JRE for ARM, some changes to library loading, and cross-compiling any native binary code Processing is currently shipping. This would help the RPi as well as any other ARMv6/ARMv7 boards (such as the BBB).
- Cross-compile all libraries known to the library manager for armv6hf and armv7hf (the former is probably sufficient except for libraries that are resource-heavy, such as OpenCV)
This would help the RPi as well as any other ARMv6/ARMv7 boards (such as the BBB).
- Create an automatically generated disk image based on Raspbian that includes Processing and the graphics driver in development
This would be specific to the Raspberry Pi and Raspberry Pi 2 (one image for both).
- Work with Eric Anholt to iron out any graphics (3D) issues that might pop up
Rather than using the closed-source (binary blob) driver that came with the RPi from day one, but needed dedicated support in JOGL etc and had a bunch of issues which never got resolved, I intend base my work on the open VC4 kernel and Gallium Mesa driver that Eric Anholt is developing with Broadcom. This should minimize the number of RPi specific changes to Processing proper.
- Work on an Arduino-like library
The RPi has a couple of exposed pins for GPIO, SPI, Serial etc. There are some caveats to using those (e.g. 3.3V levels), but it would be great to be able to make use of those instead of connecting and interfacing with another microcontroller. This could especially be nice for very high-speed IO, where the Serial and USB link used to be the bottleneck. There are already some Java libraries for IO on RPi, such as Pi4J (http://pi4j.com/), and it would be nice to wrap them for Processing, best with an API that is analogous to Arduino. It would also be great if such a library could also be made extensible for the BBB and other boards.
- Create a booklet that explains how to use Processing with the RPi
The RPi was designed with students and education in mind, but it's not entirely self explanatory (yet). A booklet can help explain in which ways such a mini computer is similar and different to a laptop running Mac or Windows. What the needed supplies are, such as a high-current USB power adapter. What peripherals can be connected. A few survival tips for using Linux, joining networks and transferring files onto and off the RPi.
- Package Processing for inclusion in Fedora, Debian
This point is also listed in the general Project List: for ease of maintenance and long term effect it would be best to either get Processing upstream in the repositories of those distributions (or update any ancient versions that they might have), or at least provide a cleanly build extra package, that could be installed with yum & apt in a few easy steps.
- Testing, testing, testing
The testing matrix is not too big with only three major RPi versions in existence, two which share the same CPU, and all of which share the same GPU.
- Continued plumb^Maintenance
Looking forward to your comments!
gohai
Comments
This sounds fantastic and very exciting, I get questions about running Processing on a Raspberry Pi (or similar hardware) often and don't really know where to start. I like that you mention documentation and tutorials as this, in addition to the technical implementation, will be key to making it easy / accessible. Are there issues with performance in terms of what sketches can run? I look forward to your proposal!
This would be great. I, too, often get students asking about using Processing with RPi . Right now it can only be pulled off with a disproportionate amount of work and the results are brittle and can't use most libraries. The RPi has the video lifting power, so if you can pull the pieces together for a stable ProcessingPi, this would be a brilliant solution. You have my vote for SOC!