Display without MISO

[ReinBentdal]

I have an ili9341 display without a MISO pin. Is it absolutely mandatory for the library to work? I have previously used ili9341_t3, which did not require this.

Thanks for this awesome library!

[vindar]

Hi,

Unfortunately, the MISO line in necessary because the driver monitors the position of the line currently being refreshed by the screen (to prevent screen tearing) so it needs to query its position regularly.

If you display does not have MISO, then I guess your best choice is indeed ILI9341_t3 or ILI9341_t3n which has some additional methods.

[DIYLAB-DE]

I have an ili9341 display without a MISO pin.

*Note I did not know that there are also ILI9341 displays without MISO connector, which display should this be exactly? Do you have a link or a picture of it?

[ReinBentdal]

Here is the display: https://www.waveshare.com/2.4inch-lcd-module.htm

If you scroll down, you will see the pins.

[ReinBentdal]

I ended up ordering a new display with the MISO pin. I really appreciate the effort put into both this library and tgx. It is exactly what I am looking for! ILI9341_t3n does not seem to deliver the performance I am looking for, but I think this one will do the trick!

[ReinBentdal]

Just received my new display, but it lacks a CS pin haha.

Looks like that does not work, but it still works with ili9341_t3n

[vindar]

Hi,

Do you mean that there is no CS pin on the display ? That is very strange...

Yet, if you have RESET, MISO, MOSI, CLK and DC on the display, then it should still work with ILI9341_T4.

You can try setting PIN_CS to any correct value in the ILI9341_T4 driver (for example pin 9 as in the examples) and just leave this pin unconnected on the Teensy. CS is an output pin used to signal the Display that SPI is active so it should not matter for the driver.

Do you have a picture / link to this display ?

[ReinBentdal]

https://www.aliexpress.com/item/1005002872319744.html?spm=a2g0o.order_list.0.0.10721802sCs5CV (Module NO Touch)

Setup runs without problems. But the screen stays completely white regardless of the loop content. Tried first with my own code then with tgx example code. Think the description of the miso pin in the link is quite strange: "Pin is not useful, Not connected is ok", but since the setup finished without errors i dont think that's the problem

[vindar]

Ok. But the setup runs ok ? This is strange because this means that both MISO and MOSI lines should be working correctly in that case...

Maybe there is some other initialization code required for that display ? I only tried the library with the classical 'red ILI9341 screens'. I will try to see if I can grab one of those blue one to test it but it will take some time.

[ReinBentdal]

I will try to investigate the problem myself as well. Ran the setup with serial output stream with no logged errors. Tried with different SPI speeds as well. I will continue on using ili9341_t3n while waiting on getting this library to work properly.

I am really impressed with the effort put into the project. Really nice interface, powerful features and really good documentation. Thanks for you effort!

[vindar]

Hi,

I just made some big changes to the library: any pin can now be used for CS and DC (but still using a CS capable pin for DC will provide a better framerate). I also fixed a problem with my scanline() method which, I believe, was the reason your screen without a CS pin did not work properly... Can you try again to see if it works now ? Thanks.

[ReinBentdal]

I can confirm that it now works!

I am planning on not using that many different colors in my UI. I therefore see a potential to define a set of compile time colors, maybe only 8. It would then be possible to only use 3 bits to determine the color and thus make the frame buffer quite a bit smaller (3202403 bits) and then when transferring frame to the display, map the 3 bits to the correct color. How difficult do you think this would be to implement? My application is really memory constrained and I don't think I can afford double buffering with 16 bits for each pixel. But 3 bits would be a completely different story. Maybe 4 bits of colors would be more practical to program.

[vindar]

I have been thinking for some time about doing something similar and using smaller buffer with color palette. This would be good for porting the driver to bigger display like ILI9844...

However, there are several difficulties to overcome first. The main one I see is that the driver will have to perform the color conversion on the fly during upload and this cannot be done by DMA so it will need to be done by the MCU using interrupts so it will tax the MCU much more.

I think I will try to implement something like that but it is a complex project so it will probably take some time... I will try with 4 bits and 8 bits buffers. I do not even want to think about 3 bits buffers : dealing with byte boundaries would be a nightmare :-)

[ReinBentdal]

I see! For simplicity I call: fb - color palette buffer (for example 4 bits per pixer) ib - "normal" 16 bit buffer Wouldn't it then be possible to translate fb to ib during the update function, then upload ib over DMA? I think it then should be possible to track buffer changes and use diff buffers. Before updating an ib pixel, compare it with the corresponding pixel in fb and potentially update diffBuffer. This would at least save some memory: 320*240*12 bits.

[vindar]

Yes, it would certainly be easier to implement it as you suggest by doing the translation at the time of the diff buffer computation. However I find this solution "less elegant" and it does not save that much space... Moreover, keeping the 4/8bits buffers around for as long as possible will also make the creation of the diff faster (because most of the time is spend reading the memory of both framebuffer being compared) so it may partly compensate for the extra time required to translate each line before DMA upload.... The other reason I prefer this approach is because some screen require upload in other format than 16 bits (e.g. 18 bits for ILI9844 with SPI) so implementing "on the fly translation" may be a first step in porting the driver to other screens.

I will try to see what I can do but I expect it will take some time.

BTW, Thanks for reporting the bug in the other thread :-)

[ReinBentdal]

Sounds reasonable. Would be cool if the library was not "ILI9341", but a more general highly optimized T4 library for different drivers. T4 certainly has stil not obtained potential which this library may unlock.

How would color palette format affect anti-aliasing in tgx? Sounds difficult to deal with since the color shades are probably not available. Or maybe just be a non-anti-alias feature.

I really like your library and hope i may contribute in a positive way