Add T6963 240X64 mode

[RndMnkIII]

Hello, can you add support for T6963 240X64 screen mode.

[olikraus]

I need a little support for this: How does the current 240x128 appear? Does it work except for the fact that the screen is too large? Can you sent a picture of the u8g2 logo?

[RndMnkIII]

I ve tested 240x128 limiting to 240x64 working ok Output from FPS program: https://drive.google.com/file/d/0By5wADoEOJ9fOG5mZ1hzbGQzdjA/view?usp=sharing https://drive.google.com/file/d/0By5wADoEOJ9fS3NsSVNScW8yakE/view?usp=sharing https://drive.google.com/file/d/0By5wADoEOJ9fMEFGOVlVM0VUck0/view?usp=sharing https://drive.google.com/file/d/0By5wADoEOJ9fdDJJZGxMejF1WHM/view?usp=sharing

[RndMnkIII]

I've using a teensy 3.2 with logic levels converters from 3.3v to 5v. I'm not sure if my T6963 can accept 3.3v signals

[RndMnkIII]

Seems not particular fast, The T6963 is the culprit?

[olikraus]

Thanks for the pictures. I will create a 240x64 device based on this.

Seems not particular fast, The T6963 is the culprit?

Speed will double with the 240x64 display. In general the parallel interface is not so much optimized to keep Arduino compatibility.

[RndMnkIII]

Can you help me, please? I've have to choose between 3.2" 256X64 oled display with SSD1322 controller or a 5" LCD t6963c 240x64. Which controller is fastest? The SPI interface can be faster than parallel? The Teensy 3.x SPI vs Arduino SPI can be faster? The Teensy 3.x overclocking can made faster, with SPI or Parallel? The 3-wire SPI / 4-wire SPI add any speed advantage? http://www.buydisplay.com/default/5-2-inch-graphic-lcd-240x64-module-display-t6963-white-on-black http://www.buydisplay.com/default/oled-3-2-inch-displays-module-companies-with-driver-circuit-blue-on-black

Thanks!

[christophepersoz]

Hello, SPI on Teensy is much faster than the Arduino's one - 5MHz at maximum speed. I made some test with a SSD1322 on Teensy 3.2 board, here the link of the results : https://forum.pjrc.com/threads/23445-Teensy-3-0-and-u8glib?p=86456&viewfull=1#post86456

Hope that can helps.

[RndMnkIII]

Thank you. I'll try the SDD1322 in SPI mode when I receive the order

[RndMnkIII]

For testing purposes, also I've tested the T6963 with theU8GLIB library with U8GLIB_T6963_240X64 and U8GLIB_T6963_240X128 with not success with the Teensy 3.x, working OK with the Arduino Mega 2560.

[olikraus]

I think U8glib will not work with Teensy.

[christophepersoz]

I does, but you need to use a wrapper, and it works quite fast :D

[RndMnkIII]

the U8GLIB works with the KS0108 with teensy 3.2, tested with 192x64 screen. Can be something related to the controller initialization?

[olikraus]

The KS0108 parallel interface differs from the T6963 interface. So it might be caused by that interface. But there might be also an issue with the wrapper or the controller itself. One of the goals of u8g2 had been a more portable low level interface. At least for u8g2 I hope it will work more reliable with the Teensy.

[RndMnkIII]

I fixed temporarily by a small modification in u8x8_d_t6963.c in the static const u8x8_display_info_t u8x8_t6963_240x128_display_info:

  /* tile_hight = */ 8, /*RndMnkIII modified: original value 16*/
 /* pixel_height = */ 64 /*RndMnkIII modified: original value 128 */

for speed up the drawing effectively using only 240x64 resolution. This is a total hack, waiting for a cleaner code implementation. Greatly improved by near x2 factor: -draw clip test 28.4 -clear screen 26.1 -draw @ 15.8 -draw pixel 18.1

[RndMnkIII]

Tested without logic level converters. My T6963 works OK with 3.3v signaling, remaining 5v for VDD, LED_A.

[RndMnkIII]

In u8g2 where actually the data is written to data pins?. I want to replace the generic digitalWriteFast by byte write to GPIOD_PDOR (32 bits GPIO D port pins: 2,14,7,8,6,20,21,5) where actually is mapped my teensy 3.2 data pins.

[olikraus]

You have to create a new byte output procedure: u8x8_byte_8bit_6800mode or u8x8_byte_8bit_8080mode both are defined in u8x8_byte.c The byte procedure is part of the constructor in U8g2lib.h

[RndMnkIII]

First, I want to apologize for this change of code because it breaks completely with the portability of the library and good standards of writing code, but it shows the potential to substantially improve the speed by applying small modifications.

In uint8_t u8x8_byte_8bit_8080mode, changed the following:

#define GPIOD_PDOR      (*(volatile uint32_t *)0x400FF0C0) // Port Data Output Register
...
...
...
    //Added by RndMnkIII
    //GPIOD_PDOR = GPIOD_PDOR | (*data);
    GPIOD_PDOR = b;
    data++;
    arg_int--;
    // Commented out by RndMnkIII
    // for( i = U8X8_MSG_GPIO_D0; i <= U8X8_MSG_GPIO_D7; i++ )
    // {
      // u8x8_gpio_call(u8x8, i, b&1);
      // b >>= 1;
    // }  

Resulting in the following test results: -draw clip test 62.5 -clear screen 51.9 -draw @ 22.9 -draw pixel 28.2

See the scrolling text is more smooth, using 1 pixel step: https://drive.google.com/file/d/0By5wADoEOJ9fcmZNVzE4WnZrUnc/view?usp=sharing

[RndMnkIII]

As side effect I've to use shorter cables because I've started to observe pixel artifacts in the screen. It's not too visible. I dont't know that this is related to my modifications or the greater speed at the microcontroller writes to the screen.

[olikraus]

Excellent scrolling :-)

Obviously, there is always a tradeoff between speed, code clarity and portability. If it had been easy enough for you to increase speed for your specific environment and setup, then I am happy.

[olikraus]

I have added the new constructor for the T6963 240x64 display. It is included here for download https://github.com/olikraus/U8g2_Arduino

[RndMnkIII]

Thank You. Tested and working!

[RndMnkIII]

Adding delayMicroseconds() of 4-5 after GPIOD_PDOR = b; almost remove pixel artifacts reducing a bit the performance but improving the appearance.

[olikraus]

yes, i guess there must be a minimal delay

[olikraus]

can we close this issue?