Modular idea

[wayland]

Hi!

I see that you've recently released 3.1.0; a quick skim over the schematic revealed the main change to be that you've replaced the earlier MCUs with a Raspberry Pi 2040 (though the analogue ports seem to have seen some work too).

I wanted to suggest an idea that came to me while I was attempting to design something that would do what I wanted. However, it's a multi-part idea that came to me in stages; I'll try to replicate my thought process here so that you'll understand what I'm thinking.

My first thought was to separate the OpenDeck board into multiple boards, so that it'd be easier to use different versions of it. I'm sure you recall this from our previous discussion. The basic idea was:

• 1 base board with the MCU, ports, and other central facilities
• 1 or more modular addon boards

The goal here was to give us variations without having to redesign the whole thing.

The next thought came while I was having my smartphone repaired. The USB-C port was flaky, and I discovered in interacting with the repairman that my smartphone has a separate board containing only the USB-C socket, the audio socket, and a couple of ancillary chips. This means that these parts, which are some of the most likely to fail, can be easily fixed simply and cheaply by replacing the ports board with a working one, rather than having to solder or anything like that.

So I started redesigning my variation on the board to have a separate ports board.

Having done that, I found that I had very little left on the baseboard. So I had the following breakdown:

Ports board:

• MIDI out/DMX out, with a TXB0104PW (to ensure we're at 5V), and the MAX485E
• MIDI in and 6N137
• 5V-to-3.3V conversion (SPX3819M5)
• 5V-5V conversion (RFM-0505)
• 5V and 3.3V jumper headers
• External USB in, internal 2xUSB out (so I could power an extra 5V device from the extra USB port)
• Power-over-Ethernet port (so I could operate from PoE instead of USB if desired)

Base board:

• MCU sockets (Black Pill or Nano 33)
• Traffic lights
• I2C and touchscreen headers
• A 74HC138 for the button columns (the rows are on the breakout boards)
• Ribbon cable to ports board
• Ribbon cable to Breakout board

At this point I was wondering whether it was worth making separate boards for them, but then I ran across your 3.1.0 design, and came to the following realisation.

If the board had originally been designed in this 3-part manner (Ports, Base, and Breakout), then:

• When I wanted to redesign things, I would only have had to redesign the breakout board; the ports board and base board would've been fine (though if I wanted PoE I would've had to redesign the ports board)
• When you did your 3.1.0 design, you would only have had to redesign the base board and the breakout board; the ports board could've remained untouched.

The reasons I can see for not opting for this breakdown are:

• Space -- if you're trying to get it in a small space, then one board is better
• Economy of $ in the short term -- if there are no ribbon cables, you don't have to pay for them or the headers
• Redesign freedom -- if it's all on the one board, then there's no reason not to change anything you feel like changing

The reasons I can see in favour are:

• Increased flexibility/modularity
• Possibly more focussed/quicker design times
• Possibly developing an ecosystem of boards

Interested in hearing your feedback on this idea.

[wayland]

Update: It seems that in 3.1.0 you got rid of DMX as well. Is this because it was incompatible with the touchscreen? Was it not possible to use multiple devices on the one SPI bus, and just use chip select lines?

[paradajz]

Update: It seems that in 3.1.0 you got rid of DMX as well. Is this because it was incompatible with the touchscreen? Was it not possible to use multiple devices on the one SPI bus, and just use chip select lines?

No, it was because it was too much work to support on various MCUs and because I've moved most of the low-level UART implementation to my core library which makes DMX support quite difficult. On most MCUs, DMX support requires hooking up to UART interrupts which my library doesn't expose at the moment. And finally, I haven't heard of anyone using DMX on OpenDeck, so...

[wayland]

Right! That makes sense. I noticed in the meantime a comment where you said you'd be willing to add it back (or presumably accept PRs) if people were keen and you could think of a way to implement it that you liked. I can live with that.

[wayland]

New idea: we divide the whole thing into:

• Motherboard (previously Base Board): Talks to all the ports; includes PoE for MIDI-over Ethernet (SPI0). Oh, and traffic indicators.
• Cards (previously Breakout Boards): Contain another RP2040, and all the button/LED/analogue stuff. Talks to motherboard using:
  • SPI (use SPI1 on Motherboard, SPI0 on Card)
  • QSPI (reading flash memory, if relevant)
  • GPIOs being used as SPI chip select lines, so that we could select different cards

That should give us a lot of flexibility in communication between the motherboard and the cards.

HTH,

[paradajz]

I've read your posts and to be completely honest - I have no idea what am I supposed to comment on? I mean, if you want to make your own modular board then you can take whatever approach you want since the design files are available. As far as my own designs go - I don't want modular approach because that then includes either cables or pin headers and I want everything on a single PCB without the need of any modifications (modular = more boards = increased cost + time to assemble). I generally just want to plug the board to a PC, flash it and ship it. Having it all on a single PCB makes the system very tidy and compact.

Cards (previously Breakout Boards): Contain another RP2040, and all the button/LED/analogue stuff. Talks to motherboard using:

• SPI (use SPI1 on Motherboard, SPI0 on Card)
• QSPI (reading flash memory, if relevant)
• GPIOs being used as SPI chip select lines, so that we could select different cards

What would be the reason for this? To make this work would require significant changes to the firmware.

[wayland]

Regarding your question as to what you're supposed to comment on, this is the kind of post I thought was your most likely response, though there was some chance you'd be interested in the idea for yourself as well.

Regarding the breakout boards:

• I am hoping that it will all work from the one flash, so the plug/flash/ship model might be the same, except that you'd have to put some extra boards in the box.
• Agreed about increased costs; that's a definite drawback to the design. Especially now that I've added a PoE module to my design (for MIDI-over-Ethernet).
• According to internet discussions, apparently RP2040 will happily boot via regular SPI, so I can eliminate the QSPI lines, but I'm going to need 2 GPIOs per card (one for chip select/RUN from the motherboard, and one for the card to send an Interrupt back)

Agreed it'd require significant changes to the firmware. My hope was to get some kind of MIDI-over-SPI thing going as one of the ways to communicate between the boards (but there'd have to be other methods too).

The advantages I'm hoping for include:

• I only have to use the components I want; I need mostly buttons with LEDs inside (say 64-128 of these) and a number of extraneous LEDs (probably 30 of these), but only one analogue input (a knob). The modular design would let me cut down on the number of analogue inputs, which would save me some money, and increase the number of LED outputs (which would be handy).
• Quick redesign: If the motherboard is always the same, but people want to do something with the pin I/O, this would give them the flexibility; they could design a specialised pin I/O board, and leave the motherboard the same. Logically the thing to do would be to also modularise the I/O ports (DIN, USB, etc), but I don't see that as being as useful as it appears on the surface, at least for me; I'm open to the possibility of putting the Ethernet module on a separate board (since it's got a fair bit of circuitry), but for the others, I'm not sure we'd save enough to make it worthwhile.
• Obviously the extra features I've designed in, especially the PoE setup, but that's not directly related to the modularity, that's a side issue.

HTH,