标签: language

One of our younger readers--we'll call Ryan (because that's his name)--is desperately keen to learn more about all aspects of electronics. Every now and then, an email will "ping" its way into my Inbox with a new question. The problem is that there's rarely an easy answer, because there are typically myriad underlying assumptions and potential areas for confusion.   Recently, Ryan has turned his attention to computers. Just a few minutes ago, for example, he sent me an email asking: "Can an operating system be created in assembly language? Also, what is the need for assembly in these days of languages like C/C++ and Java when memory is so cheap?"   Now, I must admit that I was tempted to send a short, quick, and easy (on me) answer, but I remember how confusing things were for me at the beginning -- plus I'm a bit obsessive-compulsive about this sort of thing -- so I responded as follows; I would be interested to hear your thoughts as to the way I presented all of this.   Hi Ryan -- as usual, there's more to your question than meets the eye LOL. Let's start with the fact that a processor (we'll focus on microprocessors/MPUs or microcontrollers/MCUs, but this applies to everything up to mainframe computers) ultimately executes what are called "machine code instructions." These are basically numbers representing instructions or data, where number 'x' might indicate an "Add" instruction, number 'y' might indicate a "Compare" instruction, and so forth. It is possible for someone to write a program directly in machine code -- but this is very laborious, time-consuming, and prone to error. It wasn't so bad in the very early days of computing when programs were really short and the computers themselves supported limited instruction sets and addressing modes, but it soon grew harder as computers increased in complexity. The next level up is to use assembly language, in which instructions are written using mnemonic names and you can declare labels and suchlike. In the really early days, you might write your program in assembly with pencil and paper and then hand-translate it into machine code. Later, you would use an assembler program to take your assembly source code and translate it into machine code. This actually provides a great example of "bootstrapping"; i.e., pulling oneself up by one's bootstraps. Here's the way it would go. You would define a very, very simple assembly language as a pencil-and-paper exercise. Then you would write a very rudimentary assembler in your assembly language -- again using a pencil and paper -- and you would hand-assemble this rudimentary assembler into machine code. This is where things get interesting. You would also write a very simple text editor (probably of a type known as ca "Line Editor") in your assembly language as a pencil-and-paper exercise, and you would hand-assemble this simple editor into machine code. Now you are in the position to capture simple programs in your assembly language using your text editor (in machine code) running on your computer, and then assembly them into machine code using the assembler program (in machine code) running on your computer. One of the first things you might do would be to use your simple editor to capture the source code for a slightly more sophisticated editor in your simple assembly language, and to then run this through your rudimentary assembler. Alternatively, you might capture the source code for a slightly more sophisticated assembler in your simple assembly language and run this through your rudimentary assembler. And so it would go, looping round and round using your existing editor and assembler to create bigger, better, easier-to-use versions with more functions and features. Now let's consider a modern language like C, for example. As you know, we use an editor program to create our source code in C, then we run this code through a compiler program, and -- ultimately -- we are presented with a machine code ("executable") equivalent. The first question we need to ask is: "Where did the compiler program come from?" In fact, if you were the person who created the compiler, then the first version (a very simple C compiler) would have been written in assembly language and run through your assembler program to generate the machine-code version of the compiler. This first version of your C compiler might only support a subset of the C language -- just enough to get you up-and-running. Once you had your first simple C compiler, you would probably hand-translate your original assembly code version of the compiler into your supported C subset equivalent, and then used your C compiler to compile its own source code in C and generate a new version of itself in machine code, just to make sure that everything was tickety-boo. After this, you would start to loop around creating new, more sophisticated versions of your C compiler, where each one was compiled into machine code using the previous version. Once again, you would be "pulling yourself up by your bootstraps." (For the purpose of our discussions thus far, we're assuming we go directly from assembly to C. In fact, there were other languages like FORTRAN in between, and it's more than likely that someone might have created a FORTRAN compiler in assembly, and then used FORTRAN to capture the first C compiler, but let's not wander off into the weeds.) Another interesting point is that, when someone creates a C compiler, they typically don't use it to generate machine code directly. Instead, the C compiler generates its output in assembly language source code, and then an assembler is used to take this source code and assemble it into machine code. All of this usually takes place "behind the scenes" or "under the hood," so most people don't even think about it, but expert users (including the compiler writers) often look at critical parts of the code generated in assembly language to see if they need to refine their C source code to better guide the compiler. Are we having fun yet (LOL)? OK, let's say we want to create a program that does something-or-other; perhaps it's a game of Breakout. We could create this program in assembly language or C. In the past, expert programmers would say that they knew lots of cunning tricks, so they could create smaller, faster programs in assembly language than could be generated using a C compiler. This was probably true, but it would have taken them a lot longer to do it; also, modern C compilers are very sophisticated and they typically know the same cunning tricks as the programmers. Be this as it may, we create our game in assembly or C, and then we assemble or compile it into a machine code (executable) equivalent. If we power-up the processor and point it as the first instruction of our program, then we say our program is running on the "bare metal" and we talk about this as "bare metal programming." This is still the way things are done for a lot of small embedded systems, like the microcontroller programs running on home thermostats, for example. But what happens if we want to quickly and easily switch between multiple programs. Or suppose we want to have multiple programs running at the same time (or, at least, appearing to run at the same time). Take your home computer, for example, you might have a web browser open and a Word document and an Excel document. In reality, the processor is time-slicing things -- it goes so fast that it can look at your mouse to see if you've moved it -- then switch to look at your keyboard to see if you've clicked a key -- then switch to one of the open programs to see if it needs to do anything -- then switch to the next program -- and so on and so forth. It does all of this so quickly that it appears to you, the user, that multiple things are happening simultaneously (let's keep things simple and assume a single processor/core and no multithreading). The point is that, in this case, we need to have a higher level program called an operating system (OS). We can think of the OS like the conductor of an orchestra, telling the horn section (one program) when to play and then telling the string section (another program) when to take over. And how is the OS created? Well, these little scamps come in all shapes and sizes. At one end of the spectrum we have incredibly large and complex monsters like Windows -- at the other end we might have something much, much simpler beavering away in a small embedded system. It's certainly possible to create a rudimentary OS in assembly language, but more-sophisticated systems would be created in C (or an equivalent high-level language). Returning to your original question, in the case of very low-level systems based on 8-bit microcontrollers, there are still quite a few older programmers who program exclusively in assembly language. There are also things like the PicoBlaze family of soft 8-bit processor cores used in Xilinx FPGAs that can only be programmed in assembly language because no one ever bothered creating a C compiler for them. When it comes to higher-level applications, some programmers may still hand-craft performance-critical functions in assembly language, but -- generally speaking -- this is becoming less and less common. Finally, for the moment, the underlying mechanisms behind languages like Python and Java are a whole different ball game involving things like "byte code" and "virtual machines," so I think we'll leave those for another day.   Good grief! Poor old Ryan. Even my head hurts now. This all seems so simple if you gloss over the underlying mechanisms and just say things like: "You capture your program in C and then use a compiler to translate it into an executable," but it becomes a lot more convoluted as you delve deeper into the morass.   On the other hand, I personally think this stuff is really interesting. I sometimes ponder what would happen if I were to stumble through a rift in time and space and I ended up having to develop a computer system (hardware and software) from the ground up. Hey, I'm sure we all worry about things like this... right? So, what do you think of my explanation above? Is this all "so-so soup" to you, or are there elements of this discussion that you never actually thought about before? Also, is there anything I misrepresented or missed out or that you think I should have covered in more detail?

I recently blogged about the worst oscilloscope manual of all time .. I've particularly enjoyed the feedback quoting from real-world manuals, such as "...the on-screen lathy rectangle shapes represent the front panel keys..." and "...turn the 'Universal' knob when holdoff time have been to max or min value, now the system will clew this information."   It's hard to argue with statements and instructions like this (how can you argue with something if you don’t know what it means?). And then another reader shared as follows:   I work in Switzerland and lately I've been dealing with a number of manuals/datasheets written by German companies. At first I despaired at understanding their statements and my coworkers asked me to stop my cursing, when I hit upon the secret. The trick is to read the manuals with English vocabulary but with the grammar rules of the original language! Now the sentences actually make a lot of sense. Of course, I don't speak Chinese or Japanese so most manuals still don't make sense but it's something...   In turn, this reminded me as to how different countries employ different writing styles in their English-language user manuals based on the rules of grammar associated with their native tongue.     In the case of user manuals written in English by native German speakers, for example, one tends to see things like "You will plug the probes into the analog inputs. Then you will set the vertical scale to the correct value. Then you will …" The reason I've put the "wills" in italics here is that recollect the emphasis in my German friends' voices when I've arrived at parties to be greeted with expressions like: "You have arrived! You will enjoy yourself!"   By comparison, I always find manuals written in English by the folks in Israel to have a very Shakespearian quality. You can almost read them like a play:   Character 1: "But where are the variables?" you ask. Character 2: "Ha! The variables are over here!" {Actor throws curtains apart to reveal the variables}   Some of the more interesting manuals I've run across in my time are those that have been created by Japanese and German companies working in concert to provide products to an English-speaking audience. The way this often works is that the native Japanese speakers in Japan create the first pass of the manual in German. Then they ship the product and the manual to their German counterparts, who proceed to translate the poor little scamp from Japanese-German into English.   How about you? Have you noticed any interesting "speech patterns" in manuals based on the grammar rules from their country of origin? Also, have you come across any multi-step translations like the "Japanese German English" path I discussed above?

I recently bought a 4x4x4 3D tri-coloured LED cube kit powered by an Arduino-compatible controller. Creating different effects for this rascal is helping me reacquaint myself with the C programming language (well, the Arduino version thereof). In turn, this is helping prepare me to program my Arduino-powered robot .   I will be writing a more in-depth column on my cube in the not-so-distant future. Suffice it to say, for the moment, that I started out with some very simple test patterns, and that I've gradually increased the complexity and sophistication of my effects. Each LED has three colour channels: red, green, and blue. Each channel is controlled using pulse-width modulation. The values that can be assigned to each channel range from 0x00 to 0xFF (0 to 255 in decimal). Those two values equate to being fully off and fully on, respectively. Up until now, my effects have involved driving the various channels hard on or hard off, thus allowing me to assign seven colours (red, green, blue, red + green, red + blue, green + blue, and red + green + blue) to each LED. Now I'm at the stage where I want to experiment with a wider gamut of colours and to transition gradually from one colour to another, and therein lies my problem. For the purpose of this discussion, let's assume that we are interested in a single colour channel for a single LED, and that I have two global variables of type "int" (integer): oldColor and newColor. Each will be set initially to either 0 or 255. Let's also assume that I have a function that starts off looking a bit like this.   The idea is that, when this function is called, there are four possible value combinations for oldColor and newColor.   This explains why I'm using integer variables instead of byte (eight-bit) variables. I want to be able to employ negative values. The howMany parameter specifies how many steps we wish to use to transition from the old colour value to the new colour value. The parameter is also used to calculate the modColor value, which is the amount by which we wish to keep incrementing or decrementing the oldColor (starting) value until it reaches the newColor (ending) value. Purely for the purposes of these discussions, let's assume that we pass a value of 4 into the howMany parameter when we call out the lightLEDs function. If the old and new colours start off with the same value (both 0 or both 255), then modColor will end up as 0, so nothing will change as we circle around our for loop. Of course, this is what we want in this case. Now suppose that we call this function when the old colour is 0 and the new colour is 255. In this case, modColor will be calculated as 255/4 = 63.73. This will be truncated to 63, since modColor was defined as an integer. (We certainly don't want to use floating-point values. They can consume lots of memory, and performing operations on them can involve a lot of compute cycles if our processor doesn't have a floating-point unit.) In this particular case, this is close enough for government work, as they say. This also explains why I used "i = howMany" as the control in our for loop. If I had used "i howMany," we would have gone around our for loop four times (i = 0, 1, 2, and 3). Our tmpColor variable would have been 4x63 = 252. By performing the loop an extra cycle while capping the value at 255, we ensure that we leave the LED fully on when we exit the loop. Now let's consider what happens when the old colour is 255 and the new colour is 0. Assuming howMany is 4, then modColor will be calculated as -255/4 = -63.73, which will be rounded up (or down, depending on your point of view) to -64. In this case, we really need to perform the loop only four times—255-(4x-64) = -1, which will be bottom capped to 0—not five times, as the current code would have it. Of course, since we are bottom capping the value at 0, the extra cycle won't hurt us, but it's a waste of computing resources, which niggles at me. The problem is that things get worse the more steps we take. Let's assume the old colour is 0, the new colour is 255, and we decide to perform the transition using 128 steps. In this case, modColor will be calculated as 255/128 = 1.99, which will be truncated to 1. Even if we perform our for loop 129 times (0 to 128), we'll still end up with a final colour value of 129 instead of 255. Or, as an absolute worst case, suppose the old colour is 0, the new colour is 255, and we perform the transition using 256 steps. Now we end up with modColor as 255/256 = 0.99, which will be truncated to 0. That means we won't change the colour at all. From the above, we know that we don't have to worry about fading the colour down from 255 to 0, which involves modColor having negative values, because two's complement values automatically round (truncate) towards negative infinity. It's the positive values we have to worry about. So, how about if I modify my function to look like the following?   By Jove, I think I've solved it. As you can see, if we are fading the LED up (modColor has positive values), we start off multiplying modColor by 2 before dividing it by howMany. Next we extract the least significant bit. If this is a 1, then we know the system will round our value downward, so after we've divided by 2 (to counteract our original multiplication by 2), we add this 1 back in. Remembering that multiplications and divisions by 2 involve shifting the two's complement value one bit left or right, respectively, this doesn't add much of a computational burden. It also means that we can use "i howMany" as our loop control. To see how this works, let's return to our original example (old colour = 0, new colour = 255, number of steps = 4). When we calculate our modColor, we start by multiplying 255 by 2 to generate 510. Next, we divide this value by 4 to generate 127.5, which will be truncated to 127, or 01111111 in binary. This is the point where we extract the least significant bit—in this case, 1. Now we divide 127 by 2 to generate 63.5, which will be truncated to 63. Finally, we add the 1, representing the old least significant bit, and get a modColor value of 64. When we proceed around our loop for i = 0, 1, 2, and 3, our corresponding tmpColor values will be 64, 128, 129, and 256. The last one will be capped at 255. What do you think? Have I missed anything, or have I cracked this problem? Also, can you think of a more elegant way to achieve what I'm trying to do?  

I recently bought a 4x4x4 3D tri-coloured LED cube kit powered by an Arduino-compatible controller. Creating different effects for this rascal is helping me reacquaint myself with the C programming language (well, the Arduino version thereof). In turn, this is helping prepare me to program my Arduino-powered robot .   I will be writing a more in-depth column on my cube in the not-so-distant future. Suffice it to say, for the moment, that I started out with some very simple test patterns, and that I've gradually increased the complexity and sophistication of my effects. Each LED has three colour channels: red, green, and blue. Each channel is controlled using pulse-width modulation. The values that can be assigned to each channel range from 0x00 to 0xFF (0 to 255 in decimal). Those two values equate to being fully off and fully on, respectively. Up until now, my effects have involved driving the various channels hard on or hard off, thus allowing me to assign seven colours (red, green, blue, red + green, red + blue, green + blue, and red + green + blue) to each LED. Now I'm at the stage where I want to experiment with a wider gamut of colours and to transition gradually from one colour to another, and therein lies my problem. For the purpose of this discussion, let's assume that we are interested in a single colour channel for a single LED, and that I have two global variables of type "int" (integer): oldColor and newColor. Each will be set initially to either 0 or 255. Let's also assume that I have a function that starts off looking a bit like this.   The idea is that, when this function is called, there are four possible value combinations for oldColor and newColor.   This explains why I'm using integer variables instead of byte (eight-bit) variables. I want to be able to employ negative values. The howMany parameter specifies how many steps we wish to use to transition from the old colour value to the new colour value. The parameter is also used to calculate the modColor value, which is the amount by which we wish to keep incrementing or decrementing the oldColor (starting) value until it reaches the newColor (ending) value. Purely for the purposes of these discussions, let's assume that we pass a value of 4 into the howMany parameter when we call out the lightLEDs function. If the old and new colours start off with the same value (both 0 or both 255), then modColor will end up as 0, so nothing will change as we circle around our for loop. Of course, this is what we want in this case. Now suppose that we call this function when the old colour is 0 and the new colour is 255. In this case, modColor will be calculated as 255/4 = 63.73. This will be truncated to 63, since modColor was defined as an integer. (We certainly don't want to use floating-point values. They can consume lots of memory, and performing operations on them can involve a lot of compute cycles if our processor doesn't have a floating-point unit.) In this particular case, this is close enough for government work, as they say. This also explains why I used "i = howMany" as the control in our for loop. If I had used "i howMany," we would have gone around our for loop four times (i = 0, 1, 2, and 3). Our tmpColor variable would have been 4x63 = 252. By performing the loop an extra cycle while capping the value at 255, we ensure that we leave the LED fully on when we exit the loop. Now let's consider what happens when the old colour is 255 and the new colour is 0. Assuming howMany is 4, then modColor will be calculated as -255/4 = -63.73, which will be rounded up (or down, depending on your point of view) to -64. In this case, we really need to perform the loop only four times—255-(4x-64) = -1, which will be bottom capped to 0—not five times, as the current code would have it. Of course, since we are bottom capping the value at 0, the extra cycle won't hurt us, but it's a waste of computing resources, which niggles at me. The problem is that things get worse the more steps we take. Let's assume the old colour is 0, the new colour is 255, and we decide to perform the transition using 128 steps. In this case, modColor will be calculated as 255/128 = 1.99, which will be truncated to 1. Even if we perform our for loop 129 times (0 to 128), we'll still end up with a final colour value of 129 instead of 255. Or, as an absolute worst case, suppose the old colour is 0, the new colour is 255, and we perform the transition using 256 steps. Now we end up with modColor as 255/256 = 0.99, which will be truncated to 0. That means we won't change the colour at all. From the above, we know that we don't have to worry about fading the colour down from 255 to 0, which involves modColor having negative values, because two's complement values automatically round (truncate) towards negative infinity. It's the positive values we have to worry about. So, how about if I modify my function to look like the following?   By Jove, I think I've solved it. As you can see, if we are fading the LED up (modColor has positive values), we start off multiplying modColor by 2 before dividing it by howMany. Next we extract the least significant bit. If this is a 1, then we know the system will round our value downward, so after we've divided by 2 (to counteract our original multiplication by 2), we add this 1 back in. Remembering that multiplications and divisions by 2 involve shifting the two's complement value one bit left or right, respectively, this doesn't add much of a computational burden. It also means that we can use "i howMany" as our loop control. To see how this works, let's return to our original example (old colour = 0, new colour = 255, number of steps = 4). When we calculate our modColor, we start by multiplying 255 by 2 to generate 510. Next, we divide this value by 4 to generate 127.5, which will be truncated to 127, or 01111111 in binary. This is the point where we extract the least significant bit—in this case, 1. Now we divide 127 by 2 to generate 63.5, which will be truncated to 63. Finally, we add the 1, representing the old least significant bit, and get a modColor value of 64. When we proceed around our loop for i = 0, 1, 2, and 3, our corresponding tmpColor values will be 64, 128, 129, and 256. The last one will be capped at 255. What do you think? Have I missed anything, or have I cracked this problem? Also, can you think of a more elegant way to achieve what I'm trying to do?  

In my previous column on the Arduino , we discussed the hardware platform itself. Now it's time to consider how we create programs for this little rascal. There are several programming environments one can use with the Arduino. If you are a beginner, perhaps the best option is to use the official Arduino IDE (integrated development environment), which you can download for free from the Download page on the Arduino website. Have your Arduino board and USB cable near your computer, but don't plug them in just yet. As you will see, there are Windows, Mac OS X, and Linux versions of this IDE available. Just follow the instructions on the Arduino website. When you do come to connect your Arduino to your computer, one of the first things you must do in the Arduino IDE is use the "Tools Board" pull-down menu to select the type of Arduino platform you are using. For the purposes of these discussions we will assume an Arduino Uno, so this is the option you would select. Introducing the Arduino programming language The Arduino programming language is an implementation of the open-source electronics prototyping platform called Wiring, which itself is based on an open-source electronics prototyping platform called Processing. For our purposes here, however, the simplest way to think of this is that the Arduino programming language is a simplified version of the C and C++ programming languages. If you are already familiar with C/C++, then you will also be familiar with the concept of the "main" function. The idea here is that a standard C/C++ program consists of one or more functions, and that one of these functions must have the name "main": A standard C/C++ program is executed when the higher-level operating system hands control over to the "main" function in the program. The "main" function differs from other functions in two ways: * It may not be called from within the program. * Any parameters to "main," if they exist, are provided (passed-in) by the operating system. A program written for the Arduino is called a "sketch." The main point to note here is that sketches do not contain a "main" function. Instead, every Arduino program includes two primary functions (along with any functions you add of your own) called "setup" and "loop": Any code you write within the curly brackets associated with a function will be executed when that function is called. The "setup" function runs only one time when the Arduino is first powered-up or when it is reset. The "loop" function runs continuously after the "setup" function has finished performing its tasks. As an aside, for the C/C++ purists amongst us, my understanding is that when we initiate a compilation, the IDE slips in a "main" function while we aren't looking. The thing to remember is that the creators of the Arduino are trying to keep things as simple as possible for beginners. Learning the Arduino programming language First of all, there are a bunch of useful tutorials and other resources available for free on the main Aduino.cc website. If you are an absolute newcomer to C/C++, then one book that I would personally recommend is Programming Arduino Getting Started with Sketches by Simon Monk, which is available for a very reasonable $10.99 from Amazon.   It's worth knowing that an Arduino board typically arrives with a default program called "Blink" preinstalled. As soon as you connect the Arduino to your host computer with the USB cable, this program will cause a LED on the board to start blinking. The first half of Simon's book introduces you to various aspects of the C/C++ programming language via changes you make to this "Blink" sketch. Later experiments in the second half of the book will require you to use some very basic components and tools, like a resistor, a switch, a couple of pieces of wire, and a multi-meter. As you become more advanced, you will discover that there are all sorts of Arduino-specific resources available on the Internet to answer your questions. Also, a lot of general-purpose C/C++ resources are out there, such as this 'const' and 'static' keywords tutorial and this pointer tutorial . Next, we'll look at some Arduino kits for beginners... Arduino kits for beginners There are a couple of very useful starter kits available should you wish to avail yourself of them. The first is the Arduino Uno Ultimate Starter Kit for $54.99 from Amazon, as illustrated below:   This kit includes an Arduino Uno R3 board and a USB cable to connect it to your host computer. It also includes a small breadboard and a bunch of wires and electronic components sufficient for you to perform loads of experiments. Also included is a 72 page, full-colour instruction manual that will walk you through various experiments. What the kit doesn't include is a power supply, but you can pick one up from Amazon for $5.98 ( click here ). And, while you are at it, you might as well go for the ultrasonic distance sensor for only $4.85 ( click here ). Now, I cannot personally vouch for the above kit because I don't have one, but the fact that it has a 4.5 star rating from 242 customer reviews (at the time of this writing) says a lot. As always, I would suggest that you take a look at some of these reviews yourself to get a better feel for what's going on. Another kit that I can personally recommend is The Arduino Starter Kit for $109.95 from Amazon.   This little beauty comes with a host of tasty "stuff," including a 170-page Arduino Projects Book that walks you through building things like a "Light Theremin," a "Motorized Pinwheel," and a "Love-O-Meter." As for the other kit, one thing that isn't included is a power supply, but you can pick one up from Amazon for $5.98 ( click here ). Everything in this kit is very nicely packaged and presented. When you open the box, the first thing you see is the Arduino Projects Book , as illustrated below:   When you remove the book, you are presented with a "jigsaw puzzle" of small boxes as illustrated below:     Opening the boxes reveals all sorts of goodies, including a small liquid crystal display as illustrated below:     Now, if you are an experienced hobbyist or engineer, this kit may well be too simplistic for you. On the other hand, if you wish to introduce a younger person to the magic of microcontrollers, then this kit would be ideal. You start with really simple experiments like connecting a LED to an output pin and flashing it, and then you build up to more complicated projects in easy-to-understand steps. Also, everything is achieved by means of the breadboard; that is, no soldering is required. Two more books As you may recall, one reason for my wanting to learn that Arduino in the first place is that I sponsored a Kickstarter project for a fast and easy-to-use machine vision system called the Pixy, which can be connected directly to an Arduino. In the video shown on this project's Kickstarter webpage , we see the Pixy being used to control a small robot. Based on this, I ordered a book called Make an Arduino-Controlled Robot by Michael Margolis:   Generally speaking, this book has reasonably favourable reviews. Also, a lot of the information seems as though it would be of use for robots other than the two kits featured in the book. This is fortunate, because the kits themselves receive less than favourable reviews. However, we will leave that discussion to my next column, at which point we will consider the whole robot issue in more detail. Last but certainly not least (in the book department), I just took possession of another book called Arduino Workshop: A Hands-On Introduction with 65 Projects by John Boxall (a.k.a. Tronixstuff ):   Truth to tell, I haven't even had the chance to open the cover of this little beauty yet. Suffice it to say, for the moment, that one reviewer on Amazon said: I really think Arduino Workshop is under selling itself. It's not just a workshop manual but a tutorial on electronics, programming and Arduino, and a very good one at that... Over all this is an excellent resource and one that should be on the shopping list of everyone interested in creating their own Arduino toys and tools. Reading Arduino Workshop is high on my list of things to do, and I plan on writing full-up reviews of both Make an Arduino-Controlled Robot and Arduino Workshop in the not-so-distant future. But wait, there's more... Eeeek! I almost forgot to mention that my chum Tobias Strauch just sent me a very interesting link to a 30-minute documentary about how the Arduino came to be ( click here to see this video). And just this morning, I heard from Paul Kassebaum PhD, Maker Community Relations, MathWorks. Paul informed me that MathWork's Simulink has a relatively new capability to generate code to run on the Arduino Uno, Mega, and Nano platforms, as well as other low-cost microcontrollers like the Raspberry Pi and Beagleboard. Even better, they've built a website to introduce beginners and inspire amateurs to the cool stuff this capability enables: makerzone.mathworks.com (you can see a simple example meant to get one up and running from scratch on the Arduino Uno by clicking here ). As a more complex example of the sophistication Simulink can bring to Arduino-based projects, they used the Arduino Mega 2560 to automate sumobots in a competition last April ( click here ). Arduino-powered robots As I mentioned earlier, my next blog will be about creating Arduino-powered robots. In the meantime, do you have any questions? Alternatively, are there any Arduino books, kits, or other resources that you would recommend? If so, please share them with the rest of us in the comments below.