Prefix before data

[mkohns]

Hi Noralf, first of all - great project. I am very happy to have it.

I am developing software for Siemens S65 LCD displays. I have working code for rpi for LS020 and LPH88 displays (native C SPI and GPIO handling). I now try to port it to your framework.

I have following question:

Both LCD controllers want to have a special hex value before video data can be streamed. This value must be inside the spi data frame (CS LOW, SPECIAL VALUE, ALL VIDEO DATA, CS HIGH).

I see 2 possibilities:

1) overwrite par->fbtftops.write_vmem, and copy the video buffer to an new buffer[len+1] and set buffer[0]=special value. I hate to do so. Bad overhead.

2) like Chrisitan in r61505u. He used an own gpio for cs and bit banged it in [write] and [write_vmem]. I think this is also not very nice.

What do you think would be best practise?

Greetings from Germany, Mirko

[notro]

This is quite a coincidence, I'm just now writing a driver for the ili9320 which needs a start byte inside the SPI transfer. I have never looked at the r61505ufb code before, but I see now that it is very similar to what I'm doing. Not sure why he's using a gpio for CS though. I don't see any other alternative than to have a dedicated write_vmem(), since the byte has to be inside the transfer. Raspberry Pi is Little Endian and thus have the two bytes swapped in a 16-bit value, so a transfer buffer is needed in any case to get the bytes in the right order.

The question for me is: Should the prefix be configurable or does all controllers of this kind use 0x70 for register write and 0x72 for data write? Does all transfers on your controller start with a special byte?

[mkohns]

most controllers that I know (which do not have a dc line to determine between data and cmd) have a so called automatic data command detection. This "automatic" is by sending a prefix. I have serveral prefix, 1byte, or 2 bytes long. It more looks like

a) opcodebyte1, params b) opcodebyte1, opcodebyte2, params.

where params could also be video data stream.

look at this code for overview: https://github.com/watterott/S65-Shield/blob/master/src/libraries/S65Display/lph88.cpp

[mkohns]

Hava a working version for lph88fb now. I decided for the buffer copy and get ~20 frames per second. Test videos look great. How can I commit them? Or shall I send you an email?

[notro]

You can just paste it here using a

code block

https://help.github.com/articles/github-flavored-markdown#fenced-code-blocks

I haven't had time to look more into this. Will do later.

[notro]

b) opcodebyte1, opcodebyte2, params.

Do you have an example of this case?

[mkohns]

in lph88fb.c you will find

lph88fb_write(par, 0x74, 0x00, 0x02); lph88fb_write(par, 0x76, 0x00, 0x00);

This is an example for opcode, param, param.

There is also some cmd for contrast, brightness, etc. I did not implement them in lph88fb.c, but they look like

lph88fb_write(par, 0x78, 0x01, 0x00);

where 0x78 is the main opcode, and 0x01 is brightness, 0x02 would be contrast. 0x00 is the param.

But .. you could also implement the second opcode to the param. This would not make a big difference.

[notro]

I have implementet startbyte support in FBTFT:

• add 'startbyte' argument: https://github.com/notro/fbtft/commit/60e7120c83f03786f549205c268faf7337f94857
• fbtft: fbtft_write_vmem16_bus8() add Start byte support: https://github.com/notro/fbtft/commit/4ae172bc64c054f163fe827668e2c7b5041f12b7
• fbtft: add Start byte support: https://github.com/notro/fbtft/commit/f1c76bf1b2dbc43bce358d31bd30d0c2437593d6

It is enabled with an argument to fbtft_device. hy28a uses a default if no statbyte is specified.