Wow, it’s been 5 years since I worked on that last! I actually never released any code because it was still in early stages, but I should have a backup of that somewhere. I guess it would required some migration work just to get started again, since I was using Keil RTOS and I’m not sure if that was a wise choice.
Anyway, the two major reasons I stopped working on that project were:
1- You need a flashing tool to Install the custom firmware. I think it would be necessary to create a small board with pogo pins that plugs into the PO pads area and does that, instead of requiring people to buy an EFM32 starter kit that costs $100 and install the SiliconLabs IDE. That board would need its own micro-controller and firmware, complicating things further. The good thing about that board is that it could be used as a co-processor/memory extension to augment the PO hardware. Fir example, it could have RAM for implementing a delay, or ROM for implementing a wave table, or even a USB interface and work as a pen drive to add sample audio files or patches.
2- I was not sure what that custom firmware would do. Implementing all the basic PO functionality is a lot of work (engines, sequencer, sync modes, pattern backup, automation, etc). What could it do that would be not so complicated and still interesting enough? At one point I started exploring creating a sampler, but then the PO-33 was released. Other options I considered at the time were: MIDI controller PO (not sure if that makes sense), DX7 compatible PO (cool but there are so many devices like that already), effects processor PO (probably the easiest to implement since a sequencer may not be required), looper PO (in case the flash board provides extended RAM).
Does that make sense? Do you (or anyone) have any ideas?
I’m personally looking for a hardware platform with audio IO and hardware buttons/controllers where I can focus on the code without worrying about the hardware.
The PO seems optimal in that it is widely available, portable and not too complex.
Other candidates are the LXR drum machine and Mutable Instruments modules.
These cost more and are non portable so it’s less rewarding.
I have many ideas I want to try, especially around sequencing that I didn’t see in any of the POs. I’m happy to buy the dev kit to conduct my experiments.
I was also always disappointed that none of the POs had any actual games.
It might be a memory limitation, but still.
I agree with you, I just wish TE would provide an SDK with a stripped down PO firmware for those like you that wish to explore new ideas for the sequencer, effects or sound engines, but I guess they don’t see any reason to spend their time on that because there is not a lot of people into it. Again, it will take a big effort just to get a custom firmware to that bare minimum (including performance and stability) necessary to do something useful. It may be more realistic to look elsewhere, unfortunately.
Never heard about it before but it’s a DIY open source shield for the Teensy.
More ram, faster CPU, USB, perfect for prototyping. I will look into that now.
its bluetooth audio in and illuminating for keypad.
handy because you can use po as a bluetooth , and take samples prom it. illuminating lantern helps in the dark.
Years after talking about it, I actually made a daughterboard for Pocket Operators: The MSL Pocket Integrator .
I can’t tell you how many times I re-read Hacking The PO while working on this. Thanks very much for the documentation!
This board fits snug against the back of the PO and presses into the 12 contacts with pogo pins, so it can draw power and monitor the Play LED. It runs GPIO pins from the daughterboard MCU to all the programming pads, so it ought to be able to flash a new firmware. It can also power the PO from USB .
I would love to see an open-source PO firmware project exist. I hope this board would make it easier. Do you really think the code you were working on is un-salveageable?
Hey, your project is very neat! What model of daughter board you are using there? Is it actually generating some sounds and feeding them into the PO input?
I will search for the source code for my firmware and see if the tool chain is still available to compile and install it. It may be worth uploading whatever I have to GitHub, but as I said before, it is a long way before it can turn it something interesting.
Thanks! This revision uses a Teensy 3.2, but in the next revision I’m going to move the MCU directly onto my board. And yes, it’s generating an audio signal (the maraca sound) and a sync signal & sending those to the L and R inputs of the PO, which is in sync mode 4. (I sure wish I could send sync without that little cable, but I don’t see how.)
IMO, the really amazing thing for open-source firmware would be if the Pocket Operator could be programmed from the Arduino IDE. Then all sorts of hobbyists would be able to hack on it. Other toolchains are totally legit, but they don’t have nearly the user base.
I’m really curious about what tools & libraries you tried out. I’ve been thinking a lot about what the architecture would be for a real-timey device like the PO on a microcontroller. My board is like a baby version of that – there’s various tasks that have to be performed at various rates, some have to happen in interrupts & others don’t. There’s audio, accelerometer, button presses, blinking lights, USB events. At the moment I use interrupts for audio & IMU updates and handle all the rest in a single main loop, and performance is pretty good. I can see how the right RTOS could make everything conceptually easier, but they all seem to add a ton of overhead. And there’s so many options, I don’t really know how to pick one.
I feel your pain, I had the same doubts when I started developing my PO firmware. I did some research on the performance aspects and was not convinced that a main loop would be significantly faster than using an RTOS, so I ended up choosing the later to be more productive. I was very careful with the number of tasks and queues though. I opted for Keil RTX since it was backed by Silicon Labs at the time, but I think that is not the case anymore. In fact, if I ever restart working on that project, I may need to change it.
The Teensy is a super nice platform, with a good sound library support. I haven’t look in detail at the projects that use it, but that may be a good way to decide. I would check in special the Dirtywave M8.
It seems to me that the decisions about what tasks to have, their frequencies & priorities and how they communicate with each other, those are really the important architectural questions. The choice of timesharing scheme should flow from that.
I wholeheartedly endorse the Arduino environment in general and the Teensy hardware specifically! I’ve used them for a lot of projects. Paul Stoffregen, who makes Teensy boards, is a major contributor of open-source code to Arduino and also does a great job supporting the Teensy, along with a big and very helpful user community.
Arduino started out as a hobbyist thing, but at this point it just seems to have the best libraries & best support. Every time I’ve looked at commercial AVR-based or ARM-based libraries, I’ve wondered why I would bother with them. Arduino libs are open-source, tested, documented, and have users you can find and ask for help. Those are all priorities for me.
But the Arduino coding philosophy is all about the bare-metal. The majority of the existing libraries are not thread-safe & therefore incompatible with many of the RTOS options out there. I think the keep-it-simple philosophy of Arduino started for pedagogical reasons, but I actually find it very powerful.
That DIrtywavve M8 looks cool! I’m not really a tracker user, but I guess Little Sound DJ had a really special interface.
I’ve seen Teensys in a couple of different Eurorack units as well.
I suspect that TE has used a main loop to implement the PO firmware. I think I got that idea from 1KHz scan rate for the LEDs, which seems rather high to me. As you said, there is no question about that approach being the most straightforward and the best performance wise. I think RTOS is the “sophisticated” way of doing things, but that may not always justify itself. One reason I choose that way was to learn it. I also had to spend a lot of time configuring the EFM32 peripherals, like DMA, interrupts, power management, etc. It was very challenging. At the end I started asking myself of better ways to spend my time. I recently did a small Arduino powered project for my wife that teaches at elementary school, it was surprisingly easy to put together. I’m currently contemplating doing an iOS sequencer app.
Btw, why did you choose to pair your device with the PO? You are basically just drawing power from it. Why not do something standalone with a similar form factor?
Fair question! Mostly I just love the PO. There was a year when I wore it around my neck everywhere I went, making beats on the bus and the tram. I was always wanting to sync my beats with other musicians and other things I was listening to, but that’s pretty much impossible without a tap-tempo button. I went down the rabbit hole looking at how tap-tempo was implemented in all the other gear I & my friends owned, and everything they’d let me touch at music stores, and eventually I decided everybody was doing it wrong. =)
I could have made some kind of standalone digital maraca/baton, but I think pairing it with the PO makes the concept more concrete. I’m really hoping that PO owners will see this and immediately get what it is, what’s cool about it and want to try it. I just had a booth at SUPERBOOTH 21 in Berlin, where I showed off the prototype, and the response I got from PO owners was 100% that. So I’m pretty excited to try the crowdfunding route & make a bunch for people.
And also … from the first time I read your PO docs and saw the interface, I’ve had a little dream about reprogramming a PO, making it an open platform. It’s such a lovely piece of interface, but there’s all these features I would add to it. I just haven’t taken all that on yet. But this board is a step in that direction.
But I’ve never actually flashed the firmware in a PO, even just to brick it. Have you?
Yes, I flashed my firmware using an EFM32 Starter Kit board and a custom made flash cable with pogo pins. I was able to drive the display segments and LEDs, read the keys and generate sounds from a wave table. I then experimented with adding a flash memory chip to the PO to be able to work as a sampler, but did not finish that.
You can’t really brick the PO, but flashing a new firmware is an irreversible process, you loose the original firmware forever.
There is a Silicon Labs application note with source code for a flash programmer, but it runs on an EFM32 chip, not the Teensy, so it may require some tweaking to work.
Also, one of the PO interface pads can be used as an I2C interface to talk to the Teensy at 1MHz with a custom firmware. That may be fast enough to stream audio from the Teensy to the PO, removing the need for that patch cable you are currently using and also using the Teensy as for sound synthesis and the PO mainly for the display, keys and codec. You can always dream…
Hi Punji,
I’ve poured over your Hacking the PO research you’ve done and your journey on here. Very impressive. You wrote “Note that the original firmware will stop the code and turn on (full bright) key number 2 LED in case the codec initialisation fails.” This is the case with my po-12. Is there a way to come back from this? I tried factory reset. Is there a way to use the reset pad on the back to restore it?
Hi, are you sure it is not a weak battery? If you already covered that then, unfortunately, it is unlikely that you could fix it. It may be a fault IC or just some pad with a bad solder, but you can’t even check it because the components are all under the display. Sorry.
Yes. Fresh batteries were used. I was afraid of that. I guess it’s a parts unit now. I really do appreciate all your research and experience you’ve shared.
