Teensy 3.2 for 2D MIDI foot controller -- RTOS necessary?

Status
Not open for further replies.

zwn

New member
Hi everybody,

I've been reading a lot of posts, old and new, on this forum for the last couple weeks. I'm really impressed, and to be honest a little intimidated, by both the breadth and depth of embedded systems knowledge here. I'm working on a senior design project that is essentially an enhanced expression pedal -- enhanced in the sense that we want the user to be able to control at least two musical parameters through MIDI CC signals both independently and simultaneously using center-of-mass (X & Y). We also want to support Open Sound Control (OSC). We want to use the Teensy 3.2 to control it, with an LCD screen and buttons serving as the user interface.

The actual weight measurement will be done using load cells in the four corners of a rectangular platform, whose outputs will each be routed to individual instrumentation amplifiers and then to the Teensy's analog inputs. The measurement will then be scaled to between 0-127 for MIDI depending on the force applied, and sent to a specific MIDI device determined by the user. Using the menu, the user will be able to assign a means of control, specifically, center-of-mass X or center-of-mass Y, to an outboard MIDI-enabled device or interface.

My questions concern how we're going to juggle state between the user interface and internal control of the system, all while maintaining MIDI/OSC connections that will presumably be running in the background at the same time. I have a little bit of experience with embedded systems -- specifically the TI Stellaris Launchpad -- from a class, but we never dealt with anything that couldn't be handled using a combination of interrupts and a heap-based callback scheduler. I have no experience at all with RTOS's, but I'm willing to learn. I don't even know if an RTOS would be necessary. I'm asking for help here because I want to do this right. I do not want to do a hack job. I would sincerely appreciate any input or feedback you all can offer.
 
I think the biggest determining factor as to whether to use an RTOS is 'is there some existing code written for that OS that you plan to use?'.
E.g. if you already have OSC/MIDI source code, or a display driver for a specific display that you want to reuse, either of which that relies on APIs to a specific OS or, for example, relies on being run pre-emptively.

I'm not familiar with MIDI or OSC; what physical layer communication do you intend to use? UART, USB, other?

Have you decided on what display to use or how many buttons you want?

Have I understood this correctly, you plan to build a flat board that you can stamp on, that has a pressure sensor of some sort in each corner, that you will read into four analog inputs and calculate horizontal x and y bias/angle of the board?

I'm sure all this could be done with a simple round-robin schedular/while(1). Maybe there's more to MIDI that I understand though, so hopefully someone familiar with it, will be along soon.
 
Mundungus, thank you for your reply. I apologize for taking so long to respond. It sounds like in my case an RTOS would be overkill. I'll stick with a while(1) and see how it goes!

To answer your questions, we're planning on supporting MIDI over USB and MIDI using conventional DIN cables. Luckily for us there appear to be libraries for each of these. The conventional MIDI library uses UART. I've already started working with a DFRobot LCD Keypad shield for prototyping.
 
I'd recommend starting with the samples, in File > Examples > Teensy > USB_MIDI. For buttons and mechanical switches, use the Bounce library (as the examples do). Yes, you'll end up with a lot of code in loop() checking for each thing, but that's ok. It may be a little ugly, but it works well and in the end (especially for MIDI controllers) it's a lot simpler to troubleshoot than adding the complexity of an RTOS.
 
Hi,
I'm interested in the device you're developing. Is there some way I can keep track of it? Thanks.
 
Hi dmn,

Sorry for taking so long to get back to you! Unfortunately all the code for our project is presently in a private repo. One of my partners in this project wants to keep it that way in case we actually want to try and take our idea to market. I honestly don't think that is likely, as I've always looked at this as just a learning opportunity. We will probably release the source code eventually. In the meantime, if you'd like, I can keep this thread updated with our progress. At this point we are pretty close to a proof-of-concept, very, very early prototype.
 
Hi,

I wasn't expecting to see the code. I'd just like it if this idea did actually exist as a product I could buy!
In the meantime, it would be great if you could keep this thread updated with your progress.
Much appreciated,
d



Hi dmn,

Sorry for taking so long to get back to you! Unfortunately all the code for our project is presently in a private repo. One of my partners in this project wants to keep it that way in case we actually want to try and take our idea to market. I honestly don't think that is likely, as I've always looked at this as just a learning opportunity. We will probably release the source code eventually. In the meantime, if you'd like, I can keep this thread updated with our progress. At this point we are pretty close to a proof-of-concept, very, very early prototype.
 
I'm tempted to make a MIDI enabled bathroom scale... it looks like the hardware would be very similar to this project -- four strain gauges supporting rectangular surface. ;)
 
Status
Not open for further replies.
Back
Top