All Articles | implements Elegance { // Elwyn Malethan's Blog

Arduino Uno with pure C

2011-10-22T15:28:12Z

One of my primary objectives once I got my head around how to write code for my Uno using the Arduino IDE was to make this more releveant to my aim of re-learning C. Arduino IDE provides a layer of abstraction and avoids some of the boilerplate. But, unfortunately it‘s not real, pure C. There are a number of comprehensive guides as to how to go about programming an Arduino using pure C, GNU Make and AVR tools. I don‘t know much about any of the tools being used so best to follow the links and read up on them.

Programming Arduino Uno in pure C (canthack.org)
Programming Arduino Uno in pure C (balau82.wordpress.com)
Setting up Xcode to Compile & Upload to an Arduino ATMega328 (www.quietless.com)

That last link has an XCode template linked to it, which sounded appealing to me, initially. However the Makefile did not work for me with my Uno. In fact, none of the pages linked had Makefiles that would work for me. For a good couple of hours it was very confusing while I trialled — and mostly errored — my way around my Makefile, trying to figure out what values and configurations were right for the Uno.

Many of the tutorials advocated downloading and installing AVR programming tools such as avr-gcc, avrdude etc. This was not as straight forward on my MacBook Pro as I had hoped (i.e. there was no Homebrew package that contained them all). So I elected to use the AVR tools I found inside the Arduino IDE application.

Below is the Makefile that finally worked for me. Likely variables for other users are ARDUINO_HOME and PORT. The one value that had me stumped for ages was the BAUD value. When wrong, the RX LED on the Uno would light up briefly but the program would not be uploaded and the error message avrdude: stk500_recv(): programmer is not responding would be displayed. Many others more familiar with this sort of thing would have spotted this earlier, I‘m sure.

A working Makefile for Arduino Uno using AVR tools on Mac OS X.

This is for the Blink example.

ARDUINO_HOME=/Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/
CC=$(ARDUINO_HOME)bin/avr-gcc
CFLAGS=-Wall -Os -DF_CPU=$(F_CPU) -mmcu=$(MCU)
MCU=atmega168
F_CPU=16000000UL

OBJCOPY=$(ARDUINO_HOME)bin/avr-objcopy
BIN_FORMAT=ihex

PORT=/dev/tty.usbmodemfd131
BAUD=115200
PROTOCOL=stk500v1
PART=$(MCU)
AVRDUDE=$(ARDUINO_HOME)bin/avrdude -C $(ARDUINO_HOME)etc/avrdude.conf -F -V

RM=rm -f

.PHONY: all
all: blink.hex

blink.hex: blink.elf

blink.elf: blink.s

blink.s: blink.c

.PHONY: clean
clean:
$(RM) blink.elf blink.hex blink.s

.PHONY: upload
upload: blink.hex
$(AVRDUDE) -c $(PROTOCOL) -p $(PART) -P $(PORT) -b $(BAUD) -U flash:w:$<

%.elf: %.s ; $(CC) $(CFLAGS) -s -o $@ $<

%.s: %.c ; $(CC) $(CFLAGS) -S -o $@ $<

%.hex: %.elf ; $(OBJCOPY) -O $(BIN_FORMAT) -R .eeprom $< $@

Irrigarduino: Learning electronics and re-learning C

2011-10-22T14:53:56Z

This page and the series of pages linked from it are intended as a personal journal to track my progress in working on a pet project of mine. The project is to automate the irrigation of my garden using a home made moisture sensor, some basic electronics, an Arduino Uno board and some C.

I initially started this project, not only because I wanted to automate the irrigation of my garden, but also as a vehicle for re-learning C. I studied C in university over 10 years ago. My university final year project — a dairy herd management application — I even wrote in C++. So I was — at one time — familiar with the two languages.

However, since then I‘ve worked with comparatively benign, forgiving abstraction layers between me and the machine.

As it transpires, the learning curve of the necessary electronics is far greater for me than that of relearning C. This, despite the relative trivialness of the circuitry required for this project.

In this series of pages I‘ll be posting code snippets, circuit diagrams and any links I found useful. This will be mostly for my own record and use. If anybody else finds the information here of any use then that will not only be a surprise, but a pleasant one at that.

Source code

All the source code resulting from this project will be in a Github repository, here: https://github.com/elmomalmo/irrigarduino.

Resources

In preparation for this I have found a number of resources very useful. I‘ll be adding to this list as time goes on.

Learn C the Hard Way – Zed Shaw is a great and articulate programmer.
HOW TO MAKE A CHEAP SOIL MOISTURE SENSOR - HEAVY DUTY VERSION.
Arduino.
AVRbeginners.

Don Norman: I Have Seen the Future and I Am Opposed

2011-02-14T16:45:00Z

The power of my electronic computing and communication equipment is more dictated by my service provider than by the technology itself. Imagine traveling in the future and entering a new country:

Please have your papers ready. Passport, visa, customs form, medical coverage, service provider roaming agreement.

Don Norman – I Have Seen the Future and I Am Opposed, 14 Feb 2011.

Practical TDD: It's iterative

2010-12-10T17:00:00Z

I employ TDD/BDD as my software development methodology. I have found over the years that it is the best way of producing good quality, well-designed code. Not only that, when employed with a customer willing to work iteratively, I have found it to be one of the most reliable ways of delivering software that fulfills the requirements the customer actually has and not what they thought the requirements were at the beginning of the project. So, as far as I‘m concerned, all the evidence I‘ve seen and experienced so far suggests to me that TDD/BDD produces the best results.

Not everyone agrees.

There are developers I respect that disagree, people who I‘ve spoken to, people who‘s writings I read and people I‘ve worked with who just do not see the benefits of TDD. And some that are cynical about software craftsmanship in general. None have made arguments that have convinced me that they‘re right to doubt the benefits of TDD. However, I‘m not a fundamentalist, I‘ll listen to arguments and enjoy having my views challenged.

One thing I‘ve noticed about many (not all) of the people that are skeptical of TDD is that they don‘t really understand what it is. A common misconception is that tests are written in advance of production code; that test code for a component is completed before the implementation. It is perhaps not surprising given TDD is referred to as a test-first methodology.

This is not at all how it has worked for me and not my understanding of what the literature on the matter describes. It is certainly not an approach for TDD I would advocate or advise.

As a result of the misunderstanding, some developers find a real barrier to being productive when trying to implement new code employing TDD. This article isn‘t written with the intention of making an argument in favour of TDD or to envangelise in anyway. Hopefully, it will go some way to address the barrier that some experience.

TDD is iterative

To illustrate the iterative nature of TDD I‘m going to write some code. The process whereby this problem will be solved will illustrate how TDD helps us understand the problem and how our solution will evolve. It will also illustrate how the resulting solution can more easily be refactored to provide a cleaner solution by relying on the tests to verify the correctness of the refactored code.

The simple problem in question is – bizarrely – based on an actual requirement I had to fulfil not so long ago. It is to place a sequence of integers from 1 to n , where n is an odd number, in a collection ordered such that 1 is placed in the middle with each successive number placed either side of 1, alternating from left to right.

Getting started

I know it‘s meant to be test–first, but I usually start with a class and a method representing the implementation. I‘m not too worried about the name of either the class or the method at the moment, nor the signature of the method. I can always change these as I go along and further clarify the requirements, usually multiple times.

class MiddleOutNumberSorter {
  def sort(count: Int): List[Int] = {
    return Nil
  }
}

Oh, and by the way, this is going to be Scala. I develop in Java for a living, Scala I develop to keep me sane. Writing software in Scala reminds me why I got into software development in the first place. The requirements are represented by Specs specifications.

So, now we get to the TDD bit, the very next thing we do is create a testcase (or a specification) with stubbed tests (or examples) for the requirements we know of or can easily deduce.

object MiddleOutNumberSorterSpec extends Specification with ScalaCheck {

  "MiddleOutNumberSorter" should {
    "reject even number counts and throw an exception" in { }
    "return a list of the same length as the count specified" in { }
    "produce 3 numbers in the correct order" in { }
    "produce 5 numbers in the correct order" in { }
    "produce 15 numbers in the correct order" in { }
  }
}

One of the things I like about Specs is the fact that empty examples (or more specifically examples without assertions) will manifest as skipped tests and not passing ones.

One thing you will find when producing these test stubs for business requirements is that it will prompt you to think about what the requirements you have actually mean. If, in fact, you can‘t think of any tests to write it is probably an indication that you either don‘t understand the requirements or they are not well defined. Either way it means that you need to go back to the customer to clarify the requirements.

Fail, fix, repeat

Because they are stubs, none of these examples actually break our code. We‘re going to change that. So let‘s write a test that represents a real requirement. This will cause our (currently minimal) implementation to fail.

Ok,now the production code fails the test criteria so we turn our attention to the implementation to address this. We do the bare minimum possible to achieve this. So the implementation now looks like this:

class MiddleOutNumberSorter {
  def sort(count: Int): List[Int] = {
    if(count % 2 == 0) {
      throw new IllegalArgumentException("sort only accepts odd numbers")
    } else {
      return Nil
    }
  }
}

“Hang on“, I hear you say “that‘s not going to sort our numbers, not even close”. You‘re right. All this does is satisfy the one requirement for which we have an example.

This is obviously no more correct than it was before in terms of satisfying the end requirements. This is a bit of a difficult concept to get over for non TDDers. Someone on the #java IRC channel once sarcastically said words to the effect:

TDD is wasting time writing code I know is wrong all day.

What it does mean is we can quickly get back to specifying more of our requirements by filling out another stub. So, on to the next example.

object MiddleOutNumberSorterSpec extends Specification with ScalaCheck {

  var sorter: MiddleOutNumberSorter = _

  "MiddleOutNumberSorter" should {
    doBefore {
      sorter = new MiddleOutNumberSorter
    }
    "reject even number counts and throw an exception" in {
      Array(0,2,4,10,212).foreach {i =>
        sorter.sort(i) must throwA[IllegalArgumentException]
      }
    }
    "return a list of the same length as the count specified" in {
      Array(1,3,9,15,133).foreach {i =>
        sorter.sort(i).size must_== i
      }
    }
    "produce 3 numbers in the correct order" in { }
    "produce 5 numbers in the correct order" in { }
    "produce 15 numbers in the correct order" in { }
  }
}

And back to the implementation, again doing the bare-minimum we can to satisfy the requirement.

class MiddleOutNumberSorter {
  def sort(count: Int): List[Int] = {
    if(count % 2 == 0) {
      throw new IllegalArgumentException("sort only accepts odd numbers")
    } else {
      return (0 until count).toList
    }
  }
}

And so we continue until we have an implementation…

class MiddleOutNumberSorter {
  def sort(count: Int): List[Int] = {
    if (count % 2 == 0) {
      throw new IllegalArgumentException("sort only accepts odd numbers")
    } else {
      val numbers = new Array[Int](count);
      for (number <- 1 to count) {
        val index = if (number == 1) {
          count/2
        } else if(number % 2 == 0) {
          (count/2) + (number/2)
        } else {
          (count/2) - (number/2)
        }

        numbers(index) = number
      }
      return numbers.toList
    }
  }
}

...that satisfies the entire specification:

object MiddleOutNumberSorterSpec extends Specification with ScalaCheck {

  var sorter: MiddleOutNumberSorter = _

  "MiddleOutNumberSorter" should {
    doBefore {
      sorter = new MiddleOutNumberSorter
    }
    "reject even number counts and throw an exception" in {
      Array(0,2,4,10,212).foreach {i =>
        sorter.sort(i) must throwA[IllegalArgumentException]
      }
    }
    "return a list of the same length as the count specified" in {
      Array(1,3,9,15,133).foreach {i =>
        sorter.sort(i).size must_== i
      }
    }
    "produce 3 numbers in the correct order" in {
      sorter.sort(3) must containInOrder(List(3,1,2))
    }
    "produce 5 numbers in the correct order" in {
      sorter.sort(5) must containInOrder(List(5,3,1,2,4))
    }
    "produce 15 numbers in the correct order" in {
      sorter.sort(15) must containInOrder(List(15,13,11,9,7,5,3,1,2,4,6,8,10,12,14))
    }
  }
}

Now I commit this code to version control. It‘s complete, and I can be confident that it fulfills the requirements because they are codified in unit tests. Not only that, those tests provide an invaluable resource to other developers working on the project. They now have code that when run generates a report that tells them in plain English what it should and should not do.

Being a an aspiring software craftsman I want all the code I write to be maintainable, with minimal technical debt. I want it to be sustainable in the longer term, so I'm not entirely happy with the implementation. In general, I want to reduce the number of WTFs per minute to a minimum.

The benefit

Also, I‘m becoming less keen on the imperative style and Programming in Scala promotes a more functional style using immutable objects. The thing is, having been mainly a developer of imperative languages, I'm still learning to code in a functional style – particularly in Scala – and so it doesn't quite come naturally to me yet. Without test coverage, this would be a risky approach. In my attempt to produce more functional code, I might cause it to produce incorrect results. Because I‘m new to FP, I might not really understand why. However, because I produced the test coverage as I wrote the production implementation I have a safety net which tells me instantly if I broke anything.

So after a bit of experimentation and copious runs of the specifications, I end up with the following, far more elegant solution. Although elegance is somewhat in the eye of the beholder, so I don‘t expect everyone to agree :)

class MiddleOutNumberSorter {
  def sort(count: Int): List[Int] = {
    if (isOddNumber(count)) (0 until count).map(i => numberAtIndex(i, count)).toList
    else throw new IllegalArgumentException("sort only accepts odd numbers")
  }

  private def isOddNumber(count: Int): Boolean = {
    count % 2 != 0
  }

  private def numberAtIndex(index: Int, count: Int) = {
    val middleIndex: Int = count / 2
    if (index > middleIndex) {
      2 * (index - middleIndex)
    } else {
      2 * (middleIndex - index) + 1
    }
  }
}

As I mentioned, I'm currently learning Scala and FP, so I'd love it anyone reading this could suggest alternative implementations.

Photo: Cwmcarn in the snow

2010-12-05T16:54:42Z

Just been mountain biking at Cwmcarn, it was interesting riding, and beautiful.

Human fallibility: A simple argument in favour of unit testing

2010-10-28T14:44:03Z

I was asked about TDD recently. The discussion was in the context of the polarised views with regard TDD and even unit testing. The conversation reminded me a little of the response to a post I wrote a while back.

One argument against TDD and (possibly unit testing in general) that I had in a comment to my Why TDD: Freedom to refactor post, in particular response to the assertion that unit tests evaluate the correctness of features, was the following:

You can do that with your brain and your own powers of reasoning…

The essence of this argument, as I understand it, was expressed to me recently. Essentially that – as a ‘good developer‘ – you can evaluate your code and your software yourself without the need for unit tests.

Obviously I don‘t agree.

This kind of evaluation of the correctness of your code requires constant or repeated human attention. My argument against this point of view is simple:

Human beings are fallible, they get tired, they get lazy, they get ill and they get run over by buses. Tests that rely on human beings to attend to those tests or require a human's expertise to verify the correctness of those tests are therefore not as reliable, reusable or portable as tests that can run unattended and verify their own success.

Utah Mountain Bike Trip. Day #4

2010-09-23T05:29:30Z

Rest day…

... so we only did a 3 hr ride (Hurricane Rim) and an 8 mile hike up a very high mountain (Zion National Park, Observation Point).

George, Johanna and Pierre pinning it on Hurricane Rim

George, Roddy, Russ, Pierrre and Johanna on Hurricane Rim

Johanna giving a high altitude hula lesson at Observation Point, Zion National Park

Russ annoying a rather large spider

Utah Mountain Bike Trip. Day #3

2010-09-22T12:42:44Z

Little Creek and Gould‘s Trail

Utah Mountain Bike Trip. Day #2

2010-09-21T04:51:49Z

Not much energy to write much. I‘ll let the pictures do the talking.

My last day at Move Networks

2010-09-17T12:51:16Z

Today is my last day at Move Networks. I hadn‘t expected to be leaving so soon. I honestly thought that Move was a company that I could put a few years into, grow into and have a significant impact. That all changed recently when the funding ran out, the workforce in the US was decimated and the whole future of the company was suddenly much less certain. After it became apparent to me that the future was becoming no less uncertain as the weeks passed, I decided to entertain an opportunity that had been put my way.

So I decided to move on. I‘ll be leaving one of the most pleasant and progressive work environments I‘ve worked in and a very friendly group of people. It is a somewhat sad day for me.

What is certainly less sad is that, tomorrow, I start my holiday to Utah (coincidentally the home state of Move‘s US operation) for what I hope will be an awesome mountain bike trip with Sacred Rides. I joined Sacred Rides for a similar trip in British Columbia last year. It was a fun, chilled out trip taking in some awesome, world–class trails, guided by expert and knowledgable guides. A really great experience. All indications are that this trip will be at least as good.

When I get back from Utah I start what feels like will be a great new job as a Senior Java Developer at NetDev, in Cwmbran. As exciting as this new job is (and I am very much looking forward to meeting everyone and getting stuck in), I‘m not thinking about that at the moment… Roll on Utah!