Somewhere to post updates on development progress… Here is a (rather blurred) picture of the very first attempt to build a proof-of-concept prototype panel. It is still on my desk but I reused the LEDs elsewhere. It almost worked quite nicely. The LED strips were stuck on top of the tactile buttons. The LED strip has waterproofing silicone covering that acted as a soft button press - but it ended up often activating the adjacent button.
Designing and diagnosing the one-wire detection. Each panel has a 96-bit UID and partakes in a session to identify itself until it detects another panel with a higher UID on the bus at which point it drops out of the session. The last panel standing is assigned an I2C address and starts normal operation and the detection sequence starts again until there are no more uninitiated panels.
The arrival of the first front panels and PCB from JLCPCB. An exciting day to have something that looks (kinda) professional associated with the concern that the PCB may not actually work!!! This was three weeks before I was due to exhibit something at Synthfest 2023 - it will be fine… 
Actually, that PoC was the second attempt. Here we see the first attempt on the left which proved challenging to fit LEDs between the buttons and was actually the one that I salvaged the LEDs from. On the right is a printed front panel (just paper glued to cardboard with holes cut for pots) over the second attempt (with the silicone covered LED switches). I liked the effect of the LEDs shining through the paper. And we first see puple which has been a contentious issue…
3D printed translucent push buttons to activate tactile switches and allow PCB mounted LEDs to illuminate the button. It seems barely believable that such a backlight button is not available off the shelf! These are the first run of buttons with flat tops. Subsequent refinement added domed top to give a more button like look and feel.
The first 3D print of the light boxes / spacer that separates the front panel from the PCB and blocks light from each LED from polluting its neigbours.
The bus cable (snake / necklace). One of these connectors had a short between adjacent pins and had to be rudely escorted from the building. I wonder whether it was lack of care during construction or something to do with the connectors. I will have to be careful to check the next time I build one.
One of the most challenging and frustrating days for a while - bridging non-adjacent pins on the tiny SMD processor due to a PCB design error. I NEVER want to do that again! Four boards were successfully modified, one died in the process - RIP my poor comrade. 
We have a brain talking to a module. Yay! This is actual, tangible progress. This was ten days before Synthfest 2023. A brief relief followed by more, intense development.
If nothing else, it looks kinda pretty. Maybe riban modular will act as the Christmas decorations at riban towers this year?
I missed this step. This was from the day the PCBs arrived. I added some test firmware to them and got the desired result. This was very reassuring (and a relief) as it demonstrated that the microcontroller and LEDs worked as expected. These were both components that differed to the ones used on the PoC boards I had initially designed and tested with.
A splash of colour. I experimented with a kinda pastel colour palette for the front panels. I have quite liked this kind of panel colouring for many years so maybe that is where we will go although we may be influenced by production constraints. You can just see on the right hand side the universal panel that didn’t make it to Synthfest 2023 due mainly to mechanical issues but also its firmware was (is) not sufficiently complete. That panel allows adding / removing modules for which there are not dedicated physical panel, e.g. for testing (ahead of installing the actual panel) or for infrequently accessed modules that would otherwise take up valuable rack space (and cost to purchase the panels). We still have a few (three) days left to the expo…
Less than fourty minutes before I am due to arrive at Synthfest 2023 and I am sanding push buttons and constructing VCO panels. Of course it will be fine…
…and it was. My wonderful helping elf brought distraction in the form of a Zynthian impregnated cajon. We had our friend, the Zynthian V5 on display and riban modular ran (pretty much) flawlessly for the whole day. No crashes and I only restarted it once (early morning) when I wanted to clear it back to a known state. (Subsequently I just operated it as designed.) Synthfest UK 2023 was a great show with lots of interest from a wide range of people who gave me the confidence that this is a viable product.
The next thing to do was build the much-requested website so I did a glamour shoot of what I have and built https://riban.square.site/. I am eager to improve the finish quality of the panels and reshoot these pictures but for now it is something! This picture reminds me of a stock photo you might see in an image gallery or website design package.
2 Likes
The past month has been spent refactoring the STM32 code. I had initially implemented the panel on top of the Arduino framework as this offers very rapid development… to a point. There were significant issues that needed resolution, e.g. the WS2812 LED driver was running in userspace (ab)using the SPI driver. This was interrupted by I2C messages resulting in signal corruption and weird LED behaviour.
I started to reimplement using HAL (which worked) but have a problem with HAL. It relies on custom code that is created by CubeMX IDE for each project. CubeMX does not (easily) run on arm64 Linux. So I moved to libopencm3 which is a light wrapper for bare metal register access. This has been slow going due to the documentation being sparse and example code being processor specific which makes it difficult to locate and invariably in need of modification. It also doesn’t help that libopencm3 implements the same functions in different ways for different processors which is kind of the opposite to what you expect from a framework.
I think I am on the other side of the learning curve, mostly understanding the framework and the STM32. I have WS2812 driver working, using DMA to massively reduce the CPU load.
I am considering moving back to using STM32F103 (from STM32F072). The features of the F072 that make it attractive are not actually being used and the F103 has more RAM and is available on the Bluepill development board (of which I have several) allowing ad-hoc design and testing before committing to PCB fabrication.
I am also considering moving from I2C bus to CAN. It provides many advantages including being more robust in electrically hostile environments (like on stage with lighting, etc ), supports faster bitrate and may reduce the quantity of connectors required. The data footprint is higher but I think the net difference of data throughput will be negligible. Panels will be able to initiate messages which may reduce the polling requirement and allows this same bus to be used for panel detection, removing the 1-wire detection bus and probably the reset signal. The ribbon bus could be reduced to 6 pins which makes it easier to build smaller panels. CAN does require an extra transceiver chip and the F103 is a bit more expensive but I think it can still be done within budget and offers significant advantage. I can always revisit the chip selection if I need to economise later.
I would probably interface the Pi with a STM32 in the Brain via I2C (or a custom interface if throughput is a problem). That STM32 would talk to the rest of the system via the CAN which is implemented in hardware on the STM32 but would require a software driver if driven directly by the RPi.
I am also working on a firmware update mechanism. I had intended to use the STM32F072’s bootloader feature to update firmware via I2C (not available in STM32F103) but it wasn’t viable (requiring control of each panels’ boot pin) so I am back to a previous idea of writing a custom bootloader that will allow firmware update via CAN, and runtime code selection based on firmware version (or some other rule). It reduces the available flash memory a lot. We need equal partitions for 2 versions of the runtime code (current and next/previous) to allow rollback of failed update plus a partition for the bootloader. I think this is fine but will choose a larger flash option, e.g. 128KB.
I haven’t taken my foot off the pedal and am still working hard on this project but the tangible changes are not yet material. I had hoped to order some more panels by now but these changes will render the existing design (and hence panels) useless (incompatible) so let’s get this bit right before moving on. (The old I2C panels may find their way into a Zynthian build…)
2 Likes
Some supply issues have caused some delays. I now have CAN bus working for both panel detection and control and monitoring. I also have better WS2812 LED control. These two things have resolved poor LED behaviour. It also means I can reduce the bits to 6 wires.
I have moved to the STM32F1 instead of the STM32F0. This allows bench testing with development boards like the Bluepill before committing to PCB fabrication. I had some issues with clone STM32 chips that did not support some of the required features.
Moving to the STM32F1 may enable hobbyists to build their own custom versions of they want although it may be easier to buy the official boards.
I am aware of many significant challenges in porting to Raspberry Pi 5 so I continue to develop on the Pi 4. Our friends over at Zynthian are beavering away at resolving these issues and we will benefit from their had work.
Design is nearing completion for the generic panel PCB revision 3. I hope to complete the design and send it for fabrication this week.
Firmware for the Brain interface is mostly tested but the audio processing is yet to be developed beyond the PoC (which works but I want to see substantial improvement).
1 Like
I thought I had the PCB design complete then realised the physical positioning of the controls was not consistent so have moved stuff around which has delayed the PCB design again!
I am placing the controls on a grid based on 0.1" spacing. (Previously it was metric spacing - but inconsistent.) Although eurorack is mostly metric it is still derived from imperial measurements and through hole components tend to be based on 0.1" division so it may be more flexible to use this spacing, e.g. a prototype or DIY board might be built on prototyping board which is likely to have this spacing. You would be able to build a panel on prototyping board and use a standard (or maybe generic) front panel and spacer to mount into a eurorack.
1 Like