Make:

XBox DVD Playback kit becomes a PC Remote Control

For the past several years, I have been wanting a wireless remote for my computer. The problem was that I am unwilling to pay the money for a good remote, and I don't want to waste money on a really cheap remote. The solution: transform the xbox dvd playback kit into a remote control for my computer. The dongle will then be able to be used on the xbox for movies and in my computer as an incredibly adaptable remote.

Now I can hit the big button on the top, and it opens winamp and starts playing, all from across the room!

http://dlangenberg.googlepages.com/diycomputerremote

That's nice, but I don't think it belongs in a thread specifically focusing on the Make Controller (based on a 32 bit Atmel chip).

More nearly on topic: I note that the Make Magazine specified URL, http://makezine.com/controller/ doesn't have schematics or development details, and neither do any of the pages I've so far found on the MakingThings site referenced there ( http://makingthings.com/ ) -- nor is there any evidence of "free software" for this product at the latter site, though that's advertised. It's June 18th. Kits were announced to be shipping in mid-June. Seems as if someone is not on top of this. Yet. :)

An update on the makezine page would sure be nice. (hint, hint). Detail documents and support would be even nicer. (hint^4) I want to port a decent Open Firmware style FORTH to this board but I can't do jack on that 'til the product and docs appear.

Why open firmware is cool: in principle, smart periphs can be developed with their own driver code installed locally on the peripheral (say in I2C flash ROM), and "just work".

I think smart periphs are a good thing.

I second, more information please.

I am pretty sure that there is a GNU compiler out there, I know there is one for the 8-bit atmel so there is got to be one for the 32-bit. We want schematics, yeah.


The GCC compiler supports Arm processors

Interesting sites to visit while you're waiting for the controllers to ship include:

<a href="http://www.uchobby.com/MakeControllerKit.htm"> http://www.uchobby.com/MakeControllerKit.htm</a>

--- this has links to data sheets for several of the parts in on the board

<a href="http://www.makingthings.com/makecontrollerkit/">
http://www.makingthings.com/makecontrollerkit/</a>
-- this has links to schematics! and downloadble alpha software.

Although looking at the software makes me wonder what comes before alpha (grin).

I'm hoping to incorporate the controller in a driver for my computer-controlled loom.

I was planning to use the MAKE Controller in the new Underwater ROV I am building - but it isn't rated for the type of amperage my motors will draw. The 1A limit is a bit...er, well - limiting.

the h-bridges are socketed. just solder them one on top of the other 'til you have enough to handle your current requirements. might wind up with the world's tallest uav. uh, urov.

Foobert:

Would that actually work?

Foobert,

Interesting idea, but wouldn't the hottest one in the stack have the lowest resistance and therefore carry the most current across the same voltage drop making it the even-more-hottest one in the stack until you achieve melt-down?

JavaMoose:

Without having looked into the details, I get to ask the naive questions like: is there a higher rated part with the same pinout that you could sub?

Of course you could always roll-your-own application board ;-)

Anyone have any good resources for additional components and add-ons for the Make Controller board. I can't wait until mine ships, and I want to start working on some robotic creations and bizarre computer controlled contraptions swinging around my room.

Any cool projects or products that I should pick up to start this mad scientist adventure into microcontrollers.

JavaMoose,

You could just get a mosfet (or possibly hexfet if you REALLY need some frequency) and use the signal from the controller to regulate the signal going to the motors. I'm not very familar with anything besides little old parralax'es but there should be some form of PWM command that can be used by that processor in the Make board..

Try using Comfile Technology's CUBLOC modules,
they have BS2 pin-compatible version too,
which has way more memory and I/Os at a lower cost.
Here:
http://cubloc.com/product/01_01.php?PHPSESSID=205c1c751133008a2fb999ad233eefaa

I'm going to see if I can get some sort of video signal, or an LCD connected and then work on a game.

I'm really more of a software guy, though.

I want to play with motor control algorithms and .... I have a secret surprise project involving servo motors. You can pick up some good ones on E*Bay for about $10 each.

Dobsonian Telescope Controller

I'm thinking of trying the Make Controller out as a motor controller for my Orion SkyQuest 10-inch Dobsonian telescope. For those who are unfamiliar, a Dobsonian scope sits on a simple mount that resembles a lazy susan. I plan to use the Make Controller to control two motors that will cooperate to give the telescope star-tracking capabilities, which will make the scope follow the motion of the night sky. That way I can use my scope for long-exposure astrophotography, which is otherwise nigh impossible with a Dob scope. I was originally thinking of using my Mini Atom Bot Board for this, but it seems like a nice first-project for the Make Controller.

I'm totally understanding of the fact that I'm basically an early adopter with this, and I know there is some documentation on the site, but I have to admit that I'm a bit stumped on how to get started. I know there are a couple sample binaries to upload, and some examples of various tasks of interest like reading from inputs, but as someone who has never used a controller or written C, I don't really know where to begin. I downloaded and installed the applications on my Mac. I have the OS X developer CD installed so I know I have GCC, but aside from attempting to compile some applications in the past, I've never used it. I program in PHP and think I can carry the concepts over to other languages, but standing on the "outside" so to speak and looking in makes it a bit intimidating. Saying "here is the spec for the ARM processor and for the TCP stack" is great for those who have a good base of knowledge. I'm sure in time, such "getting started" guides will come to exist, maybe I will even write some of them, but until then, any tips on how to get started if you're comfortable with computers but relatively inexperienced in electronics design and advanced programming?

Michael

I will be in about the same boat as you, while I have had c++ before, it has been years since I took an intro class and I haven't used it since. I just hope mine shows up soon so I can atleast take it out of the box and look at it. I have a few ideas floating around that may seem feasible once I get the controller.

Ok, I downloaded the source code 100 file and modified make.c to use my network's address space. I then tried unsuccessfully to recompile it until I figured out where the arm-elf-gcc file was and added the path to my environment path.

Then make ran fine and I was able to upload it using mchelper and connected it to my network. I can issue the command "/appled/0/state" and it will return "osc> /appled/0/state 1" but the command "/appled/0/state 0" seems to have no effect on the state returned nor the blinking LED on the application board. As this is as much as I had to go on I tried to use the same concept and do "dipswitch/0/state" but got a packet error in response. I also found that when sending it things it doesn't like, for example "/appled/0/state=0" it appears to crash the board. The LED stops blinking and the board won't respond to further commands until I unplug it from the USB port and re-plug it. If, while it is hung, I try to re-upload the binary, the application will unexpectedly quit on me. Re-loading the program and trying again without having reset the board results in the same thing.

Just a note, the mchelper output window doesn't seem to scroll properly. It appears to insert new content at the bottom of the visible text area, even if there is content below that that is scrolled down. Basically it doesn't seem to auto-scroll as additional content is added so it makes it hard to tell what is a recent command/response and what is an old one. There also appears to be no way to clear the output without restarting the application. This is on a Mac FYI.

So... I got a ways, but I'm now pretty much out of content to work from. I imagine I can go modify the poly program, but although it says it's possible, I don't know how to output information via debug to the osc. In PHP I would simply echo it... but it talks about having your debug level set properly for it to show up, so I imagine it's not the same. With that, I could probably try some of the functions that are documented to get the state of various things.

In Vol 6 of the magazine, it mentioned that out of the box, the board should have many capabilities accessible from the dip switches without even connecting a computer. I found no list of these, and without any sort of output window, didn't see the point in trying them randomly.

Please know that this is not meant to be a criticism, I'm excited about the board, and like I said previously, I'm not out to blame or complain about the missing documentation, but I would love some help on how to get started. Once I get to a reasonable level of understanding, I would be happy to write some content myself.

Oh, and is this the only forum for discussion like this? It seems like there should be a wiki or bbs or something for the board as this thread isn't going to support the eventual onslaught of questions from users.

Michael

Hey MacFanMR

It sound as if you actualy *HAVE* a board. Does that mean they're really shipping. I got a package last night and was all excited until it turned out that it was just a T Shirt (in honor of them sitting on my $$$ for a couple of months now)

Communication to customers (i.e. me!) has not been great, but if they're finally shipping boards I'll probably forgive & forget.

Weaver:

You got a T-shirt? I didn't get one. All I got was a controller. Yeah they finaly shipped. I got mine on Tuesday.

MacFanMR:

When it comes to this controller I'm not much further along than you and came to the same conclusion. I would like better output to know WTH is going on. I decided to try connecting an LCD to it and bypassing the OSC dump to the LCD. This will allow me to "echo" to the LCD. That is the intent but we'll just have to see how that goes.

In a perfect world I'd have the money for (or already have) a JTAG. That would give much better debug info. But I don't have one nor the money to get one so I'll have to make do with what I got.

I think a wiki is a great idea. Has anyone here set one up before?

Yes, I have mine. I got it earlier this week. My shirt came a few days later. So they are shipping. But in the package is the card, a cable and a spec sheet. Ultimately you are directed to http://makingthings.com/makecontrollerkit/ which has lots of information, but it's mainly targeted at people who already know how to operate something like this.... schematics, port lists, component spec sheets, etc. For those of us who are completely new to it, all we have to go on is a binary called Tiny that is the minimal code needed to run something, and one called Poly which is the full environment with real time OS, network support, etc. I can open them and I can make sense of the functions within in general, but they reference a huge library of other files contained in the firmware_100 download. These are all .h and .c files. I don't know the difference really and while conceptually I can make sense of some of it, it doesn't give me much to go on. For example, I found the code for the osc and the functions that return the state of the LED I was accessing earlier.

// Get the index LED, property
int AppLedOsc_PropertyGet( int index, int property )
{
int value;
switch ( property )
{
case 0:
value = AppLed_GetActive( index );
break;
case 1:
value = AppLed_GetState( index );
break;
}

return value;
}


But I access it by sending the command /appled/0/state and I can't really tell how that gets converted into the call for this function. It's possible this has something to do with it, but I don't know how because the arguments don't seem to correlate with the values:

// Now getting a message. This is actually a part message, with the first
// part (the subsystem) already parsed off.
int AppLedOsc_ReceiveMessage( int channel, char* message, int length )
{
return Osc_IndexIntReceiverHelper( channel, message, length,
APPLED_COUNT, AppLedOsc_Name,
AppLedOsc_PropertySet, AppLedOsc_PropertyGet,
AppLedOsc_PropertyNames );
}

Even so, I don't know how to take this and apply it to something new.

Wiki would be great, but it seems like it should be hosted at makingthings.com since they are sort of the clearing house of info. I guess one of us could set it up under a new domain, but at the moment we don't have much real info to offer. If no one else will/can, I can set it up, but others will need to moderate as I won't have the time in the future.

Michael

Ok, so it turns out that I was looking at the wrong LED, I was looking at the green one on the controller board, not the four LEDs on the application board. Sure enough, you can use the commands I referenced earlier to turn them on and off. However, when getting the status to see if they're on, the answer is reversed. If the LED is on it returns 0 and if it's off it returns 1, even though setting it to on is done by setting it to 1 and off to 0.

I searched on this forum and found this site:
http://www.uchobby.com/
which looks to be a resource for us in the future. They have information about the board there, but it is based on an earlier design as there are more/different connectors on the one in the photo than there are on the board I received. One thing of interest was the information there on using Eclipse and applicable plugins to develop for the ARM processor. I am downloading that and installing it now. By default the files loaded in Apple's XCode application but that is primarily intended to be used for OS X development in Objective-C and I'm not sure if it will compile C/C++ code. So I'm giving this a shot. I also found links to a site with a JTAG interface cable and mention on the side above to support in Eclipse for showing JTAG output. On one site I found the pinout for the JTAG plug, so I would think we could build our own conversion cable if we knew what the pinout was on the other side. I'm not sure how critical JTAG is for basic stuff though.

I did look around at hosted Wiki solutions, and found this one to be intriguing: http://www.wikidot.com/ It's free and supported by google ads, but if you're an open-source related site, you can request that the ads be removed or even converted to your own ads account. So if we want, we can go ahead with that, but personally I would like to see Make or MakingThings step up and provide that resource, not as a cost concern, but as a commitment to the community they're aiming to build with this tool.

Michael

Ok, so Eclipse didn't turn out to be much help... I installed the application and the support for C/C++ and the support for embedded C development which comes with its own debugger that requires special setup. I created a new project and imported the firmware_100 files. I could open and look at them just fine, but despite having enabled indexing, I couldn't seem to click on a function and have it show me the definition in whatever other file it existed in. It also didn't prompt me with the proper arguments when typing in a function name. It wasn't clear how to build, especially since both Tiny and Poly were in the same project and had separate make files. I tried setting a build target but that didn't seem to get me anywhere. These things are what having an IDE is all about, so I'm a bit disappointed.

Moving on, I thought I would try the Tiny binary, but the upload failed and mchelper crashed. A few more tries and I decided to try recompiling it, but I got an error and I don't know what caused it. So I tried the firmware for tiny I downloaded separately. It failed as well. So I tried Poly... both the downloaded binary and the one I had built earlier. I even tossed the one I built and re-built it again. All resulted in instant crashes of mchelper. After many times, I was finally able to make out the error message that flashed up briefly.. something about being unable to find the specified chip and boot code and to make sure I had erased and done something with a browser.

I had seen ERASE on the board next to a set of jumper pins, so I unplugged the board and repurposed a power setting jumper nearby to these pins, powered up, then powered down and put the jumper back, then powered up again. No green blinking light which seemed right as that was part of the poly code I believe. This time the upload worked fine.

I tried calling /appled/0/status several times without success before pulling up the rtf file that came with mchelper and discovering that it was actually /appled/0/state. That worked fine, but every time I called it with status, the board would stop responding until I cycled the power.

I can't help worrying how sensitive this board is? Can we get it in a position where we have messed it up boot wise? Can we use ERASE without powering off the board in between? Is there no way to have it automatically erase on upload? As far as I can tell, we're looking at a situation where we can't pre-run the code in Eclipse (at least in my experience so far), so we have to compile it into a binary, erase the existing code from the board, then upload the new code, power cycle the board to boot off the new firmware, and only then do we find out whether some little change we just made worked?

Information I could use based on what I've done so far:

- Proper ERASE procedure
- Detailed list of all the connectors on the board. All the info I'm finding refers to older board versions which differ from this one. Although there are port list files on makingthings.com, one of the files is missing and the other ones don't really mean much to me. Specifically I want to know where I can connect my stepper motor, and how I know which of the wires goes in which connector point.
- Some more code samples of various other tasks
- Explanation of how /appled/0/state translates into appled_getState() and why things like /dipswitch/0/state does not.
- Explanation of how OSC works and specifically how we can output to it in our code
- Links to a couple C tutorials that are applicable, if not specific to embedded programming
- Explanation of the poly system, does everything we do need to be registered and made into tasks? I looked at the arguments for the makeTask() function but it didn't really tell me much about how to configure my own task.
- Which ports are external power to the board? what voltage does it require?
- I see options for power selections of 3.3V and 5V and V+ in some cases... what is V+?
- Would JTAG really be useful to us or is it really more than we need if we're newbies and know we will learn osc?
- Where can we meet up with others online who have experience with this and are willing to help us out?
- Where is the best place to post the things we learn? Things like having to erase the program before uploading another is pretty critical to know and a showstopper, at least in my case where the application crashes on my Mac.

Whew... it's interesting certainly, but unfortunately the more time I spend, the more questions I have and i don't really feel like I have anywhere to turn aside from this thread and everyone here at the moment is in the same boat I am.

Michael

Hi there,

Thank you so much for all your patience! I thought I'd post a bit of an update from MakingThings.

It looks like Make is shipping boards and we shipped some today too. Finally. This whole project has been about 9 months in the making. I have have personally aged two years in this same time.

We had a final board design in early July after we switched from RMII to MII (arrgh!), made some changes to the power scheme on the App Board (which explains why it looks slightly different) and fixed a final nasty bug on the Controller to do with the on-board PLL. From there, the pc boards took a couple of weeks to come back from China, where they were made. While this was happening we had to assemble the approximately 200 parts for each kit in the same place at the same time and figure out all the little pits and bumps that characterize building a new board. After much hair pulling things started to work and we were able to enjoy the sight of a whole factory (briefly) dedicated to the building and the testing of our project. We have some nice video of automatic pick and place machines putting components onto the Controller board which we'll post shortly.

We hear from our manufacturers that they'll be on a steady shipping schedule starting today. Within a week or two we'll haved shipped all the backlog of orders and we'll be back on top of things.

The boards that we've been using for the last few weeks have been either final boards or their handmade precursors, so we've had quite a bit of time with them. They're tough and reliable. We built the first decent sized application with one the other day, it is a tester for newly built Controller boards. We needed something to test the 30-ish general IOs, the USB, CAN, and Ethernet ports and the onboard EEPROM, so we used another controller! The complete setup uses a computer running a QT application with classes for SAMBA and OSC, a network router, a Controller as tester and the Controller under test. When it starts, the tester brings the new board up and monitors the current consumption. If all is well it loads in the test program. Then the QT application can fire OSC messages to the tester and the new board to co-ordinate the other various IO tests. On our first outing, the second board we tested came up with an EEPROM failure. Sure enough, there was a cracked lead on the EEPROM and our tester had found its first buggy board. During this development and all the testing before it, we've found the boards to be very robust and not sensitive to handling or the many other various accidental events that have befallen them. In handling approximately 30 boards over the past few months I've only damaged one, and that was before we had Application Boards so I was using one of my homebrew boards prototyping boards with a dangling V+ (12V) wire. The phy chip went POP.

(to be continued...)

(continued...)

Since most of the hardware action has finally moved down to the factory in San Jose our attention up here in San Francisco has turned to documentation and the firmware.

We spent a lot of time over the last few days getting information up on our web site (www.makingthings.com/makecontrollerkit). It's a little sparse still, but it's a start. We now have some general introduction pieces, quite a bit of technical reference information, a glossary and some status information about the board and the firmware. Our target audience is very wide, from non-programming non-electrical engineers in one corner to firmware writing, pc board designers on the opposite corner, so this documentation task is pretty large. Our engineering customers will want electronics details, dimensions, best interfacing practices, etc., our microcontroller people will want to know more about ARM, the firmware, the OS, networking, etc. and our newbies will want to know everything right from the start. Please bear with us as we build this all out. Next on the list are detailed "how to" guides for people getting started from as many perspectives as possible.

The firmware is in quite nice shape now. Right now, running under the window I'm writing on is a terminal program listening to the new USB subsystem. It's been pouring 50bytes of data out every 50ms for hours, I'm very happy to say. This same build has the web server and Osc subsystems enabled and all is well.

We'll update the version on the site now (firmware_100) with a new version later on today (Friday). This new version is more stable, and will have a USB subsystem, and much better documentation. We're also hoping for Osc over USB to get into this release, but if not it will be a day or two later. In general we'll be giving everything a thorough working over to try to make the process of programming as easy as possible.

The idea behind having the two projects in the download ("tiny" and "poly" - although we'll probably rename poly soon to something more like "big") is that one demonstrates bare bones programming for those that think that C is almost overdoing it on a microcontroller and the other is for people who want to have a fully featured system on their board. Both projects are presented as starting points. Copy their directories, rename and start doing your own stuff. You'll find code for most of the things the board can do - motors, servos, sensors of various kinds, network comms, usb comms (next release!), eeprom access, etc. all non-trivial to do from scratch, as we can attest in many cases. With the OS present (based on Richard Barry's awesome FreeRTOS.org) coding can be done almost like on a desktop - multithreaded and complex as you like. With all the source code in front of you you can twiddle with it until you get it exactly right.

For those hoping to use the board more purely as an interface we have implemented a version of OSC. This is a protocol designed for running over networks. It's more compact and efficient that XML, but retains some of XML's internal visibility so its a good one for the microcontroller world. You say the OSC packet version of "/servo/0/position 500" and the servo zips to position 500. You say "/analogin/0/value" (with no data) and the controller sends a message back equivalent to "/analogin/0/value 202". It's very simple and many programming languages (Java, C, C++, PHP, etc.) have libraries available to send and receive OSC messages, also many environments do too - Flash, Processing, Max, Supercollider, Pd, etc. are all ready to go with it.

We've got more work to do but we're getting very pleased with what we've got. We look forward to hearing your questions, comments and suggestions, most of all we look forward to seeing what people do with our baby. Keep a eye on our site especially over the coming weeks - I'll post here when new things come up too.

Thanks for staying with us as we get this huge project off the ground.

David.

Michael,

Thanks for the effort you have already put in. Thanks also for your documentation and other suggestions.

We're on it, as they say.

I'll add some of your discoveries to our nascent FAQ, and make sure that we address as many of your issues as possible in the doc and software, etc.

For now, you could use this forum to communicate with us and others. MakingThings also has a yahoo group forum - called "MakingThings", if you can believe that. See http://groups.yahoo.com/group/makingthings/ I monitor that quite closely.

We've talked to Make about getting a more fully featured forum solution. I believe this is on the way.

D.

does anyone know what percentage of the pre-orders shipped? I didn't order mine untill July so I am sure that I am at the end of the list, I just hope I get one soon.

Hi Michael - another few comments to respond more specifically to your wonderfully detailed post:

- if you wouldn't mind sending details of how you manage to crash the MC Helper app, please do so...if I can reproduce, I'll get it fixed up.
- V+ is the voltage of the power supply that you connect to the main power connector
- depending on the complexity of your programs, you may find a JTAG connection is overkill. It's really nice for single-stepping through code that's not working, but if you just need to read back some values,etc. the OSC debug system should be fine. For more info on that, check out the "Debug" section in the API reference.
- more info on OSC is on the way but essentially, the way it's been implemented on the board is as follows: Each "subsystem" on the board (LEDs, dip switch, analog ins, etc) has a number of devices (4 LEDs, etc), and those devices have a property (state for the LEDs, position for the dip switch, etc.). So, generally speaking, you create an OSC message in the form "subsystem/device/property value", the value being the data you're sending. If your message has no value at the end, the board assumes it's a read and will send back the corresponding value.

Again, more info is on the way, but your feedback helps us make sure we get the important stuff up there first! Hope that helps.

Liam

i'm looking closely at the Make Controller, and am curious about a couple things:

1) is FLOSC the Mac/Flash/OSC solution you are assuming people will use? Or is it the making things socket server thing?

2) how do you get from FLOSC (or whatever) to the USB connection?

3) is the OSC implementation simple enough that if one sends the appropriate form (e.g. "/subsystem/device/property value") value via the USB connection it will "just work"? we have an XML socket communication system already built for flash that can talk to serial ports (including USB with the proper drivers), so this would be easy to implement for us.

4) are there good Mac and PC drivers available for the USB used on the controller out of the box?

5) since a lot of active sensors produce 0-5V outputs, and the controller analog inputs accept a 0-3.3V input, what is the simplest way to scale the 5V signal down? Will a voltage divider with a 1K resistor on the source side, and a 2K resistor to ground do it? Anything simpler? Any problems using 5V sensors in this configuration (e.g. loss of accuracy)? Any plans to offer some sort of off-the-shelf in-line converter to do this?

It looks like a great product!

Thanks,
.phil

pvadbx,
I think I can answer some of your questions.
In general the way makingthings has set up the sample software is to send all OSC over the ethernet connection. The current version only uses the USB for writing the binary into memory. You can of course change that if you want.

Atmel's USB driver for the MCU creates a virtual serial port on the PC. For more on this see the SAM7x <a href="http://makingthings.com/makecontrollerkit/datasheets/AT91SAM7X_doc6120.pdf">manual</a> page: 136, section: 22.4.3.

davidthings,

Thanks for the update on things. I feel more connected to this project and that it can be truly community driven now that we are getting details on what is going on.

I know things are going to be changing fast for a while but a revision history for the firmware source is essential for us out here. A simple one with only a list what files have been changed would be usefull.

I just downloaded Firmware_100_1.zip and it contains duplicate files.

pvadbx - for now yes, flOSC is the best way to connect to the board although as sirionic pointed out, this is only set up to work over the Ethernet connection for the moment. This will soon include USB as well.

Once you connect with USB, you'll still need a way to pack and unpack OSC messages as flOSC does. We will ultimately be providing a way to do this separate from flOSC. But then yes, the simple /subsystem/device/property style messages will still be the way to go.

sirionic - technically, the USB driver on the board is not supplied by Atmel but is part of the open source effort from freeRTOS. But in any event, it uses drivers on the PC side that are built in to both OS X and Windows, and does idneed emulate a serial port. In the case of Windows, it requires an INF file (included in the firmware, for now) descriptor file, and on OS X it's all set out of the box.

As for the 5V to 3.3V conversion, yes a voltage divider is the way to go, however the 1K/2K combination you mentioned will give the wrong ratio. Since you want to get the 5V to 3.3V ratio, you need to select resistor values with that ratio. For precision, 20K on the 5V side and 39K on the ground side, but if you need to use more commonly available components, 10K and 15K will do pretty well. We may eventually provide some sort of converter for this, but in the meantime we'll most likely just post a diagram of the circuit.

As for the duplicate files in the firmware, those have been pruned and a working copy is now up. The changelog is kep on the status page at http://www.makingthings.com/makecontrollerkit/status.htm. Thanks for pointing that out!

Thanks again for your help in sorting out the initial kinks.

I created a wiki at <a href="http://make.binarytide.com">make.binarytide.com</a>. Not much there yet, but feel free to register an account and put some information.

The link for the make_appboard_schematics.pdf file on the resources page is dead.

Thanks for the notification about the bad link. It's fixed now.

I was thrilled to get my kit in 2 days (thanks MT!). The <a href="http://www.makingthings.com/makecontrollerkit/guides/getting_started.htm">getting started</a> link was very straightforward and in 10 minutes, I uploaded <tt>heavy</tt> and got my LEDs to turn on and off and looked at the status web page. So far, so good. :) Now I'm looking beyond that (a <em>next steps</em> page would be handy). The <a href="http://www.makingthings.com/makecontrollerkit/">MT web page</a> says the poly code has a bunch of pre-configured functions. <tt>poly.c</tt> seems to have functions for a timer and a follower controlled cryptically by DIP switches. But what is a follower? And what nifty functions do I get from poly? And how do I get it running? Do I use OSC to call it? I feel like I'm missing some essential piece of context.

Keep up the great work! This is fun!! --aaron

downloaded the following:

firmware_100_03.zip - firmware source
mchelper-setup.zip - windows installer - make controller "helper" application
GnuArmTools.zip - windows installer for build tools

Installed MCHelper. It comes up on the windows firewall. You'll have to unblock it in your firewall.
Default port is 10000.

..followed the readme..

after plugging in the board it comes up as an "atm6124 Sys ATMEL AT91xxxxx TestBoard"
( Should this come up as "Make Controller"?

Just one red light on the controller card.

OK, so the readme says the default IP of the board is 192.168.0.200. So in order to talk
to the board I must get on its subnet. Plug board into laptop. Doesn't work. I guess I
need a crossover cable, or a switch. Board does not seem to be auto-sensing. This means
you can not just pick up any old network cable and plug it between your computer and the
board, without using a switch. It would be nice if it did this. Very nice. Can we do it?)


Since I don't have a switch or a crossover cable with me, I guess I'll just try downloading
the binaries. You only need ethernet to do the OSC debugging.

Downloaded tiny.bin using mchelper. Takes almost not time to download (nice job, guys! USB
am a bitch!) It's supposed to blink the LED. It doesn't, despite the fact that the mchelper
says "Upload complete". Tried it a couple of times. No go.

OK, now let's try heavy.bin. Same thing. Nothing. Am I doing something stupid?

Read the forums here at http://forums.makezine.com/comments.php?DiscussionID=443. Saw the post
that suggested taking the jumper on the 3.3V to the left of ERASE on the controller board and
"repurposing" it by plugging it into erase. Power up. Now I get a green light and a red light.

OK. power down, put the jumper back. Try to download. Still don't work! Am I still doing something stupid? Please advise! I am starting to supsect my board is broken.

Well that's it I am done for tonight. Any suggestions I'd love to hear them. I hope this thing flies.

I am in San Jose. Any bay area people that want to work together send mail to geoff@ubcomputer.com

I AM doing something stupid...reset the board! After upload you gots to unplug and re-plug the board. Now I have one solid red light and one blinky green light! Not bad for an hour's investment!

hey is there any hope for a poor fool running linux? i got the mchelper sources and noted, happily, that you used qt for the ui, but the absence of a Makefile has me stumped and the absence of any hint of linux support leaves me quaking with fear, or, you know, wondering if i'm gonna have to boot up windows when my gizmo arrives next wednesday.

Woodbot -

Getting the IP networking right is worth it for the OSC debuging. I'd be very surprised if either your PC or the card didn't autosense on Ethernet. My guess is that you have DHCP configured on your ethernet port. You should manually configure your PC's address to <tt>192.168.0.1</tt> (the address the board has for the network router) or at least something on the same subnet, i.e., <tt>192.168.0.xx</tt>. Also be sure to set the MChelper destination address to pint to the board's default IP, <tt>192.168.0.200</tt>. And, yes, after you upload new firmware you need to power cycle the board by unplugging and replugging the USB cable.

Good luck! --aaron

Heh, new questions. The <tt>heavy</tt> binary works fine for me out of the box. However, I tried compiling from source today (<tt>make clean; make all</tt> in make/firmware_100/heavy) and when I upload it, the red and green lights come on and stay on. Neither the OSC commands nor the web server seem to work. The compilation completed without error. So, I'm a bit confused on where to start... FWIW, I'm working on a Mac PowerBook running OSX 10.4.7. This may be a clue: I <em>did</em> get a listing of missing files burped out from the Makefile which actually seem not to be missing. For brevity's sake, I'll put it up for download by the curious <a href="http://www.isi.edu/~falk/share/heavy-compile-stdout.txt">here</a>. --aaron

mamadrum,
FYI, windows ignors (completly ignors) all non-routable IP blocks that are outside of its current IP segment. This is supposed to make networks easier to set up but usually just pisses the hell out of me.

woodbot,
You can attach a second IP address to an ethernet card (maybe not with XP Home) in the advanced TCP/IP properties. I have an extensive network already running so adding a second IP makes everything nice.

Unfortunately, compiling and running heavy doesn not woork currently.

As it's mentioned on the status page:

http://www.makingthings.com/makecontrollerkit/status.htm

The GCC build is known to build without error but not run properly. This is (clearly) a pretty serious problem, and is currently being worked on. Thanks for your patience.

The reason the board comes up as "atm6124 Sys ATMEL AT91xxxxx TestBoard" is because it's not yet the Make Controller Kit at that point. It's still the Atmel bootloader on the chip, waiting for a program to be uploaded to it. Once you get a binary shoved onto it, it should pop up as the Make Controller Kit.

Also, whenever you see "missing file/directory *.d" when building, the .d files are dependency files created by the Makefile which go away with a 'make clean'. It's no problem at all if they can't be found.

Hi Liam-

I'm sure you have your hands full. :) It seems like the status page should mention the lack of Mac OSX gcc support. DavidThings posted a nice summary <a href="http://forums.makezine.com/comments.php?DiscussionID=815&Focus=4442#Comment_4442">here</a>.

Can you add to your list of things to do some additional documentation of poly & heavy? Also, please add 'follower' to your glossary.

Many thanks! --aaron

Hey Aaron - absolutely. The Poly documentation is forthcoming - "Follower" is just a name we've given one of the behaviors, like "Timer". In poly.c, the general idea is that it reads in the DIP switch and runs a particular function based on the configuration of the switches.

The Follower function basically gets the outputs to "follow" the input signal at a specifiably slow speed...instead of jumping around as the input fluctuates, they can be a bit more filtered. In any event, these functions will be documented more fully in a little while.

And you're right...the status page should reflect those issues with the GCC build.

I was wrong about autosense- it does seem to work by simply plugging a cable between laptop and the board, no switch required - you just have to upload heavy.bin successfully! Thanks gang!

The lovely Phy on the Controller board has an autoswitch mode (which we activate) where it automatically detects what kind of device it is connected to and reverses sense as appropriate - no need for crossover cables when connecting directly to computers. I had forgotten about it until we were doing a demo at Foo Camp with a crossover cable by mistake. All good.

ease of use is huge. Making your users look smart by default is a plus. I see a lot of this philosophy in this project and it makes me have hope for it. Please keep pushing!

my kit arrived yesterday. is there an eta for a linux build of mchelper? instructions for building the rest of the toolchain? i'm running suse 10.0 if anyone cares.