Introducing Custom Boards

[ohmtech-rdi]

Today, Eurorack-blocks is built around the concept of board. A board mediates between the UI and the Daisy Patch Submodule, by expanding the features of the latter. Technically a board like kivu12 is just a set of pin headers, which forward or retrieve signals from a back board. The back board stuffs as many features as possible, to match all potential features of any digital module for a given HP width, at least conforming to what ModularGrid returns about digital modules for a specific width.

Today a Eurorack-block module is composed of 3 parts, the front PCB holding the user interface, the back board like kivu12 and finally the Daisy Patch Submodule.

While the kivu12 is OK for prototyping quickly, and is reusable, it has some limitations:

• While the left and right headers are placed carefully to allow attenuverter to nicely fit, headers are coming in the way in some cases,
• Having 3 boards is OK for prototyping, but:
  • It doesn't fit in some Eurorack cases, so field testing is not optimal when your tester isn't provided with a compatible case,
  • It is not suitable for mass production.

In addition, some companies express their need to use Eurorack-blocks, but suitable for mass production.

For this we are introducing "custom boards" which allows, in a nutshell, to "merge" the UI component PCB that Eurorack-blocks was already producing, with the back board, which typically contains multiplexers and demultiplexers.

We've just merged part of this feature so companies could use it now, but there is still no documentation for it. What it does is add a syntax in erbui to add inline boards, where the fields are the same in the board definition.py file, but in the erbui style rather than python style.

Here is what it looks like:

module XXX {
   material aluminum

   board {
      class "BoardXXX"
      include "BoardXXX.h"
      pcb "board/xxx.kicad_pcb"
      width 16hp
      pins P1..14 Pot, Trim { bind "p({index-1})" }
      pins CI1..7 CvIn { bind "ci({index-1})" }
      pins AI1..2 AudioIn { bind "ai({index-1})" }
      pins AO1..2 AudioOut { bind "ao({index-1})" }
      pins L1..2 Led { type dac bind "l({index-1})" }
      pins B1..2 Button { bind "b({index-1})" }
      pin GI1 GateIn { bind "gi(0)" }
   }

   route manual

This is exactly like kivu12 python definition except you have it inline in the code.

Also you can notice the syntactic sugar pins P1..14 Pot, Trim { bind "p({index-1})" }: it expands from P1 toP14, which accept (in the original definition) controls of kind Pot and Trim and bind to an expression "p({index-1})". What is in those {} is evaluated when parsing the board. index here is the index of the pin, so here ranging from 1 to 14 (that we map back to a 0-based indexes).

This feature was quite made on a rush, but seems to fit the need.

Any opinion on it? Ways to improve it? Please comment below!

[ohmtech-rdi]

Trying it myself, you really need to plan your routing proper before you start to route. Since the entire board is regenerated, it's not very good at diffing.

Also, since it's regenerated, it's extremely important to save your work. For this, since artifacts is most likely in your .gitignore you need to force the board addition by executing something like:

$ git add -f artifacts/hardware/mymodule.kicad_pcb

The most annoying part of diffing is probably not being able to do pin swapping from a .net file. For this today you can just pin swap directly in the .kicad_pcb by changing the net of a pad, but later I think I'll generate a KiCad .net file so one can reload the .net file for pin swapping.

Apart from that, works like a charm from my (maintainer) perspective 🙂

[ohmtech-rdi]

The solution to that is written into the problem description. Ideally we want to merge the routing work and changes from the erbui file or custom board, so we need a way to find a good way to merge.

All components have a unique way to be identified (either by designator or timestamp), so that's one way to track changes.
Probably the only problem is when the custom board includes traces, as there is no way to know the identity of a trace (and using the content as identity is brittle, as we might change traces), and same goes with copper planes.

So:

• Either the target file doesn't exist and we generate it like we currently do,
• Or the target file does already exist and we merge the changes, taking into account only components.

This will allow to do pin swapping or changing the custom board layout without having to reroute everything, and without the need for the net file.