rPi MIDI via GPIO (or USB)?

Hello everyone,
Is it possible to MIDI-fy a RISC-loaded Raspberry Pi? A few people have successfully done this on a Linux-rPi both via USB (linux drivers exist..) and via the GPIO UART pins (after slowing the baud rate to the appropriate speed.) Is it a question of having the proper driver written for a USB-MIDI interface? What about with the GPIO? I’ve thrown this out to a few people here and a seemingly dreaded “bit banging” was mentioned as possible but not desirable. I don’t understand what bit-banging is so that’s why I put it in quotes, feel free to school me please, but other than this method would it be possible via those pins? In Linux land one experimenter found that using USB-MIDI slowed down the system considerably which is why he switched to a GPIO solution.

Some more info if it would help: I have a specific MIDI task that I’m attempting and I’m hoping that the process can also open up the rPi with RISC OS to some other MIDI uses:
You can laugh, I know it’s rather silly sounding: I’m hoping to use an Atari ST program to control some MIDI hardware without having to use a very large, fragile, non-portable Atari ST. Franck Martinaux’s RISC port of Hatari, the ST emulator, runs beautifully on the rPi, but the Linux port on the rPi is very slow (yet MIDI functions.)

Is it possible to MIDI-fy a RISC-loaded Raspberry Pi?

From my earlier post, it looks like slowing down the UART clock would be the simplest way. You’ll still need an interface board to convert the Pi’s serial (0v-3.3V) into real-world serial (approx +/- 9V). The two are very much incompatible.

As for slowing down the serial port, hopefully somebody more familiar with the internals of RISC OS will have an idea if this is easily doable.

A few people have successfully done this on a Linux-rPi both via USB (linux drivers exist..)

A USB dongle isn’t any good under RISC OS unless a RISC OS driver exists.

a seemingly dreaded “bit banging” was mentioned as possible but not desirable. I don’t understand what bit-banging is so that’s why I put it in quotes, feel free to school me please,

A digital serial link is basically a series of pulses. Running at a specific speed, the serial port will have a start bit, a series of data bits, and a stop bit. If you can “wiggle” any digital output at the right speed, it will look to the other end of the wire as if it is a serial link. I have used a similar method to this to do my own IIC through a parallel port, but since the IIC master device also supplies the clock pulses, it is a lot less time sensitive. With true serial, it must be exactly to time, no hiccups.

But that isn’t the hard part. The hard part is reading the serial using a bit-bang method. In this case, you will need to sample the GPIO pin at 2x (and better, 4x) the clocking rate so you can be assured of a detection of a change of state, not just a glitch or transient in the wire. You’ll need code to match up the framing so you can reliably detect the start, data, parity (if any), and stop bits. To run at MIDI speeds, you’ll need to be able to read data at thirty thousand bits every second, which with oversampling will mean running the samples at around 120,000 times a second for good detection. I suspect you’d burn a lot of time/effort/power doing just that. You can bit-bang just about anything through a GPIO (for instance, PCM data), but doing such a thing on a general purpose microprocessor should probably be the last idea you consider.
Things are different for microcontrollers like the PICs and Arduinos, because while they often run slower, a bit-bang job can be the only task they have to do; not run RISC OS and applications at the same time!

Complication. As RISC OS was written very much in the days when single-tasking was still widespread (it predates Windows 3), there are parts of the OS code that disable interrupts around “critical sections”. Well, bang goes your serial link if the OS does something to require it to disable interrupts…

In Linux land one experimenter found that using USB-MIDI slowed down the system considerably which is why he switched to a GPIO solution.

USB fires a lot of events which need to be handled. The GPIO solution is using UART pins. Since the UART (serial hardware) is already present inside the chip, most of the hard work can be tasked off to the hardware with the UART raising an interrupt once per byte received. This is childishly simple for the host hardware, so much so that you could expect an 8MHz machine to handle MIDI without breaking into a sweat (think of the Acorn BBC I/O and Midi podule stuck in the back of an A310).

If you can find out how to change the serial rate, and get an interface board sorted, the UART method would be the most responsive and least laggy on the system.

You can laugh, I know it’s rather silly sounding: I’m hoping to use an Atari ST program to control some MIDI hardware without having to use a very large, fragile, non-portable Atari ST. Franck Martinaux’s RISC port of Hatari, the ST emulator, runs beautifully on the rPi, but the Linux port on the rPi is very slow (yet MIDI functions.)

Why laugh? Susumu Hirasawa, who did the music for “Papurika” (as well as “Millennium Actress” and “Paranoia Agent”) frequently uses Amigas. Why not? If it works for him to use Amigas, and for you to use Atari, then why not?

Meditational Field (Paprika OST): http://www.youtube.com/watch?v=aQIZKbyPtXc

Whole bunch of MP3s on his own website to listen to (needs script & flash): http://noroom.susumuhirasawa.com/modules/opus/index.php/category/7/

I fully and totally endorse anyone using Amigas or Ataris or any obsolete hardware for new purposes, and I do it with real STs right now, but I’ve encountered a few people that I’ve approached with my problem who think I should just learn a new program on an iPad, which isn’t the point, and nothing I need to go into here anyway ;)
Anyway, yes, UART is the way I want to go because that’s what MIDI uses, as I understand it, on other systems, And I sure do know that 8mhz is enough to get great MIDI timing, that’s the speed of an Atari ST.
An interface board for the UART pins on the Raspberry Pi has been made, http://www.siliconstuff.com/2012/08/serial-port-midi-on-raspberry-pi.html

but I’ve encountered a few people that I’ve approached with my problem who think I should just learn a new program on an iPad,

iPad? They are useful for something other than for executive-wannabees to make pie charts to point at?

which isn’t the point,

Exactly. Why do we bother with RISC OS? Why not jack it in and spend our time on a more productive environment? It’s because that misses the point entirely. Feelings and emotions, which I’m sure we all have (hell, look at the package manager thread) don’t have any basis in logic.
Neither does love.

How can you be productive if you jack in your Atari and use something completely alien? You know I still write webpages in a plain text editor? It doesn’t even colourise. Because that is what feels right for me. I don’t need logic or rationality when talking about “feeling”.

An interface board for the UART pins on the Raspberry Pi has been made, http://www.siliconstuff.com/2012/08/serial-port-midi-on-raspberry-pi.html

Yup! I posted that link in a different thread here … um … six hours ago. (^_^)

Looking further into the datasheet, it seems as if it will be possible for the Beagle to output MIDI rate.

The serial speed is defined as:
-8<———-
Baud generation based on programmable divisors N (N = 1 … 16,384) operating from a fixed functional clock of 48 MHz
Oversampling is programmed by software as 16 or 13; thus, the baud rate computation is either:
• Baud rate = (functional clock/16)/N
• Baud rate = (functional clock/13)/N
-8<———-

So you’d need to work out to divide by 13 or by 16, and then the further divisor. If the MIDI speed is 31.25kbps, then a quick calc would mean you should program the first divisor to be 16, and the main divisor to be 96. That should get you bang on the right speed.

As for the Pi… don’t have its datasheet to hand (swapped SD cards for Naniwa Shônen Tanteidan).

And I’m the guy “7thheaven” that commented there 10 days ago! Ok so what do you do with this information of serial speed in RISC OS in order to access UART? Sorry, I just dont know here where to go next.

I don’t have any pearls of wisdom about MIDI, sorry, but:

Well, bang goes your serial link if the OS does something to require it to disable interrupts

Hardware drivers with very tight interrupt latency requirements are what FIQs were invented for…

YES! Finally some success!

Using the official release, a minor addition to CONFIG/TXT, two resistors and a transistor and little BASIC I’ve got a simple rythm running.

In CONFIG/TXT I have the line:

init_uart_clock=813802

Derived from 3000000*31250/115200
Changing to the suggested “init_uart_baud=38400” and “init_uart_clock=2441406” didn’t seem to work.

Then a bit of BASIC using the initial post from this thread to get me started, then some numbers from something I started years ago for a portable drum machine using a DB50XG MIDI card.

HAL_UARTTransmitByte=70
fin%=FALSE

WHILEfin%=FALSE
d%=35:PROCdrum
PROCdelay
d%=42:PROCdrum
PROCdelay
d%=38:PROCdrum
PROCdelay
d%=42:PROCdrum
PROCdelay
ENDWHILE

END

DEFPROCdrum
SYS “OS_Hardware”,1,153,,,,,,,0, HAL_UARTTransmitByte
SYS “OS_Hardware”,1,d% ,,,,,,,0, HAL_UARTTransmitByte
SYS “OS_Hardware”,1,127,,,,,,,0, HAL_UARTTransmitByte
ENDPROC

DEFPROCdelay
FORdel%=1TO15:WAIT:NEXT
ENDPROC

Circuit I used:-

Use with caution, or if anyone can suggest better please do so.

Hardware is 256Mb RPi, dodgy circuit into DB50XG card fitted to PowerWAVE Podule on RISCPC.

EDIT.
The circuit referenced to in previous posts, is a safer option and works with the above.