search

wdim0 / esp8266_with_KeDei_lcd_module

ESP8266 with 3.5" KeDei LCD module
43 stars 4 forks source link

LCD WR Input #1

Closed metropt closed 7 years ago

metropt commented 8 years ago

I was trying to understand your schematic and I'm confused. Shouldn't WR input from the LCD be connected to 74VHC4040 Q4 ? I'm saying that because I suppose you want to WR the LCD when all the 16 bits are ready and that mean we need to count to 16: Q0 - 1 Q1 - 2 Q2 - 4 Q3 - 8 Q4 - 16

:s

wdim0 commented 8 years ago

Hi José,

the trick is, that only first 8-bits are used. By default, the LCD controller is also receiving only first 8-bit (the U3 is not used). You can check this yourself when you connect the original KeDei display to a microcontroller and write a simple program to drive the U1-U3 shift register. You'll realize, that only bits 7:0 are used and bits 15:8 (U3) are completely ignored. But .. this is exactly what we need when we want to hack the display and design a circuit that emulates the "4-wire 8-bit data serial interface II" standard. So that's why we write data every 8 bit .. not 16 bit. This is also advantage, because then we can connect ESP8266's HSPI interface and directly (driving 16-bit would be more complicated and I believe also slower (look at the draw line optimizations etc...)).

And as for your question about where to set the "mode" - see the esp8266_fast_lcd_driver_hspi https://github.com/wdim0/esp8266_fast_lcd_driver_hspi/include https://github.com/wdim0/esp8266_fast_lcd_driver_hspi/tree/master/include/ driver https://github.com/wdim0/esp8266_fast_lcd_driver_hspi/tree/master/include/driver /wlcd.h - the section inside "//======== WLCD MAIN CONFIG ========".

See you

Martin

2016-07-25 15:37 GMT+02:00 José Xavier notifications@github.com:

I was trying to understand your schematic and I'm confused. Shouldn't WR input from the LCD be connected to 74VHC4040 Q4 ? I'm saying that because I suppose you want to WR the LCD when all the 16 bits are ready and that mean we need to count to 16: Q0 - 1 Q1 - 2 Q2 - 4 Q3 - 8 Q4 - 16

:s

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/wdim0/esp8266_with_KeDei_lcd_module/issues/1, or mute the thread https://github.com/notifications/unsubscribe-auth/AQL1nFl-8a7063vF1umOMO-N0So_zi8dks5qZLwOgaJpZM4JUIMb .

metropt commented 8 years ago

I'll need to read the readme file again ... For some reason I though you use all the 32bit spi buffer to send the data to LCD. So the propagation delay you talk about come from the 74HC565?

On Jul 25, 2016 7:48 PM, "Martin Winkelhofer" notifications@github.com wrote:

Hi José,

the trick is, that only first 8-bits are used. By default, the LCD controller is also receiving only first 8-bit (the U3 is not used). You can check this yourself when you connect the original KeDei display to a microcontroller and write a simple program to drive the U1-U3 shift register. You'll realize, that only bits 7:0 are used and bits 15:8 (U3) are completely ignored. But .. this is exactly what we need when we want to hack the display and design a circuit that emulates the "4-wire 8-bit data serial interface II" standard. So that's why we write data every 8 bit .. not 16 bit. This is also advantage, because then we can connect ESP8266's HSPI interface and directly (driving 16-bit would be more complicated and I believe also slower (look at the draw line optimizations etc...)).

And as for your question about where to set the "mode" - see the esp8266_fast_lcd_driver_hspi https://github.com/wdim0/esp8266_fast_lcd_driver_hspi/include <https://github.com/wdim0/esp8266_fast_lcd_driver_hspi/tree/master/include

/ driver < https://github.com/wdim0/esp8266_fast_lcd_driver_hspi/tree/master/include/driver

/wlcd.h - the section inside "//======== WLCD MAIN CONFIG ========".

See you

Martin

2016-07-25 15:37 GMT+02:00 José Xavier notifications@github.com:

I was trying to understand your schematic and I'm confused. Shouldn't WR input from the LCD be connected to 74VHC4040 Q4 ? I'm saying that because I suppose you want to WR the LCD when all the 16 bits are ready and that mean we need to count to 16: Q0 - 1 Q1 - 2 Q2 - 4 Q3 - 8 Q4 - 16

:s

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/wdim0/esp8266_with_KeDei_lcd_module/issues/1, or mute the thread < https://github.com/notifications/unsubscribe-auth/AQL1nFl-8a7063vF1umOMO-N0So_zi8dks5qZLwOgaJpZM4JUIMb

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/wdim0/esp8266_with_KeDei_lcd_module/issues/1#issuecomment-235047267, or mute the thread https://github.com/notifications/unsubscribe-auth/AAuoiKjr7eHrKCfWxRTYgxBQ6Q_GS6YJks5qZQUWgaJpZM4JUIMb .

wdim0 commented 8 years ago

Hi José,

yes, it's using the whole HSPI buffer of ESP8266 - max. 512 bits in one transaction (16 x 32-bit HSPI buffer register). The HSPI is directly emulating 4-wire 8-bit data serial interface II. From the ESP8266's point of view, it's just writing 512 bits in a row without any SW intervention -> it's quite fast, compared to other ESP8266 possibilities. .. Or to explain it in a different point of view - when the speed is your main concern, the critical thing is SPI clock speed, not the 8-bit vs 16-bit shift register length, because you can still shift bits in this register only as fast as your SPI clock is. So don't worry about 8-bit shift register. See the YouTube video, demonstrating the speed ...

See you

Martin

On 25 Jul 2016 21:40, "José Xavier" notifications@github.com wrote:

I'll need to read the readme file again ... For some reason I though you use all the 32bit spi buffer to send the data to LCD. So the propagation delay you talk about come from the 74HC565?

On Jul 25, 2016 7:48 PM, "Martin Winkelhofer" notifications@github.com wrote:

Hi José,

the trick is, that only first 8-bits are used. By default, the LCD controller is also receiving only first 8-bit (the U3 is not used). You can check this yourself when you connect the original KeDei display to a microcontroller and write a simple program to drive the U1-U3 shift register. You'll realize, that only bits 7:0 are used and bits 15:8 (U3) are completely ignored. But .. this is exactly what we need when we want to hack the display and design a circuit that emulates the "4-wire 8-bit data serial interface II" standard. So that's why we write data every 8 bit .. not 16 bit. This is also advantage, because then we can connect ESP8266's HSPI interface and directly (driving 16-bit would be more complicated and I believe also slower (look at the draw line optimizations etc...)).

And as for your question about where to set the "mode" - see the esp8266_fast_lcd_driver_hspi https://github.com/wdim0/esp8266_fast_lcd_driver_hspi/include < https://github.com/wdim0/esp8266_fast_lcd_driver_hspi/tree/master/include

/ driver <

https://github.com/wdim0/esp8266_fast_lcd_driver_hspi/tree/master/include/driver

/wlcd.h - the section inside "//======== WLCD MAIN CONFIG ========".

See you

Martin

2016-07-25 15:37 GMT+02:00 José Xavier notifications@github.com:

I was trying to understand your schematic and I'm confused. Shouldn't WR input from the LCD be connected to 74VHC4040 Q4 ? I'm saying that because I suppose you want to WR the LCD when all the 16 bits are ready and that mean we need to count to 16: Q0 - 1 Q1 - 2 Q2 - 4 Q3 - 8 Q4 - 16

:s

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/wdim0/esp8266_with_KeDei_lcd_module/issues/1, or mute the thread <

https://github.com/notifications/unsubscribe-auth/AQL1nFl-8a7063vF1umOMO-N0So_zi8dks5qZLwOgaJpZM4JUIMb

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/wdim0/esp8266_with_KeDei_lcd_module/issues/1#issuecomment-235047267 , or mute the thread < https://github.com/notifications/unsubscribe-auth/AAuoiKjr7eHrKCfWxRTYgxBQ6Q_GS6YJks5qZQUWgaJpZM4JUIMb

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/wdim0/esp8266_with_KeDei_lcd_module/issues/1#issuecomment-235061397, or mute the thread https://github.com/notifications/unsubscribe-auth/AQL1nB2z-5SMIyCclg7Sbf8DKqAO496Iks5qZRFJgaJpZM4JUIMb .

metropt commented 8 years ago

Got it :) and about the propagation delay that come from the 74HC565, there isn't a fast IC?

On Jul 25, 2016 9:01 PM, "Martin Winkelhofer" notifications@github.com wrote:

Hi José,

yes, it's using the whole HSPI buffer of ESP8266 - max. 512 bits in one transaction (16 x 32-bit HSPI buffer register). The HSPI is directly emulating 4-wire 8-bit data serial interface II. From the ESP8266's point of view, it's just writing 512 bits in a row without any SW intervention -> it's quite fast, compared to other ESP8266 possibilities. .. Or to explain it in a different point of view - when the speed is your main concern, the critical thing is SPI clock speed, not the 8-bit vs 16-bit shift register length, because you can still shift bits in this register only as fast as your SPI clock is. So don't worry about 8-bit shift register. See the YouTube video, demonstrating the speed ...

See you

Martin

On 25 Jul 2016 21:40, "José Xavier" notifications@github.com wrote:

I'll need to read the readme file again ... For some reason I though you use all the 32bit spi buffer to send the data to LCD. So the propagation delay you talk about come from the 74HC565?

On Jul 25, 2016 7:48 PM, "Martin Winkelhofer" notifications@github.com wrote:

Hi José,

the trick is, that only first 8-bits are used. By default, the LCD controller is also receiving only first 8-bit (the U3 is not used). You can check this yourself when you connect the original KeDei display to a microcontroller and write a simple program to drive the U1-U3 shift register. You'll realize, that only bits 7:0 are used and bits 15:8 (U3) are completely ignored. But .. this is exactly what we need when we want to hack the display and design a circuit that emulates the "4-wire 8-bit data serial interface II" standard. So that's why we write data every 8 bit .. not 16 bit. This is also advantage, because then we can connect ESP8266's HSPI interface and directly (driving 16-bit would be more complicated and I believe also slower (look at the draw line optimizations etc...)).

And as for your question about where to set the "mode" - see the esp8266_fast_lcd_driver_hspi https://github.com/wdim0/esp8266_fast_lcd_driver_hspi/include <

https://github.com/wdim0/esp8266_fast_lcd_driver_hspi/tree/master/include

/ driver <

https://github.com/wdim0/esp8266_fast_lcd_driver_hspi/tree/master/include/driver

/wlcd.h - the section inside "//======== WLCD MAIN CONFIG ========".

See you

Martin

2016-07-25 15:37 GMT+02:00 José Xavier notifications@github.com:

I was trying to understand your schematic and I'm confused. Shouldn't WR input from the LCD be connected to 74VHC4040 Q4 ? I'm saying that because I suppose you want to WR the LCD when all the 16 bits are ready and that mean we need to count to 16: Q0 - 1 Q1 - 2 Q2 - 4 Q3 - 8 Q4 - 16

:s

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/wdim0/esp8266_with_KeDei_lcd_module/issues/1, or mute the thread <

https://github.com/notifications/unsubscribe-auth/AQL1nFl-8a7063vF1umOMO-N0So_zi8dks5qZLwOgaJpZM4JUIMb

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <

https://github.com/wdim0/esp8266_with_KeDei_lcd_module/issues/1#issuecomment-235047267

, or mute the thread <

https://github.com/notifications/unsubscribe-auth/AAuoiKjr7eHrKCfWxRTYgxBQ6Q_GS6YJks5qZQUWgaJpZM4JUIMb

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/wdim0/esp8266_with_KeDei_lcd_module/issues/1#issuecomment-235061397 , or mute the thread < https://github.com/notifications/unsubscribe-auth/AQL1nB2z-5SMIyCclg7Sbf8DKqAO496Iks5qZRFJgaJpZM4JUIMb

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/wdim0/esp8266_with_KeDei_lcd_module/issues/1#issuecomment-235066950, or mute the thread https://github.com/notifications/unsubscribe-auth/AAuoiDxL0_lLCBp38qpuqbYd4rkCrXCtks5qZRYggaJpZM4JUIMb .