Local procedures from Delphi in C#

Pascal has this nifty feature where you can declare procedures inside of procedures. Something like:

procedure procA

    procedure procB
    begin
        // procedure B code here
    end;

begin
    // procedure A code here calling procB
end;

It's not the type of thing I used a lot, but there were times where it came in handy. It was a nice thing to have in the tool belt even if it wasn't pulled out too often. A couple times I have wanted to do this in C# and have resorted to other means.

Today while reading an article by John Cook about C++, I realized this is trivially easy to do in C#: simply use named lambdas. It's one of those things that's so obviously simple and easy, I don't know why it didn't occur to me before.

So, the above Pascal code could be written in C# like so:

public void procA()
{
    Action procB = () => 
        {
            // procedure B code here
        }

    // procedure A code here calling procB()
}

Stepper motor references

Recently I have been playing around with stepper motors on my Arduino. (An overview of one project is on my photography blog.) Here's a list of online resources I've found helpful in my education:

How to wire a stepper motor has a good overview of the different types of steppers and how to identify the wires on an unknown motor.

Circuits for Unipolar motors on the Arduino site uses a ULN2003 or ULN2004 chip. One circuit has a couple resistors and a diode to allow two pin control of the motor. The other uses only the chip but requires four pins. I built the two pin configuration and it worked flawlessly. Note: the ULN2003 will only source up to 500mA. Higher current motors will cause its magic smoke to escape.

Stepper motor controller circuit uses two logic chips, four each of resistors, transistors and diodes and is controlled by two pins. Since it uses discrete components, it's easily modified for higher current motors than the ULN2003/ULN2004 can support. I haven't built this one, but have the components to do so in the future.

The 28BYJ-48 stepper motor is a really cheap, high resolution stepper motor that comes in both 5V and 12V ratings. Not sure how reliable it is, but so far in my experiments it has worked well. It has a 64:1 reduction gear head built into it, so it is pretty high torque for the current draw (I think it's spec'd to be around 250ma) and a whole lot of steps per revolution.

Stepper Motors and Control is a good overview tutorial. It includes logic charts for different ways of driving stepper motors for different purposes: lower power, higher torque and higher number of steps. It also talks about identifying different types of steppers and how to select a current limiting resistor.

I'll update this list if I find anything else that seems like it'd be good to have here.

There and back again: A Cursor's tale

I've been working on UI code recently and have run into this quite a bit:

Cursor = Cursors.Wait;
SomeLongRunningTask();
Cursor = Cursors.Default;

Pretty straight forward code. I see this type of thing a lot, not just in the C# code I'm working on now, but I've seen this in the past. In other languages. On other platforms. It's a common practice. The problem is it only works in some cases.

This will have problems if any method in the "long running task" does the same thing. The cursor will be set back to default prematurely. Of course, this is easily solved by saving the old value prior to setting the new one.

var oldCursor = Cursor;
Cursor = Cursors.Wait;
SomeLongRunningTask();
Cursor = oldCursor;

This is an improvement but will still fail if an exception is raised. This can be fixed with a try/finally.

var oldCursor = Cursor;
Cursor = Cursors.Wait;
try
{
    SomeLongRunningTask();
}
finally            
{
    Cursor = oldCursor;
}

Ok. So now we have some code that works reasonably well. The issue now is one of code maintainability and clarity. Every method that needs to change the cursor needs to add nine lines before it can do any work of its own. It's nine lines where bugs could hide. It's nine lines obscuring the real purpose of the method. There's got to be a better way.

Way back in my Delphi days, I had a small class which handled this chore for me. The constructor took a parameter containing the new cursor. The current cursor was saved in a class field, the cursor was changed and the constructor finished. The destructor simply set the cursor back to the saved value. In that environment, interfaces were reference counted and destroyed when the reference went to zero. The compiler took care of all the bookkeeping automatically. So I could create an instance of this class, store it in a local variable and, when the variable went out of scope, the object was destroyed, resetting the cursor. It worked really well. One line to change the cursor to whatever I wanted and it automatically reset to the original value when done. Pretty sweet.

Unfortunately, C# does not have any deterministic way of handling object lifetimes. This is one of my biggest frustrations with the language. The closest thing we have is the hack that is the using statement. Since this is the best we have, I have put together a class, shown below, similar to the one I had before. The constructor takes the new cursor value and control whose cursor should be changed, saves the current one and, in the Dispose method, resets it back. Now we can have three simple lines with one code block rather than the nine lines with two blocks. It's a big improvement although still not the single line like I'd prefer.

In use, it looks like this:

using ChangeCursor(this, Cursors.Wait)
{
    SomeLongRunningTask();
}

Arguably, this is a bit cleaner than even the first code snippet we started with.

Since this takes a FrameworkElement, it's WPF specific. It'd be easy enough to change the type to work with WinForms, if needed. The same technique could be used to handle other things where a state needs to be set to one value and then reset when some unit of work is done. For example, if using TreeViews with BeginUpdate/EndUpdate pairs.

Hope this helps someone.

using System;
using System.Windows;
using System.Windows.Input;

namespace CursorResourceProtection
{
    public class ChangeCursor : IDisposable
    {
        private FrameworkElement Context { get; set; }
        private bool Disposed { get; set; }
        private Cursor OriginalCursor { get; set; }

        public ChangeCursor(FrameworkElement context, Cursor newCursor)
        {
            Disposed = false;
            Context = context;
            OriginalCursor = context.Cursor;
            context.Cursor = newCursor;
        }

        public void Dispose()
        {
            Dispose(true);
            GC.SuppressFinalize(this);
        }

        protected virtual void Dispose(bool disposing)
        {
            if(Disposed)
                return;

            Context.Cursor = OriginalCursor;
            Disposed = true;
        }

        ~ChangeCursor()
        {
            Dispose(false);
        }
    }
}

Non-int array indexes from Delphi in C#

In Delphi, array indexes can be any type that resolves to an integer, not just integers. So for example, enum and bool types can be array indexes. This can be handy in many situations to reduce a if-then or switch construct to a simple assignment. A simple, contrived example:

MyEnum = (item1, item2, item3);
...
function enumToString(value: MyEnum): string
begin
switch(value)
case item1: result = "Item one";
case item2: result = "Item two";
case item3: result = "Item three";
end;
end;
...
SomeLabel.Caption = enumToString(value);
...

becomes something like this:

MyEnum = (item1, item2, item3);
enumToString[MyEnum]: string = ("Item one", "Item two", "Item three");
...
SomeLabel.Caption = enumToString[value];
...

Not only does it reduce code, it also reduces possible bugs. Consider what happens when a value is added to MyEnum. The first example will simply return an empty string creating a possible silent failure that hopefully will be caught when tests are run. The second will generate a compiler error, forcing the programmer to intentionally decide what to do.

In C#, array indexes must be one of the four integer types: int, uint, long or ulong. I really miss the ability to use bools and enums. While lamenting this lack as I looked at some code today similar to the original switch statement, I realized I could use a generic dictionary. The new code looks like this:

MyEnum = (item1, item2, item3);
enumToString = new Dictionary = {{item1, "Item one"}, {item2, "Item two"}, {item3, "Item three")};
...
SomeLabel.Contents = enumToString[value];
...

On one hand, it is a bit more wordy than the Delphi array; on the other, it's clearer how things are associated in the initializer. The biggest drawback is it doesn't have the compiler error when things are added to the enum. This is mitigated a bit by the runtime exception generated by a missing key; it's not quite as silent as just returning nothing in the original code. However, it still depends on good test coverage to find it.

Arduino notebook: 16x2 LCD display (Part 2)

How to change the default behavior

Prologue

My last article in this series talked about why I chose Sparkfun's Serial Enabled LCD display kit and how to build it. One of the reasons it caught my eye was because it uses an Arduino as the controller for the display. I figured it was pretty busy doing nothing most of the time and thought it could be used for other purposes in addition to driving the display. Upon further investigation, it turns out I was right.

Nicole, a friend of mine, recently e-mailed me about a photography project she was interested in doing but didn't want to spend the money for a professional rig to do some of the things involved. She asked if I had any ideas. I'd already given some thought to the problem, the investigation of which led me to the Arduino platform in the first place. This project was one I had stewing on the back burner for quite a while and it was now time to turn up the heat on it.

One of the requirements was to be stand-alone. It had to allow for some user configuration at the time of use in battery mode, without any other devices attached. This ruled out the obvious easy solution of setting the parameters via USB through a computer. Also, it involved controlling a stepper motor. I immediately thought of the LCD kit. I knew I would at least use it for the display, and hopefully some toggle switches. I had a distant hope I could also use it for the motor control. Since this was going to be a pretty permanent build, I immediately ordered another LCD to use specifically for this project.

After getting a new display on the way, I pulled out my first kit to take a look at it. Sure enough, it had a handful of empty holes on the PCB labeled with both digital and analog pin assignments. Cool. It had enough extra pins to accomodate everything I needed to do. So, I started work on the rest of the project while I waited for the LCD to arrive. (The other details of this project I'll write about in future articles here and on my photography blog Hooked On Light.)

First thing after getting the new kit, I assembled it. It went much faster this time with no of the frustrations I experienced on the first one. It actually worked the first time I applied power.

One of the biggest things I did differently was to use ribbon cable between the display and controller boards. In some ways this made things easier and in other ways it was harder. I think on the next project I'll probably put the header pins that come with the kit in one board and get a socket to solder onto the other board. That will give me a cleaner build like the first one, but with the ability to separate the boards for easier access like I have with the ribbon cable on the second one.

The web site to order the kit indicates the firmware can be reprogrammed with an FTDI Basic Breakout board. I had ordered one with the first kit, but hadn't had a chance to use it prior to this project. Knowing I needed to use this, I also purchased some 90 degree header pins from my local electronics parts supplier and soldered them into the holes on one end of the board designed for the purpose. This allowed the FTDI board to plug onto the controller board, providing a plug for a USB cable to be plugged in.

Now I started looking for instructions on how to actually reprogram the thing. The order page indicated you needed to change a setting in the Arduino IDE and referenced the github page for further instructions. Well, the github page had no other instructions on programming the thing. All it talked about was how to use the board through the serial interface. The software for the firmware was also hosted there. Besides the one sentence on the order page, I couldn't find any other instructions either on those two sites or anywhere else via web searches on how to reprogram this kit.

Reprograming the kit

I figured, no guts, no glory and decided to experiment some. I downloaded the source code from github, loaded it in the Arduino IDE and made a simple change to the splash screen text. Since the splash screen is the first thing you see, I thought this would be an easy way to verify if my changes worked or not. In the IDE, as instructed on the order page, I changed the target machine to Arduino Duemilanove or Nano w/ ATmega328 and hit the upload button.

It compiled.

It uploaded.

And when it reset after the upload, there was my new splash screen text.

Amazing. That was all there was to reprogram the kit's default software. The reason I couldn't find any other instructions was, there weren't any other instructions needed.

Epilogue

After this success, it was simply a matter of changing things to do what I needed it to do for this project. Essentially, I ripped out everything the existing software does and replaced it with what I needed. There are a few lines to initialize the LCD and one function to write characters to the screen that are the same, but everything else is completely new.

Now that I've found how easy this is to repurpose, I think I'll probably use it for other projects in the future too. It's an easy way to get an entire Arduino system up and running in a clean package with a simple user interface and minimal external support circuitry needed.

Arduino notebook: 16x2 LCD display (Part 1)

As I experiment with my Arduino kit, I find I want an easy, self-contained way to display information. The system provides one easy method in the Serial object with its print functions to send things to the computer through the USB port. This works well in development phase when the computer is attached to the board. However, I want to be able to run the kit detached from the computer and still get feedback. When there's limited data, I can use LEDs. They can be on or off to provide one bit of information. Additionally, they can be blinked in various patterns to communicate more than one bit of data. However, this is more abstract than I want. It doesn't strike me as easy, either to program or to use. I just want to read something directly without resorting to Morse Code to get the information.

I also don't want to spend much money.

So, with these three requirements in mind, I searched around. It seemed an LCD display was the way to go, as I found a couple different options. The first is to connect the LCD directly to the Arduino kit. At about $10, it is an inexpensive choice. It requires a number of wires and a moderate amount of programming to drive the display. Yes, this meets the cost and self-contained requirements, but isn't as easy as I would like. The second option is a kit with one of these LCDs and support circuitry to allow me to simply hook power, ground and a single data line to my Arduino. It uses the same Serial object to display information as the computer uses to receive data via USB. So, it satisfies the easy requirement much better, is more self-contained than the bare LCD, and at $25, still doesn't break the bank.

Upon further investigation, the support circuitry turns out to be an Arduino. I'm pretty sure this controller is sitting idle, spinning around doing nothing, most of the time. In addition to getting an LCD display, I believe this option in essence gives me a second Arduino that I might be able to reprogram to have additional features.

With all this going for it, I purchased this kit from SparkFun.com.

How to build a Sparkfun Serial Enabled LCD kit (LCD-10097)

Some assembly required

(Click any of the pictures for a larger view.)

This is definitely a kit. It comes as seen above: a printed circuit board (PCB), some capacitors, a resistor, a crystal, a transistor, a potentiometer, a 28-pin chip, the LCD screen assembled on its own board and miscellaneous hardware. All this comes in a plastic bag in a box.

There were no instructions with the kit, nor could I find any online. To make up for this, the circuit board was well marked with silk screened values for the components and orientation marks for items that have to go in one way. Since I have put together many electronics kits over the years, I wasn't intimidated by this at all. If you are new to building kits, not having instructions might put you off a bit. However, don't let it. It's really pretty simple if you know how to solder. I'll outline what I did below to help you along.

As an overview, I basically installed the smallest components first and worked my way up to the larger ones.

First, I installed the small, ceramic capacitors and the one resistor. There are two values for the capacitors. The capacitors labeled "220" go in the locations marked "22pF" on the PCB and "104" capacitors go in the locations marked "0.1uF". The resistor goes in the place marked for it. How these components are oriented on the board does not matter. Either lead can go in either hole.

Next I added the transistor, crystal and electrolytic capacitor. The crystal can go in either way. The transistor and capacitor however need to be oriented correctly. For the transistor, make sure the flat side of the component matches the outline on the PCB. The capacitor has a light band with a minus sign in it running down one side. Make sure the lead next to this marking goes in the hole with the minus sign silk screened next to it on the PCB.

Following this, I added the power/data connector and the potentiometer. These pretty much can only go in one way. Just match the components to the silk screen outlines on the PCB.

After installing all the discrete components, I went to my local electronics store and picked up some DIP sockets. Generally, I don't like soldering IC chips onto boards directly. If I damage them with too much heat while soldering, or do something else stupid to cause them not to work, I don't want to go through the hassle of unsoldering all those connections to replace it. I've had to do that before and it's no fun.

The store didn't have any 28-pin DIP sockets in the narrow variety, but two 14-pin ones will sit nicely next to each other without any problems. On the PCB, note the silk screened outline. One end has a flat edge and the other end has a divot taken out. By convention, the edge with the divot marks the end where pin one goes. The sockets should also have one end that's flat with the other end notched. It's best to put them in with the same orientation as the silk screen. This makes things much less confusing. After the sockets are soldered in place, the chip can be inserted into it. The chip also has a notch in one end. Just line up all the notches and everything should be good.

Finally, I did a good visual inspection of all my solder joints with a magnifying glass. The next step involves soldering the two boards together. Once this is done, it will be very hard to take them apart, so I wanted to be sure everything looked good.

There are three primary things to look for:

1. Solder bridges. This is when solder spans two pads when it shouldn't. This is particularly easy to do on the pins for the IC sockets, but they can happen anywhere.
2. Cold or missing solder joints. When working down a row of IC pins, it's easy to accidentally miss one. A cold joint is when one part of the joint, either the PCB pad or the component leg isn't hot enough to melt the solder but the other one is. Solder will flow onto one but not the other. Both cold joints and missing joints can cause intermittent or unreliable operation.
3. Solder splatters. Sometimes solder will splatter or drop onto the board where it shouldn't be. Make sure there isn't any messy blobs anywhere. If you do find one, typically they'll just scratch off pretty easily.

After the visual inspection, I soldered the header to the LCD's PCB. Then I placed a small piece of cardboard between the two PCBs to function as a spacer. I placed the controller's PCB on the other side of the header's pins and made sure the two boards were parallel. I wrapped a bit of scrap wire around the assembly to hold them together while I soldered the two end pins. Once they were soldered, I took the wire off and finished soldering the rest of the pins to the controller board. When all the pins were done, I removed the cardboard and declared myself finished with the construction phase.

Batteries not included

Now that I had the physical assembly done, the next step was to hook it up to the Arduino. I went to the oracle of all things technical, Google. Unfortunately, with a moderate amount of searching, I didn't find any definitive instructions regarding what to do next. I found some forum postings that alluded to using the Serial object and some others that said to just hook it up, but didn't give any details.

I figured I probably couldn't hurt anything too badly with a bit of guess work. The connector for the LCD was clearly marked with 5V, Gnd and Rx, so I connected the red wire to the 5V pin, black wire to the Gnd pin and the Rx wire to the Tx pin on the Arduino. Typically in serial communication, transmit on one device goes to receive on the other. With the normal trepidation that I always have turning on a kit for the first time, I plugged in the USB cable.

The backlight came on and no smoke escaped. Well, that's a good first step. The SparkFun site points to some documentation on github, but it only talks about command sequences to control the LCD, it doesn't talk about how to talk to the LCD. It presupposes you know how to do that. I found a library that seemed to imply it worked with this kit, but didn't outright say it did. When I tried using some of the code from it, I got nothing. At this point I didn't know if it was a software problem or a hardware problem. I turned everything off, unconnected the LCD and took a magnifying glass to the kit. I looked at all the solder joints I could. Unfortunately, most were in the middle where I couldn't see. I examined all the legs on the chip going into the socket to make sure none of them got folded up underneath the package instead of going into the socket. They all looked good. I hooked everything back up and tried again. Nothing. I tried more searching online to see if I could find more information. Nothing. Arg. Frustrated, I set it aside for a week.

When I came back to it, I rechecked all the hardware I could with the magnifying glass. I plugged it in and tried writing to it. Same result as before. The backlight came on but I couldn't get it to display anything. Looking at the library code, it seemed a bit suspect, but even if it was wrong, I thought I should still see something. I searched more online but found no new information. One last time I decided to take a look at the kit before contacting customer support. And then it hit me. Pin one was in the wrong position. I couldn't believe it, I'd stupidly put the chip in backwards. I pulled the chip out and put it in the correct way. This time when I applied power, it showed a splash screen. Oh, much, much better.

I uploaded a program that I expected to put some data on the screen and it worked. Well, sort of. That code that looked suspect in the library I used didn't work properly. I suspect it was for some other serial controller with a different command set. I threw together some code based on the manufacturer's documentation on github and suddenly it worked properly. Woo, hoo!

Lessons learned

1. If you build this kit, expect to see a splash screen on power up. This will tell you if the board works or not, independent of serial communication.
2. Make sure to get some sockets for the chip. I'm sure glad I did. It would have been a nightmare if I'd accidentally soldered the chip in backwards and then had to desolder first the header and then the chip itself to correct the mistake.
3. If I ever build another one, I will get a plug for the header. This would allow the two boards to plug together rather than be soldered together. A ribbon cable could also be placed between them for more flexibility with mounting.

That's about it for this write up. Next for this project is to figure out the best way to communicate with it. I need to look at the library to see if I was using it wrong or if it really is designed for a different unit. After that, I plan to investigate reprogramming the LCD's controller to investigate using it for additional processing tasks.

A Geek's Guide to Sports

I understand there is a big sports competition coming up this weekend. I don't know much about sports, but thought I'd share what I do know with my fellow geeks so they can be more informed around the office for water cooler conversations.

American Football

This is where two smart guys are mad at each other. They each have recruited two groups of really big supports. By "really big," I mean physically huge. Each group is trying to kill the other group's smart guy while at the same time trying to keep their smart guy from getting murdered by the opposing side's hit squad. They do this in a strange, alternating dance, where one team tries to kill the other's smart guy for a while and then they trade off and the second team tries to do in the first team's smart guy. To make their homicidal intents socially acceptable, they hide their true, life-ending goal behind a facade of moving an oblong ball from one end of a grassy expanse to the other.

Rugby

This is a variation of American Football, just without the smart guys.

Australian Football

This was developed in the southern hemisphere where everyone is upside down. I think the blood rushes to their heads since they've confused the rules. Like American Football and Rugby, there are two teams. However, half of each team plays American Football while the other half of each team plays Rugby.

Basketball

This is a track and field sport for tall people during the winter months when it's too cold to go outside. It involves a lot of running back and forth and back and forth (the track part) and jumping and heaving heavy objects (the field part) over their heads attempting to get it into a basket about the same size as the ball. All the while the other side is trying to stop the person with the ball. There are a couple guys running around dressed like zebras who randomly stop the action. Everyone gets angry at them. I think this has something to do with some hunting ritual that has slipped into the game. It's probably to remind us that sustenance is more important than games and we need to stop once in a while, come together and remember to focus on the hunt. Does zebra taste good? Seems like an odd animal to incorporate into the game.

Soccer

(This is known as Football in the rest of the world which actually makes more sense than what Americans call Football since it actually uses the feet whereas American Football uses the hands. Perhaps we should rename American Football to Handball. It'd certainly be more logical.) Anyway, soccer is just the same as Basketball except it's for short people who can't use their hands.

Hockey

This is soccer for people living in Canada where it's too cold for grass to grow. Since it's icy all the time, they play on frozen ponds while wearing skates. Other than that it's just like soccer. I think they must be really mad they have to play on ice since score is kept based on how much blood is shed.

Baseball

The strategy of this game is to play it so slow that you bore the other team into forfeiting. It's played with a small ball that, one by one, each team member tries to hit with a thin, long stick. Since these two items are both so small, they only come into contact randomly, thus prolonging the game. This is a great strategy to make the other team think they really are trying to move the game along when in fact it's simply a delaying tactic.

Cricket

The English have taken Baseball and really perfected the underlying goal of boring everyone. They obviously have much more patience that Americans though and have adapted the game to prolong it even further than the short-attention spans we have here in the colonies.

Well, now that you're better informed, I hope that helps you the next time the topic of sports comes up in the lunch room or during hallway conversations.