Following on from my first look at the Arduino, I freed up a few hours in my day to continue with the tutorial projects.

Project 6 builds on the LED chase effect that was created by project 5 and adds a potentiometer that adjusts the speed of the chase.  Shame I dismantled project 5 when I finished up on day 1.  It took me a few minutes to reconfigure all the LEDs and connect them to the Arduino.  Once this was done attaching the potentiometer and the update to the sketch was quick and easy.  I skipped the two exercises at the end of project 6 as they were effectively programming exercises.

Project 7 involves creating a single pulsating LED.  This is achieved by doing an analog write to the output pin (the output pin is a digital pin).  An interesting explanation of how we get a digital pin to behave like an analog pin follows with a description of PWM (Pulse Width Modulation).

Project 8 creates a mood light that uses a clear red, clear green and clear blue LED  and adjusts the brightness of each to simulate a range of colours.  The sketch was interesting as it managed the transitions so that transitions from one colour to another were not too abrupt.

Project 9 creates a fire effect using two yellow and a red LED.  The wiring and sketch are more basic than the last couple of projects so there really wasn’t a lot to this project.

Project 10 uses the same circuit as project 8 but uses the serial monitor to manually input commands to the Arduino.  Simple commands allow manual control of each of the LEDs individually.

Project 11 puts away all the LEDs and starts to play with some of the other components, namely the Piezo Sounder and the terminal block.  The circuit is trivial but we start to see new functions within the sketch that control the Piezo Sounder.

Project 12 uses the Serial Temperature Sensor to output temperature readings to the Serial Monitor.  There appeared to be an issue (which I caould not find the source of) that caused my PC to freeze when I connected this circuit.  It seemed to be a problem with the sensor itself.  This was the first problem I had with the kit so far.

Project 13 uses a light sensor to adjust the rate at which a LED flashes.  Normal service resumed and after putting together the circuit and downloading the sketch the LED reacted to the lighting as expected.  I’m a little relieved that there is nothing wrong with the board!

I’m not going to finish projects 14, 15 and 16 as the next thing I want to try is to control the Arduino from a Java program.  But that’s for another day.

My wife recently bought me an Arduino Starter Kit from Earthshine Electronics and I have been keen to start playing around with it.  Despite doing some electronics in university I have absolutely no idea where to start but there was a free book (downloadable PDF) that accompanied the kit.  I downloaded the book and followed the instructions to install the Arduino IDE and verify that the Arduino board was functioning.

Figure 1: The Arduino Board

Project 1 in the book involved connecting an LED and resistor to the board (using a breadboard) and writing a short sketch to make the LED blink every second.  While it was pretty straight forward, I was quite pleased when it all went to plan (I think trouble shooting would be beyond me at this stage) and the little red LED started to flash when I uploaded the sketch to the Arduino.  The book then reviews the C code (which I skimmed over) before providing an overview of the hardware for the project.  Its on the hardware side that I will find my challenge so I needed to read this section carefully.

Project 2 used the same hardware configuration but changes the sketch to signal S.O.S in Morse Code via the LED.  Given this only involved a rather simple sketch and the same hardware configuration I did not find this interesting.  On to the next project.

Project 3 simulates the light sequence on a set of UK traffic lights; that is, red, red-amber, amber and green.  Given the two previous projects this was pretty straight forward.  Different resisters were used this time so that the LED’s were not as bright as in the previous projects.  Given the additional components, I can see now why a strong table lamp is a necessity for this type of activity. Anyway, I’ll press on without one.

Project 4 adds a set of pedestrian lights (red and green) and a push button to the previous project.  Steady state shows the traffic green and the pedestrians red.  On pushing the button, the traffic is shown amber then red.  The pedestrians are then shown green.  After a little time passes the green pedestrian light flashes before changing to red.  The traffic lights then transition to amber and then green thus completing the sequence and returning to the steady state.  The circuit was straight forward although given the number of components I had to recheck the connections a couple of times.  I also made the mistake of placing and LED the wrong way around thus it did not illuminate.  This was easy to detect and diagnose.  The code itself was fairly straight forward.

Project 5 creates a LED chase effect.  Both the hardware and sketch are straight forward but given it uses 10 LEDs and 10 resistors it is fairly time consuming.  I worked through it anyway for completeness.

So far it has been fun learning about the Arduino and I’m looking forward to working my way through the other projects in the accompanying book.  It’s getting late so time to pack up for today.  Hopefully I’ll get some time over the Christmas holidays to tackle the rest of the projects.

I remember when I started commercial coding in early 1999.  The developers that I worked with would constantly remind me of the value of commenting code.  The main reason they would give was that it reduces the cost of maintenance by making it easier to return to the code at a later date.

Now, I wanted to write code and not comments so this did not come naturally but on my best days I would diligently comment every class/method declaration and adorn non-trivial methods with a liberal spattering of the same.  After a while I noticed the amount of noise produced by comments that added no value or that were no longer relevant was a considerable distraction.  In fact, this distraction was increasing the maintenance cost rather than reducing it as I had previously been told.

Since then much has changed and the publication of books such as The Pragmatic Programmer, Clean Code and The Clean Coder has changed the perceived wisdom surrounding the commenting of code.  The authors of these books suggested that better code maintainability will come from writing better code (who would have thought!).  By better code they meant code that is easier to understand but how do we write code that is easier to understand.  A good start is to:

• Use descriptive class and method names.
• Do Not Repeat Yourself
• Write SOLID code.
• …

Given the way in which modern logging frameworks work, using descriptive class and method names also increases the value of your application logs.

Bob Martin said that “The proper use of comments is to compensate for our failure to express yourself in code. Note that I used the word failure. I meant it. Comments are always failures.”.  I’m a little more open to comments and still see the value in class and public method comments (please, no bean accessor and mutator commenting!) but regardless of each individuals personal preferences for comments its is good that people are thinking about the subject and doing what makes most sense for them rather than blindly commenting everything.