This is the first of a series of posts where we point to things we’ve found on the WWW, and do our best to address some questions/share some thoughts about our tools.
To answer the question that we’ve received several times and seen in a number of places, Windows is coming.
A few weeks back, a thread was started on the St. Louis Area Robotics Group forums regarding our libraries and the Arduino/robotics.
The original poster (gifted) pointed out that while the native Arduino programming environment provides threading via protothreads, it doesn’t necessarily make it easier to handle multiple events taking place simultaneously. This past week, I had students working on a challenge involving three LEDs fading in and out on three PWM channels; as each finished its fade cycle, it would “ask” for a new reading from an ADC channel. I encourage students working with dataflow languages like occam to first draw a picture of their program:
We call this a “dataflow” language because the entire basis for programming in occam is one where we are communicating data from one parallel process to another. Hence, it is useful to think of values “flowing” from one process to the next. I’ll break things down fully here:
The fader process gets done bringing it’s specific LED (in this case, the LED on pin 11) to full brightness and back. At this point, it wants a new reading from the ADC to determine how fast or slow it should fade. So,
fader signals the
switch process that a new reading is desired. (So you know, the
fader process does not know who is listening—it just knows that it wants a new reading, so it sends out a
switch process grabs the
SIGNAL and then signals the
adc process that a new reading is desired. From the point of view of
adc, it has been sitting quietly doing nothing, simply waiting for someone to ask for some data.
adc takes a reading from pin 0.
adc process communicates its reading down the
adcResp channel, and proceeds to begin waiting again.
switch process takes the value it received from
adc (it was waiting), and sends that on to the
fader process (who is also waiting).
There is a 1:1 correspondence between this diagram and the code we write. If you want to see an implementation of this tri-LED fader, you can see it in our repository. I’ll eventually write this up as a sequence of short chapters in the book, but I simply haven’t had time yet. (And, actually, that code needs some comments. I use replicated syntaxes to keep it short, but those should probably be explained.)
So, yes… we think this is good for robotics, because a lot of robotic control is about reading from and reacting to sensors. We
<3 the Arduino because it is a low-cost microcontroller that lots of people use for exactly these kinds of applications—but we think it’s too difficult to manage this kind of complexity in C, especially for programmers just starting point.
And, for tmaiden on the St. Louis robotics forums: we use the word parallelism to denote when things happen “at the same time,” and use the word “concurrency” to mean “the appearance of simultaneity.” I don’t know if others make this distinction, but we do… because when we use our tools on multicore devices, we get parallelism. When the Arduino goes multicore, our domain will be technically incorrect, and we’ll have to go get
.cc domains are expensive.