Norns on Raspberry Pi



…built in battery :wink:

But in all seriousness hitting the reset button on the bottom of the device could in theory cause filesystem corruption. The norns device isn’t using an SD card - the cm3 module has a 4GB eMMC which has higher write throughput than an SD card and potentially different buffering characteristics as a result.

The fact that your SD card occasionally mounts read-only sound more like a system configuration thing. Forgive me for not knowing the specifics in the case of an rPI distro but most Linux/UNIX systems have the option of attempting to repair filesystem on boot if it wasn’t unmounted cleanly or to simply mount the filesystem read-only if it wasn’t cleanly unmounted. FWIW I suspect you might be running into the later situation - a system configured to be conservative and mount the fs read only.


fsck ?

ive been meaning to checkout overlayfs as an option for readonly fs.
organelle, uses a simple approach of having rootfs readonly most of the time, but then making it writeable when doing things like installing. then using a ramfs (tmp) for transitory data.
then when I introduced patches on an sdcard (rather than usb which was the normal case) , I just added a second writeable partition


The filesystem will flip into read-only mode during a system upgrade, no reboot required. This isn’t a configuration problem.

I’m familiar with fsck but I’d rather not have to do a file system check because I’d prefer if the filesystem not be corrupted. It sounds like the organelle design is closer to what I’m looking for.


Does anyone know where to look for changing the GPIO pins to hook up encoders and buttons?

I’ve tried looking through norns/matron/src/hardware/gpio but nothing is standing out


you have to change the norns-buttons-encoders-overlay.dts file

it can be found here:

and has to be converted into a .dtbo file by using

dtc -W no-unit_address_vs_reg -@ -I dts -O dtb -o norns-buttons-encoders.dtbo norns-buttons-encoders-overlay.dts

and place into /boot/overlays

so far as a starting point. :wink:


Would it be a crazy idea to use a terminal emulator as the OLED screen? 128x64? No problem! That’s high resolution compared to an emulator a friend of mine put together while developing for a 35x45 pixel display made of milk crates and beer bottles called Flashen Taschen.

I haven’t read over the code but he made a 24bit color screen emulator that renders in a TTY. This is pretty important for development since there is literally only one of the 9 foot by 7 foot F~T screens :wink:

So…all the Cairo Linux framebuffer stuff in matron is coupled to a real display device. What if (pure imagination) there is some kind of /dev/fb => 8 bit ASCII utility?

In leiu of that. I’ll check out how hzeller did his version.


So I’m having quite a few issues getting encoders and buttons working with the norns stack (fried 2 rpis), so I was wondering, is there an easy way to replace the physical encoders with OSC controls?

I saw the latest study make extensive use of it, however I understand that the supercollider (crone?) level is separate from the hardware (matron?) level, so it’s probably not a quick solution at this point. Just thought I’d ask the question.


What happened with the encoders you used that the whole board let out the magic smoke? Was it a short circuit? IIRC there are some Adafruit tutorials that describe how to wire a rotary encoder to an RPi.

Regarding OSC, I got TouchOSC working on a cheap Kindle Fire tablet. This is described in the 5th study.


First one, soldering while it was still powered (half asleep) and managed to ground the 3.3v and 5v together. It blew the GPIO, but the pi3b still functions.

The second one, I made sure everything was soldered correctly, powered it on (new 3b+). Everything booted correctly. After about a minute, screen went black (red power light flashing) then after reattaching power, i just get a constant red pwr light. The cable i attached might have been backwards, but the worst that should have happened is sending 3.3v directly to a pin. No idea what’s going on.

I found so many conflicting wiring diagrams, so at moment i have it soldered data pins on either side of the encoder and then ground to ground. Same on the pushbuttons.

With TouchOSC, can you scroll through the menus (emulating the hardware controls), or only change parameters within a loaded app(?)?


this is not that difficult,
( but does require a bit of C coding, because as you say, it needs to be done in matron)

all you need to do is receive the osc messages you define, and then generate encoder and key events. then as far as the rest of the norns code is concerned they are treated exactly the same as if they come from the hardware.

you can see this being done here:

(thats also fun, is you are not restricted to using 3 encoders and buttons, you can have as many as you like… so that your own scripts can use more - hence ive 11 encoders on the push2 :slight_smile: )


This is the canonical reference for RPi pinouts.


I bought one of these and will hopefully try this on a Pisound setup soon

It is a bit cumbersome but certainly useful for buttons/encoders:



hi there did you use cairo_scale(cr, x, y); to scale up the display if so where do you put it? :thinking:


not sure if this is aimed at me or @reijo, the original question was aimed at me :confused:

anyway, yes for push2 I used cairo_scale (when Im in ‘emulation’ mode, i dont when in native mode) , I put it in the init() method , after cairo_create(…)

in my particular case, I have added push2 as a separate device, so that it can be used alongside the norns display. which is a bit involved :wink:

but if you are just trying to get this to work on a rPI and want to ‘hack’ (and dont care about the norns display) it then you could just chuck it in screen.c


hi there yes i was just getting it to work on my pitft but its tiny at the moment ihave been looking in screen.c to see where to enter this but am stumped as you can see. :face_with_raised_eyebrow:

this is where i have it at the moment but no dice

surface = cairo_image_surface_create(CAIRO_FORMAT_ARGB32,128,64);
crfb = cairo_create(surface);
cairo_scale(cr, 2, 2);


For my 7’ screen, i have:

(CAIRO_FORMAT_ARGB32,1024,600); // resolution of the display

cairo_scale(cr, 4.5, 6);

Maybe that’s closer to what you’re after?


Hi all, I have made a little progress in mimicking hardware encoders with OSC.

I’ve hit a bit of a wall though, so any help would be greatly appreciated.

In GPIO.c where the encoder and key events are generated, in enc check, the event enc.n is looking for a value to select the right encoder (1,2,3) and is looking for the direction (1, -1)

In key check, I’ve tried some values, enc.n (0,1,2) and (0,1) or (1,-1), however this crashes matron.

Here’s the copy of osc.c where I’m trying to generate the events.

osc.c (4.1 KB)

And a copy of the TouchOSC file

norns-control.touchosc (494 Bytes)


enc.n is based from 1 (not 0), delta is -1,1

here’s a link to my working code for push2, its (currently) around line 770

I did try other deltas, but this mucks up because of other monome lua code which also tries to do acceleration.
also I found I had to thin the data a bit, otherwise it was way to sensitive on the push.

@martindunne as @Taubaland said, you have to give the real size of your display, what happens is then scale will scale the drawing calls to that display size.

(this is done in my code around line ~200, though its a bit more complex for push as i have two screen buffers one for native and one for the emulated … this allows me to switch between the two without any artefacts )


Works perfectly, I will have to investigate the acceleration.

Everything is working now. Strange that it would crash Matron rather than just shift the button presses along, but oh well.

Thanks heaps for you help (and everyone else) over the past few months on and off, I finally have the stack working.

Now to give back to the community!


and the penny drops :smile:. many thanks will have some fun now, although the puzzling is fun too.