Lifetime

Here’s an interesting question spawned after a discussion with a fellow developer, while discussing the need to use development tools like version control, test suites and methods like TDD/ATDD:

How long do you plan/hope your project to live?

Is it hours, weeks, years, millions of years, maybe more?

a) If the answer is hours, then just go ahead and hack away, since you won’t care about the code in a couple of hours, it does not matter what process/methods and techniques you use when you develop it. If you get the job done, then it’s OK even to write it on a napkin and ask your dog to compile it (if you have a dog, otherwise let your cat run it as interpreted code). A good example in this category is TopCoder algorithm contest problems. When I participate to one of those I don’t really care for writing and tracking detailed requirements (you get them anyhow in the problem statement), writing test suites myself, running a static check, do a peer review of the code or track the changes with a VCS. That would be a total overshoot and probably any of the tasks would actually not fit nicely within the time allocated for the contest.

b) If the answer to the above question is more than hours, then you’re probably building something that requires maintenance, fixing bugs, new features and will require something else than a human’s brain to hold most of the knowledge. And here comes the issue/bug tracking system, requirements and design documents (or specs), documentation, test suites, version control, traceability matrixes, and so on. All these are tools we use in order that we are able to track what’s going on in the project across days/weeks/years (and teammates or parties involved).

One interesting remark here is that many projects start as a) and then becomes a b). Someone hacks an idea in the garage and then people decide to overtake the prototype as production version 1.0 (protoduction).

That’s OK (sort of).

But you have to realize that you’re not a), you’re b) now, a full-blown application that has a desired scope of years or more and will probably have several releases, that you want to be able to handle gracefully, so fire your desired search engine and get some development tools.

Posted in Software development | Tagged , , , , , , | 1 Comment

Build, build, build

I don’t want manual builds. I just want to commit to the version control my changes and there should be a background process doing the builds for me. Daily (or nightly), depending how you prefer it. That’s because I’m lazy and this task can be easily automated.

Thus, long live continuous integration server. I’ve been using TeamCity while working on my past hobby projects, and every time I set it up I am amazed.

When Joel Spolsky was talking about how important it is to remove barriers for users to start using a product, he couldn’t be more right about it. And TeamCity has very few barriers.

I’ve decided to give Mercurial a try on this project, although I’m currently only one developer working on it. TeamCity pulls snapshots for the build from svn, Mercurial, TFS, VSS (which was kind of dead, but anyhow), git, Perforce and so on. Virtually no barriers for the version control side.

Also, TeamCity supports a couple of build runners, including Visual Studio, Ant, etc. And it’s just so nice that you can use it for free up to 3 agents and 20 build configurations. Sounds like no barriers for build runners too.

The setup is flawless (every time I have installed TeamCity in the past – or upgraded it for that matter), it just worked, no hassle. The build agent was always configured without any issues.

Generally configuring the whole thing for me takes less than 15 mins from nothing to a basic running build.

All setup is done via a browser, no need for rich clients, just login to the server and you can immediately change the setup or track the build status.

The first Oscosaur successful build with TeamCity

The first Oscosaur successful build with TeamCity

I’m planning to write the unit tests using Visual Studio, since I’m familiar with the environment, and TeamCity can also natively run mstest tests as a build step.

Thus I decided to build both flavors for the project:

  • a Visual Studio project that contains all HW independent code and tests
  • one (or more) target projects. Currently the target IDE that I settled on is IAR Embedded Workbench and obviously the target build step is done with the IAR compiler.

A nice side effect of the fact that I am using a dual platform build is that I am forced to abstract the HW and all target dependent things (like data type defines). So if (or better said when) I will switch to a different compiler/target board I don’t need to go and sanitize all my code so that it does not contain any specific uC/target dependencies. But I’ll stop beating the dead horse now, it’s pretty obvious for everyone that that’s what a HAL should do.

There’s much more about TeamCity that appeals: automatic versioning, agents can be configured for affinity for specific projects, integration with IDEs, etc.

Build setup to be triggered once a day and upon any check-in.

Build setup to be triggered once a day and upon any check-in.

There’s other CI servers out there (Hudson, Cruise control, etc.), I picked TeamCity because I find it easy to use, configure and almost bug free (up to now).

Posted in Oscosaur, Tools | Tagged , , , , , , , | Comments Off

The name

Everyone knows Dilbert. Or at least everyone that is likely to read this blog.

The first episode in the Dilbert series is “The Name“. It’s “When Dilbert wakes up after another night of having the egg dream, he discovers he isn’t the only one to have had the dream. His fellow employees tell Dilbert about a guy, Chicken Man, who turned into a chicken after he was put in charge of a product that he was unable to name.

I found that episode really funny, specially the part where the pointy haired boss is stressing that first you name the product and then you see what it does.

Somehow I get at least part of the name for my projects before I even know what the project is about, that’s why I feel compelled to have the Dilbert reference (plus there’s never enough Dilbert references to go around). And now let’s see why the name of my hobby project is really so ugly.

It all started a while back, when I was working for Siemens. Siemens is a big corporation and like in any big corporation, it is a requirement to have all kind of jokes circulating around. It even seems as if some people are paid to browse the Internet and send the other guys huge amounts of hoax and joke mails.

One day me and one of my colleagues obviously got the one about Bjarne Stroustrup, where supposedly he’s having an interview where he states that C++ was meant as a joke and “anyone with half a brain can see that object-oriented programming is counter-intuitive, illogical and inefficient…”

This was obviously a fake interview, however it was quite funny and there was a remark that was directly about Siemens:

“Now I hear that Siemens is building a dinosaur, and getting more and more worried as the size of the hardware gets bigger, to accommodate the executables. Isn’t multiple inheritance a joy?”

At the time I was working on a hobby project for screen sharing (a VNC like app with integrated HTTP tunneling and another bunch of features), which was obviously written using C++. So jokingly I called that “my dinosaur” when talking to my colleagues.

The net result is that all my hobby projects since then have a dinosaur-ish name, thus the current project is no exception from the rule, it’s a dinosaur alright …



Posted in Oscosaur | Tagged , , | Comments Off

JTAG

It stands for http://en.wikipedia.org/wiki/Joint_Test_Action_Group.

I can’t go back to blindfolded development. For a decently complex piece of software it’s very hard to advance without a debug probe.

So I got a debug probe that supports JTAG/SWD, and I decided for a yellow  J-Link (http://www.iar.com/website1/1.0.1.0/369/1/).

IAR J-Link for ARM

Posted in Oscosaur | Tagged , , , , , | 2 Comments

First prototype board

Long time, no post.

Finally, some time ago I decided to use one of  Luminary Micro’s MDL-IDM-L35 (http://www.luminarymicro.com/products/mdl-idm-l35.html).

It has a very nice small TFT display with an attached touch panel, the display controller is on the prototype board, it has a Cortex M3 @ 50 Mhz on it, it has a decent number of break-out pins to connect to, and it has a ton of other nice things (including an SD port). If there’s one word I need to qualify this board, I’d use “juicy”!

Of course this is still a prototype board and it is not the final board to place in the oscilloscope.

Posted in Oscosaur | Tagged , , , | Comments Off

To ARM or not to ARM

After spending some time looking around which platform I would use for Oscosaur, I settled on ARM (http://www.arm.com/).

I was oscillating between ARM and AVR (http://en.wikipedia.org/wiki/Atmel_AVR), but I settled on ARM, primarily because of a wider range of tools and manufacturers. Also because it’s hip these days, but that’s not that important.

Even more specifically I chose the ARM Cortex M3 family, even though this sounds like a bit of overshoot (http://en.wikipedia.org/wiki/ARM_architecture). Cortex M3 runs at 1.25 DMIPS/MHz, which is definitely neat.

There are a bunch of ARM Cortex M3 manufacturers, Texas Instruments, Atmel, ST Microelectronics, and many more. So a wide range of manufacturers to chose from.

Then the hardest part was to decide what I will actually use. Now the fact that there are so many manufacturers and kits out there backfired.

The main 2 choices were basically:

  • Use a prototyping kit.
  • Build a board from scratch

Let’s look at both a bit.

1. Using a prototyping kit is easy, just settle on one, order it and use it. This one has some big pros:

  • Fast
  • Reliable (I would hate to know how much debugging time I need to waste to see that I made a tiny mistake when soldering one uC pin).
  • Cheaper (yes, if you add up all components + the value of the time spent, it is definitely obviously cheaper to buy a prototype board)

2. Building it myself would be harder (I am a software guy after all, even if I wrote a lot of embedded software in my days). This one offers some pros too:

  • Complete control over the HW design
  • It’s cooler from a geek perspective.

So my conclusion is that if one can find a prototype board that suits the project needs, there’s no question about it: it’s better than building it yourself. But nothing new there.

Now, for my project I want 20MHz as sampling frequency. To achieve that I need some extra hardware besides the on-chip ADC of the ARM uC. That part I would need to build by myself anyhow, so it does not really influence which of the two choices mentioned above I would pick.

So I decided to split with my project in at least 2 phases:

  1. Limited to 1 MHz. Build a first version of Oscosaur (let’s call that v 0.1) that has a limited acquisition rate. 1MHz is pretty common around in ARM chips, so that would not be a problem.
  2. Add the input circuitry for acquisition at 20MHz.

Anyway, I’m sure that the project would evolve in a couple of iterations (I’m not a big believer in the big design up-front idea – it purely does not fly). So, what I have to do is just focus on the first iteration, which is get a version 0.1 which has all the functionality I need, while being limited on the acquisition rate.

So, for the first iteration it would be very very easy for me to build everything on a prototype board, in order to speed things up. And later in the next version, I’ll dive into handling the custom parts.

And the prototype board winner that will be used in first version of Oscosaur … drum-rolls …, well, in the next post.

Posted in Oscosaur | Tagged , , , , | Comments Off

What to use, or maybe, what to build?

A very interesting thing to decide is what to use for building a hobby oscilloscope.

By what to use, I mean which micro-controller and what hardware. The number of choices are mind-boggling in all areas (chip, PCB, case, display, display controller, etc.).

And of course the way this kind of decisions should be taken is based on what requirements are there. Requirements are the root of all evil here. My best developer friend (to which I’ll keep referring throughout this blog) kept saying that most issues in software development can be traced to requirements.

So let’s see what for a hobby oscilloscope I want. Let’s list the functional requirements briefly (the ones that I know of now at least):

  • It has to use a display (duh)
  • It has to use a touch display. More on this in another post.
  • It has to display analog signals and digital signals.
  • It has to support frequencies up to 20 MHz for both analog and digital signals.
  • It has to be compact. I would hate a PC like size scope. That just sucks.
  • It has to be able to run on batteries or AC power.
  • The case has to be transparent. This is purely for the geek factor. If its not transparent, it would just look like any other commercial oscilloscope.
Posted in Oscosaur | Tagged , | Comments Off

Oscilloscope

When I told the people around me that I’m building an oscilloscope, I obviously got asked why.

There are several answers:

  • Because I can.
  • It’s fun.
  • It involves writing embedded software and dealing with hardware, a thing that I purely like. Really I can’t even compare seeing something hardware come to live with even the most complex object oriented designs.
  • It is a complete project that involves writing the software, interacting with and even building some hardware, it requires a design that’s not really trivial.
  • It is a very good way of getting acquainted with a new platform (ARM in my case).
  • It has the potential of motivating by increasing self esteem.
  • Far from being the last bullet point, it is a perfect project to perfect TDD techniques in embedded. More about this in another post.
Posted in Oscosaur | Tagged , , , | Comments Off

“Why” in 42 words

Since introductions like “Hi! My name is Dan and I have <insert number here> beautiful children” creep me out, I’m just going to tell you why I started this blog.

In order to share ideas about building an oscilloscope with anyone interested.

Posted in Oscosaur | Tagged , , , | Comments Off