The fillScreen function

I was looking in the example repository at Arduboy.cpp and I was a little confused about fillScreen.

FillScreen calls FillRect, which calls fastVLines for the width of the rectangle, which calls drawPixel for the length of the line, which writes individual pixels to the screen buffer.

However, earlier I had seen clearDisplay, which simply does this:

for (int a = 0; a < (HEIGHT*WIDTH)/8; a++) sBuffer[a] = 0x00;

Couldn’t a screen fill use a similar technique? I haven’t looked into everything in detail yet, but I’m assuming you could just change the last part to sBuffer[a] = 0xFF;.

Forgive me if this is a dumb suggestion, I’ve only done some hobbyist coding type stuff, I don’t necessarily have a full understanding of how it all works and all the terminology, and I know that a little knowledge can be a dangerous thing. :slight_smile:

I will admit I haven’t fully looked through the code yet but what you say looks valid. just looking at the clear & drawPixel functions, writing 0xFF will fill a set of 8 pixels to on (guessing white?).

I’ll have to dig into it tonight but providing you can address the buffer in 32bit writes it should be faster to flush 32 pixels at a time then 8 pixels (unless there is an even faster way to dma to the screen buffer).

This is just an assumption, but I don’t think you can do 32 bit writes because the ATmega32u4 is an 8-bit processor. But again, I’m no professional and might misunderstand the way it works.

The C-like language may implement wider type than 8-bit character, still cpu supports just 8-bit memory write. Have to say cpu power per pixel is much higher than any 8-bit systém could dream. The cpu should run on 16MHz, memory read/write typicaly takes two ticks.
I think filling the char array by bytes will do the trick.

http://www.atmel.com/Images/Atmel-7766-8-bit-AVR-ATmega16U4-32U4_Datasheet.pdf

You guys are correct, it is 8bit register set. Sorry little new to this processor (more use to working on arm cortex-m3 chips).

Still doing more digging on the datasheet to see if there are faster ways to handle large memory read/writes.

There may well be some optimizations available to the driver. We are scrambling to get everyone setup on the github and can share our pull requests and do some testing/validation. Pardon the construction here!

Expect some more updates in the upcoming weeks! Thanks!

Just an update, we had @chris our programmer take a look at this and he is working on an update. Thanks team!

Ya, you should be able to do this, or just max out the char value. But you would be filling not 1 pixel at a time using this method, rather you would fill an 1x8 rectangle. So if you wanted to just fill these 1x8 tiles in one go, set the sBuffer at a particular index to 255.

Couldn’t a screen fill use a similar technique?

It could. A lot of work needs to be done on the libs, but also constant checking to make sure we’re reducing the size, not increasing it… it’s not always obvious without checking the output (and assembled code) to be sure something is actually an improvement.

Fill screen probably isn’t going to be called a zillion times… so does loading a few registers and then calling another function use less memory than creating a two byte integer and doing two byte arithmetic in a for loop? Good question. What about changing clearDisplay to just call fillScreen?

I’ve started hacking on the library but haven’t submitting a pull request yet.