TWI or UART to HUB75 matrix driver - Koakuma V3

So having 7 colors is nice but incredibly limited .... i wanted more.

But more colors = more memory and processing power. So i sacrifieced a huge part of the sprite system (which nobody would use anyways) and added additional buffers to enable 6 bit color -> 64 possible colors.

Also a USB-UART adapter is used to send framedata with a 230400 Baudrate.

The result is up to 5 FPS and with a small python script i can even play some GIF´s

Obviously, it looks much better in reality .... damn phone camera ; )

So we know sending every frame pixel by pixel is awfully slow. But that was never the goal. Goal was to send "draw this sprite here" commands.

And it does.

The Letters are already preloaded, so i just send "draw sprite 'W' on X/Y.

So making an animation like this is just a matter of. 

Drawing the letter sprite.
Delay a bit.
Draw a blank sprite over the old position.
Draw the letter on new position.
Copy Shadowbuffer

Easypeasy.

The Arduino function looks like:

void Scr_DrawSprite(char x, char y, char spr){
  Wire.beginTransmission(0x41);
  Wire.write(3);
  Wire.write(x);
  Wire.write(y);
  Wire.write(spr);
  Wire.endTransmission();
}

So i can just write

Scr_DrawSprite(30, 20, 'W');

In my Arduino code.

It seriously cant get any easier than that.

So after a complete rewrite of the render function i split the display buffer in two.

One "Displaybuffer" which buffers everything on screen. A interrupt task which shifts out this buffer on the screen every x-milliseconds.

Via TWI we can write into an, i call it, "shadowbuffer". Only after we give a command to copy the shadowbuffer into the displaybuffer we can see what we send over. This reduces flickering by A LOT.

To write a pixel we simply send the X, Y and color value via TWI. While this is comparably awfully slow its incredibly easy to use.

So a write pixel function on an Arduino looks like this:

void Scr_DrawPixel(char x, char y, char col){
  Wire.beginTransmission(0x41);
  Wire.write(2);
  Wire.write(x);
  Wire.write(y);
  Wire.write(col);
  Wire.endTransmission();
}

So lets test the possible refresh rate with a simple arduino program:

for(int c=0; c<8; c++){
    for(int x=0; x<64; x++){
      for(int y=0; y<64; y++){
        Scr_DrawPixel(y,x,c);  // Write pixel
      }
    }
    Scr_CopyBuf();   //copy shadow buffer into screenbuffer
  }

Increasing the TWI speed of the Arduino up to 700Khz we can reach up to 365ms/frame in 64x64 mode.

Decreasing the resolution down to a 32x32 screen we can get 90ms (~10FPS)

While this is not very much and pretty slow/unusable for video playback...... IT IS NOT THE INTENDED PURPOSE.

Goal is to make it as easy as possible. This way the TWI master is free to do whatever and does not have to render every frame.

So i thougt, screw it. I got a 64x64 matrix to test the full capabilities of the driver.

First of all, yes! The DCDC can drive it on full tilt.

However only for about a minute until it overheats again. Lets improve in this again in version 4.

Also: rendering 32 lines causes quite some flickering. Also the sprite feature tends to break down under quite some flickering.

So i had to rewrite the whole thing.....

So the way this screen works is by buffering 8x8 sprites and displaying them on demand.
The sprite buffer is just a multidimensional array of 100x8x8 bytes.
At startup all 100 bytes are blank, but i preloead bytes 64-90 with letters and 48-57 with numbers. Yes according to the ascii table.

My plan is to make the commands be like "DrawSprite(number, Xpos, YPos);". So drawing an "A" could be like "DrawSprite('A', 15, 6);"

First test: I just display the Name, Version and TWI-Address on startup.

Great success!

One Problem if the older versions was that i used an LDO to power the screen. However i underestimated the power consumption and the LDO constantly overheated. So this version got a buck converter.

Using a simple TPS4020 we can generate our deeded 5V with up to 3A.

Also you can power the board also with 24V eliminating the need for beefy 5V supplies and makes power distribution easier.

Running the screen in full tilt (all pixels white, maximum brightness) is now possible.
The DCDC doesnt even get warm.
And before you ask. The brighter stripe in the middle is due to the slow phone camera this is shot with. in reality you wont see any flickering with your eyes.