Uploading New Firmware

Load a new program onto your Make Controller, either to update it or to run a program of your own creation.

New firmware (which must take the form of a .bin file) is uploaded onto the Make Controller Kit via USB. These can be downloaded from the MakingThings site, or you may create them yourself.

The first step is to get the board into upload mode, so it's ready to accept a new app - this process depends on whether you're running an OSC-enabled application (like Heavy) or something else.
OSC Erase

If you're running at least Heavy 1.6.0 and your Controller Board is version 1.1 or later, you can erase the board simply by right clicking on the board in the Boards list and selecting 'erase board'. Once you've done this, the your board should drop off the Boards list and come back momentarily as an Unprogrammed Board. At this point, double-click on the board, or select Uploader from the Board menu to bring up the Uploader dialog.
Manual Erase

If your board is not running an OSC-enabled app or it's earlier than version 1.1, you need to erase it manually. This is also the way to erase a board that is not responding to the above method.

There are just a few steps:
You'll need to make contact between the two pins labeled ERASE on the Application or Interface Board - these are located near the top left corner of the Controller Board, and the labels might be pretty small!. Connect these pins with any piece of metal (screwdriver, paper clip, etc) to erase it. If you're doing this often, it might be convenient to connect a pushbutton between these two pads so you can use it to erase your board.
Unplug and replug the board to reset it. When you plug it back in, the board should pop up in the list on the left as an Unprogrammed Board. Double click on it, or select Uploader from the Board menu to bring up the Uploader dialog.
Upload Dialog
Once the Upload dialog is up, select the .bin file you want to upload by clicking the Browse button, and then click the Upload button. The status bar will show the progress of the upload - make sure not to unplug your board while this is uploading. When it's complete, you're running your new firmware. If your Controller Board is version 1.0, you'll need to disconnect/reconnect the board to have it reconnect over USB - if you're just using it over Ethernet there's no need. That's it!

The mchelper Uploader dialog
Platform Specific Notes


On Windows, you need to install USB drivers twice:
the first time the board is plugged in while it's running heavy.
the first time the board plugged in when it's in upload mode.
For each of these cases, the device manager will pop up alerting you that new hardware has been detected. Tell it to install automatically and it should be able to find the appropriate drivers. It will also warn you that the driver is not certified - this just means that nobody has paid Microsoft the fee they require to prevent that dialog from coming up! Press "continue anyway" and all is well.

As of 06/2009 we don't have support for uploading new firmware on Vista 64-bit. Other Windows platforms are supported, but Atmel (the chip manufacturer) has not yet released support for this yet. We're currently working with them to try and get this together!


As of 10.5 (Leopard), changes were made to the USB system that require an extra setup step. In the mchelper download, install the OS X Uploader package which will allow you to upload new firmware successfully to your board. It's best to do this before plugging your board in.
Next Steps

Once you've uploaded new firmware, the Uploader dialog will close. If the board does not appear momentarily in the Boards list, try disconnecting and then reconnecting your board.

Once it shows up in the list of boards, you may want to give the board a quick test to confirm it's working. A good way to do this is to send an OSC message from the "Dialog" view. When the board pops up in the list on the left, try typing
/appled/0/state 1
and then hitting return, or pressing the Send button.

You should see one of the LEDs on the Application Board light up. Then, if you send
/appled/0/state 0
you should see it turn off. If you're using an Interface Board you don't have any appleds, so you can send a message like
/led/state 1
instead. You should see the green LED on the Controller Board light up for a moment before resuming its normal blink pattern.


Communicate with the Make Controller via OSC (Open Sound Control)

« Return to page index

A tutorial going over OSC, the protocol used to communicate with the Make Controller Kit.
Overview and Concepts

Some background info and important concepts to understand about how to communicate with the Make Controller.

OSC - Open Sound Control - is the protocol, or format, that the Make Controller uses to communicate with other devices and applications. Almost all modern programming languages/environments include support for OSC, which is great since that means the Make Controller can talk to all of them. The list of languages and environments that support OSC includes, but is not limited toMax/MSP
C/C++ Processing
Java Perl
Objective C
Super Collider

OSC on the Make Controller Kit

OSC provides an intuitive way to organize the elements on the board, and specify which messages go to which parts of the board. OSC messages for the Make Controller Kit all look similar - they specify an address, and then give the value that should be sent to that address. They adhere to the format of:
/subsystem/device/property argument
Subsystems are different elements of the board - analog inputs, LEDs, digital outputs, servos are all examples of subsystems. Each of these subsystems has a number of
Devices - 8 analog ins, 4 LEDs, 1 dipswitch. The device element of the address specifies which analog in we want to read, or which LED to turn on. These devices each have different
Properties - there are several different properties of the servo, for example, that we might want to set - the speed, the position, etc. For the LEDs, this would be their on/off state, and for the analog ins it would be the value. Finally, the
Argument is the value that should be sent to the address specified by the subsystem, device, and property.

Reading & Writing

Sending a message to the board is simple enough - you simply send it, and that's that. For reading values, you have two options:
Send a request message to the board for the value you want to read, and the board sends a message back, with the requested value.
Configure the board to automatically send any new messages back to you as they are generated. For this option, check this how-to.

We'll continue here to document the first method, sending a request message. So how does the board know whether your message is a request or a write? Write messages include an argument value, as in the example above. If a message doesn't include an argument, then the board interprets it as a request.

So, to tell the board to turn on LED number one on the Application board, we would send the message
/appled/1/state 1

Notice that
our subsystem here is appled (Application Board LED)
our device index is 1
the property is the state (whether it's on or off), and the value is 1, or on.

If we wanted to read back the current value of the LED, we'd send the request message

Notice that we didn't send a value this time, so we expect the board to send back a message that looks like
/appled/1/state 0

if the LED is currently off, or
/appled/1/state 1

if the LED is currently turned on.

To continuously read values from the board, we simply continuously send request messages to the board.

Finding Out More About Your Make Controller

You can also send messages to the Make Controller Kit to find out what OSC devices it knows about using the same approach as with normal OSC reads. For example, to see all the subsystems that the board knows about (the highest level of the address), send the message

Then when you see which subsystems the board knows about, you can ask that subsystem how many indexes it has. For the analogin system, for example, send the message

Lastly, to find out the properties for a given index within a subsystem, you can ask for those too by sending the message

This way, you always know which OSC messages your board understands and knows how to respond to.


Quite often, you'll have a situation in which you're reading or writing messages to several devices on the board. It gets pretty inefficient pretty quickly to send a separate message for each of these devices. The way around this is to use OSC bundles whenever possible.

An OSC bundle is simply a group of normal messages all wrapped up in a single bundle and sent at once. Different programming environments deal with bundles in different ways, so you'll need to check out how to create and send them in the environment you're working in. Information on how to do this should be included in the documentation for that environment.

More on Addressing

OSC also provides a nice, flexible way to send single messages to more than one address.

One of the most frequently used methods of doing this is using the * character as a wildcard. The wildcard matches all available entries for a given element in the OSC address. So if we wanted to read all the analog ins using a single message, we would send the message

and the board would return a bundle with messages giving us the values of each of the analog inputs. Or, if we wanted to set all the servos to the same position, we could send the message
/servo/*/position 512

You can also specify a range of values, instead of just asking for all of them. Do this by specifying the range as the lower limit followed by a hyphen, followed by the upper limit, and enclosing the range in square brackets. So, to ask for analog ins 4 through 7, we'd send the message

and to turn off LEDs 1 through 3, we'd send the message
/appled/[1-3]/state 0

This is a very handy feature of OSC and allows us to send messages to the board more efficiently - try to use these conventions whenever possible to reduce the number of messages to and form the board. It's not too difficult to overwhelm the board with too much traffic, and these techniques help avoid that.



Servo - OSC
Control Servo motors with the Application Board via OSC. More...

Control Servo motors with the Application Board via OSC.

There are 4 Servo controllers available on the Application Board, numbered 0 - 3.
See the servo section in the Application Board user's guide for more information on hooking up servos to the board.
Each servo controller has three properties:

The position property corresponds to the position of the servo motor within its range of motion. This value can be both read and written.
Most servos like to be driven within a "safe range" which usually ends up being somewhere around 110-120 degrees range of motion, or thereabouts. Some servos don't mind being driven all the way to their 180 degree range of motion limit. With this in mind, the range of values you can send to servos connected to the Make Controller Kit is as follows:
Values from 0-1023 correspond to the normal, or "safe", range of motion.
You can also send values from -512 to 1536 to drive the servo through its full range of motion.
Note that it is sometimes possible to damage your servo by driving it too far, so proceed with a bit of caution when using the extended range until you know your servos can handle it.
To set the first servo to one quarter its position, send the message
/servo/0/position 256
Leave the argument value off to read the position of the servo:
The speed property corresponds to the speed with which the servo responds to changes of position. This value can be both read and written, and the range of values is 0 - 1023. A speed of 1023 means the servo responds immediately, and lower values will result in slower, and smoother, responses.
To set the speed of the first servo to just under full speed, send a message like
/servo/0/speed 975
Adjust the argument value to one that suits your application.
Leave the argument value off to read the position of the servo:
The active property corresponds to the active state of the servo. If the servo is set to be active, no other tasks will be able to write to the same I/O lines. If you're not seeing appropriate responses to your messages to a servo, check the whether it's locked by sending a message like


Connect a Servo Motor

Connect and use a servo motor with the Make Controller Kit.

You want to connect a standard servo motor to the Make Controller Kit.

Standard Servo
A servo motor.

Plug a servo with a standard 3-spot servo connector into one of the 4 available servo controllers on the Application Board. Be sure to get the orientation correct - servos usually come with 3 wires on them. The black is usually ground, the red is usually 5V, and the yellow or white is the signal. Check the servo section of the Application Board Overview

for more info.


The reference for controlling servos via OSC can be found here, and the reference for programming servos in your own firmware is here.


Servo motors are great for specifically positioned movement within a 180 degree range. The connectors on the Application Board are 0.1" spaced headers that are compatible with the standard Hitec and Futaba servo connectors.

You can draw about 90 mA through the USB connection, which is enough to drive one servo with little to no load. You can draw up to 1A of current from the 5V line on the board if you have a power supply connected to the main power connector. If you need even more current for your servos, provide your own supply (usually 5V or 6V for servos) and connect it to the 2-spot VExtS (external servo voltage) connector and switch the external power select jumper shown in the image above. Again, check the Application Board Overview for more info. Log in
Login Name
Forgot your password?
New user?

© 2012 MakingThings LLC. All right reserved.