Arduino: Printing ASCII characters to LEDs / pointer weirdness

Question

I've made a 24 x 15 LED matrix using TLC5940s and shift registers, running on an Arduino Due.

First thing first, I want to print an ASCII char, eg. 'A' directly to the display.

So I stored a font array in PROGMEM, using a link I found :

 PROGMEM prog_uchar font[][5] = {
    {0x00,0x00,0x00,0x00,0x00},   //   0x20 32
    {0x00,0x00,0x6f,0x00,0x00},   // ! 0x21 33
                ...
    {0x08,0x14,0x22,0x41,0x00},   // < 0x3c 60
    {0x14,0x14,0x14,0x14,0x14},   // = 0x3d 61
    {0x00,0x41,0x22,0x14,0x08},   // > 0x3e 62
    {0x02,0x01,0x51,0x09,0x06},   // ? 0x3f 63
                etc.

Now, the weird part, is that everything almost works, but is shifted slightly. For example, '>' gets morphed to this:

00000000      -->     00001000    
01000001      -->     00000000
00100010      -->     01000001
00010100      -->     00100010
00001000      -->     00010100

So i think it is a pointer boundary issue. Maybe I've just been looking at it for too long, but I don't know!

Here is the relevant code, where I've hardcoded the values for '<'. I did a Serial.println, and it is showing the correct value for 'b'. x and y are 0 and 0, to place the character in the corner. The commented-out assignment of 'b' is what I usually do, instead of hardcoding. charWidth = 5 and charHeight = 7. setRainbowSinkValue(int led, int brightness) has worked forever, so it's not that.

  unsigned char testgt[]   = {0x00,0x41,0x22,0x14,0x08};

  for (int iterations = 0; iterations < time; iterations++)
  {

    unsigned char indexOfWidth = 0;
    unsigned char indexOfHeight = 0;

    for (int col = x; col < x + charWidth; col++) 
    {
        openCol(col);      
        Tlc.clear(); 
        unsigned char b = testgt[indexOfWidth];//pgm_read_byte_near(font[ch] + indexOfWidth );

          //Serial.println(b);

        indexOfHeight = 0;
        for (int ledNum = y; ledNum < y + charHeight; ledNum++)
        {
          if (b & (1 << indexOfHeight))
          {
            setRainbowSinkValue(ledNum, 100);
          }
          indexOfHeight++;
        }

        indexOfWidth++;
        Tlc.update(); 
    }
  }

Can you see anything wrong? The most likely issue is the bit operations, but it makes sense... b & 1... b & 2... b & 4... b & 8... b & 16... b & 32... b & 64... b & 128...

Answer 1

Basically the value you extract from testgt[] goes into the wrong column on the display. The presented code looks fine. It's something in what you haven't shown. Perhaps, your circuitry is indexing the input differently from what you're expecting.

Answer 2

Ok I worked it out... There seems to be a slight timing difference between the speed of the 74hc595 and the TLC5940s, so what's happening is that there is residual flicker carried over to the next column because the TLC isn't cleared by the time the 74hc595 opens the new column. So I switched Tlc.clear() and openCol(col) and added a delay(5) in between, and that helps. Doesn't fix it entirely, but delay(15) hurts the eyes, and it's an acceptable compromise.