Matt Godbolt’s blog

Coding

LCD screen hackery

Although I haven’t touched my Weebox project very much recently, I’ve been thinking about the LCD display. It’s a one-bit-per-pixel 320×64 display, with a simple controller (the HD61830). The controller has 8KB of on-board video RAM, which is more than enough to hold the 320×64÷8 = 2560 bytes of screen. The controller allows me to set and clear bits in bytes of screen memory, or set bytes to specific values. It also has a register which controls the start of the displayed image in RAM.

My driver code currently just points the start of screen to the beginning of the screen memory, and then manipulates the first 2560 bytes of the memory to draw the text and images. However, I’ve had an idea to get something out of those remaining 5632 bytes.

The LCD display is pretty unresponsive — it takes a noticeable amount of time to go between black and white, and it occurred to me that I might be able to take advantage of this: If I were to quickly toggle pixels between on and off then I might be able to simulate shades of grey.

However, writing to the screen memory is pretty slow and CPU intensive — over a microsecond per byte, with the CPU managing the process of bringing enable lines and address lines up and down to talk to the LCD controller. I wouldn’t be able to do much else at the same time if I were to just continuously flip pixels on and off individually.

What I plan on doing instead is upload multiple images of the screen into the LCD display’s memory, and then alter the start of screen to quickly switch between them. For example, imagine I have two images in video RAM, and then I change the start of screen to show one image, and then the other, flipping between them say ten times a second. Any pixel that’s set to be on in both images will remain on all the time, and similarly any pixel that’s off will remain off. However, if a pixel is on in one image and off in the other, then its colour will be flipped back and forth between black and white ten times a second. I’m hoping this will give me a kind of 50% grey shade.

As it happens there’s enough room to fit three screens in video memory. Each screen would be like a plane in a three-bit-per-pixel bit plane image. Initially I thought I’d show each screen image for the same amount of time, which would make the 8 possible values for each pixel correspondingly:

Using this encoding means 1, 2 and 4 are all “stay on 33% of the time”, and 3 and 6 are “stay on 67%”, but at slightly different phases. I imagine there would be no visible difference the phases, so this make this encoding pretty redundant — I have eight values but only three possible shades.

My next idea was to hold the first image for 4N units of time, the next for 2N units, and ther last for N units. That way I actually get eight different amounts of “on time” per pixel:

This looks great on paper – I should be able to in theory make a one-bit-per-pixel display display eight different shades of grey.

Except… in reality it won’t work like that. The response curve of an LCD display is non-linear, so I’ll need to experiment with the display to work out appropriate settings. For example, does being on for 14% of the time actually correspond to a useful “light grey”? Also, it could be that I can’t change the screen address often enough to make this viable. Or having seven time steps makes the display too flickery.

Once I get the Weebox working again, I’ll run some tests and post what I find. And then I need to think of what to do with the last 512 bytes of unused screen RAM…

Filed under: Coding

Posted at 14:30:00 BST on 5^th June 2008.

Permalink

The C library's strcmp routine is badly named

One of those gotchas you find early in your C programming career is the strcmp string comparison routine. It takes two const char pointers to null- terminated strings and returns a integer: zero if the two strings match, -1 if the second is lexicographically less than the first, else 1.

However, it’s really easy to forget this and assume the routine compares for equality, and that the return value is effectively a boolean. I’m sure we’ve all forgotten this at some point and ended up debugging a problem which turns out to be inverted logic in a string compare.

Why can’t strcmp return true for equality? Well, its return value is a tri-state value, of which two states indicate non-equality. That means the only choice for indicating equality is zero.

A common idiom for using strcmp is this:

if (!strcmp(name, "Bob"))
    printf("Hello Bob");

What’s with the logical not operator? Of course it’s to turn the implied false (from the zero if the strings are equal) into the true needed to compare for equality (which is what the programmer actually wanted). It’s easy to forget the not operator. Another common idiom is:

if (strcmp(name, "Bob") == 0)
    printf("Hello Bob");

Again, it’s easy to forget the == 0 part. I’ve also seen code that incorrcctly combines both:

// This doesn't work...
if (!strcmp(name, "Bob") == 0)
    printf("Hello Bob");

This kind of bug is hard to spot when reading through code. You tend to see what you expect to see there, not what’s actually there.

I think it would have been much less error-prone if the function had been named strdiff. To me this better indicates that the function returns the difference between two strings. The example code reads a little more naturally:

if (!strdiff(name, "Bob"))
    printf("Hello Bob");

Of course, even this isn’t an ideal name. One might reasonably expect the difference between two strings to have a magnitude, not just a sign.

An alternative, suggested by Malcolm, is to separate the operations “are these strings the same” and “is this string greater than or less than”. Perhaps it would make more sense then to have a function streq (returning a boolean) checking for equality, in addition to the strdiff function. (The strdiff function is still useful inasmuch as its return value is compatible with sorting functions like qsort.)

The example code would then be:

if (streq(name, "Bob"))
    printf("Hello Bob");

Filed under: Coding

Posted at 12:45:00 BST on 14^th April 2008.

Permalink

Launching a debugger automatically

I’m spending a fair amount of time debugging at the moment. The particular application I’m looking at is a suite of related server processes which spawn each other and are very multithreaded.

I’ve been looking for was a way of getting my debugger “in” right at the start of the one of the servers, even when it was launched by another server process. Ideally, I’d just put a DebugBreak() somewhere at the beginning of the server, and use JIT debugging to attach at that point.

Unfortunately, for some reason that wasn’t working; by the time the debugger had attached, the call stack was out in the uncaught exception handling code. Not very useful.

After some searching around, I found something in Windows I’d never heard of before, which I thought might be the perfect thing. Apparently, with the right registry keys, you can make Windows automatically debug a given executable. The details are on MSDN.

This seemed like a perfect solution. Whenever the server is run, the debugger is launched with the parameters to debug the executable. However, a fresh new IDE is started every time, and the process isn’t started automatically.

By the time I’ve started the process myself — annoyingly forcing a save of the solution file, with all the attendant dialogs that requires — the server which spawned the process has timed it out and started another copy. That timeout, coupled with the plethora of new IDEs popping up everywhere made this approach unusable.

In the end I rolled my own solution, querying the relevant registry key myself, launching the JIT debugger in code and then awaiting its attachment using IsDebuggerPresent().

Filed under: Coding

Posted at 13:32:00 GMT on 19^th February 2008.

Permalink

Things I didn't know about Visual Studio's Debugger

I’ve used Visual Studio in its various incarnations since version 5.0, and I’m still finding cool little things out about it. Today, while Googling about for debugger-related things, I stumbled across a CodeProject post which contains a real gem. It’s possible to create a watch on the value of GetLastError() — the pseudovariable @ERR reflects the value of the last error generated.

Additionally, the format specifier hr formats the number as an HRESULT style identifier, so putting @ERR, hr in a watch pane shows values like S_OK. Previously I’ve only known about the number formats (e.g. 12 to show 12 elements of an array) and x to show stuff in hex.

Dead handy stuff, and worth checking out the original article for even more pseudovariables.

Filed under: Coding

Posted at 17:42:00 GMT on 18^th February 2008.

Permalink

Copyright 2007-2008 Matt Godbolt. Unless otherwise stated, all content is licensed under the Creative Commons Attribution-Noncommercial 3.0 Unported License.

This blog is powered by the MalcBlogSystem by Malcolm Rowe.

Note: This is my personal website. The views expressed on these pages are mine alone and not necessarily those of my company.