ls013b7dh03 display has incorrect SPI configuration

[eraustud]

The Sharp Memory LCD Application Guide states:

The SPI port should be set up so that, in the idle state, the serial chip select (SCS) and the serial clock (SC) are LOW. Data is clocked on the rising edge of SC.

The ls013b7dh03 and ls027b7dh01 displays (both in csrc\u8x8_d_ls013b7dh03.c) are configured for active low, rising edge. This causes the HW SPI implementation to skip 1 bit per byte, resulting in a stripe every 8 pixels on the display.

Switching the SPI mode byte in u8x8_display_info_t for the displays to 1 seemed to resolve the issue when running HW SPI, but broke the SW SPI implementation, so changing the SPI mode byte is not a complete fix.

Tested on a Teensy 3.2 with an ls027b7dh01 2.7" LCD display

[olikraus]

You mean it works correctly with SW SPI?

[eraustud]

The library code appears to work correctly in SW SPI mode in its current state. However, flipping the SPI mode to 1 fixes the HW SPI problem and breaks the SW SPI implementation.

[olikraus]

Can I buy one of those displays somewhere?

[eraustud]

https://www.digikey.com/product-detail/en/sharp-microelectronics/LS027B7DH01A/425-2908-ND/5054067

I had to make my own 10 pin 0.5mm breakout board to be able to breadboard it. Hopefully you already have something like that from working with other FFC/FPC-connected displays.

[eraustud]

Since it looks like it would be expensive for you to have digikey ship to Germany, I can test some code for you, if you like. I think the only issue is that the clock line needs to be active high and the data reads on rising edge. If you can implement that in SW SPI while keeping the HW SPI on mode 1, I can try it out on the displays we have here.

[olikraus]

Indeed, I think I take the testing option. Any SW SPI code suggestion, would be useful too.

[olikraus]

Notes (mostly for myself): I once made some pics regarding SPI mode: https://github.com/esp8266/Arduino/issues/2416 Currently, code is configured for Mode 2: https://github.com/olikraus/u8g2/blob/master/csrc/u8x8_d_ls013b7dh03.c#L136 and https://github.com/olikraus/u8g2/blob/master/csrc/u8x8_d_ls013b7dh03.c#L172

Nice page with several references: https://makerdyne.com/2015/02/08/large-memory-lcd-breakout-board-details/

little bit expensive: https://www.exp-tech.de/displays/lcd/5090/sharp-memory-display-breakout-1.3-96x96-silver-monochrome

[olikraus]

Taking this picture:

(spi modes are from left (mode 0) to right (mode 3) and comparing this with the sharp datasheet (LS013B4DN04 page 13), then the correct mode should be 0.

Can you change the mode to 0 (in the sourcecode) and test whether it works with HW SPI and SW SPI?

[eraustud]

Apologies for the long break; I got pulled away on other projects for a while.

I updated the u8x8_display_info_t u8x8_ls027b7dh01_400x240_display_info code in u8x8_d_ls013b7dh03.c to SPI Mode 0, and the screen appears to be working just fine. Drawing works properly to the edges of the screen.

My guess is that when I tried Mode 0 before, I was making errors in setting draw colors and the like.

---

On another note, it appears that the ls027b display's display_cb callback function uses a "SWAP8" macro to rearrange the bits as opposed to just setting LSBFIRST in the SPISettings call in the u8x8_byte_arduino_hw_spi(u8x8_t u8x8, uint8_t msg, uint8_t arg_int, void arg_ptr) function.

Would it be feasible to include the MSBFIRST/LSBFIRST option as a struct somewhere, perhaps with getters and setters like what is done for the bus clock and have it be part of the U8X8_MSG_BYTE_INIT? I can just hard-code LSBFIRST on my copy of the library, but I imagine that some other obscure displays may also use LSBFIRST.

edit: For reference, here's a working link to the LS027B datasheet.

The timing diagram is identical to the one you linked, so this is just for reference in case there is additional data you need from it.

[eraustud]

*Correction. I forgot to test the SW SPI:

• HW SPI works when the struct is set to mode 0.
• SW SPI does not work. Instead, it produces something that looks like this:

It looks like the top tiles and the pixels at x_max and y_max are not showing correctly. This is using SPI mode 0. Mode 2 behaves the same way, and Modes 1 and 3 simply do not work at all (as expected).

Hopefully, you recognize where there might be the off-by-one error or similar that is causing this. I'll be using the HW SPI (which seems to work perfectly w/ mode 0), so please don't feel rushed to address this on my account.

edit: It's just the top tile that is missing. The missing pixels at max_x and max_y were because I was drawing a box of (0,0,width-1,height-1).

[olikraus]

Thanks for the feedback. So your suggestion is to use mode 0 for displays, right? The LSBFIRST in the SPISettings is Arduino specific. I can not rely on this for other platforms. Also, I would need to change this setup depending whether I want to send a command or data. This will be very complicated.

So, the todo at the moment is: change SPI mode to 0.

Not sure what is wrong with SW SPI...

[eraustud]

Yes, my suggestion is to use mode 0 for HW SPI, but leave the code unchanged for SW SPI.

Thank you for explaining the SPISettings difficulty. It is not important; I was simply curious.

I think this ticket can be closed when the HW SPI mode change is committed, as the HW SPI is the important issue. The screen takes a very long time to update using SW SPI, so I think few people will want to use it.

Thank you very much for making the u8g2 library! It has been very easy to use and the documentation and code is very easy to read.

[olikraus]

So you say, that HW SPI requires mode 0 and SW SPI requires mode 2

strange...

Info for myself: Maybe implement two versions of the device one with mode 0 and one with mode 2

[olikraus]

Implemented U8G2_LS027B7DH01_M0_400X240_x_4W_HW_SPI for SPI Mode 0