What is the most power-efficient way (in terms of the nrf52840) to drive an LCD screen with six data lines?

[thejeffcooper]

Hi DevZone,

I'm a hobbyist working on a wearable project using nrf52840 and a memory LCD from sharp. I'm currently using the monochrome LS018B7DH02 and driving it using SPI (I believe this uses the SPIM peripheral with EasyDMA under the hood, but I'm not positive). This works great because the display only has one data line and one clock line (that is, it's a traditional SPI device), and I can buffer the data, feed it to the SPIM peripheral, and be done.

I'm considering moving my project to instead use the LS021B7DD02 (datasheet) memory LCD, which has 2-bit RGB color per pixel, but I'm not sure what the best way to do it is. Instead of one data line, this one has six - two each for red, green, and blue - in addition to a more complex series of clock signals. The relevant part of the timing diagram from the datasheet looks like this:

My question is this: what is the most power-efficient way to drive this LCD from the perspective of the nrf52840 CPU? Power efficiency in my mind seems like it should mostly be decided by how much CPU-on time the update uses, which is why I think I get such a benefit from the SPIM peripheral / EasyDMA under my current scheme. With six data lines, though, I'm not sure if there exists a peripheral (or a way to abuse a peripheral) to drive all of them in sync with the same clock from a memory buffer. The alternative is bit-banging the output with GPIO pins, which I'm sure would work, but would eat up a comparatively large amount of CPU time (moving from bitbanging to SPIM under my current one-channel scheme was a 4x speedup!) and thus consume more power.

Thanks!

[thejeffcooper]

I think the "right" way to do this is probably to use a driver chip like the S1D13C00 (which is what's on the product page from sharp), but unfortunately this chip doesn't seem to be available in quantities smaller than a few hundred.

[Jared]

Hi,

My question is this: what is the most power-efficient way to drive this LCD from the perspective of the nrf52840 CPU? Power efficiency in my mind seems like it should mostly be decided by how much CPU-on time the update uses, which is why I think I get such a benefit from the SPIM peripheral / EasyDMA under my current schem

Yes exactly, with the SPIM peripheral you can avoid using CPU power during the transaction, only time it would be used when the data has to be processed. 

With six data lines, though, I'm not sure if there exists a peripheral (or a way to abuse a peripheral) to drive all of them in sync with the same clock from a memory buffer.

The alternative is bit-banging the output with GPIO pins, which I'm sure would work, but would eat up a comparatively large amount of CPU time (moving from bitbanging to SPIM under my current one-channel scheme was a 4x speedup!) and thus consume more power.

No, there isn't any such peripheral. Yes, this would require the CPU to on most of the time which would require more power. But you were able to speed the transfer 4x when you moved to SPIM? If so, then I would definitely not see the motivation of implementing the bit banging, as you could go to IDLE sleep earlier to conserve power in between the transfers. 

regards

Jared 

[thejeffcooper]

Thanks for the reply! The problem is that I would need 6 data lines all clocked together coming out of the nrf52, or I'd need some sort of low power shift register to accept 6 or 8 bits at a time and output them.

Is it possible to run two SPIM data lines on the same clock line somehow? That opens up a lot more possibility here, even if it's not ideal.

[Jared]

thejeffcooper said:

Is it possible to run two SPIM data lines on the same clock line somehow? That opens up a lot more possibility here, even if it's not ideal.

No, that is not possible. Each SPIM instance will have it's own dedicated SCLK. But maybe you could try to synchronize them by using PPI to start the task simultaneously on the same event? Not sure if that would fix your issue? 

[thejeffcooper]

That might work! I wasn't aware of PPI. Can you point me at an example of using it? I won't be able to test this on real hardware for a week or two, but I'd like to have as many options to test as possible before then.