Théo Lepage-Richer

Fab Academy / Digital Fabrication 2015

Intro to Communication 101: Networking and Working in C

While the other weeks called for linear interactions between various inputs and outputs, this week’s networking assignment called for a more complex engagement with information treatment, as we had to program nodes to not only record and react to various data, but to filter them and recognize which ones to react to, and which ones to simply pass along.

The internal architecture of networking is (obviously) still obscure to me, but this week’s assignment emerged as a great opportunity to force myself to finally put my head around programming directly in C. Throughout the last weeks, as the exercises required little more than a few AnalogRead and AnalogWrite, I found it easy to justify restricting myself to ‘higher’ programming languages such as Arduino and Processing – yet, the level of complexity of this assignment’s international communications didn’t allow for such a detour, and it appeared almost impossible to continue on such a track... which is a good thing, for I now would recommend anybody doing Fab Academy to work in C as soon as possible.

To begin with, I decided to build upon Neil’s Serial Asynchronous boards by adding/changing few things. I kept Neil’s LEDs, but used ATtiny44s instead of ATtiny45s (not enough pins on the 45 for my needs), added two potentiometer inputs on the bridge and one DC motor output on each motor (EAGLE files available here), with the idea that I might want to consider using two independently controlled motors for my rotocaster (having the two axis independent from one another can always be handy). The first ‘challenge’ – calling it a ‘challenge’ is a bit of a bold statement, but I was so clueless at the beginning that it truly was one for my standards – was to adapt Neil’s code to the ATtiny44, which conveniently enough forced me to go through his Serial Asynchronous script and tried to understand most of it. This part mastered, I restricted my ‘creative input’ to having the LEDs switching off rather than flashing when their node ID is called (files available here).

Hello.bus.44 - Lightworks from Theo L. Richer on Vimeo.

After this, I gave myself the objective to program the motors to react to the potentiometers – having each motor associated with one potentiometer – but quickly gave up. I started by wigging out a bit and tried to do it with Arduino, but couldn’t figure out the serial asynchronous communication part with the IDE. I then went back to C, but couldn’t understand how to program the treatment of input values. I therefore rearticulate my problem and rather aimed at making the motor starts spinning when their node id was called, to then stop when their node id was called again. To do so, I mixed Neil’s serial asynchronous script with his one for DC motors and, after a shamefully long period of trial-and-error, could finally make the whole thing works. Under the script’s final form, all the LEDs flash when any channel is called on a computer's serial communication interface, the bridge flashes twice when its id (1) is called, the motors start spinning when their channel (2 or 3) is called, and finally stop when their id is called a second time (files available here). It is obviously nothing out of this world, but I was nonetheless really glad of this result for a first attempt at C.

Hello.motor.44; or, The Breakdancing Motor from Theo L. Richer on Vimeo.

See below for all the details/for each step.

Your Name

  • Week: 13
  • Subject: Networking and Communication
  • Tools: EAGLE, Modela, C (Xcode)
  • Objective: Design and build a wired and/or wireless network connecting at least two processors
  • Files: Click here
Project 01a Project 01a
To start with, I might indeed be getting better at quickly designing, milling and soldering boards, but it has pretty much come at the price of me getting too confident about it and making stupid mistakes. At a first glimpse, the boards look functional, their components well packed, the line big enough to adapt to the various voltages passing through the board but…
Project 01a Project 01a
It didn’t stop me from forgetting to connect the bridge’s serial communication pins to the appropriate external headers. I could easily fix the problem with jumpers, but let’s just say that it is not especially elegant (but, hey, as long as it works - I actually find post-milling corrections quite fun to do, for some reason).
Project 01a
When I started working on the programming, I quickly ran into various incompatibilities between the script made for the ATtiny45 and my boards' ATtiny44s. While I initially found the minimalist, overwhelming aesthetics of the terminal error messages, I quickly ended up liking their straightforwardness and the ease with which they allow to find pretty much all the information one needs to adapt whatever script (it was mostly a matter of adapting the pin numbers and few variables). While modifying the C script was fairly self-explicit, it took me a while to realize that I could actually modify the .make file – I initially thought that it was a static execution file, not something that actually establishes the guidelines to read the .c file’s commands – and I could then start uploading the scripts when I had figured it out.
Project 01a
Before uploading the files, one has to change the node id so each board can be differentiated from the others. Programming the bridge is simple – please refer to the Output Devices week to see how to upload C scripts through the Terminal – as one has to simply connect it to the FabISB and to the computer through its FTDI connection.
Project 01a
For the nodes, it is essential to connect them to an external source of power, as they cannot rely on the FabISB, nor any FTDI/VCC input. As they have to power DC motors, my nodes already afforded a header for external power, so I simply connect them to a voltage generator to upload everything.
Project 01a
It all sounds simple, but debugging my scripts was the most time-consuming part of this week’s assignment. My main recommendation – especially for such a script like my hello.motor.44 where boards have to differentiate two states (spinning_state = 1 or 0) – is to add superficial LED flashes throughout the script. In the sense, even if the motors don’t start spinning, it is possible to pin down if it is because the part about the spinning motors doesn’t work (if the LEDs start flashing appropriately to this state, even though the motors don’t react), or if it is because the alternative state is never reached (if neither the motors, nor the LEDs act appropriately to this state). As a final note, I warmly recommend to anybody using regulators in this assignment to cut off the VCC connection from the bridge’s FTDI header – for, as the regulators can only handle current from inside out, any external VCC input quickly heads them up and threatens to fry them. I have been lucky enough to not break my boards in such a manner, but burned quite badly my fingers by inadvertently touching them, so I would recommend watching out for both technical and safety reasons.