I feel I must forewarn you that working with XMOS is a REAL PIG! A feeling that is not just shared by my software team but everyother team we work with who has experienced the "joys" of working with XMOS.
XMOS documentation is terrible - like REALLY truly awful... Once you start to work with XMOS you will find things dont work as described (or not described as is more often the case), only to find its not documented or incorrect..
Due to the lack of hardware peripherals even a simple serial port ends up taking one core.... due to the architecture the XMOS has no interrupts, I cannot recall what XMOS call there equivalents - but they are useless in practice... Due to the lack of real interrupts, a simple 32KHz IR decoder requires - you guessed it, a core... Communications between tiles is via channels... good luck working with these...
I/O's are really useless, limited one bit ports, most are 4 or 8 bit ports.. in fact many pins are not available due to the internal USB PHY connected to various ports... practically half the I/O's end up being unusable due to one reason or another.. then if they are on different tiles you have to use channels to control them... If you dont already know about XMOS Channels... well the first thing to know is that they are Pigs to work with...
The XMOS debugger tools (Xscope or some such) - only works occasionally, there whole development software environment is really poor. The compiler is very hit or miss.. complies sometimes, then next time even without code change will not... Your NEVER sure if your hunting down a genuine software bug - or almost just as often its a random compiler issue...
Install the latest compiler / development tools and it breaks your "working code"... then pile on the extra days hunting down the latest "bug" twist...
Forget about getting any support from XMOS, they seem to have moved on and and IMO now only seem to care about there "Amazon Alexa" Voice command products... Now that they are playing with the big guys, HiFi USB applications are not worth the support hassle... not that support was great before...
If it where not for the Legacy USB audio drivers then we would use an ARM core without a moments thought...
The number of times we sit down over drinks with other company's working with XMOS and the conversation inevitably starts on how bad working with XMOS is, rarely in life is there such a universal agreement about a common shared experience!
At Munuch I bumped into a company who had developed a highend ESL headphone system and noticed that they where driving an OLED display panel (in fact it was a really decent LCD panel) directly from the XMOS (as we do with one of our designs). Knowing how hard this was for us to implement, I got speaking with there MD and ended up reassuring him that his software team who had struggled for over a year with the XMOS where not incompetent - that there struggles really was NOT there fault... He seem much happier after we spoke... I guess its nice sometimes to have confirmation from an independent 3rd party...
Last edited:
Wow! This feedback is pure gold, thank you so much.
I had a good experience interacting with them on their developer forum four years ago, but I have never actually used their product for a real project, and everything you wrote makes a lot of sense to me. I can totally see how their relatively recent discovery of a lucrative market would make them forget about the little guys.
With that in mind, the question becomes: what are my alternatives? All I need is:
- USB interface
- I²C interface
- 12 GPIOs
- Support for standard audio protocols
I am not planning to use the XMOS chip to drive any peripherals like OLED displays or controls. For these, everything will be done with a microcontroller or an ARM chip. And the fact that XMOS does not have interrupts is actually part of the appeal: this is what makes the chip suitable for audio processing.
But I am totally willing to consider alternatives. Any suggestions?
It seems your more of software guy, so I suggest buying one of those HK DiY XMOS boards and try working with the XMOS software environment / development tools, see how you get on 
Otherwise, there are plenty of cheap ARM cortex processors thesedays with internal USB 2.0 PHY.
Thesycon are developing a solution based on the ST STM32H743 (32-bit Arm Cortex-M7 CPU)
U-HEAR – USB High-end Audio Receiver Firmware Solution
Otherwise, there are plenty of cheap ARM cortex processors thesedays with internal USB 2.0 PHY.
Thesycon are developing a solution based on the ST STM32H743 (32-bit Arm Cortex-M7 CPU)
U-HEAR – USB High-end Audio Receiver Firmware Solution
It seems your more of software guy, so I suggest buying one of those HK DiY XMOS boards and try working with the XMOS software environment / development tools, see how you get on
Otherwise, there are plenty of cheap ARM cortex processors thesedays with internal USB 2.0 PHY.
Thesycon are developing a solution based on the ST STM32H743 (32-bit Arm Cortex-M7 CPU)
U-HEAR – USB High-end Audio Receiver Firmware Solution
If everything can be done with a chip like the STM32H743, I would much rather go that way quite frankly. I did not know about the U-HEAR firmware, and I did not want to have to build something like that myself, so this looks quite attractive. What would be the downside?
I really suggest to try working with XMOS first, there are plenty of cheap XMOS boards available where you can try your hand with the code...
While its not pleasant to work with XMOS, we now have so much experience with it that we almost use it by default... We also work with code from MQA for the XMOS, so we stay safe... basically it "Can Work" but its just SOOO painful!!!!
Last week we issued two new PCB designs using XMOS, and already Jarek (who works on the software) is crying about having to work again on the XMOS, hes says its like the feeling of returning to school after the summer holidays, you try not to think about it - but it arrives too soon anyway......
Poor Jarek!!! While hes dreading working on the software, I'm really excited to work with the hardware (I'm a hardware guy) and listen to the designs ASAP
While its not pleasant to work with XMOS, we now have so much experience with it that we almost use it by default... We also work with code from MQA for the XMOS, so we stay safe... basically it "Can Work" but its just SOOO painful!!!!
Last week we issued two new PCB designs using XMOS, and already Jarek (who works on the software) is crying about having to work again on the XMOS, hes says its like the feeling of returning to school after the summer holidays, you try not to think about it - but it arrives too soon anyway......
Poor Jarek!!! While hes dreading working on the software, I'm really excited to work with the hardware (I'm a hardware guy) and listen to the designs ASAP
Last edited:
I will play with a handful of XMOS boards no matter what, but your comments give me pause. The project is complex enough that I do not really want to deal with a flaky toolchain. I have so much to learn that it's really important that I can trust the underlying framework...
I’d much prefer using a Cortex M over this XMOS junk, but the Thesycon solution won’t be free and requiring a 400 MHz Cortex M7 for simple USB audio seems crazy, but might be due to I/O limitations. I guess the good news is that they wrote the driver Microsoft adopted/licensed for UAC 2.0 in Windows, so it should work without issues.
All of the available USB Audio Class 2.0 options are a bit sad in some ways. CMedia is using an 8051 core with some I2S peripherals but you get no JTAG and some other annoyances.
Writing your own presents some challenges in terms of high res and DSD output if you care about that. Most Cortex M MCUs with I2S peripherals are limited to 192 kHz sample rate or at least it’s questionable if they work at 384 or 768.
All of the available USB Audio Class 2.0 options are a bit sad in some ways. CMedia is using an 8051 core with some I2S peripherals but you get no JTAG and some other annoyances.
Writing your own presents some challenges in terms of high res and DSD output if you care about that. Most Cortex M MCUs with I2S peripherals are limited to 192 kHz sample rate or at least it’s questionable if they work at 384 or 768.
We're definitely on the same page. The ST MCU might be overkill for what we need, but it's actually half the cost of the large XMOS that we were planning to use, and it's a lot more versatile. In fact, we could use it for most of our bricks, and I really like the idea of having a single MCU that could be used for everything. I also like the fact that most Mutable Instruments' modules are built using ST chips, which would make the porting of their open source code that much easier...
As far as licensing is concerned, I'll need to talk to Thesycon, but I doubt that it will add much to our BoM.
The more I'm thinking about it, the more I like this option...
Last edited:
NUCLEO-H743ZI
The STM32H743ZI MCU has the advantage of having a low-cost ($27) evaluation board with detailed schematic: NUCLEO-H743ZI.
The STM32H743ZI MCU has the advantage of having a low-cost ($27) evaluation board with detailed schematic: NUCLEO-H743ZI.
STM32H743ZI Redesign
I am in the process of redesigning the USB and DAC boards around the replacement of the XMOS chip by the STM32H743ZI MCU. Because this chip is so versatile, we will try to expose as many pins as possible, so that we could use it to drive all our bricks (not just the DAC one). To do so, we will move from the two side connectors that we were using so far, to a single connector (or set of connectors) located on the South side of the board. For this connector, we have two main options: either a 0.6mm pitch 80-pin Hirose connector, or 4 rows of 16 × 2mm pitch headers. The former would give us more pins (80 vs. 64) while using less space, but the latter would be cheaper and more DIY-friendly.
One of the many questions raised by this redesign is where we should put our Si86xx Digital Isolators: on the USB board still, or on the DAC board? We were planning to use 3 chips giving us a total of 18 isolated channels, and we could put these chips on either board, but they will be useful only when used in combination with the DAC board, therefore we are tempted to put them on the latter.
For both boards, we will start with an 8-layer design (Cf. PCB Stack-Up):
1. Signal(H1)
2. Ground
3. Signal (V1)
4. Ground
5. Power
6. Signal (H2)
7. Ground
8. Signal (V2)
And we'll move to 10 layers if we can't make it work with 8.
I am in the process of redesigning the USB and DAC boards around the replacement of the XMOS chip by the STM32H743ZI MCU. Because this chip is so versatile, we will try to expose as many pins as possible, so that we could use it to drive all our bricks (not just the DAC one). To do so, we will move from the two side connectors that we were using so far, to a single connector (or set of connectors) located on the South side of the board. For this connector, we have two main options: either a 0.6mm pitch 80-pin Hirose connector, or 4 rows of 16 × 2mm pitch headers. The former would give us more pins (80 vs. 64) while using less space, but the latter would be cheaper and more DIY-friendly.
One of the many questions raised by this redesign is where we should put our Si86xx Digital Isolators: on the USB board still, or on the DAC board? We were planning to use 3 chips giving us a total of 18 isolated channels, and we could put these chips on either board, but they will be useful only when used in combination with the DAC board, therefore we are tempted to put them on the latter.
For both boards, we will start with an 8-layer design (Cf. PCB Stack-Up):
1. Signal(H1)
2. Ground
3. Signal (V1)
4. Ground
5. Power
6. Signal (H2)
7. Ground
8. Signal (V2)
And we'll move to 10 layers if we can't make it work with 8.
Last edited:
Mikroe Fusion Board
In order to facilitate the development of our USB board, we will do all our prototyping using a Mikroe Fusion board. It comes standard with an MCU card for the STM32F407ZG, and we will develop our own for the STM32H743. The form factor for the Mikroe MCU cards is quite a bit larger than the 35mm × 35mm that we have in mind for our USB board, but this will allow us to debug everything at a larger scale before we scale things down to the level that we are shooting for.
This approach will also allow us to learn how pins should be grouped in a logical fashion, and to finalize the number of pins that we want to expose on our USB board. Last but not least, the Fusion board will also make it a lot easier to prototype many of our bricks using some Click Boards.
In order to facilitate the development of our USB board, we will do all our prototyping using a Mikroe Fusion board. It comes standard with an MCU card for the STM32F407ZG, and we will develop our own for the STM32H743. The form factor for the Mikroe MCU cards is quite a bit larger than the 35mm × 35mm that we have in mind for our USB board, but this will allow us to debug everything at a larger scale before we scale things down to the level that we are shooting for.
This approach will also allow us to learn how pins should be grouped in a logical fashion, and to finalize the number of pins that we want to expose on our USB board. Last but not least, the Fusion board will also make it a lot easier to prototype many of our bricks using some Click Boards.
Relaxing size constraints
In light of the most recent comments, I think we should relax our size constraints: instead of trying to cram 2 DAC boards and 2 USB boards within a single brick, one of each should be plenty enough. This would give each board a much more reasonable 70mm × 70mm footprint, which should allow us to avoid any tradeoff that could negatively affect sound quality. And while it won't allow us to provide a dual mono brick powered by two AK4499EQ chips, it will still allow us to provide a quad mono brick powered by a single AK4499EQ and a single mono equivalent.
Going down that path, we could then consider using a Mikroe MCU for ST32 card for our USB board. This would give us the following stack:
3. DAC board connected to PSU board
2. MCU board connected to DAC board
1. PSU board with USB and DC ports
This configuration is quite different from what we had originally imagined, but I think it makes a lot more sense, for several reasons:
First, having one board deal with both power and USB connectivity would make it a lot easier to get power either from the USB port or from a separate DC port, like is done by the power supply module of the Mikroe Fusion board.
Second, having the MCU board directly connected to the DAC board through two 168-pin Hirose connectors would give the DAC board or any brick-specific board a ton of connectivity for supporting all kinds of applications.
Third, building all this on top of an established pair of connectors that supports 852 different ST chips is quite comforting.
Fourth, while Mikroe does not provide an MCU card for the STM32H743 yet, they should be able to produce one easily, and if they don't feel like it, making our own should be relatively easy, as can be seen on the schematic for the STM32F429ZI.
Now, there is something else that Mikroe can give us: the mikroBUS standard. For the sticks that will go into our bricks, this bus is actually quite nice and provides the following:
- SPI
- UART
- I²C
- PWM
- Interrupt
- Analog Input
- Reset
- Chip Select
- +3.3V / GND
- +5V / GND
While the DAC board won't use it, most other brick-specific boards could really take advantage of it by providing 4 or 6 mikroBUS sockets. Doing so, some Click Boards could be used out of the box to create some really cool bricks, like the Knob G Click (three of them would fit within a brick).
In order to focus our efforts on what really matters, this architecture relying on more off-the-shelf components is quite attractive, especially for a v1.
With that in mind, I have ordered a few components to build some prototypes.
In light of the most recent comments, I think we should relax our size constraints: instead of trying to cram 2 DAC boards and 2 USB boards within a single brick, one of each should be plenty enough. This would give each board a much more reasonable 70mm × 70mm footprint, which should allow us to avoid any tradeoff that could negatively affect sound quality. And while it won't allow us to provide a dual mono brick powered by two AK4499EQ chips, it will still allow us to provide a quad mono brick powered by a single AK4499EQ and a single mono equivalent.
Going down that path, we could then consider using a Mikroe MCU for ST32 card for our USB board. This would give us the following stack:
3. DAC board connected to PSU board
2. MCU board connected to DAC board
1. PSU board with USB and DC ports
This configuration is quite different from what we had originally imagined, but I think it makes a lot more sense, for several reasons:
First, having one board deal with both power and USB connectivity would make it a lot easier to get power either from the USB port or from a separate DC port, like is done by the power supply module of the Mikroe Fusion board.
Second, having the MCU board directly connected to the DAC board through two 168-pin Hirose connectors would give the DAC board or any brick-specific board a ton of connectivity for supporting all kinds of applications.
Third, building all this on top of an established pair of connectors that supports 852 different ST chips is quite comforting.
Fourth, while Mikroe does not provide an MCU card for the STM32H743 yet, they should be able to produce one easily, and if they don't feel like it, making our own should be relatively easy, as can be seen on the schematic for the STM32F429ZI.
Now, there is something else that Mikroe can give us: the mikroBUS standard. For the sticks that will go into our bricks, this bus is actually quite nice and provides the following:
- SPI
- UART
- I²C
- PWM
- Interrupt
- Analog Input
- Reset
- Chip Select
- +3.3V / GND
- +5V / GND
While the DAC board won't use it, most other brick-specific boards could really take advantage of it by providing 4 or 6 mikroBUS sockets. Doing so, some Click Boards could be used out of the box to create some really cool bricks, like the Knob G Click (three of them would fit within a brick).
In order to focus our efforts on what really matters, this architecture relying on more off-the-shelf components is quite attractive, especially for a v1.
With that in mind, I have ordered a few components to build some prototypes.
Last edited:
Why not just use the arm processor to run an SD card for an input(12s)?
I don’t use a usb input anymore on my home reference setup, prefer a more simple and lower powered device than a pc.
Before you procure the nice trial board from akm, you could start playing around with some kits and get a better feel for how the power supplies respond to different passive parts etc.
I don’t use a usb input anymore on my home reference setup, prefer a more simple and lower powered device than a pc.
Before you procure the nice trial board from akm, you could start playing around with some kits and get a better feel for how the power supplies respond to different passive parts etc.
This is a great suggestion! Let me see where we should put the SD card reader. Most likely on the DAC board. And do you want regular SD or microSD?
That is most definitely part of my plan. Whatever can keep me busy until I get the AKM board...
Submodular Form Factor
The adoption of the mikroBUS interconnect has brought some unexpected benefits: it forced us to make our bricks a bit bigger, and by doing so, it made them a lot more modular internally. Here is why.
The base dimension of a mikroBUS Click Board™ is 27.94mm × 28.57mm (1100mil × 1125mil), and two adjacent boards cannot be closer than 1.27mm (50mil). As a result, if we want to put three boards side by side within a brick, we need at least 88.25mm. We could consider limiting ourselves to putting only two boards side by side, but that would mean only 4 boards instead of 9 within a brick. And because the mikroBUS standard mandates 16 pins per board, pin headers end up taking a significant amount of real estate on the board, leaving only 20.32mm × 28.57mm for components, which means that 4 boards are not sufficient to implement the bricks that are required for recreating modules such as the ones offered by Mutable Instruments.
Bottomline: 9 Click Boards™ per brick is the way to go.
Now, 88.25mm is the bare minimum needed, but if we want to leave some room for the extruded aluminum profile used for the brick's enclosure (2mm-thick walls) and a bit of extra padding, 96mm × 96mm seems to be a good target. As a result, this would leave 90mm × 90mm for the DAC board, which is a lot better than the 70mm × 35mm that we were originally shooting for (3.3 times more surface area).
With that in mind, we started to redesign the instruments around custom Click Boards™, and we realized that all Mutable Instruments modules at the exception of two (Elements and Shelves) could be built using nine Click Boards™. Therefore, all modules but two would fit within a single brick, while they used to take two or three before.
As a result, we've decided to adopt this form factor and to change our terminology: what we used to call a "brick" is now called a "block", and what MikroE calls a Click Board™ is now called a "brick". While this might seem a bit confusing at first, there is some method to this madness: with this new design, each brick (aka Click Board™) can be packaged with its own enclosure made of aluminum or plastic. Consequently, each brick comes with its own cover, which means that blocks (nine bricks on a base) do not need any cover. This architecture makes the whole platform modular at three levels:
- Multiple 2 × 3 grids in a setup (12 in this case)
- 6 blocks on a grid
- 9 bricks on a block's base
This architecture is really interesting, because it allows us to pack everything we need for our reference setup by using 12 grids instead of 20, and our grids now host 6 blocks instead of 8, making the USB topology a lot easier to deal with (because of the limitations imposed by most USB hubs).
Of course, much like blocks could be made larger and take more than one spot on a grid, bricks could take more than one socket on a block. In that case, only one mikroBUS socket would be used by the larger brick. But so far, every single brick that we had to design seems to fit within one slot.
Once we had figured all this out, we started to think about the mechanical aspects of the platform. Nine bricks will be mounted on a block's base, and each brick will have 16 × 2.54mm pin headers connecting it to the base. Therefore, for most applications, this should be sufficient for ensuring a solid connection. And because each brick will have its own enclosure, we do not need the block's enclosure to contain them. Instead, we can mount them flush on the block's base, thereby making them 32mm × 32mm.
The block's base itself will be fabricated from two aluminum profiles stacked on top of each other: the bottom one will be hollow and will contain the PSU board and the MCU board; the top one will be hollow when used with a large board like the DAC board, but framed when used with bricks. The internal frame of the top profile used in conjunction with bricks will ensure that bricks have a perfectly flat reference plane to sit on (soldered pin headers cannot provide such a reference plane) and some indexing surfaces to drive conical indexing pins. This approach should make for a very clean assembly, while keeping manufacturing costs at a minimum (aluminum profiles are really cheap to produce once the extrusion die has been amortized).
Last but not least, we've decided to take advantage of this new architecture to make the Sitara SoM fully optional. Here is how it will work: by default, blocks will use the STM32H743 in their base. This MCU is probably overkill for most blocks, but a cost analysis of our instruments shows that it will never amount to more than 5% of the block's total cost. As a result, there is no point trying to support a cheaper component. And for all advanced blocks like the ADC or DAC blocks, it will be perfect.
Optionally, the user will be able to mount the entire block (base and top) on a separate base containing a TI AM5728 Sitara chip. Obviously, this will make the overall block a bit taller (by about 15mm), but it will make it a lot more powerful as well. And from the viewpoint of the underlying grid, nothing should change, as the grid will only see a USB device, sometimes powered by an SoC, and sometimes by an MCU.
The adoption of the mikroBUS interconnect has brought some unexpected benefits: it forced us to make our bricks a bit bigger, and by doing so, it made them a lot more modular internally. Here is why.
The base dimension of a mikroBUS Click Board™ is 27.94mm × 28.57mm (1100mil × 1125mil), and two adjacent boards cannot be closer than 1.27mm (50mil). As a result, if we want to put three boards side by side within a brick, we need at least 88.25mm. We could consider limiting ourselves to putting only two boards side by side, but that would mean only 4 boards instead of 9 within a brick. And because the mikroBUS standard mandates 16 pins per board, pin headers end up taking a significant amount of real estate on the board, leaving only 20.32mm × 28.57mm for components, which means that 4 boards are not sufficient to implement the bricks that are required for recreating modules such as the ones offered by Mutable Instruments.
Bottomline: 9 Click Boards™ per brick is the way to go.
Now, 88.25mm is the bare minimum needed, but if we want to leave some room for the extruded aluminum profile used for the brick's enclosure (2mm-thick walls) and a bit of extra padding, 96mm × 96mm seems to be a good target. As a result, this would leave 90mm × 90mm for the DAC board, which is a lot better than the 70mm × 35mm that we were originally shooting for (3.3 times more surface area).
With that in mind, we started to redesign the instruments around custom Click Boards™, and we realized that all Mutable Instruments modules at the exception of two (Elements and Shelves) could be built using nine Click Boards™. Therefore, all modules but two would fit within a single brick, while they used to take two or three before.
As a result, we've decided to adopt this form factor and to change our terminology: what we used to call a "brick" is now called a "block", and what MikroE calls a Click Board™ is now called a "brick". While this might seem a bit confusing at first, there is some method to this madness: with this new design, each brick (aka Click Board™) can be packaged with its own enclosure made of aluminum or plastic. Consequently, each brick comes with its own cover, which means that blocks (nine bricks on a base) do not need any cover. This architecture makes the whole platform modular at three levels:
- Multiple 2 × 3 grids in a setup (12 in this case)
- 6 blocks on a grid
- 9 bricks on a block's base
This architecture is really interesting, because it allows us to pack everything we need for our reference setup by using 12 grids instead of 20, and our grids now host 6 blocks instead of 8, making the USB topology a lot easier to deal with (because of the limitations imposed by most USB hubs).
Of course, much like blocks could be made larger and take more than one spot on a grid, bricks could take more than one socket on a block. In that case, only one mikroBUS socket would be used by the larger brick. But so far, every single brick that we had to design seems to fit within one slot.
Once we had figured all this out, we started to think about the mechanical aspects of the platform. Nine bricks will be mounted on a block's base, and each brick will have 16 × 2.54mm pin headers connecting it to the base. Therefore, for most applications, this should be sufficient for ensuring a solid connection. And because each brick will have its own enclosure, we do not need the block's enclosure to contain them. Instead, we can mount them flush on the block's base, thereby making them 32mm × 32mm.
The block's base itself will be fabricated from two aluminum profiles stacked on top of each other: the bottom one will be hollow and will contain the PSU board and the MCU board; the top one will be hollow when used with a large board like the DAC board, but framed when used with bricks. The internal frame of the top profile used in conjunction with bricks will ensure that bricks have a perfectly flat reference plane to sit on (soldered pin headers cannot provide such a reference plane) and some indexing surfaces to drive conical indexing pins. This approach should make for a very clean assembly, while keeping manufacturing costs at a minimum (aluminum profiles are really cheap to produce once the extrusion die has been amortized).
Last but not least, we've decided to take advantage of this new architecture to make the Sitara SoM fully optional. Here is how it will work: by default, blocks will use the STM32H743 in their base. This MCU is probably overkill for most blocks, but a cost analysis of our instruments shows that it will never amount to more than 5% of the block's total cost. As a result, there is no point trying to support a cheaper component. And for all advanced blocks like the ADC or DAC blocks, it will be perfect.
Optionally, the user will be able to mount the entire block (base and top) on a separate base containing a TI AM5728 Sitara chip. Obviously, this will make the overall block a bit taller (by about 15mm), but it will make it a lot more powerful as well. And from the viewpoint of the underlying grid, nothing should change, as the grid will only see a USB device, sometimes powered by an SoC, and sometimes by an MCU.
Last edited:
Everything listed there. Mostly controls, displays, CV ports, and lo-fi audio ports used in noisy modular sound synthesis. All the hi-fi audio should go through the ADC and DAC boards that won't use mikroBUS.
Downstream of mikroBUS (from the MCU's viewpoint), we'll have some entry-level ADCs and DACs for driving the Audio/CV ports, but they do not need to be high quality. I will provide more details on these soon.
Bricks
Following the introduction of our submodular architecture, let's review our bricks. As previously mentioned, these have a 32mm × 32mm footprint and use the mikroBUS interconnect (specification). For the time being, we will focus on single-unit bricks, but multi-unit versions will be added later.
Within a brick, the board is 28.57mm × 27.94mm, but because of the pin headers, the usable area is only 28.57mm × 20.32mm. This postage stamp size footprint will create quite a few challenges for some bricks like the E1 single encoder with LED ring, or the P4 quad Audio/CV port. We will review them in details here.
B1: One Button
Because all our controls must be soft controls in order to be properly handled in the digital domain, all our buttons and switches must have a momentary action, yet they fall into two separate categories:
- Buttons, which do not have a click/detent
- Switches, which have a click/detent
In order to visually differentiate them, buttons will have a round cap, while switches will have a square cap. This will allow users to properly expect the control's behavior by simply looking at it, or by feeling its shape with a finger.
Most bricks will actually use switches instead of buttons, but buttons are needed for manually triggering repetitive actions, like playing a sound. For example, the "Play" button at the top left of the Elements module is a button. The absence of a click/detent serves two purposes:
1. It provides a smoother tactile feedback when used repeatedly.
2. It does not generate any parasitic auditory sound.
By default, all our buttons and switches will be illuminated. For switches, the illumination will indicate the soft button's state (on or off). For buttons, the illumination serves a slightly different purpose: when always on, it provides a useful highlighting of the button on the control surface; when blinking or glowing, it provides some visual feedback in relation to a low-frequency oscillation (very useful for modular sound synthesis).
The circuit for the button board will be very simple, as illustrated on this documentation from MikroE. Borrowing from their website, "when pressed, it will send an interrupt signal to the MCU, while the backlight LED is controlled separately through the mikroBUS PWM pin." The only change we will make to this circuit is to use a button with RGB illumination instead of single-color illumination.
The use of RGB illumination has two primary motivations:
1. Highlighting different functions for the button.
2. Reducing our number of stockkeeping unit (SKU).
The latter is really important, because buttons will be used by at least 8 bricks, and if we have to support multiple illumination colors (Red, Green, Blue, Yellow, White, etc.), the number of SKUs will quickly explode.
The main challenge in developing this brick is in the selection of the mechanical button itself: we will want the right kind of mechanical feedback, which is quite subjective. Mutable Instruments uses the E-Switch LP4OA1PBCTG, but it is not RGB. E-Switch has an RGB alternative with the LP11 Series, but it is only available as a square cap. Bottomline: we're still looking for the perfect button...
For the time being, our analysis of instruments shows that we only need a single-button brick, but we could easily develop versions with 2, 4, or even 9 buttons. MikroE even makes a Click Board™ with 16 buttons (4x4 Click), but it is using an L-size board, instead of the S-size adopted by our bricks.
D1: One Display
With earlier design iterations of our reference setup, we were planning to use a lot of Android smartphones as touchscreens. With this latest iteration, we still do, but fewer of them, and they do not appear on the setup's mockup. The smartphones will be mounted on top of the covers for the ADC and DAC blocks located at the very top of the surface control. We can do that because our blocks (what we used to call "bricks") have become so large, and the ADC and DAC blocks only need to expose four XLR ports. Therefore, we have a lot of space available on their top covers, and we can use this space to fit a USB-C dock. So, in the reference setup, we will have up to 12 smartphones standing tall in front of our XLR cables.
Throughout the rest of the control surface, we will use small color and monochromatic OLED displays in order to provide useful visual feedback for some controls, especially the small encoders that do not have any LED ring. These displays will be small because they need to fit within a single-unit brick, and because we do not want to waste any time developing complex MCU-controlled user interfaces. Instead, these should be developed using the modern tools offered by the Android platform.
The other benefit of this approach is that it will turn our DAC block into a great smartphone dock, letting the user play music through the DAC from a phone, without having to use any PC. As a result, we do not need to put an SD card slot within the DAC block anymore. This part of the project is really important: while we are developing a crazy reference setup that very few people will ever build (I might very well be the only one being excited by such a thing), we want to make sure that some components of the project (the DAC especially) can be used by other people, in a standalone fashion.
Coming back to the D1 display brick, this brick will have a square OLED display like the one used by the OLED C Click. This display has a 96 × 96 resolution, but we will try to use something a bit better down the road. That being said, this is a fairly complex board, and we won't spend too much time on it initially, because it will be used by only 3 of our 23 planned instruments.
The main challenge in developing this brick will consist in making everything fit within an S-size board (the MikroE Click Board™ is again using the L-size form factor). This should not be too difficult though, because the OLED C Click does not have any component on the board's backside, and all the components (at the exception of the screen itself) seem to fit within an S-size footprint, while the screen component is connected to the board through a flexible printed circuit (FPC) connector. Therefore, all we will have to do is to figure out a way to properly mount the screen on top of the brick's PCB.
This work will mostly affect the overall height of the brick, and this is something that we will find with many other bricks. In other words, depending on the components hosted by the brick (button, display, encoder, port, etc.), the height required above the PCB will vary, but we will want all our bricks to have exactly the same height. As a result, some components might need an extra spacer, or might be deported through cables, and some others might even be mounted on separate PCBs. With that in mind, we fully expect this type of mechanical engineering challenge to keep us busy for a while...
Finally, on the mechanical front, yet another challenge will be to design a proper enclosure for this type of brick. What makes it difficult is that we will want the screen's glass to be flush with the brick's cover. Therefore, a square or rectangular opening will have to be cut on the cover, which is much more difficult that drilling a round hole for a button with a round cap or for an encoder.
If we were planning to make this type of product in large quantities, we would go with plastic injection moulding. But for prototyping or low-volume production, we might have to go with aluminum machining. Last year, I received some training as a manual and CNC machinist at a local community college, working with both lathes and mills, and this part of the project really excites me, but it could make BoM costs explode rapidly. Therefore, we need to find out if we can source such components at a low cost in China before we commit to any design.
E1: One Large Encoder with LED Ring
The E1 single encoder with LED ring brick will be one of the most interesting bricks to develop. Originally, I was a bit reluctant to go down the LED ring path, but the single-encoder brick will be used by 14 out of our 23 planned instruments, and we will need 54 of them for our reference setup. Therefore, it is a very important brick, and the LED ring can provide great visual feedback when properly implemented.
The reason for my reluctance was motivated by space constraints: it is really difficult to fit 24 LEDs around a rotary encoder within a square inch, but MikroE did it successfully with the Knob G Click. Of course, they are again relying on an L-size form factor, but we should have no problem doing the same on our S-size form factor by stacking two PCBs (one for the mikroBUS interface and driver IC, and one for the encoder and LED ring).
MikroE also provides a 16-LED version with different color options for the LEDs (e.g. Rotary G Click), but 24 LEDs provides a much more precise visual feedback. In our case, we will probably offer two options: blue (for input levels) and green (for output levels). Also, we will add the push-button functionality offered by the Rotary Click, and we will probably make the encoder itself RGB illuminated in order to provide an additional level of visual feedback.
One question we still need to answer is the interconnect between the two PCBs: we could either go for a single FPC connector, or a pair of Hirose connectors. The former would be cheaper, but the latter would kill two birds with one stone, by offering both electrical connectivity and mechanical assembly. This question will need to be answered for other bricks as well, and we will probably settle on a generic answer once we have a better idea all the mechanical constraints that we have to deal with.
E2: Two Medium Encoders
Many instruments need a brick with two encoders. Unfortunately, we cannot fit two encoders with LED rings within a single-unit brick. Therefore, this brick will have two medium encoders without any LED ring, and the encoders will be diagonally staggered in order to fit within a single square inch of space. As a result, it won't provide any direct visual feedback, making it unusable without an external display (either a D1 display brick or a smartphone). For this reason, we are not planning to use this brick for any of our instruments. Instead, we will use the D1E2 brick, which provides two small encoders underneath a small OLED display (see below).
E3: One Medium Encoder and Two Small Encoders
This brick will have a medium encoder on top of two small encoders mounted side by side. Much like the E2 brick, it won't be usable without an external display, but a couple of instruments did not give us any alternative if we wanted to fit everything within a single-unit block. And once we have a better understanding of all the bricks available to us, we might find a better solution.
M1: One MIDI Port
This brick will provide a single MIDI port with a 5-pin DIN connector. Support for alternative connectors will be added down the road, and we're following the development of the MIDI 2.0 standard with great interest. This brick will be inspired by the SparkFun MIDI Shield for Arduino and will be opto-isolated. But unlike the SparkFun board, it will allow a single 5-pin DIN connector to be used either for MIDI In or MIDI Out.
P2, P4: Two or Four Audio/CV Ports
The P2 and P4 dual and quad Audio/CV bricks are probably the most challenging ones that we have to develop, for several reasons. But before we dive in, let me explain what these bricks do: they provide 2 or 4 hybrid ports using 3.5mm stereo TRS connectors. The mono version of this connector is used by Eurorack modular synthesizers for three main types of signal:
- Audio signals (-5V to +5V)
- Control voltages (-2.5V to +2.5V or 0V to 8V)
- Trigger, gate, or clock signals (0 to 5V)
Eurorack modules are typically powered by a dual rail 12V DC power supply.
In our case, we will use stereo jacks in order to carry audio signals or control voltages on the left channel and digital signal signatures on the right channel. Doing so, we will be able to use stereo cables to connect any of our P2/P4 bricks to external Eurorack modules, which will leave the right channel (ring of the TRS connector) unconnected (open circuit) on the Eurorack side. We will also be able to use mono cables to do the same, which will ground the ring (right channel) of the socket on the P2/P4 brick side.
Most importantly, we will want any port to be able to handle any of the six following functions:
- Audio input
- Audio output
- Control input
- Control output
- Trigger input
- Trigger output
And we want to fit 4 of these within a single square inch!
Fortunately, we are not trying to get any decent sound quality out of these ports. Nevertheless, we will still try to make them as good as we can. On the audio side, we will shoot for 24-bit/96kHz. On the CV side, we're still trying to figure out what a reasonable target should be.
The brick will be built around two PCBs: one for the mikroBUS interface and ADC/DAC chips, and one for the TRS connectors. Ideally, we will find suitable quad-channel ADC and DAC chips that will allow us to implement both Audio and Control inputs and outputs from a single pair of ADC/DAC chips (suggestions are welcome).
The remaining challenge will be the +12V DC power supply that we need. Unfortunately, the mikroBUS only gives us +5V, therefore we will have to go beyond the standard by adding a couple of pins (+12V and GND) to our brick interconnect. In order to remain as close as possible to the standard and to prevent any incorrect brick insertion, we will add both pins on the left side, with the +12V pin above the AN pin (at the very top), and the GND pin below the existing GND pin (at the very bottom). Of course, only the boards that need this power supply will use these pins, making all other boards perfectly compatible with the mikroBUS standard.
Finally, we will try to add three bi-color blue-green LEDS next to each TRS port, allowing us to visually indicate the port's function:
1-blue: Audio Input
1-green: Audio Output
2-blue: Control Input
2-green: Control Output
3-blue: Trigger Input
3-green: Trigger Output
Whether we will have enough space on the brick's cover to cram all this remains to be seen.
This brick is probably the most important one that we have to develop, because it will largely condition the user-friendliness of the control surface for modular sound synthesis, therefore we expect to spend quite a bit of time refining it.
This post is already way to long, therefore other bricks will have to wait...
Following the introduction of our submodular architecture, let's review our bricks. As previously mentioned, these have a 32mm × 32mm footprint and use the mikroBUS interconnect (specification). For the time being, we will focus on single-unit bricks, but multi-unit versions will be added later.
Within a brick, the board is 28.57mm × 27.94mm, but because of the pin headers, the usable area is only 28.57mm × 20.32mm. This postage stamp size footprint will create quite a few challenges for some bricks like the E1 single encoder with LED ring, or the P4 quad Audio/CV port. We will review them in details here.
B1: One Button
Because all our controls must be soft controls in order to be properly handled in the digital domain, all our buttons and switches must have a momentary action, yet they fall into two separate categories:
- Buttons, which do not have a click/detent
- Switches, which have a click/detent
In order to visually differentiate them, buttons will have a round cap, while switches will have a square cap. This will allow users to properly expect the control's behavior by simply looking at it, or by feeling its shape with a finger.
Most bricks will actually use switches instead of buttons, but buttons are needed for manually triggering repetitive actions, like playing a sound. For example, the "Play" button at the top left of the Elements module is a button. The absence of a click/detent serves two purposes:
1. It provides a smoother tactile feedback when used repeatedly.
2. It does not generate any parasitic auditory sound.
By default, all our buttons and switches will be illuminated. For switches, the illumination will indicate the soft button's state (on or off). For buttons, the illumination serves a slightly different purpose: when always on, it provides a useful highlighting of the button on the control surface; when blinking or glowing, it provides some visual feedback in relation to a low-frequency oscillation (very useful for modular sound synthesis).
The circuit for the button board will be very simple, as illustrated on this documentation from MikroE. Borrowing from their website, "when pressed, it will send an interrupt signal to the MCU, while the backlight LED is controlled separately through the mikroBUS PWM pin." The only change we will make to this circuit is to use a button with RGB illumination instead of single-color illumination.
The use of RGB illumination has two primary motivations:
1. Highlighting different functions for the button.
2. Reducing our number of stockkeeping unit (SKU).
The latter is really important, because buttons will be used by at least 8 bricks, and if we have to support multiple illumination colors (Red, Green, Blue, Yellow, White, etc.), the number of SKUs will quickly explode.
The main challenge in developing this brick is in the selection of the mechanical button itself: we will want the right kind of mechanical feedback, which is quite subjective. Mutable Instruments uses the E-Switch LP4OA1PBCTG, but it is not RGB. E-Switch has an RGB alternative with the LP11 Series, but it is only available as a square cap. Bottomline: we're still looking for the perfect button...
For the time being, our analysis of instruments shows that we only need a single-button brick, but we could easily develop versions with 2, 4, or even 9 buttons. MikroE even makes a Click Board™ with 16 buttons (4x4 Click), but it is using an L-size board, instead of the S-size adopted by our bricks.
D1: One Display
With earlier design iterations of our reference setup, we were planning to use a lot of Android smartphones as touchscreens. With this latest iteration, we still do, but fewer of them, and they do not appear on the setup's mockup. The smartphones will be mounted on top of the covers for the ADC and DAC blocks located at the very top of the surface control. We can do that because our blocks (what we used to call "bricks") have become so large, and the ADC and DAC blocks only need to expose four XLR ports. Therefore, we have a lot of space available on their top covers, and we can use this space to fit a USB-C dock. So, in the reference setup, we will have up to 12 smartphones standing tall in front of our XLR cables.
Throughout the rest of the control surface, we will use small color and monochromatic OLED displays in order to provide useful visual feedback for some controls, especially the small encoders that do not have any LED ring. These displays will be small because they need to fit within a single-unit brick, and because we do not want to waste any time developing complex MCU-controlled user interfaces. Instead, these should be developed using the modern tools offered by the Android platform.
The other benefit of this approach is that it will turn our DAC block into a great smartphone dock, letting the user play music through the DAC from a phone, without having to use any PC. As a result, we do not need to put an SD card slot within the DAC block anymore. This part of the project is really important: while we are developing a crazy reference setup that very few people will ever build (I might very well be the only one being excited by such a thing), we want to make sure that some components of the project (the DAC especially) can be used by other people, in a standalone fashion.
Coming back to the D1 display brick, this brick will have a square OLED display like the one used by the OLED C Click. This display has a 96 × 96 resolution, but we will try to use something a bit better down the road. That being said, this is a fairly complex board, and we won't spend too much time on it initially, because it will be used by only 3 of our 23 planned instruments.
The main challenge in developing this brick will consist in making everything fit within an S-size board (the MikroE Click Board™ is again using the L-size form factor). This should not be too difficult though, because the OLED C Click does not have any component on the board's backside, and all the components (at the exception of the screen itself) seem to fit within an S-size footprint, while the screen component is connected to the board through a flexible printed circuit (FPC) connector. Therefore, all we will have to do is to figure out a way to properly mount the screen on top of the brick's PCB.
This work will mostly affect the overall height of the brick, and this is something that we will find with many other bricks. In other words, depending on the components hosted by the brick (button, display, encoder, port, etc.), the height required above the PCB will vary, but we will want all our bricks to have exactly the same height. As a result, some components might need an extra spacer, or might be deported through cables, and some others might even be mounted on separate PCBs. With that in mind, we fully expect this type of mechanical engineering challenge to keep us busy for a while...
Finally, on the mechanical front, yet another challenge will be to design a proper enclosure for this type of brick. What makes it difficult is that we will want the screen's glass to be flush with the brick's cover. Therefore, a square or rectangular opening will have to be cut on the cover, which is much more difficult that drilling a round hole for a button with a round cap or for an encoder.
If we were planning to make this type of product in large quantities, we would go with plastic injection moulding. But for prototyping or low-volume production, we might have to go with aluminum machining. Last year, I received some training as a manual and CNC machinist at a local community college, working with both lathes and mills, and this part of the project really excites me, but it could make BoM costs explode rapidly. Therefore, we need to find out if we can source such components at a low cost in China before we commit to any design.
E1: One Large Encoder with LED Ring
The E1 single encoder with LED ring brick will be one of the most interesting bricks to develop. Originally, I was a bit reluctant to go down the LED ring path, but the single-encoder brick will be used by 14 out of our 23 planned instruments, and we will need 54 of them for our reference setup. Therefore, it is a very important brick, and the LED ring can provide great visual feedback when properly implemented.
The reason for my reluctance was motivated by space constraints: it is really difficult to fit 24 LEDs around a rotary encoder within a square inch, but MikroE did it successfully with the Knob G Click. Of course, they are again relying on an L-size form factor, but we should have no problem doing the same on our S-size form factor by stacking two PCBs (one for the mikroBUS interface and driver IC, and one for the encoder and LED ring).
MikroE also provides a 16-LED version with different color options for the LEDs (e.g. Rotary G Click), but 24 LEDs provides a much more precise visual feedback. In our case, we will probably offer two options: blue (for input levels) and green (for output levels). Also, we will add the push-button functionality offered by the Rotary Click, and we will probably make the encoder itself RGB illuminated in order to provide an additional level of visual feedback.
One question we still need to answer is the interconnect between the two PCBs: we could either go for a single FPC connector, or a pair of Hirose connectors. The former would be cheaper, but the latter would kill two birds with one stone, by offering both electrical connectivity and mechanical assembly. This question will need to be answered for other bricks as well, and we will probably settle on a generic answer once we have a better idea all the mechanical constraints that we have to deal with.
E2: Two Medium Encoders
Many instruments need a brick with two encoders. Unfortunately, we cannot fit two encoders with LED rings within a single-unit brick. Therefore, this brick will have two medium encoders without any LED ring, and the encoders will be diagonally staggered in order to fit within a single square inch of space. As a result, it won't provide any direct visual feedback, making it unusable without an external display (either a D1 display brick or a smartphone). For this reason, we are not planning to use this brick for any of our instruments. Instead, we will use the D1E2 brick, which provides two small encoders underneath a small OLED display (see below).
E3: One Medium Encoder and Two Small Encoders
This brick will have a medium encoder on top of two small encoders mounted side by side. Much like the E2 brick, it won't be usable without an external display, but a couple of instruments did not give us any alternative if we wanted to fit everything within a single-unit block. And once we have a better understanding of all the bricks available to us, we might find a better solution.
M1: One MIDI Port
This brick will provide a single MIDI port with a 5-pin DIN connector. Support for alternative connectors will be added down the road, and we're following the development of the MIDI 2.0 standard with great interest. This brick will be inspired by the SparkFun MIDI Shield for Arduino and will be opto-isolated. But unlike the SparkFun board, it will allow a single 5-pin DIN connector to be used either for MIDI In or MIDI Out.
P2, P4: Two or Four Audio/CV Ports
The P2 and P4 dual and quad Audio/CV bricks are probably the most challenging ones that we have to develop, for several reasons. But before we dive in, let me explain what these bricks do: they provide 2 or 4 hybrid ports using 3.5mm stereo TRS connectors. The mono version of this connector is used by Eurorack modular synthesizers for three main types of signal:
- Audio signals (-5V to +5V)
- Control voltages (-2.5V to +2.5V or 0V to 8V)
- Trigger, gate, or clock signals (0 to 5V)
Eurorack modules are typically powered by a dual rail 12V DC power supply.
In our case, we will use stereo jacks in order to carry audio signals or control voltages on the left channel and digital signal signatures on the right channel. Doing so, we will be able to use stereo cables to connect any of our P2/P4 bricks to external Eurorack modules, which will leave the right channel (ring of the TRS connector) unconnected (open circuit) on the Eurorack side. We will also be able to use mono cables to do the same, which will ground the ring (right channel) of the socket on the P2/P4 brick side.
Most importantly, we will want any port to be able to handle any of the six following functions:
- Audio input
- Audio output
- Control input
- Control output
- Trigger input
- Trigger output
And we want to fit 4 of these within a single square inch!
Fortunately, we are not trying to get any decent sound quality out of these ports. Nevertheless, we will still try to make them as good as we can. On the audio side, we will shoot for 24-bit/96kHz. On the CV side, we're still trying to figure out what a reasonable target should be.
The brick will be built around two PCBs: one for the mikroBUS interface and ADC/DAC chips, and one for the TRS connectors. Ideally, we will find suitable quad-channel ADC and DAC chips that will allow us to implement both Audio and Control inputs and outputs from a single pair of ADC/DAC chips (suggestions are welcome).
The remaining challenge will be the +12V DC power supply that we need. Unfortunately, the mikroBUS only gives us +5V, therefore we will have to go beyond the standard by adding a couple of pins (+12V and GND) to our brick interconnect. In order to remain as close as possible to the standard and to prevent any incorrect brick insertion, we will add both pins on the left side, with the +12V pin above the AN pin (at the very top), and the GND pin below the existing GND pin (at the very bottom). Of course, only the boards that need this power supply will use these pins, making all other boards perfectly compatible with the mikroBUS standard.
Finally, we will try to add three bi-color blue-green LEDS next to each TRS port, allowing us to visually indicate the port's function:
1-blue: Audio Input
1-green: Audio Output
2-blue: Control Input
2-green: Control Output
3-blue: Trigger Input
3-green: Trigger Output
Whether we will have enough space on the brick's cover to cram all this remains to be seen.
This brick is probably the most important one that we have to develop, because it will largely condition the user-friendliness of the control surface for modular sound synthesis, therefore we expect to spend quite a bit of time refining it.
This post is already way to long, therefore other bricks will have to wait...
More on Thesycon U-Hear
We just heard back from Thesycon regarding the U-Hear firmware. We're not under any NDA with them, but I won't disclose their pricing out of courtesy. That being said, I am pleased to report that we should be able to afford it, and that the contribution to our BoM for the AK4499EQ-powered DAC block should be less than 10%. Also, they do support the STM32F723 alongside the STM32H743, which makes me hopeful that they could support the STM32F767ZG currently offered by MikroE as an MCU Card. If that were to be the case, it would accelerate our development efforts quite significantly.
As far as I can tell, an evaluation is already available, but I am waiting for some confirmation.
I am super excited about this... So much better than the XMOS alternative (on paper at least)...
We just heard back from Thesycon regarding the U-Hear firmware. We're not under any NDA with them, but I won't disclose their pricing out of courtesy. That being said, I am pleased to report that we should be able to afford it, and that the contribution to our BoM for the AK4499EQ-powered DAC block should be less than 10%. Also, they do support the STM32F723 alongside the STM32H743, which makes me hopeful that they could support the STM32F767ZG currently offered by MikroE as an MCU Card. If that were to be the case, it would accelerate our development efforts quite significantly.
As far as I can tell, an evaluation is already available, but I am waiting for some confirmation.
I am super excited about this... So much better than the XMOS alternative (on paper at least)...
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.