Using a serial LCD module

[flybabo]

I'm working on retrofitting a 9x board to an old vintage transmitter (Kraft 7C).
I'd like to replace stock LCD by a small 128x64 LCD module with serial mode interface
since I don't want to punch a big hole on the beautiful metal box.
Serial data transmission to the LCD module may slow down refreshDisplay() function around 24x.
Question I have is does that cause a problem in normal system operation.
Is there any info on the runtime profile of major functions of open9x code (ala callgrind output)?
Thanks,
HT

[MikeB]

I think you will find er9x, ersky9x and open9x all work the same way for the display. They have a graphics buffer in memory, which is filled in, then a single routine puts the whole lot on the actual display.

Mike.

[flybabo]

If I read the code correctly, current implementation writes out the graphics buffer 1 byte at a time since the stock LCD module has a byte-wide data bus connected to PORTA_LCD_DAT[0:7].
If I use a serial LCD like this http://www.ebay.com/itm/12864-128X64-Se ... 4217772%26, I should rewrite the refreshDisplay() in such a way that it writes out the graphics buffer one bit at a time through PORTA_LCD_DAT[0].
That requires 8 write cycles for 1 byte graphics data and each write cycle requires two additional write operation to generate a data strobe.
This increases refreshDisplay() execution time at least 8x(1+2)=24x in addition to a byte-to-bit conversion operation.
If I use the same port for data and strobe, the write performance may be slightly improved.
Well, I may have to buy the serial LCD, solder it and hack the code to see what happens.

[bertrand35]

But why this screen?
Bertrand.

[flybabo]

But why this screen?
Bertrand.

I'd like to replace an analog RF/volt meter of Kraft 7C Tx by this LCD module.
The size of the meter is about 40x25mm and I couldn't find any LCD module
having parallel interface with this size.
HT

[Romolo]

What about this one ?
http://www.adafruit.com/products/326
Ok very small, but have a look on oled displays there are many that can fit with parallel interface

http://www.trulydisplays.com/oled/index.html

[flybabo]

What about this one ?
http://www.adafruit.com/products/326
Ok very small, but have a look on oled displays there are many that can fit with parallel interface

http://www.trulydisplays.com/oled/index.html

Actually I have been looking for a LCD module with ST7565 controller which is same as the one used by stock LCD module.
Since I have to hack the code anyway to make it work, I should look for LCD modules with parallel interface using different controller as well.
Thanks for the links.
HT

[SkyNorth]

How about 128 x 32 ?
SPI - ST7565 , but its runs on 3.3V max.
http://www.digikey.com/product-detail/e ... ND/2059236

[Romolo]

How about 128 x 32 ?
SPI - ST7565 , but its runs on 3.3V max.
http://www.digikey.com/product-detail/e ... ND/2059236

128x32 can be a problem, not only hacking the code for the display driver but also all the menus...
furthermore in 128x64 we are sometimes already limited, I cannot figure in 128x32

[flybabo]

I found one on eBay and it supports both SPI and 6800/8080 style parallel interface.
http://www.ebay.com/itm/130658588870?_t ... 97.c0.m619
Since this module uses SSD1306 COG, the LCD driver should be rewritten.
HT

[Kilrah]

Same one Romolo showed, just a different adapter PCB

[bertrand35]

The LCD driver should not be too complex to write, but all the menus to rewrite would take much more time. So I really suggest you stick with a 128x64 resolution!
Bertrand.

[flybabo]

The LCD driver should not be too complex to write, but all the menus to rewrite would take much more time. So I really suggest you stick with a 128x64 resolution!
Bertrand.

Yeah, I know it - that's why I'm sticking with 128x64 module.
Also, I don't want to (can't?) solder any flex cable - that's why I'm looking for a LCD module with adapter board.
Thanks guys,
HT

[flybabo]

Same one Romolo showed, just a different adapter PCB

Right

[flybabo]

I roughly calculated runtime required to dump entire frame buffer based on compiled assembly code after I modified refreshDisplay() for a serial LCD module. Each byte of display data writing requires ~100 instructions (not 24).
So, approx runtime to refresh entire frame buffer is whopping 6.4ms (=(128x64/8)x100)/16MHz)
Unless I rewrite the refreshDisplay() in such a way that the frame buffer got refreshed in the background, I don't think I can put any serial LCD on 9x system.
Any thoughts?
Thanks,
HT

[MikeB]

100 instructions sounds a lot. Can you post your code, I might be able to suggest some improvements.
The original, parallel, refreshDisplay() took around 4mS to update the LCD, I improved that to around 1mS I think.

Mike.

[flybabo]

I just modified the innermost for-loop of refreshDisplay() in a straightforward manner:

Original byte-wide write loop:
for(uint8_t x=DISPLAY_W; x>0; --x) {
PORTA_LCD_DAT = *p++;
PORTC_LCD_CTRL |= (1<<OUT_C_LCD_E);
PORTC_LCD_CTRL &= ~(1<<OUT_C_LCD_E);
}

Modified for bit-wide write loop:
for(uint8_t x=DISPLAY_W; x>0; --x) {
uint8_t b = *p++;
for (uint8_t z=8; z>0; --z) {
if ((b&1)!=0)
PORTA_LCD_DAT |= 1;
else
PORTA_LCD_DAT &= ~1;
b >>= 1;
PORTC_LCD_CTRL |= (1<<OUT_C_LCD_E);
PORTC_LCD_CTRL &= ~(1<<OUT_C_LCD_E);
}
}

If I use whole 8bit PORTA_LCD_DAT for a single bit serial connection, I can replace the bit test if-else statement by a single assignment statement: PORTA_LCD_DAT = b;
But I'd like to save remaining 7bits of PORTA_LCD_DAT for other purpose if possible.
I also thought about unrolling/expanding the for-loop by typing in same thing 8 times.
Any other suggestions?
Thanks,
HT

[MikeB]

Yes to unroll the loop, it savesall the loop counter every bit. I'm not sure where you got the original code from, the existing code for er9x outputs 4 bytes in sequence before looping round.

To set the output bit, try:

PORTA_LCD_DAT &= 0xFE ;
if ( b & 1 ) PORTA_LCD_DAT |= 1 ;

only uses 3 instructions, + 2 for the 'E' bit is 5 instruction per bit, so 40 per byte + 4 for the loop control = 44 per byte giving around 2.8mS to update.

Mike.

[flybabo]

Thanks Mike!
I checked out open9x code from google code depository 2 days ago. I have to recheck whether I have up-to-date source code.
Do you have any info about slack time per 20ms frame update cycle on er9x?
Since original refresh time for parallel LCD was 4ms before you improved, a serial LCD with 2.8ms refresh time shouldn't cause any problem. Is it correct interpretation?
Thanks,
HT

[MikeB]

Er9x has slightly different code in refresh_diplay() (Yes diplay not display!), it uses a few extra bytes of flash, but is faster.

On er9x, if you go to the STAT2 screen it shows how long main takes to loop round. The value is the longest time taken, Press MENU LONG to reset it.

Mike.

[bertrand35]

If I measured well, er9x is 150us faster and uses 22bytes flash more. On open9x it's the DEBUG screen which will give you the same info about the main max time.
Bertrand.

[flybabo]

I bought a Turnigy 9x many months ago and finally soldered a programming connector on the stock board and flashed the latest er9x firmware.
If I read STAT2 screen correctly, main took less than 5ms. If open9x took extra 150us, it must be slightly over 5ms. (I'll try open9x this weekend)
That means I have a plenty of time to refresh the serial LCD module!
As you may know, we also can convert stock LCD module to the serial mode by simply relocating a jumper resistor.
(R40 to R41 in Gruvin's v2 schematic)
By doing so, we can free 8bits of I/O (PA0-PA5, PC4, PC5) for other purposes.
Any thoughts about this conversion?
Thanks,
HT

[bertrand35]

In STATS screen you see the duration of the main (including the mixer / the menus / LCD refresh / everything else). So the duration will depend on the complexity of your model, more than the LCD refresh which here is not significant (150us are not a lot compared to the time needed for complex mixers / curves!).

Also keep in mind that the main time is increased by the interrupts, audio and voice use a lot of interrupts, some protocols as well ...

Bertrand.

[flybabo]

Hi Bertrand,
Do you have any complex model/mixing example?
What's the longest main run time you've ever seen?
Thanks,
HT

[MikeB]

Er9x may be different, on the stat screen of er9x, the time for main is the longest seen, reset to a new value with MENU LONG.
Also on er9x, I have seen the value reach 25 and 30mS after going round the menus. These values may be long as I think that when chaining from one menu to another both menus are executed in one pass round the loop.

Mike.

[bertrand35]

Er9x and open9x/stock do the same on the STATS screen then. To have a big value on open9x, you will create 3 flight phases associated to ID0 / ID1 / ID2 and you will add a slow transition between the phases. Then you will create a lot of mixes with slow and delay. After that you switch very quickly from ID0 / ID1 / ID2. I think you will be able to see values around 30ms
Bertrand.

[Ariel]

Hello, I am Ariel from Spain.

Y try to connect the LCD serial SSD1306 but i can't see the schematic or the pin-out to connect to the 9xr main-board.

I see this fantastic work in a old transmitter:
download/file.php?id=6156

I have the same LCD and need the connections to put ready my special 9xr.

Can any show me the connections or schematic Please

thanks friends.
Regards.
Ariel

[simonhun]

wiring guide for display control pins in parallel mode (for oled SSD1306):
IN CODE ------------- ATMELPIN ----- OLEDPIN ---- LCDPIN(gruvin9x_v2_actual-1.pdf)
OUT_C_LCD_E --------- PORTC5 ------ E/RD ------- LCD_RD
OUT_C_LCD_RnW ----- PORTC4 ------ R/W ------- LCD_WR
OUT_C_LCD_A0 ------- PORTC3 ------ D/C -------- LCD_A0
OUT_C_LCD_RES ------ PORTC2 ------ RES -------- LCD_RES
OUT_C_LCD_CS1 ------ PORTC1 ------ CS --------- LCD_CS1
but it's not working. I don't know why.