views:

305

answers:

3

This is my first post on stackoverflow, I've heard of this website and I think its awesome! Let's see if i can get some guidance on how to start my project.

The Idea: Basically I want to build my own custom OSC controller (OSC is a protocol based off UDP with the intention of replacing MIDI). What's interesting about this is that I want to build the controller as a guitar, so I can use it as a synth and include some typical MIDI controller hardware on the body of a guitar. This will include, velocity sensitive pads, optical encoders, a LCD panel, velocity sensitive strings, and touch sensitive frets. Here's an example.

My Questions: I am confused about how to start a project of this magnitude and complexity. At the basic low level it seems that the firmware would just be dealing with basic integers and conversion to the appropriate OSC signals. I am unsure of how to choose my hardware and programming language, or even how to implement this protocol. Maybe I'm biting off more than I can chew, but I think that this is a good project for getting a good understanding of how embedded hardware works and programming low latency concurrent systems.

  1. What would be a good hardware platform to base this device off of? I assume that PIC18s would be to slow to deal with OSC since it's a modern protocol. What type of microcontroller could deal with an OSC implementatation?
  2. What is a good language to implement this protocol in? I understand that C is commonly used for embedded software, but ADA has sparked my interest. The goal here is to create a low latency firmware that can deal with multiple inputs from the user. I understand that ADA is used in many of this types of situations and is "more stable"? What are your opinions on this?
  3. Is it possible to simulate the hardware and microcontroller without having the physical hardware? I'm a bit iffy to invest a few hundred dollars into hardware without knowing that it's the appropriate setup for my needs (I'm on a students budget). If I were able to simulate all the inputs and write the firmware without having the hardware it would make me far more confident in my ability to complete this project. Even being able to simulate a basic version of my idea would be more ideal than nothing.

I hope that I can get some input on this, and if my questions about the hardware are not appropriate for this site I understand if you folks feel hesitant on advising me on the hardware end.

Thanks again!

+2  A: 
  1. Something with support for Ethernet and an available network stack would seem sensible. Are you looking for an off-the-shelf board or developing your own? Many ARM microcontrollers include on-chip Ethernet controllers. You need to consider support for the networking hardware and whether such support (or indeed the application itself) requires an OS or RTOS.

  2. C compilers are ubiquitous for nearly all architectures from 8 to 64bit. However if you use a 32bit part with more than a few tens of Kbytes of RAM, C++ is viable and almost as ubiquitous. Ada is a rarer less well supported beast, and outside of military/aerospace would be an unusual choice IMO. You may need third-party support such as a network stack and Ethernet drivers - are those going to be available for Ada; at reasonable cost?

  3. You may not need to simulate the hardware at the instruction or cycle level. If using C or C++ you can prototype much of the code on a PC. The advantage being that PC already have network support. Many embedded development tool-chains include instruction simulators, some also simulate on-chip peripherals, but their use is limited - they do not execute in real-time, and simulating external I/O can be complex and impractical.

[edit]Regarding C++ (an in response to Jason S's comment). It is not that C++ necessarily needs more memory; you pay for the features you use. However care needs to be taken since things that C++ makes easy and attractive can have hidden resource costs. I use C++ in embedded systems, but seldom for example use the C++ standard library - it is great and saves a lot of time, but at a high cost in terms of resource and determinism that some systems may not afford. I have successfully used C++ on 8 and 16 bit systems, but the advantages are not so critical when the subset used is highly constrained, and the code body small. I would not for example suggest that you learn C++ just to use it on an 8bit system; but if you already know C++, go ahead (with care). I am currently working on a dsPICF33 device, and the lack of C++ support is very frustrating.

Clifford
C++'s viability has nothing to do with 32-bit parts or tens of K of RAM. It's a myth. If you program with dynamically-allocated memory and complicated constructors and virtual functions + such, you'll need more RAM. But the basics are just fine, and a good compiler will optimize. C++ helps with encapsulation + modularization and I wish more embedded processor manufacturers would make sure they offer a C++ compiler.
Jason S
Agreed; with C++ you pay for what you use - I certainly did not intend to propagate the 'myth'. However, if constraints are tight what you might use may make it less compelling if you need to get up-to-speed with C++ at the same time. As Stroustrup said: "In C++ it's harder to shoot yourself in the foot, but when you do, you blow off your whole leg". Moreover on 32bit platforms there are mature and solid C++ compilers available (GCC for example is widely ubiquitous); on smaller targets quality and compliance can be more variable.
Clifford
A: 

You might want to look at something like the gumstix. small, low power, runs linux, wireless and cheap!

It looks like there are linux OSC libraries available. you could definitely prototype your app on a linux PC and then cross compile on an embedded linux platform.

simon
+1  A: 
  1. For starters, take a look at both the Arduino and Make Controller. Both are open-source (hw&sw) micro-controller modules that can handle OSC and have strong user communities. You can find example videos for both on youtube.

  2. Both C and Ada still get compiled down to machine code, so if you want the most control over your hardware, you might want to look at assembly language - but only when it becomes absolutely necessary. Until then, I would stick with C. It will take you quite far.

  3. Yes, it is possible to simulate your circuitry in software. However, some things are just easier with the actual hardware. But, for some good software examples, take a look at the Max/MSP tutorials on the Cycling '74 website. Max/MSP is sort of a graphical programming language that is frequently used for computer/hardware interaction. This article will give you some ideas on what it can do.

  4. Similar to Max/MSP is an open source product called Pd. It is less polished than Max/MSP, but being freely available, you can begin messing around with it whenever.

  5. A couple of good books for beginners are Physical Computing by Tom Igoe, and Practical Electronics for Inventors by Paul Scherz. Tom Igoe also has a very informative website.

  6. A few good magazines you might find helpful are Make, Circuit Cellar, and Nuts & Volts. All deal in some capacity with the type of electronics you would be using for a project like this.

  7. Unless you are prototyping for a commercial venture, you might consider starting an open source project. This sounds like a great idea, and I'm sure it would generate plenty of interest.

Joe Internet