Monochrome 128*64 OLED screen - SSD1306 driver questions

[amateurasu]

By the way, NickGammon, your tweaks worked like a charm. Now text is screaming across my little OLED. Thanks!

[amateurasu]

Came across another little issue. The drawbitmap() function seems to corrupt the lower right chunk of the image if the dimensions are not multiples of 8. So far, I've had success with 16x8, 16x16, 32x32, and 128x64. 8x4, 30x10, 45x11, and 40x21 have all had corruption in that same area. From my earlier attempts at manually coding in a bitmap in binary to sort of "paint" with 1's and 0's in the code window, I know that the image that results on screen is rotated 90 degrees counterclockwise from what you would expect from the way the bytes are laid out. So instead of painting left to right, top to bottom, it paints bottom to top, left to right. Given where the glitching begins, this means that the routine works for the first several odd-length rows, only getting wonky for the first few pixels of the last few rows. I've got some pictures that should make it a little clearer.


The image I'm feeding in.


The result (click for full size)

And while getting the pictures ready, it occurred to me that it may be the LCDAssistant program which is causing the issue. I don't have any way other than the OLED itself to view/verify the program's output, but maybe I can make a small odd-sized one by hand to test. I'll investigate that possibility in the morning, but right now I've got to get some shuteye.

[amateurasu]

OK, looked into it a bit more, and it is the drawbitmap() function causing the issue. The loop goes through and, for each row of height, uses a column counter based on the width (as well as the row counter divided by 8 ), that acts as a pointer for what byte to read from the array. So the width can be any number, but the height of the bitmap must be a multiple of 8, because the function expects to get some number of full bytes for each column. If you have, say, a 10x4 image stored in 5 bytes, the function is still going to try to read 10 bytes, one for each column. If the image is fairly large, this happens to work out for most of the image, as the data it gets when it overshoots the end of one column is still within the array, and happily enough is the data for the next column anyway. But I suspect the glitches in the bottom right corner result from the function going out of the bounds of the array and reading whatever other random data is sitting next to the array in memory.

If the array was an array of bits rather than an array of bytes, they could be addressed individually, but I think if you did that, each bit in the array would still take up a byte of memory, since each would need its own address. Not sure how else to fix this, though.

Also, is there any way to edit posts? Kind of a drag to have to delete and repost because the forum turned my 8 ) (without spaces) into a smilie...

[amateurasu]

The plot thickens... I took a 30x10 output from the LCDAssistant program and transcribed it by hand into binary in notepad, with ' ' for 0 and '*' for 1, so I could actually look at it. What I found is, it cuts the image into 8-pixel tall rows, and these become 8-pixel wide columns in the output (this is probably why the function rotates the image CCW like I noted before, to get it back to the proper orientation). For the last, partial column, the output stops several rows short of the end. "Drawing" in the missing part of my picture in notepad, transcribing back to hex bytes, and adding those on to the end of LCDAssistant's output fixed the problem, and now my odd-sized bitmaps display fully, with no glitches. So it was GIGO after all. Which is good, because patching up a few bytes (22 in this case, not sure if that's constant or if it varies with how far you are off from multiples of 8 or something) is much easier than the ideas I was coming up with for modifying drawbitmap...

[amateurasu]

While working on a Snake program (Youtube link to my work so far), I found myself wanting to be able to check the status of a particular pixel. I added a getpixel(x, y) function to the library that returns the value of the buffer at that location. If anyone wants to add this to their library, just insert the following code:

In SSD1306.h, after the line "void setpixel(uint8_t x, uint8_t y, uint8_t color);":

Code: Select all

int getpixel(uint8_t x, uint8_t y);

In SSD1306.cpp, after the "void SSD1306::setpixel" function's curly braces close:

Code: Select all

int SSD1306::getpixel(uint8_t x, uint8_t y) {
  if(buffer[x+ (y/8)*SSD1306_LCDWIDTH] & _BV((y%8)))
    return 1;
  else
    return 0;
}

It's probably not absolutely critical to put the code in the exact same spot I did, but that's where I put it and it works. Works the same as everything else in the library, call it with nameOfOledObject.getpixel(x, y).

[amateurasu]

drawstring() doesn't seem to be tolerant of being passed an int value to convert to a string, so I wrote a drawint() function for the library. Handles ints from -32767 to 32767 (reacts strangely to -32768, not sure why). Adds a '-' to negative numbers and trims leading 0's. Hope somebody finds this useful.

Add to SSD1306.h:

Code: Select all

void drawint(uint8_t x, uint8_t line, int c);

Add to SSD1306.cpp:

Code: Select all

void SSD1306::drawint(uint8_t x, uint8_t line, int c) {
int offset = 0;
boolean leadingZeroes = true;
if(c<0) {
  drawchar(x, line, '-');
  c = -c;
  offset += 6;
}
  for(int i = 4; i >=0; i--) {
    char digit = c / pow(10, i);
   if(digit != 0)
       leadingZeroes = false;
   if(!leadingZeroes) {
     c -= digit*pow(10, i);
     drawchar(x + offset, line, digit + 48);
     offset += 6;
     }
  }
  if(leadingZeroes)
    drawchar(x + offset, line, '0');
}

[nszankic]

Thank you so much Nick!

In case anyone want to know the pins on the mega:
#define OLED_DC 23
#define OLED_CS 53
#define OLED_CLK 52
#define OLED_MOSI 51
#define OLED_RESET 22

[mocenter1]

has anyone tried to download the LCD assistant software? it doesn't like the unzip file process. is there any good download link for this software? also is there any way of downloading the SSD1306 demo software as a file? If i copy and paste the lines shown in the link, into UNO ver 1.0 IDE, it doesn't copy right. Need some help. thanks

[amateurasu]

The LCD Assistant program (from here) unzips and works fine. You might have a corrupted download or something. Have you tried redownloading it?

As for the demo software, do you mean the library, at github? If so, you shouldn't be copying and pasting anything. You download the whole thing as a zip file (there is an easy-to-overlook link to do this near the top of the page), and unzip it to your libraries folder (you'll find it in your Arduino install folder, with arduino.exe). You'll want to rename that folder to remove the extra bits github adds at the beginning and end. It should just be "Adafruit_SSD1306". So you should have "Arduino folder\libraries\Adafruit_SSD1306\", which contains the .cpp and .h files, and an examples folder. Now close the Arduino software if you have it open, and restart it. Now when you go to File > Examples, there should be one for the SSD1306.

[mocenter1]

thanks for your help. got the lcd assistant to finally downloaded. took out the adruino 1.0 and reloaded. downloaded the SSD1306 libraries into arduino 1.0>libries> arduino_ssd1306. also added the example file. closed all the .exe's. opened 1.0 again. loaded the 1306 example sketch. added the adafruit_ssd1306.h and adafruit_GFX.h files (.pps file did not load). verified program and now the error reads:
"class Adafruit_ssd1306' has no member named 'fillCircle"
any ideas?
loaded older 0023 IDE and same error message appears.
appreciate any help

[mocenter1]

typo from last post:
(didn't load .cpp file)

[amateurasu]

Hmm. Looks like the library has been significantly reworked since I downloaded it. Formerly, all the GFX routines were in the SSD1306 library itself, now it seems they've spun them off into a separate library. Did you make sure to rename the GFX library folder to "Adafruit_GFX"? If so, and if that folder is in the libraries folder along with the Adafruit_SSD1306 folder, then I can't see why it wouldn't work. I'm curious what you mean when you say you "added" the .h files, though. They should already be incorporated by the #include statements in the example sketch. You don't need to actually add them to the sketch, just make sure their folder names in the libraries folder match the name of the .h file being included. That being said, I don't see why adding them to the sketch would cause the compile to fail. It also seems curious that it failed on fillCircle, of all things, rather than failing immediately when display is declared. From poking through the .h and .cpp files, I see no obvious reason why the SSD1306 class would inherit other functions from GFX, such as drawLine or drawRect, but not fillCircle. But my experience is with C moreso than C++. You might need adafruit's help on this one.