Hi Forum
I‘m currently building my tinypilot system and I was wondering if it would be possible to use a monochrome e-paper with partially refresh and spi interface instead of the jlx or nokia lcd.
Issues would probaly be:
- different library for the display
- different resolution (200x200 for instance)
- different refresh rate
It seems interesting to me mostly because of readability in bright sunlight. A refresh rate of twice a second would be more than sufficient is my guess.
Has anybody tried / done this? Which files would need to be changed in the code for the raspberry pi?
Thanks for your thoughts ?
You would most likely just need to modify the ugfx.cpp code to add a new driver for your lcd. Since your resolution is 200x200 it might not be perfectly optimized for the default menu display. I would first try it, and post results, and we could look at the options.
Likely it will need some hints to slow down the refresh as well.
(2024-06-15, 01:39 PM)seandepagnier Wrote: [ -> ]You would most likely just need to modify the ugfx.cpp code to add a new driver for your lcd. Since your resolution is 200x200 it might not be perfectly optimized for the default menu display. I would first try it, and post results, and we could look at the options.
Likely it will need some hints to slow down the refresh as well.
Thank you for your reply. I didn‘t order one yet, but just for practice I‘m trying to get a 128x64 screen to work, which has a ssd1309 chip. It displays without any changes to the ugfx.cpp but the image is mirrored and very slowly moves up. I‘m trying to work out the dependencies in the programm and how to implement a driver. Maybe you could point me in a right direction?
(2024-06-15, 10:33 PM)J_Groot Wrote: [ -> ] (2024-06-15, 01:39 PM)seandepagnier Wrote: [ -> ]You would most likely just need to modify the ugfx.cpp code to add a new driver for your lcd. Since your resolution is 200x200 it might not be perfectly optimized for the default menu display. I would first try it, and post results, and we could look at the options.
Likely it will need some hints to slow down the refresh as well.
Thank you for your reply. I didn‘t order one yet, but just for practice I‘m trying to get a 128x64 screen to work, which has a ssd1309 chip. It displays without any changes to the ugfx.cpp but the image is mirrored and very slowly moves up. I‘m trying to work out the dependencies in the programm and how to implement a driver. Maybe you could point me in a right direction?
You might need a new driver. The start sequence might need to change. Where did you get your screen?
Did you find the jlx1264 and nokia5110 drivers in the ugfx.cpp code? The code specific to a particular lcd is very short.
I‘ve made changes in the jlx driver to match the sequence of the ssd1309 (just to get it to work and make a seperate class afterwards), but it looks like this driver is not being used, since changes do not effect the behaviour of the display. In hat.conf the jlx12864 is „selected“.
Is there another checking mechanism where another driver is used? I haven‘t looked in a way to get debug messages and am just ssh-ing into the raspberry pi zero w. I have no eeprom implemented.
The display I use I got from amazon, very widely spread:
https://www.amazon.de/dp/B0CVZTJN5B/ref=..._SCE_dp_i1
Changes you make to the source code on a tinypilot are not immediately reflected. They first need to be built into a new tinycore package. There might be tricks around this, but if you are not aware of this, this might be what you are running into. You might get some hints at
https://github.com/pypilot/workbook/wiki...r-the-hood
(2024-06-17, 11:17 AM)ironman Wrote: [ -> ]Changes you make to the source code on a tinypilot are not immediately reflected. They first need to be built into a new tinycore package. There might be tricks around this, but if you are not aware of this, this might be what you are running into. You might get some hints at https://github.com/pypilot/workbook/wiki...r-the-hood
Thank you for this hint! I allready thought it must be something I‘m missing.
I‘ll look into it as soon as I have some spare time.
When I have everything working, I‘ll make my changes available to Sean and if he pleases he can implement it, since these displays are very common.
first try running "make" in the ugfx folder.
This should produce the splash screen binary and this could be useful for testing the display.
It would be great to have additional drivers. I already started support for a larger one but didnt test it yet.
(2024-06-17, 03:54 PM)seandepagnier Wrote: [ -> ]first try running "make" in the ugfx folder.
This should produce the splash screen binary and this could be useful for testing the display.
It would be great to have additional drivers. I already started support for a larger one but didnt test it yet.
Thank you, I‘ll try that.
There actually is a quit comprehensive library which covers a lot of monochrome lcd chips, the jlx12864 uses the uc1701 if I‘m not mistaken, this is covered as well as the whole familly of the ssd130x chips. To implement this library would probably mean to change from putting drivers direct in ugfx.cpp to including the library and so on. As you might have guessed, my skills are not (yet) good enough to get this done probably for you it is a piece of cake ;-)
But my guess is, when I get my display to work from ugfx.cpp, most displays using a chip from this family and a resolution of 128x64 will work.
I have written my code so that the resolution of the lcd does not matter. For this reason it is a bit different from other libraries and ugfx only supports functions that are not specific to resolution.
What could be done, is to write a ugfx driver to use this library which supports more lcds using it as another layer rather than directly talking to spi.