SPI doesn’t seem to have much support so probably not going in that direction. I got several variations on the “snowy screen”, some that had an extremely partial image (line of blue or similar variants) - after trying this, I moved over to other displays and have successfully gotten a couple of more simple text displays to work via I2C. The most success that I had was following and and trying what you had discussed.
Hi - I’ve read this entire thread at least 5x over and tried most of the implementations mentioned with mixed success and not once have a gotten a full bitmap to display. I’ll try some experiments to adjust the color scheme to get a closer appearance - still waiting for my display to arrive (been working on a remote display to get that code running…) PS: for the note, the picture won’t look as good on the display as on your computer, due to the different pixel density on both displays. I’m publishing the class in my github repository here: This said, since it is a class, everyone will be able to add to any kind of conversions, adjustments, cropping or else they like. Saving in 16bits colors (565-color coding scheme) should be present in most picture editors (it is at least in GIMP and Photoshop) and since you will probably have to downscale a picture from a huge size to 128x128, why not directly saving in the format the display likes?
The main difference with the original function used for the demo here is, I’m reading a native 16 bits Windows BMP, not a 24-bits, so I don’t have to do any color conversion/adaptation. So reading this thread and looking online for a description of the BMP format I decided to isolate the bitmap loading function in a dedicated class, called… Bitmap.
#Coolterm tutorial driver#
Move was easy but I missed the bitmap loading function in the driver (the existing one is only monochrome). I had to switch in my project from a SSD1309 128圆4 B&W display to SSD1351 128x128 16-bit colors one.
0 kommentar(er)
