When datasheets fail
-
I've been trying to get the SSD1306 device working with my library, only come to find out that the way the framebuffer keeps its memory is bizarre. Basically, it's monochrome, so 8 pixels are packed into a byte. But they're packed *vertically* It appears as though the screen is divided into vertical banks, 1 byte high that hold 8 rows, but those are arranged left to right. Whoever designed it that way should be punished. Severely. Anyway, I figured out a way to change the memory addressing mode, and on top of doing that I flip the whole screen from landscape to portrait and address it that way, and I get some sort of sane horizontal bitmapping, even if my screen is now 64x128 instead of 128x64 However, that mapping mode isn't quite working the way I'd expect. SSD1306, error - YouTube[^] I had to post a 3 second video instead of a pic because of the camera->screen refresh interference causing tearing (you'll see what i mean) I tried to draw a 64x128 hatched rectangle with a solid white border. That hatched square is supposed to take up the entire screen. It does not, and the border if you look closely, does not appear along the left edge of the screen like it should, and the other side appears but is offset by several pixels as if the screen is wrapping around and offset by like 20 or so. I can't decipher the datasheet on this addressing mode. It's not clear at all, but it's the closest mode to sanity I've managed to find. My other option is to do what the other drivers do, and create a special frame buffer in the weird format, then blt everything to that, and force you to call an update() method explicitly to draw it to the screen. I wanted you to be able to create a bitmap and then use that as your framebuffer, and not have an extra hidden framebuffer stealing RAM. But in order to do that I need to know how this elephanting memory addressing scheme works, and why it's giving me this output. I hate datasheets.
Real programmers use butterflies
-
I've been trying to get the SSD1306 device working with my library, only come to find out that the way the framebuffer keeps its memory is bizarre. Basically, it's monochrome, so 8 pixels are packed into a byte. But they're packed *vertically* It appears as though the screen is divided into vertical banks, 1 byte high that hold 8 rows, but those are arranged left to right. Whoever designed it that way should be punished. Severely. Anyway, I figured out a way to change the memory addressing mode, and on top of doing that I flip the whole screen from landscape to portrait and address it that way, and I get some sort of sane horizontal bitmapping, even if my screen is now 64x128 instead of 128x64 However, that mapping mode isn't quite working the way I'd expect. SSD1306, error - YouTube[^] I had to post a 3 second video instead of a pic because of the camera->screen refresh interference causing tearing (you'll see what i mean) I tried to draw a 64x128 hatched rectangle with a solid white border. That hatched square is supposed to take up the entire screen. It does not, and the border if you look closely, does not appear along the left edge of the screen like it should, and the other side appears but is offset by several pixels as if the screen is wrapping around and offset by like 20 or so. I can't decipher the datasheet on this addressing mode. It's not clear at all, but it's the closest mode to sanity I've managed to find. My other option is to do what the other drivers do, and create a special frame buffer in the weird format, then blt everything to that, and force you to call an update() method explicitly to draw it to the screen. I wanted you to be able to create a bitmap and then use that as your framebuffer, and not have an extra hidden framebuffer stealing RAM. But in order to do that I need to know how this elephanting memory addressing scheme works, and why it's giving me this output. I hate datasheets.
Real programmers use butterflies
I wrote a bitmap font renderer for such a display many years ago, the strange pixel format meant rearranging the font data so it could be rendered quickly at any position with bit shifts and bitwise or's on a seriously underpowered cpu. That was a fun challenge.
-
I wrote a bitmap font renderer for such a display many years ago, the strange pixel format meant rearranging the font data so it could be rendered quickly at any position with bit shifts and bitwise or's on a seriously underpowered cpu. That was a fun challenge.
I didn't design for this. Who makes framebuffers this way? It's just ... meh
Real programmers use butterflies
-
I've been trying to get the SSD1306 device working with my library, only come to find out that the way the framebuffer keeps its memory is bizarre. Basically, it's monochrome, so 8 pixels are packed into a byte. But they're packed *vertically* It appears as though the screen is divided into vertical banks, 1 byte high that hold 8 rows, but those are arranged left to right. Whoever designed it that way should be punished. Severely. Anyway, I figured out a way to change the memory addressing mode, and on top of doing that I flip the whole screen from landscape to portrait and address it that way, and I get some sort of sane horizontal bitmapping, even if my screen is now 64x128 instead of 128x64 However, that mapping mode isn't quite working the way I'd expect. SSD1306, error - YouTube[^] I had to post a 3 second video instead of a pic because of the camera->screen refresh interference causing tearing (you'll see what i mean) I tried to draw a 64x128 hatched rectangle with a solid white border. That hatched square is supposed to take up the entire screen. It does not, and the border if you look closely, does not appear along the left edge of the screen like it should, and the other side appears but is offset by several pixels as if the screen is wrapping around and offset by like 20 or so. I can't decipher the datasheet on this addressing mode. It's not clear at all, but it's the closest mode to sanity I've managed to find. My other option is to do what the other drivers do, and create a special frame buffer in the weird format, then blt everything to that, and force you to call an update() method explicitly to draw it to the screen. I wanted you to be able to create a bitmap and then use that as your framebuffer, and not have an extra hidden framebuffer stealing RAM. But in order to do that I need to know how this elephanting memory addressing scheme works, and why it's giving me this output. I hate datasheets.
Real programmers use butterflies
It is a well-known "fact" among hardware designers that software is free. The reasoning goes like that: given that software is written only once for any number of devices, its cost is vanishingly small compared to any gate on silicon. So they don't bat an eyelid when they invent stuff like write-only registers (hey, software can keep a copy of the register) or convoluted memory paging schemes (hey, software can change the paging register every 100 instructions or so). Those of us who have to debug programs with a scope suffer the consequences ;P
Mircea
-
It is a well-known "fact" among hardware designers that software is free. The reasoning goes like that: given that software is written only once for any number of devices, its cost is vanishingly small compared to any gate on silicon. So they don't bat an eyelid when they invent stuff like write-only registers (hey, software can keep a copy of the register) or convoluted memory paging schemes (hey, software can change the paging register every 100 instructions or so). Those of us who have to debug programs with a scope suffer the consequences ;P
Mircea
The write only thing over serial i could live with if not for the other thing. But don't mess with me from both directions at once. These modules these days are almost entirely sold to MCU builders. MCUs don't have spare cycles and RAM for this nonsense. :doh:
Real programmers use butterflies
-
I've been trying to get the SSD1306 device working with my library, only come to find out that the way the framebuffer keeps its memory is bizarre. Basically, it's monochrome, so 8 pixels are packed into a byte. But they're packed *vertically* It appears as though the screen is divided into vertical banks, 1 byte high that hold 8 rows, but those are arranged left to right. Whoever designed it that way should be punished. Severely. Anyway, I figured out a way to change the memory addressing mode, and on top of doing that I flip the whole screen from landscape to portrait and address it that way, and I get some sort of sane horizontal bitmapping, even if my screen is now 64x128 instead of 128x64 However, that mapping mode isn't quite working the way I'd expect. SSD1306, error - YouTube[^] I had to post a 3 second video instead of a pic because of the camera->screen refresh interference causing tearing (you'll see what i mean) I tried to draw a 64x128 hatched rectangle with a solid white border. That hatched square is supposed to take up the entire screen. It does not, and the border if you look closely, does not appear along the left edge of the screen like it should, and the other side appears but is offset by several pixels as if the screen is wrapping around and offset by like 20 or so. I can't decipher the datasheet on this addressing mode. It's not clear at all, but it's the closest mode to sanity I've managed to find. My other option is to do what the other drivers do, and create a special frame buffer in the weird format, then blt everything to that, and force you to call an update() method explicitly to draw it to the screen. I wanted you to be able to create a bitmap and then use that as your framebuffer, and not have an extra hidden framebuffer stealing RAM. But in order to do that I need to know how this elephanting memory addressing scheme works, and why it's giving me this output. I hate datasheets.
Real programmers use butterflies
-
I've been trying to get the SSD1306 device working with my library, only come to find out that the way the framebuffer keeps its memory is bizarre. Basically, it's monochrome, so 8 pixels are packed into a byte. But they're packed *vertically* It appears as though the screen is divided into vertical banks, 1 byte high that hold 8 rows, but those are arranged left to right. Whoever designed it that way should be punished. Severely. Anyway, I figured out a way to change the memory addressing mode, and on top of doing that I flip the whole screen from landscape to portrait and address it that way, and I get some sort of sane horizontal bitmapping, even if my screen is now 64x128 instead of 128x64 However, that mapping mode isn't quite working the way I'd expect. SSD1306, error - YouTube[^] I had to post a 3 second video instead of a pic because of the camera->screen refresh interference causing tearing (you'll see what i mean) I tried to draw a 64x128 hatched rectangle with a solid white border. That hatched square is supposed to take up the entire screen. It does not, and the border if you look closely, does not appear along the left edge of the screen like it should, and the other side appears but is offset by several pixels as if the screen is wrapping around and offset by like 20 or so. I can't decipher the datasheet on this addressing mode. It's not clear at all, but it's the closest mode to sanity I've managed to find. My other option is to do what the other drivers do, and create a special frame buffer in the weird format, then blt everything to that, and force you to call an update() method explicitly to draw it to the screen. I wanted you to be able to create a bitmap and then use that as your framebuffer, and not have an extra hidden framebuffer stealing RAM. But in order to do that I need to know how this elephanting memory addressing scheme works, and why it's giving me this output. I hate datasheets.
Real programmers use butterflies
Quote:
My other option is to do what the other drivers do
This would definitely work. Have a look at what existing drivers do and infer the addressing mode. We are lucky there is Arduino with all the related drivers around.
"In testa che avete, Signor di Ceprano?" -- Rigoletto
