Teensy as main controller for a midi fader wing

X

XENONFFM

Member
Hello

I'm currently developing a Midi controller to control GrandMa on Pc (Lighting control software).
The main part of the controller is the fader wing. It consists of buttons, encoders and motorized faders.
These are controlled through dedicated chips by a RP2040 over i2c. A simplified schematic is attached.
I've already got these PCBs produced and tested them successfully.

At the current stage I'm thinking about how to tie the fader wings and future expansion together (See the second schematic).
The RP2040 could be used standalone as it does supports MIDI over usb, which is the main thing I need.
But I though about using a more powerful and feature rich MCU to increase performance and allow for as much expandability as possible.
The Teensy 4/4.1 could be a good option, but the RT117x seems to be even more promising (1GHz, dual ethernet with TSN, 2D GPU, etc...).

I've read the Future Teensy feature thread, where the RT117x is already mentioned.
This would be great as developing a board incorporating this MCU on my own is not an option.
Furthermore all currently available dev boards do not seem a good option (Coral micro, EA uCOM, Avnet MaaXboard) due to support, availability, footprint or pinout.

Now that I want to start developing the firmware, I could use a currently available Teensy board with the plan to migrate to a next gen Teensy board.
I'm aware that I'm relying on something that does not exist yet, but this is a hobbyist project with an open timeframe, thus I'm willing to give it a shot
Would this be a viable temporary solution? How much effort would it be to migrate from a Teensy 4/4.1 to a RT117x?
And last but not least, can there be anything said regarding a potential Teensy 4.1 successor?

I would appreciate helpful input regarding this.
 

Attachments

  • draw.png
    draw.png
    121.4 KB · Views: 111
  • draw2.png
    draw2.png
    142.5 KB · Views: 114
  • FaderPCB_V3_v11.jpg
    FaderPCB_V3_v11.jpg
    54.3 KB · Views: 121
Somewhere it was said that there can't be expected any newer Teensy in the foreseeable future. You should find it somewhere in this forum in posts from the last weeks.

For a sophisticated MIDI controller even a Teensy 4.1 looks extremely powerful to me with a lot of pins. What exactly are you missing? Why not focus on a device with that?

Possible bottlenecks I could see would be the number of pins for such huge number of encoders. Controlling displays can be sometimes difficult when the sending of the data is blocking everything else. Nothing of that is a matter of processing power or memory.

Edit: This is one of the current statements about new Teensy versions:
https://forum.pjrc.com/threads/7337...t-2-per-person?p=330915&viewfull=1#post330915
 
To answer this specific question:

XENONFFM said:
How much effort would it be to migrate from a Teensy 4/4.1 to a RT117x?
Click to expand...

It really depends on whether your code makes use of libraries or directly accesses hardware registers. The more you access the hardware directly, the more tightly tied your code becomes to that specific hardware. Sometimes this is necessary for the highest performance. But often functions like digitalWriteFast() are highly optimized and give the same performance as directly writing to the register.

So my main advice is to ask here on the forum if you're working with the libraries and you need higher performance. And quite often the way to achieve higher performance involves using a different approach, so best to ask early and be open minded about ideas to do things differently. Usually when people are near the end of a project and a lot of slow-but-working code is written, changing course becomes a lot harder.


These are controlled through dedicated chips by a RP2040 over i2c. A simplified schematic is attached.
Click to expand...

This modular approach is good. All to often we see people attempt a huge MIDI controller project which becomes too much to build and troubleshoot. Building it as modules greatly improves your chances for success.

But if you are concerned about performance, I would urge you to reconsider I2C. Most I2C chips can communicate at 400 kHz and some even 1 MHz if the wires are short and not much else connected. But if you create a long chain of many chips, even if each would be able to use 400 kHz by itself, you might end up with a situation where the whole bus is limited to 100 kHz speed to the long wires and capacitive load of so many chips.

USB might be a better choice. Chips like RP2040 only support 12 Mbit/sec speed, but that's still a lot faster than 0.4 or 0.1 MHz typical on I2C. Teensy's USB host port supports 480 Mbit/sec speed. If you use a good multi-TT USB hub, all the downstream 12 Mbit devices can use their full bandwidth simultaneously on the 480 Mbit connection to Teensy 4. Even if you use a cheap single-TT hub, 12 Mbit is still a lot faster than I2C. USB also uses very efficient bus master DMA, so the CPU overhead is a much lower than I2C.
 
Thanks for both of your replies.

What exactly are you missing? Why not focus on a device with that?
Click to expand...
Indeed the Micromod Teensy I have on hand should be sufficient for the hardware control (fader wings).
But I'm unsure if it will be possible to add auxiliary functionality like
- scribble strips based on ips displays (1 Display per Channel 172x320px)
- Ethernet: Art-Net Node and AVB Controller
due to missing TSN and graphics acceleration. And my Micromod Teensy has no ethernet :)
That's why the RT117x is so interesting to me, it's incredible feature rich.

I would urge you to reconsider I2C
Click to expand...
For the 3 fader wings I split the i2c bus into two separate buses. Each controlled by a RP2040. Future expansions will adopt this approach if it works.
To each i2c bus there are no more than 10 devices connected.
I decided to use i2c devices to expand i/o instead of serialisation (like midibox does). With the though of easier expandability and embedded development.


USB might be a better choice
Click to expand...
This could be a solution to connect the MCU's to the Main processor. I looked into this and found a promissing Usb hub. The attached updated schematic shows how I imagine this could be implemented.

View attachment 31939

A major open decisions is the platform of the main controller. The Teensy can handle all the i/o of the midi controller, that's fine.
But I'm unsure regarding the auxiliary functions I mentioned above. I want to use this project as a platform to get more into embedded development.
That's why I want to "futureproof" the main controller. I do not want to change the platform half way through.

What could be a solution which fits the requirements I outlined? I thought about adding a processor (RT117/STM32H7) with more peripherals on top of the Teensy. Or maybe even a MPU (STM32MP1/Raspberry Pi).On the one hand this could allow me to start now with the development of the hardware control and expand the system in the future. On the other hand this would add another even more complex component to the system.

If you have helpful input or even an idea how to tackle this, it would be greatly appreciated!
 
I've updated the schematic again to distribute the devices more equally.
 

Attachments

  • draw4.jpg
    draw4.jpg
    76.7 KB · Views: 84
Hey, I know this was a long time ago. But I'm embarking on a similar project, a midi ma3 fader wing. I'm hoping to do 3 banks of 5 non-motorized executor stacks in one box (to replicate compact xt / ma3 light)

Just curious if you ended up completing this project and if you have any tips for someone else who is having a crack at it.

My current plan is to hand wire everything to two teensy 4.1s and then let the computer read them as two separate midi controllers.
 
jack_h_mullen2222 said:
Hey, I know this was a long time ago. But I'm embarking on a similar project, a midi ma3 fader wing. I'm hoping to do 3 banks of 5 non-motorized executor stacks in one box (to replicate compact xt / ma3 light)

Just curious if you ended up completing this project and if you have any tips for someone else who is having a crack at it.

My current plan is to hand wire everything to two teensy 4.1s and then let the computer read them as two separate midi controllers.
Click to expand...
15 analog ins for the faders would be easily managable with one Teensy 4.0 and one multiplexer. Very large numbers for analog ins can become challenging regarding grounding and noise to get clean signals from faders or potentiometers. Another option could be external ADC boards.
A higher number of buttons (digital inputs) could be also managed via multiplexers.
You can configure one Teensy board to be 1, 4 or 16 MIDI USB ports.
If you should need two physical USB connections that would of course need two Teensy boards.
Teensy 4.1 has the advantage (besides more pins) to have an easy access to the USB host port and also an Ethernet option which could be come in handy.
 
@TomChiron

Thanks for the tips. Im thinking I can skip the multiplexer if I use teensy 4.1 which has 18 analog pins.

Then a 15x4 key matrix takes 19 pins.

For the rotary encoders Im thinking of using 5 PCF8575 GPIO expanders with this code that allows for 8 encoders per board over i2c

The OP had a lot more going on with Motors and LEDs, Im hoping I can keep it a little simpler.
 
The PCF8575 is a 5V only chip from what I can see, maybe a MCP23017 would be better, it works from 1.8V to 5V, and is also availalble in PDIP which is handy for breadboarding and testing.
 
You could use something like the SX1509 which has a built in keyboard scanner/decoder which can handle up to 8x8 keypads.
 
MarkT said:
The PCF8575 is a 5V only chip from what I can see, maybe a MCP23017 would be better, it works from 1.8V to 5V, and is also availalble in PDIP which is handy for breadboarding and testing.
Click to expand...
Not sure where you're seeing that, but it seems like there are multiple mfgs for PCF8575. The Adafruit I'm looking at is 2.5v-5.5v power supply and claims it can accept 1.8v gpio input.

For the sake of discussion though. Because there is ready-made code for rotary encoders out there for the PCF8575, would it make sense to use a level shifter rather than a different board altogether?

Edit: I checked my link the the earlier post and realized it was wrong. Here's the Git hub link to the rotary decoder for the PCF8575. Im curious how hard it would be to adapt something like this to another board.
 
Last edited:
PCF8575C is generally the 4.5-5.5V device (from Texas Instruments).
PCF8575D can swing both ways (2.5V-5.5V or 4.5-5.5V). You'll need to reference datasheet to determine which flavor.
 
I just searched for the datasheet and got the PCF8575C one as first hit. Best to quote full part numbers (especially with T.I. who have a habit of the numbers on the datasheet not matching the orderable part numbers). Anyway don't get the C variant!
 
MarkT said:
I just searched for the datasheet and got the PCF8575C one as first hit. Best to quote full part numbers (especially with T.I. who have a habit of the numbers on the datasheet not matching the orderable part numbers). Anyway don't get the C variant!
Click to expand...
I'm curious where you're searching. Are you searching for just the chip with no pcb?

I'm a noob but I just went on DigiKey and found one made by adafruit mounted on a pcb with no-solder connectors for i2c wired connections.

I don't see a C or a D in the datasheet. But the product description specifies 2.5v-5.5v. Am I looking at the wrong product?
 
With 8 I2C addresses, it'll fit your need for 5 addressable modules.
Wether it's "perfect" or not will depend on what other factors we don't know about. You should definitely read Adafruit documentation to determine if there will be any gotcha's.
And be sure to power it from 3.3V thus avoiding any future headaches from potentially damaging Teensy.
And, with 5 modules tied to a single I2C bus, you may have to change/remove I2C resistors on modules.
 
You must log in or register to reply here.
Back
Top