NERP (Not Exclusively Raspberry Pi) is PS1’s embedded programming interest group. At a special NERP on December 17, Kattni Rembor will be giving a workshop on Adafruit’s Circuit Playground Express board running CircuitPython. This is a paid event.
That’s right — the next NERP is not free and open to the public! There’s a first time for everything! Registration details here.
Kattni Rembor is an embedded software developer, technical writer, and community leader with Adafruit Industries. She joined Adafruit as a member of the CircuitPython team, and has written the definitive Getting Started guide, the library designed to make CircuitPython simple to use on Adafruit’s premier learning board, as well as many project guides and tutorials. She has helped build the amazing, supportive online community around CircuitPython and a wide variety of other open source topics.
CircuitPython is Python that runs on microcontrollers. It is designed for learning and if you are new to programming or electronics, CircuitPython can help you get started with both. All you need to do is plug in a microcontroller board and start writing code.
Participants will be given a Circuit Playground Express microcontroller board to use. This beginner-friendly workshop will introduce CircuitPython and cover the basics. Then we will get into working with code. There will be a series of examples that use the various sensors, lights and switches built into the Circuit Playground Express board. We will start simply, and we will build on the concepts learned, combining them as we go to eventually build a light-up, capacitive touch tone piano.
Doors open at 6:30pm. NERP is usually free and open to the public, although this event is paid and requires registration.
For those who are interested, there will be the opportunity to stay after the break for further exploration.
We will be using Mu as our code editor. Mu is an editor that has the serial REPL and a plotter built in, and makes getting started with CircuitPython particularly easy.
Participants must bring a laptop (ideally running Windows 10, Mac OSX, or a recent version of x86 Linux) and a compatible USB Micro cable (e.g., USB-C to USB Micro if you have a newer Mac). Be sure that your USB Micro cable includes data transfer capabilities, and is not charge-only as it will not work if it is charge only.
In the last days of Radio Shack, I was in a store on Michigan Avenue when I spotted, buried amongst the disassembled shelving units and discarded phone cases, a small red box that turned out to be an Arduino-based soldering project, the 2770158 LED Cube (https://github.com/RadioShackCorp/2770158-LED-Cube). I bought it for something like $5, took it home, and promptly put it on the shelf as a project I’ll ‘get to’ at some point.
The honest truth is that I was somewhat intimidated by the soldering; it’s a 3x3x3 cube of LEDs that are soldered together and the lights were smaller than i was expecting, and looking at some pics of the final result, I resigned myself to likely screwing it up and at best hoping that I might learn something from what I assumed would be a complete failure. So I somehow justified to myself that, in order to not waste my $5, I shouldn’t actually try to make the thing I spent $5 on.
At some point I hit myself with a clue-by-four and realized the stupidity of my situation; accept the possible loss of the $5 and actually try instead of fretting about what-ifs. So I took the kit to PS:1, sat down in the Electronics area, got out the soldering iron, magnifying glass, and went to work. It took a couple of hours, and I was certain, absolutely positively certain, that, even though it looked right, there was no chance that I had actually gotten the leads all wired together correctly, especially the ones in the middle that were extremely hard to reach with the big tip of the soldering iron. Okay, well, only thing left was to actually plug it into the Arduino Uno I had, load up the sample sketch (available in the RS GitHub repo above), and see what happens.
I fired up the Arduino IDE, loaded the sample sketch, hit upload, and all of a sudden all the lights came on as it started through the canned routines. I was initially skeptical, checking every single light to see which one was never lighting up, and all of a sudden it dawned on me that I had actually done it, all the lights actually lit up as part of the demo routine, and HOLY CRAP I MADE A THING AND IT WORKED!!!!1111
And then in my excitement I dropped it, ripping the USB cord from the Arduino, and landed lights-down on the floor. Well, of course I did. Of course I broke it, right? But as I checked the connections, nothing had come loose, there were no broken connections. I plugged the Arduino back in, and sure enough, it happily came back to life and started going through the routine. Whew!
So I resolved to make this truly my own; running a demo program that I didn’t write was not ‘finishing the job’. I remembered the QBasic ‘Snake’ program that drew a line bouncing around the screen, hitting the edge and then randomly turning and going off into another direction. Ah, but this is a cube, in threeeee deeeeeeee, so the challenge would be that more interesting, especially as I resolved to sit down and actually try to implement it without any help from the Internet; a three-dimensional matrix of lights, translated into C++.
This is where I remembered a line from Top Gun that went something along the lines of “Our pilots had become dependent on missiles” as a reason for loss of dogfighting ability. (And then I got that Everly Brothers song stuck in my head). Well, writing C++ for years, I had become dependent on the containers provided by the Standard Template Library (map, vector, etc.). While the Arduino is programmed using C++, it’s really a pretty small subset of C++ (which sort-of-kinda-not-really makes sense) and the STL is not available; go ahead and #include <map> all you like, all the compiler’s gonna do is complain. So I knew I’d have to regain some amount of dogfighting capability and do all the array/matrix stuff in pure C. So I decided the best way to keep myself honest and regain some of the skills I think I used to have, I created a C file in Vim (using Emacs always made me angry, straight-up I hate this, whatever this is), wrote the program, saved, compiled and ran straight from the terminal prompt. Again and again and again.
One of the biggest problems was forcing myself to get past the ‘sheesh, this woulda been easy to use <insert some STL thing> here’ and just focus on getting the values in the right cells of the matrix. It took a few hours to get the algorithm right, but pretty soon I had it spitting out numbers that seemed right, but how was I gonna know that it was right?
This is where I decided to make a quick diversion and build a virtual version of the matrix in OpenSCAD:
Using this model, I could walk through the output of the program and verify that the snake was truly moving correctly around the matrix. I rotated the model around, checking that the numbers were right and HOLY CRAP I MADE ANOTHER THING THAT WORKED!
The last thing to do was to actually get the program to work with the LEDs. This is where the spartan documentation of the original Radio Shack code became a problem; the sketch did a passable job of explaining how the lights were addressed, but the examples were all arrays of pre-baked values without having to do anything dynamic, and my program was all dynamic. I studied how the demo program worked, started fiddling with the values, and discovered how to set the bits in the right way to turn on individual lights, on specific levels. From there I modified my C program and added some code to translate my positioning, which turned out to be the mirror opposite of the way the lights are addressed; I solved the problem by physically turning the Arduino around so I was looking at the other side. Problem solved!)
I uploaded my sketch to the Arduino and it suddenly the lights were lighting up in what appeared to be a snake moving around the matrix. HOLY CRAP I GOT IT TO WORK!!!!!!11111
This is a long post for what amounts to a small light toy, but whilst I was feeling rather verbose (a consequence of sitting and waiting for an unrelated program to finish), I can’t emphasize how foolish I feel for not starting all this earlier; fear of failure is a very, very powerful emotion and if there’s a TL;DR in here somewhere, it’s that it is always better to try and fail than to never try at all, which is something PS:1 has done a very good job of teaching me.
A while back I built a pair of sound-reactive LED towers which were on display a few times, at some local Chicago events.
To plug into the DJ mixer output required a relatively expensive device to get the stereo signals (with external gain control) seen by a computer running processing.org as a microphone input. Also, it was a relatively bulky affair to have yet another laptop sitting next to the mixer when the artist wasn’t using it to make the music.
Recently I discovered that starting with the 3.1 release, Processing can now run on a Raspberry Pi and has built-in ability to manipulate the GPIO ports. This blog entry highlights the release. This is exciting news as now the laptop can be replaced by a Pi 3 with a small touchscreen.
Here is a video of the light towers in action.
The towers each have 8 panels with 60 individually addressable RGB LEDs. These pictures show off more of the visual esthetic and the cutaway view reveals something of the construction. The LED strips are hidden in a channel in the wood supports which side illuminate acrylic panels (backed with just a strip of white cardboard). The acrylic is impregnated with a diffuser which reflects the edge-lit light 90 degrees to exit out of the faces of the panels. The white cardboard reflects the 1/2 of the light that would otherwise be directed inwards. The acrylic is produced by Evonik and is called Acrylite EndLighten. The towers themselves only require 110 VAC power. The data frames to control the LED strips are sent wirelessly from the processing script using an Open Pixel Control module which maps points on the processing screen into frames sent to a Fadecandy server running inside a OpenWRT Wifi device which is then physically connected to a Fadecandy board. I used TP-Link TL-MR3040 WiFi devices to run OpenWRT and added the Fadecandy server application into the img file used to reflash the WiFi devices. The Fadecandy GIT repository can be found here.
There were a lot of possible paths to follow in getting this build working the way I wanted it to be. Most of my Google searching turned up outdated examples, particularly due to the changes introduced in the 4.4 kernel with /boot/config.txt use of overlays. Adafruit had this very nice looking tutorial of how to get the touchscreen working with their version of the Jassie Raspbian os image. The inclusion of how to use FBCP was of particular interest as mirroring the HDMI output is important for displaying processing scripts with the 2D or 3D graphics libraries. Their Raspbian image was based on an older kernel and updating the os (sudo apt-get update; sudo apt-get dist-upgrade) turned out not to just work.
After much tinkering, these are the steps that worked for me. (note that I working with OSX 10.11)
$ curl https://processing.org/download/install-arm.sh | sudo sh
disable auto monitor-off
$ sudo nano /etc/lightdm/lightdm.conf
xserver-command=X -s 0 -dpms
The touchscreen should now display the 640×480 desktop scaled down to the 320×240 PiTFT screen. This makes things look less crisp but has the advantage that connecting to an external HDMI display will work and that most apps need the larger dimensions be usable. Note that many HDMI displays will not be able to handle a 320×240 HDMI signal.
FBCP stands for frame buffer copy, which rescales and mirrors the HDMI framebuffer (/dev/fb0) onto the PiTFT framebuffer (/dev/fb1)
The version of the 2.8″ PiTFT I got from Adafruit, comes with 4 buttons and I created this test Python script to demonstrate not only how to use the RPi.GPIO library, but how to manipulate the PiTFT backlight (so as to not burn-in the screen), use multi-threaded event handlers, and shutdown the os to safely disconnect the power.
I created this script as: /home/pi/pitft_buttons.py (chmod +c pitft_buttons.py to make it executable) and test by typing ./pitft_buttons.py. Note that pressing the bottom right button (#27) will ask for authentication for powering off the Pi. See below to set this script running as a service, in which case, the user will not be asked for authentication.
# example code tested with Pi 3
# Raspibian Jassie (4.4 kernel): https://www.raspberrypi.org/downloads/raspbian/
# Adafruit 2.8" Capacitive Touchscreen: https://www.adafruit.com/products/2423
# for running on startup see: https://learn.adafruit.com/running-programs-automatically-on-your-tiny-computer/systemd-writing-and-enabling-a-service
# make sure to update the ExecStart= entry in the Adafruit script after copying from the example
import RPi.GPIO as GPIO
# list of BCM channels from RPO.GPIO (printed on the Adafruit PCB next to each button)
channel_list = [17, 22, 23, 27]
backlightOn = True
# event handler to toggle the TFT backlight
backlightOn = False
backlightOn = True
# event handler to manage button presses
startTime = time.time()
while GPIO.input(channel) == GPIO.LOW:
print "Button #%d pressed for %f seconds." % (channel, time.time() - startTime)
# event handler to manage Pi shutdown
startTime = time.time()
while GPIO.input(channel) == GPIO.LOW:
if (time.time() - startTime) &amp;amp;gt; 2:
subprocess.call(['poweroff'], shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
# initialize GPIO library
GPIO.setup(channel_list, GPIO.IN, pull_up_down=GPIO.PUD_UP)
backlight = GPIO.PWM(18, 1000)
print "Button #17 exits."
print "Button #22 toggles the TFT backlight."
print "Button #23 displayed the time the button is pressed."
print "!!! Pressing button #27 for at least 2 seconds, powers down the Pi !!!"
GPIO.add_event_detect(22, GPIO.FALLING, callback=toggleBacklight, bouncetime=200)
GPIO.add_event_detect(23, GPIO.FALLING, callback=buttonEvent, bouncetime=200)
GPIO.add_event_detect(27, GPIO.FALLING, callback=poweroff, bouncetime=200)
print "Exit button pressed."
# exit gracefully
To install pitft_buttons.py as a service,
# pitft_buttons service file, start a daemon on startup
# file: /etc/systemd/system/pitft_buttons.service
Description=Start PiTFT buttons daemon
ExecStart=/usr/bin/python -u /home/pi/pitft_buttons.py
Run a processing sketch from a script or from a terminal window or ssh session.
$ DISPLAY=:0 processing-java –sketch=/home/pi/HelloWorld –present
For the 100th NERP Meetup (Yea!), we’ll have the second of a two-part discussion of embedded GUIs on small Linux devices. Qt is much more than a GUI library. Tonight Ron Olson will share some wisdom on the Qt application framework. Ron tells me that Qt promises a lot, and it delivers. Sounds good to me!
Ron says “I figured the main thrust of the talk would be Qt, how it works, its two main parts (C++, QML), and how it works with the BBB as well as a Qt project controlling an Arduino, all with an eye towards demonstrating the QML, and lightly, the C++ connection.”
After graduating from NYU’s film school, Ron took full advantage of his film and theatre background by becoming a software developer. For 24 years, Ron has been one of the developers that companies go to when they want to make their customers lives worse; he helped write the system to show commercials at MTV, worked on cancelled projects at an animation studio that went out of business, pioneered allowing you to lose your retirement savings on the web at Bankers Trust, came up with new ways to target ads to you at DoubleClick, did his part in the financial crisis at Goldman Sachs, and lately has been writing software to help your attorney remember when your trial date is.
Mostly in C++ and Java.
NERP is not exclusively Raspberry Pi, the small computer and embedded systems interest group at Pumping Station:One in Chicago. NERP meets every other Monday at 7pm at Pumping Station:One, 3519 N. Elston Ave. in Chicago. Find NERP and Pumping Station:One at
Doors open at 6:30pm. NERP is free and open to the public. Ed Bennett ed @ kinetics and electronics com Tags: electronics, embedded, NERP, Open Source, raspberry pi, hackerspace, Beagle Bone, Pumping Station One, programming, Qt
The PS1 ShopBot is a great CNC machine that has the benefit, among other things, of being huge, allowing for a lot of cuts on large pieces of material. One of the difficulties working with the machine, however, is getting the bit at exactly 0,0,0 in the X, Y, and Z axis so that if you need something cut at exactly six inches from the edge of the material, it will be exactly six inches. There is already a built-in method for setting the Z axis, using a metal plate and clip and running a specific program on the ShopBot, but there is no such program for setting the X and Y, requiring the user to manually position the bit. This can lead to inaccuracies and wasted work.
To help everyone with accurate setting of the the X, Y, and Z axis, I made a thing:
This is an aluminum plate that is milled to be as precise as I could make it (read: probably a lot of room for improvement) where it sits on the lower left hand corner of the piece to be cut, with the corner of the work sitting directly in the middle of the circle.
With the piece placed on the work, the cable is plugged into the back (I had originally drilled two holes on the front left and bottom of the plate, forgetting that is where the bit has to touch so as to not push the plate off the work, so I drilled a new hold on the back and wrote “Do not use this hole” on the other two) and attached via the alligator clips (ToDo: make a better cable) to the Z plate.
The user should position the bit somewhere over the top part of the plate, where doesn’t matter. The user loads xyz-zero-finder.sbp (the code is available at this GitHub repository) into the ShopBot software and runs it. Assuming the bit is somewhere over the top, it will then slowly move the bit down until it touches the top, at which point it will move to the side (visually this appears to be moving towards the front of the machine, but in reality the side of the machine with the power switch is technically the bottom, or X axis). The program will move the bit inside the circle at what it believes is exactly 0,0,0 and, after displaying a message, will move the bit up two inches to allow the user to remove the plate and put it away.
The plate is in the drawer under the ShopBot in the Arduino box (ToDo: Make a real box for the plate). Feel free to use it and report back how it worked for you, so that we can make it better.
I want to thank Dean, Everett and Todd for giving me valuable advice about how to mill the plate on the Bridgeport; it was tricky because both sides of the plate are milled and getting it to sit properly in the vice was very worrying to me. I also want to thank Eric for suggesting the project in the first place.
NERP is not exclusively Raspberry Pi, the small computer and embedded systems interest group at Pumping Station:One in Chicago. NERP meets every other Monday at 7pm at Pumping Station:One, 3519 N. Elston Ave. in Chicago.
The ESP8266 module has come up several times in discussions at NERP, and it keeps getting better. Tonight at NERP, Jay Hopkins will tell us about some of his recent findings as he revisits the esp8266. In Jay’s own words:
“The esp8266 is an ultra low cost module (sub $10) with an 80Mhz 32 bit processor, up to 4 MB flash memory, 100k of ram and 802.11 radio. What sets the module apart from other ultra low cost modules is the inclusion of an 802.11 b/g/n radio and in firmware the IP stack for connectivity in the IoT (internet of things).
“At NERP we will be looking at the tools available to build firmware for the ‘8266. Both microPython, lua and the arduino IDE are available for programming the ‘8266.”
NERP is Not Exclusively Raspberry Pi, the small computer and
embedded systems interest group at Pumping Station:One in
Chicago. NERP meets every other Monday at 7pm at Pumping
Station:One, 3519 N. Elston Ave. in Chicago.
Luciano Ramalho is a member of Garoa Hacker Clube in Sao Paulo,
Tonight at NERP, Luciano will tell us about the Pingo
project in progress at Garoa HC
(http://www.pingo.io/docs/intro.html). Pingo aims to make
interconnecting small controllers of all sorts easy and
transparent, so that they can use each other’s peripherals. An
example use case would be using Python on a Beagle (or similar)
to effectively “program” one or more attached Arduinos.
From the website:
“Pingo provides a uniform API to program devices like the
Raspberry Pi, BeagleBone Black, pcDuino etc. just like the
Python DBAPI provides an uniform API for database programming in
The API is object-oriented but easy to use: a board is an
instance of a Board subclass. Every board has a dictionary
called pins which lists all GPIO pins on the board. Each pin is
an instance of a Pin subclass with attributes that you can
inspect to learn about its capabilities.”
Find NERP and Pumping Station:One
Doors open at 6:30pm. The next meeting is July 7th, 2014.
NERP is free and open to the public.
Ed Bennett ed @ kinetics and electronics com
Tags: electronics, embedded, NERP, Open Source, raspberry pi,
hackerspace, BeagleBone, Element14, Pumping Station One
NERP June 23rd – BeagleBoard Project co-founder Jason Kridner
NERP is Not Exclusively Raspberry Pi, the small computer interest group at Pumping Station:One in Chicago. NERP meets every other Monday at 7pm at Pumping Station:One, 3519 N. Elston Ave. in Chicago.
Some quick specs on the BeagleBone Black rev C : Technology: Texas Instruments Sitara® 32-bit ARM core cpu @ 1GHz, 512MB SDRAM, accelerated HDMI, Ethernet, USB, 69 (max) GPIO, and a host of i/o peripherals directly accessible from onboard headers. Dim 3.4”x2.1”, weight 1.4 oz., Debian Linux pre-installed, Price $55. Availability: everywhere. Element14 is a good place to look http://www.element14.com/community/docs/DOC-54121?ICID=knode-beagleboneblack-space/
PLEASE NOTE: For this special NERP, we will keep introductions short and start promptly at 7pm. Please use the meetup (below) to confirm your attendance!
Find NERP and Pumping Station:One
Doors open at 6:30pm. The next meeting is June 23rd, 2014.
NERP is free and open to the public.
Ed Bennett ed @ kinetics and electronics com
Tags: electronics, embedded, NERP, Open Source, raspberry pi,hackerspace, BeagleBone, Element14, Pumping Station One
ERP is not exclusively raspberry pi, the small computer and embedded control interest group at Pumping Station:One in Chicago.
Tonight, Eric Stein, who is Chief Cat Herder and president of Pumping Station:One will take time out of his busy schedule to show us a Raspberry Pi and Python based system that sends messages by passing messages.
Eric’s system, which is currently in development, receives input from IRC (internet relay chat) and responds by playing an informational message over one of several louudspeakers located around the PS:1 facility. The Pi does text-to-speech conversion on stored messages and i/o logic and control to select the appropriate audio output channel.
A very interesting aspect of the system is the use of ZeroMQ to pass control messages between the Pi and and a server that does something important that Eric will explain. From wikipedia:
“ØMQ (also spelled ZeroMQ, 0MQ or ZMQ) is a high-performance asynchronous messaging library aimed at use in scalable distributed or concurrent applications. It provides a message queue, but unlike message-oriented middleware, a ØMQ system can run without a dedicated message broker. The library is designed to have a familiar socket-style API.”
Find NERP and Pumping Station:One
NERP meets at 7pm 4-8-13 at Pumping Station:One, 3519 N. Elston Ave. in
Chicago. NERP is free and open to the public.
Ed Bennett firstname.lastname@example.org
Tags: announcement, electronics, embedded, meetup, NERP, Open Source, raspberry pi