Re: ssd1306 using I2C on the esp8266
Posted: Sat Jul 30, 2016 1:03 pm
@mflmartin I'll try to explain.
I hand crafted the [7,192,24,48...] array by drawing a smily on a 16x16 grid, split into groups of 8 pixels, then converted binary to decimal.
16 pixels wide fits into 2 bytes.
Each 2 bytes in the array is a row.
MSB of byte 1 is the top left pixel. LSB of byte 2 is the top right pixel.
MSB of byte 3 is the 2nd row left most pixel, LSB of byte 4 is the 2nd row right most pixel.
The smiley is actually only 15x15, but I used a 16x15 grid. You may notice below the right most column is all zeros.
There's only 30 bytes instead of 32 as you would expect for a 16x16 image, because I skipped the last two bytes. ie. the last row.
If you convert the array to binary (and squint), you may see the the image.
It was a rather laborious process!
If I had a 9x9 image, it would still require 2 bytes per row, but there would be lots of wasted space.
It would effectively be a 16x9 image. 2 bytes per row.
Now, a more efficient format would be to warp to the next row at exactly 9 bits, but would be more complex to decode.
eg. a 4x4 image currently fits on a 8x4 grid with 4px wasted per row. 32 bits, 4 bytes.
If it were stored more efficiently, with no wasted space, it's 16 bits in total, or 2 bytes.
I hand crafted the [7,192,24,48...] array by drawing a smily on a 16x16 grid, split into groups of 8 pixels, then converted binary to decimal.
16 pixels wide fits into 2 bytes.
Each 2 bytes in the array is a row.
MSB of byte 1 is the top left pixel. LSB of byte 2 is the top right pixel.
MSB of byte 3 is the 2nd row left most pixel, LSB of byte 4 is the 2nd row right most pixel.
The smiley is actually only 15x15, but I used a 16x15 grid. You may notice below the right most column is all zeros.
There's only 30 bytes instead of 32 as you would expect for a 16x16 image, because I skipped the last two bytes. ie. the last row.
If you convert the array to binary (and squint), you may see the the image.
Code: Select all
[00000111,11000000, .....11111......
00011000,00110000, ...11.....11....
00100000,00001000, ..1.........1...
01000000,00000100, .1...........1..
01000000,00000100, .1...........1..
11111111,11111110, 111111111111111.
10100111,10011010, 1.1..1111..11.1.
10101111,10111010, ---> 1.1.11111.111.1.
10011100,01110010, 1..111...111..1.
10000000,00000010, 1.............1.
01000000,00100100, .1........1..1..
01000011,11000100, .1....1111...1..
00100000,00001000, ..1.........1...
00011000,00110000, ...11.....11....
00000111,11000000] .....11111......
If I had a 9x9 image, it would still require 2 bytes per row, but there would be lots of wasted space.
It would effectively be a 16x9 image. 2 bytes per row.
Now, a more efficient format would be to warp to the next row at exactly 9 bits, but would be more complex to decode.
eg. a 4x4 image currently fits on a 8x4 grid with 4px wasted per row. 32 bits, 4 bytes.
If it were stored more efficiently, with no wasted space, it's 16 bits in total, or 2 bytes.