When I first thought about redesigning the CORE my main goal was to use one Teensy to control at least one IOAPEX module and two CODEC modules, to reduce the overall cost of a full system (one Teensy 3.6 is at around 30 $), to reduce the number of duplicated parts over the modules or, in other terms, to agglomerate the mandatory common parts in one module. These common parts are, again, the Teensy, but also the USB port, MIDI ports mainly.
Minimum Common Denominator
I for one don't like having to reserve one USB port for my audio interface and another one for my USB MIDI controller, and with the increasing number of laptops that sport less and less connectors for peripherals I suppose that the average user would like to have MIDI+Audio over one single USB cable, too.
Secondly, to get more flexibility out of the CODEC modules I want to use low-jitter I2S master clock generators, in the form of two selectable oscillators that output 22.5792 MHz and 24.5760 MHz, but I don't want to have two oscillators near each AK4558 codec, it would take more resources (PCB real estate, Teensy pins to enable/disable them, actual component cost). I'd rather have them near the Teensy.
Third, the Teensy requires a 5 V power supply, which may or may not be available in an Eurorack system, so I'd like to have a small switching supply to convert the readily available 12 V from an Eurorack supply to 5 V (switching rather than linear because a 12-to-5 V linear supply would dissipate more power than it would be ever needed by the whole module).
This need for a main, minimum common denominator, module is why the CORE is now, well, the core module of the MAD project.
This also sets the CORE as a must-have thing for a MAD-powered setup, and to justfiy the eventual price of this module I can't just make it something that has a USB port and MIDI IN and OUT. I need features.
A Teensy 3.6 has a LOT of pins, but a lot of them are reserved for the IOAPEX, for the two CODECs, for the I2S external clocks, for the TFT, and for the MIDI ports.
In particular, the IOAPEX requires full control over an SPI port, plus a reset pin and the two ADC channels.
The two CODECs share 3 I2S pins (master clock, bit clock, frame select), then there's a TX and RX pin for each codec (4 total), one GPIO for each codec (for powering it down), and they also share the I2C bus (two more pins).
The MIDI ports take only two UART pins.
The two I2S master clock generators take one pin each and they share their output on the I2S MCLK pin (when one clock is disabled its output is in Hi-Z mode, thank you three-state outputs).
The TFT takes 5 pins (three SPI pins and 2 hardware chip selects).
About the SPI ports, the IOAPEX is going to be reserved on SPI2, the TFT on SPI0 (because the Teensy optimized TFT library makes extensive use of the SPI0 4 words FIFO), and this leaves a free SPI1 port. But, since I want to keep its pins for SPI instead of using them for GPIOs, the SPI1 pins are reserved too (4 pins). This is to allow future small upgrades (a RAM chip, or a Flash ROM maybe, or whatever). I'm also keeping untouched the common CS pins for the SD and memory expansions available on the Teensy Audio Adaptor in case someone wants to fiddle with them on a CORE.
All of this leaves us with 30 available pins; 3 are analog only pins A10, A11, and AREF but since the IOAPEX is going to make full use of the two ADC channels continuously they're a no-go; furthermore, I'm fine with the way the AREF pins is connected on the Teensy itself so I do not need to touch it.
So it's down to 27 pins, two of which are the two DAC channels. Not bad after all.
Features, you said?
This is where I thought about CV outs and Gate outs.
The DACs have already been used to output audio and CV, and driving a gate can be as simple as connecting one pin straight to a jack. Since there's going to be a USB port and MIDI ports already...
Read more »