标签: programming

Young Jacob is working on programming the Arduino to make his robot's eyes flash messages in Morse code. We may have an engineer in the making.   It doesn't seem all that long ago when I was a bright-eyed, bushy-tailed young engineer. Now I feel like an old fool, but where are we going to find one at this time of the day (LOL)?   One thing that seems to come up a lot in conversation recently is the way in which we attract younger folks into engineering. Of course, this does involve learning a lot of "stuff," which can be a bit of a downer when you are a young person.   Now, I firmly believe that the best way to learn something is to work on a fun project. I can't speak for everyone, but when I'm studying how to do something for one of my hobby projects, it really doesn't seem like work at all.   Thus, it seems to me that one way to galvanize, electrify, and energize young folks into wanting to learn more about engineering is to get them to want to make something first and then guide them in the making of that thing, whatever it may be.   All of which brings me to a young lad called Jacob, who is very interested in learning about computers, electronics, soldering, and suchlike. Jacob has an Arduino Uno, and he was looking for something interesting to do with it. When Jacob visited our office building with his family a few weeks ago, I showed him a few of my ongoing hobby projects, including an old television cabinet that I've had restored.   I explained to Jacob that, in the fullness of time -- after I've finished some of my other projects -- I intend to build a diorama inside the television. I'm thinking of a cave scene circa 10,000 BC.     Unlike the above image, the cave people in my diorama will be sitting around a fire. The entrance to the cave will be located about three inches from the back of the cabinet, which will actually be formed from a flat-screen display. This display will show a computer-generated image of mountains in the distance, along with clouds and birds (maybe pterodactyls -- it's not like I'm aiming at historical accuracy) flying in the sky and suchlike.   One thing that will be really cool is that I intend to link the system to the Internet. When it's daytime in the real world, it will be daytime in my diorama. When it's nighttime in the real world, it will be nighttime in my diorama (though the moon will be bigger, the stars will be brighter, and there will be shooting stars and so forth). Furthermore, should it be stormy in the real world, it will be storming magnificently in my diorama with the most amazing lightning you've ever seen and a more-than-satisfying amount of thunder. (Yes, of course, there will be sound effects -- do I look like the sort of man who wouldn't have sound effects?)   It may not surprise you to learn that Jacob was rather enthused by this idea. He would really like to create something like this himself. There are just two small things that are currently holding him back -- he doesn't have a television cabinet, and he doesn't know how to implement the electronics -- but both of these are minor details in the scheme of things.   Having just turned 16, and only having just gotten his driver's license, Jacob (not surprisingly) doesn't have a lot of cash to splash around, though he is eagerly looking for a part-time job. I've been there and done that. (I've even got the tattoo and the T-shirt.) Fortunately, I'm a great believer in the power of cardboard. You wouldn't believe the things I've made out of this magnificent material. So I explained to Jacob that one cheap and cheerful short-term solution would be to get a cardboard box, cut out the front to make it look like a TV, build whatever diorama he decides to build, and worry about moving up to a real TV cabinet later.   Meanwhile, we still have to work on the electronics side of things. As I explained to Jacob, if you can use a computer to read the value of a switch and control something like a LED, you can rule the world. Anything more sophisticated is really just a matter of scaling things up. It didn't take long for us to get a LED merrily flashing away, but you can get only so much enjoyment out of one LED on its own, so I suggested that Jacob make a robot head. You can only imagine the look of fear that flickered across his face until I explained that I wasn't expecting him to start milling, drilling, grinding, and arc welding. We just need something to get the creative juices (and the hot glue) flowing. For example, we can easily create a simple robot head out of cardboard and give it two flashing LEDs for its eyes. (We can add sensors and other stuff later.) Furthermore, we can stick this head in our TV cabinet as a place-holder until we get around to creating a full-up diorama. Much like a cooking show on television, here's a video of a robot head I created earlier.   We sketched out a simple circuit involving two LEDs with associated current-limiting resistors. I showed Jacob how to cut the wires and strip their ends. Then I let him run wild and free (metaphorically speaking) with a soldering iron.   Speaking of soldering irons, my chum Alan Winstanley's The Basic Soldering Guide Handbook just came out in print. I see on Amazon that it says this was published in July, but it actually hit the streets only a couple of weeks ago. Alan was kind enough to send a copy to Jacob, along with a special certificate confirming that he was the proud possessor of the world's first copy of this book. Needless to say, Jacob was pretty excited by this, and he immediately had the certificate framed to go on his bedroom wall. The photo below shows Jacob in the office holding his book and certificate.     But wait. There's more. When it comes to programming his Arduino, Jacob has been struggling along using a battered old notepad computer that has seen better days. I've mentioned on occasion that my office is located in the building owned by the engineering company MaxVision . The folks at MaxVision had seen Jacob showing me his progress in our shared kitchen area, and they noted the sad state of his computer. As we see in the photo below, on his last visit, they surprised him by presenting him with a spare notepad that happened to be lying around.     There's an old saying: "It's not what you know. It's who you know." It's obviously true. In this case, Jacob knows me, and I know the folks at MaxVision (LOL).   It was fall break at the local high schools recently. I hear that Jacob had a happy time showing his cousins all the things he's been doing with his Arduino. He's currently working on programming the Arduino to make his robot's eyes flash messages in Morse code. I don't know what the future holds, but I think we may have an engineer in the making.

In 1981, two colleagues and I set up the first computer-aided software engineering company with the goal of improving the workflow for IBM mainframe programmers. The opportunity was huge, as were the potential payoffs for us and our prospective customers. The original idea was to develop a series of programming tools in a staged fashion. The ultimate goal was to offer a workstation that provided a closely integrated editor, syntax checker, compiler, and runtime emulation of the behaviour of the IBM mainframe's COBOL environment, coupled with testing tools and full code analysis. The plan was to develop the editor and syntax checker quickly and put them into the customers' hands for feedback. Enter the venture capitalists, who required changes in the development plans. These investors (who dominated our board) insisted that, rather than offering the editor/syntax checker initially as a minimal functional product, we offer only the fully capable, final visionary product. To get the funding, we caved. We gave up the ability to get early feedback for our approach. This single decision significantly stepped up the risk factor. We increased the amount of software that needed to be completed, delayed customer feedback, increased the company spend rate, and suffered the usual delays in delivering a working product. Furthermore, we had to scale up our training staff, documentation staff, and field applications engineering staff. The company eventually failed for a variety of reasons, but the chief cause was rooted in the need to acquiesce to board members who were disconnected from our prospects. By circumventing the opportunity to gain early feedback (through design of experiments), we delayed validating our product ideas. Every validation delay increases risk—disproportionately. Apart from development delays, the single largest product failure was rooted in the original minimal functional product. We had planned a tightly integrated editor-syntax checker. However, we had chosen a more capable editor than the one IBM COBOL programmers used. We selected a better but wrong editor. If the original development and release plan had been followed, we would have discovered the magnitude of that single error within the first year of our existence. Instead, we learned of the error more than two years into the development. I've seen and experienced this general sequence many times in my career. I've taken away one fundamental guiding principle: Design the product so that early testing of a minimal functional product (also called an essential product) can begin early in the development cycle. This is a risk containment and control strategy. You'll see this technique used in agile development methodology, Alex Osterwalder's Canvas business generation system, and other enlightened business and product planning approaches. I've adopted a personal approach to product development that focuses on risk mitigation. You cannot and should not eliminate risk. But you should want to contain the effects of risk and control how you react to problems as they emerge. That business philosophy, practised for close to 30 years, is codified by Osterwalder in his book Business Model Generation and by Ash Maurya in his Lean Stack system. The bottom line is that you shouldn't fall in love so hard with the product or company idea that you can't (or won't) see the risks, along with the opportunities to mitigate those risks. In my previous column , I posed the following trivia question: "What 1957 movie was used to influence people subliminally to buy popcorn and drink Coca-Cola?" The answer was a 1957 showing of the 1955 movie Picnic . The experiment failed. James Vicary, who designed the experiment, admitted that he lied about the results. Nevertheless, the effectiveness of subliminal advertising is still widely accepted by the public. Here's another trivia question for you. Long-distance telephone calls used to be measured in minutes. How much did the first three minutes of a call between New York and London cost in 1927? Henry Davis Independent Contractor

In 1981, two colleagues and I founded the first computer-aided software engineering company aimed at improving the workflow for IBM mainframe programmers. The opportunity was huge, as were the potential payoffs for us and our prospective customers. The original idea was to develop a series of programming tools in a staged fashion. The ultimate goal was to offer a workstation that provided a closely integrated editor, syntax checker, compiler, and runtime emulation of the behaviour of the IBM mainframe's COBOL environment, coupled with testing tools and full code analysis. The plan was to develop the editor and syntax checker quickly and put them into the customers' hands for feedback. Enter the venture capitalists, who required changes in the development plans. These investors (who dominated our board) insisted that, rather than offering the editor/syntax checker initially as a minimal functional product, we offer only the fully capable, final visionary product. To get the funding, we caved. We gave up the ability to get early feedback for our approach. This single decision significantly stepped up the risk factor. We increased the amount of software that needed to be completed, delayed customer feedback, increased the company spend rate, and suffered the usual delays in delivering a working product. Furthermore, we had to scale up our training staff, documentation staff, and field applications engineering staff. The company eventually failed for a variety of reasons, but the chief cause was rooted in the need to acquiesce to board members who were disconnected from our prospects. By circumventing the opportunity to gain early feedback (through design of experiments), we delayed validating our product ideas. Every validation delay increases risk—disproportionately. Apart from development delays, the single largest product failure was rooted in the original minimal functional product. We had planned a tightly integrated editor-syntax checker. However, we had chosen a more capable editor than the one IBM COBOL programmers used. We selected a better but wrong editor. If the original development and release plan had been followed, we would have discovered the magnitude of that single error within the first year of our existence. Instead, we learned of the error more than two years into the development. I've seen and experienced this general sequence many times in my career. I've taken away one fundamental guiding principle: Design the product so that early testing of a minimal functional product (also called an essential product) can begin early in the development cycle. This is a risk containment and control strategy. You'll see this technique used in agile development methodology, Alex Osterwalder's Canvas business generation system, and other enlightened business and product planning approaches. I've adopted a personal approach to product development that focuses on risk mitigation. You cannot and should not eliminate risk. But you should want to contain the effects of risk and control how you react to problems as they emerge. That business philosophy, practised for close to 30 years, is codified by Osterwalder in his book Business Model Generation and by Ash Maurya in his Lean Stack system. The bottom line is that you shouldn't fall in love so hard with the product or company idea that you can't (or won't) see the risks, along with the opportunities to mitigate those risks. In my previous column , I posed the following trivia question: "What 1957 movie was used to influence people subliminally to buy popcorn and drink Coca-Cola?" The answer was a 1957 showing of the 1955 movie Picnic . The experiment failed. James Vicary, who designed the experiment, admitted that he lied about the results. Nevertheless, the effectiveness of subliminal advertising is still widely accepted by the public. Here's another trivia question for you. Long-distance telephone calls used to be measured in minutes. How much did the first three minutes of a call between New York and London cost in 1927? Henry Davis Independent Contractor  

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.