I'm programming a VFD display to show a simple bar (filled rectangle) and I can do it, but I'm not sure why this code (from the manufacturer) is working:

void Noritake_VFD_GU7000::GU7000_drawImage(unsigned width, uint8_t height, const uint8_t *data) {
if (height > NORITAKE_VFD_HEIGHT) return;
command(us_seq, 'f', 0x11); //tell display that we want to upload a bit by bit image
command(width);                  //tell display how wide the image is (in pixels)
command(width>>8);           //tell display....what??? (see below*)
command(height/8);             //tell display how many rows high the image is (in pixels, but each row is 8 pixels high)
command((uint8_t) 0);           //tell display what the starting row is (always 0)
command((uint8_t) 1);           //don't know what this is, but it's supposed to always be 1
for (unsigned i = 0; i<(height/8)*width; i++)  //upload the image itself as an array of bytes
    command(data[i]);
}

The spec sheet says that the width>>8 statement ought to be 0 in all cases, but it's only 0 when width is <256. Otherwise it's 1 (and maxed out, as this is a 512 bit wide array of bits). Y is always starting at zero, why not X?

So why is it ever 1? Why not just make this value 0 all the time?

Or is it always going to be zero because of the re-cast as an 8 bit integer in the function header? In which case my question becomes "Why didn't they just say 0 instead of "width >> 8"?

Here's the spec:

Bit image write            Real Time Bit Image Display
1FH, 28H, 66H, 11H     Display the bit image data,
xL, xH,                            Bit image Xsize low/high(1dot) 
yL, yH,                             Bit image Ysize low/high(8dots),
g, d1, dk                         g=1 (always); d1-dk is the bit image data

Another way to state the question is: Why should xL be xH>>8 all the time?

Hi jeffspc88mx,

I think what is going on here is that you are setting the the width of the image in two different steps. You are first sending over the low byte, and then the high bite. I bet the command() function takes an 8-bit integer as its input, so when you call command(width) it will cast the width variable to an 8-bit integer, thereby ignoring the higher bits. Then to send over the high byte you shift width down by one byte and send that. If in fact the width is always less than 256 (and width is unsigned) then the high byte of width will always be 0.

Humberto

Ahhh - that explains why the spec refers to them as low-byte/high byte. I had a feeling that low-byte/high-byte meant what you said, but I chose not to believe it. Explains a lot of other things about the Noritake code that I'm seeing as well. Right on! That solves that and a lot more, thanks!

I'm off to turn this thing into a sound meter....