Hi Terry, > See https://www.waveshare.com/wiki/1.5inch_OLED_Module > This page contains everything available about the device.
There's a lot of good information there, and a bit of bad written by Waveshare. Working from eyeball backwards, there's the OLED display described by https://www.waveshare.com/w/upload/c/c3/1.5inch_OLED_Specification.pdf Here's page numbers and interesting bits. - 4 - White colour, i.e. greyscale, 128×128 pixel resolution - 6 - Life time depends on contrast setting. Does it also depend on the amount of whiteness in the pixels? - 9 - This OLED is connected to the SSD1327 driver by 256 connections: C0-C127 and S0-S127. - 11 - The framebuffer is 128×128×4, i.e. there are four bits per pixel. This requires 8 KiB with 8-bit bytes. It says ‘128x128 data bytes’, but that's incorrect, being 2**(7+7) = 2**14 = 16 KiB. And they're don't mean 4-bit bytes as they talk of the high and lower nibble of D0[0:7]. So that's an error. - The ability to re-map the framebuffer's bits to different pixels might be useful coupled with scrolling mentioned below. Observe the zig-zag lines to get the jist on that page and the following ones. - 20 - Contrast ratio is the ratio of luminance between the pixels which are on and those which are off. - 24 - You can burn in a ghost image over time. Stepping back we arrive at Solomon Systech's SSD1327 driver chip: https://www.waveshare.com/w/upload/a/ac/SSD1327-datasheet.pdf - 7 - 128×128×4. I²C, SPI, or parallel interface available to the MCU. (It later says only the parallel interface allows reading from the SSD1327.) - 16 grey scale, which tallies with the ‘×4’. - 256-step contrast brightness current control. - Horizontal and vertical scrolling. - 27 - Observe how the segment voltage during phase 4 controls the amount of current for a pixel and thus its brightness. - It has a programmable palette, or colourmap, of greys: ‘The length of phase 4 is defined by command B8h or B9h. In the table, the gray scale is defined in incremental way, with reference to the length of previous table entry.’ - 29 - The status at reset. - 30 - More details of remapping the framebuffer to the pixels. - 33 - The 16 greys can be defined by the length of their Phase 4, except greys 0 and 1 look to be fixed. The lengths must not get smaller as you progress through the palette, i.e. pixel value 7 can't be darker than pixel value 6. - 36 - Start of command-table summary. A useful reference and good to browse for an idea of what's possible. - 40 - Reference for scrolling horizontally. (For vertical scrolling, e.g. to simulate the TV's vertical hold being on the blink, remap the framebuffer to the pixels to rotate the image and rotate the OLED to compensate.) - 46,47 - If you image isn't tall enough, you could compensate by setting the Display Start Line part-way down the screen with the MUX ratio lowered to the height of your image. - 49 - How to save power. - 51 - B8h sets the grey-scale table, i.e. palette/colourmap. - GS0, i.e. pixel value 0, can't be programmed; it's always black. This matches the reference table, page 38. - B9h resets the table back to the default. - 53 - Scrolling supports only shifting part of the OLED's pixels. My reading is the framebuffer is unaltered and it's the mapping of framebuffer to pixels which changes. About the only interesting bit in the user manual, https://www.waveshare.com/w/upload/8/80/1.5inch_OLED_Module_User_Manual_EN.pdf, which isn't better described by the above two documents is using the python-imaging package on Raspbian to provide the Python Image module, which is PIL I mentioned in an earlier email. - 8 - Image.new()'s first parameter is given as ‘L’, with the claim it's greyscale. It is, http://effbot.org/imagingbook/concepts.htm#mode shows it's 8 bits per pixel, but the OLED_ShowImage() shown takes the bottom nibble for the framebuffer's value which could have no relation to the top nibble's value, e.g. 0b1110_0000 is bright grey but would appear black with their code. The source code, https://www.waveshare.com/w/upload/9/9d/1.5inch_OLED_Moudle.7z, includes - flower.bmp - This isn't as your Gimp suggested last night due to its display of colours in the colour map. As ever, the shell trumps. $ bmptopnm flower.bmp | ppmhist bmptopnm: Windows BMP, 128x128x4 bmptopnm: WRITING PPM IMAGE r g b lum count ----- ----- ----- ----- ------- 0 0 0 0 13779 255 255 255 255 1289 128 128 128 128 990 192 192 192 192 326 $ There are four distinct pixel values. bmptopnm decides to produce an RGB image, PPM, instead of a grey one, PGM, so we see r/g/b columns, but their values are all the same. The four ‘colours’ are black, white, grey50, and grey75. All four can be seen around the ‘*’ in the image. - OLED_Driver.py - Its OLED_ShowImage() has the same bug I mentioned for the user manual above thus I'd expect their test image to only display its white pixels, the grey50 and grey75 having low nibbles of zero. A white-noise display should be possible by writing to the framebuffer once and then using the inverse-video command and display offsets to randomly map the framebuffer to the pixels. You could experiment to see how quickly you can write new frames. Good enough for the collapse-to-a-white-dot on unplugging the TV? Or even displaying video? You may want to mask off rounded corners of the display with the enclosure, for that CRT TV look. -- Cheers, Ralph. -- Next meeting: Online, Jitsi, Tuesday, 2020-09-01 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
