Sharp Memory LCD Displays = Ultra Low Power


@Wingman Check your in box.

What is your application?

@ScruffR I ended up choosing this chip for it’s ultra low power consumption and because I needed the VCOM to be toggled even when the Photon is off to keep the screen ON while everything else is sleeping.


The screen gets all scrambled sometimes when photon is connected, even though I have SYSTEM_THREAD(ENABLED). Is there any fix other than SYSTEM_MODE(MANUAL)? Particularly animations, however simple, mess things up quick.


@Meizirkki, without seeing your code, you hardware design and which library you are using, it is incredibly hard to help you! Can you please supply more details :grinning:


Of course :slight_smile:
I’m using these (slightly modified) adafruit libraries.

I have:

Adafruit_SharpMem display(SCK, MOSI, SS);

In the beginning of my code and the display is initialized in the setup routine like this:

  // Initialize display

I use a timer for refreshing the screen:

void refreshScreen() { display.refresh(); }
Timer refresh(1000, refreshScreen);

refresh.reset(); is called every time something is to be drawn on the screen, to avoid timed refresh during that.

Now I’d like to have a kind of “loading” animation when photon is connecting to the cloud or waiting for input from cloud. I know this is probably the worst time to be actively drawing on the display, but having this would add to a pleasant user experience.

Here’s an example of an aesthetically pleasing loading animation on the 2,5" display: (looks simple, but probably is not in terms of CPU time)

void loadingAnimation(int x, int y) {
	display.fillCircle(x, y, 4, WHITE);
	display.drawCircle(x, y, 8, WHITE);
	display.drawCircle(x, y, 12, WHITE);
	display.drawCircle(x, y, 16, WHITE);
	display.drawCircle(x, y, 20, WHITE);
	display.fillCircle(x, y, 4, BLACK);
	display.drawCircle(x, y, 8, BLACK);
	display.drawCircle(x, y, 12, BLACK);
	display.drawCircle(x, y, 16, BLACK);
	display.drawCircle(x, y, 20, BLACK);
	display.fillCircle(x, y, 24, BLACK);

I’d like to run this animation every 1 or 2 seconds to let the user know the device is not frozen. However, if the photon happens to receive data from cloud (as is expected) at the time this animation is running, the screen goes nuts and needs to be refreshed multiple times before returning back to normal.

My hardware is a custom PCB with photon, a connector for the display and some buttons on it. The SPI wires do go within 15mm of the antenna, can that cause problems?


@Meizirkki, using a software timer for the refresh will cause conflicts with the SPI port. The reason is that the code uses software refresh vs hardware refresh with an external timer. When the timer callback fires, it will take over the SPI hardware, screwing any transactions in progress. You need to either create a flag that you set whenever you are writing to the display to prevent the timer from calling display.refresh() or rethink your code to do not use the timer.

In your case, I noticed you are using software SPI instead of hardware SPI. Using hardware SPI would be faster. I have a library for that if you are interested.

The animation can be done with a cascading non-blocking FSM that goes through the animation “frames” at a fixed time interval (30 fps or every 17ms is good). If you need help with that, let me know.



[quote=“Meizirkki, post:145, topic:2747”]
refresh.reset(); is called every time something is to be drawn on the screen, to avoid timed refresh during that.
[/quote]I’m doing this to avoid timed refresh during writing to display. Whenever the timer is reset there’ll be a whole second before the next timed refresh. Plus, the problem persists even when no timer is used at all. In my current firmware the timer is only started at the end of the setup routine, after the most troublesome part that is connecting to cloud.

I’m definitely interested in using hardware SPI, if that fixes things and doesn’t cost too much :blush:

[quote=“peekay123, post:146, topic:2747”]
The animation can be done with a cascading non-blocking FSM that goes through the animation “frames” at a fixed time interval (30 fps or every 17ms is good). If you need help with that, let me know.
[/quote]This went way over my head :grin: Maybe it’s not that complicated, I don’t know, but I’ll probably need a lot of help here. If there’s a way to fix the current code I’d like to stick to that for now. (:

Thanks for the help!


I’m not sure why @peekay123 said this

since the library you linked above does seem to me to be using hardware SPI (despite the superfluous parameters for MOSI/SCLK), unless your “slightly modified” version does swap these bits out for software SPI

void Adafruit_SharpMem::init() {
  // Set pin state before direction to make sure they start this way (no glitching)
  digitalWrite(_ss, HIGH);  
  digitalWrite(_clk, LOW);  
  digitalWrite(_mosi, HIGH);  
  pinMode(_ss, OUTPUT);
  pinMode(_clk, OUTPUT);
  pinMode(_mosi, OUTPUT);

void Adafruit_SharpMem::sendbyte(uint8_t data) 

void Adafruit_SharpMem::sendbyteLSB(uint8_t data) 


@ScruffR The libraries I use are as in github :blush:


Problem solved, my bad! :sweat: It was exactly what @peekay123 said about refreshing the screen while writing. Though I thought I had taken care of that I can’t reproduce the error with new code I wrote no matter how much I use cloud functionality. Thanks for helping out! :blush:


The colour library for which you paid 500$, will it work for Arduino compatible chips having 16kb Ram and 128kb flash?

If it will work, i would be intrested to make your dwvelopment cost lower :slight_smile:


@amitkumarsharma008 I do not think so due to low ram but we would have to ask @peekay123 to be sure.

I know it will work on the Photon & Electron though.

You will need some special software we had modified to create the bitmap image files but it’s only like $50-80.


But as far as I saw, peekay is maintaining a library for Arduino as well in that same place.

And for Ram, 16kb is quite enough to drive it i guess. I have a variant of Arduino which have 16kb ram.

@peekay : Can you please throw some lights here:)


@amitkumarsharma008, @RWB, the Sharp color display is 128x128 piexels and the library requires 6,144 bytes of RAM for the display buffer.

The current libraries are for the monochrome Sharp displays which are far simpler to use.


@amitkumarsharma008 What are you trying to use the Color LCD for? I can tell you that the resolution on the color screen is not a high as I would like or as high as what you would see on the new Pebble Time watches.

But some images do look good. If you don’t need the lowpower, then a similar color OLED display may be way easier to work with.


@RWB, the Pebble display is totally different and either is not made by Sharp or is custom and not available otherwise. :pensive:


@peekay123, The Arduino version which you have kept in the github can be adopted for this colour diaplay as well?


@amitkumarsharma008, nope. The basics yes but the buffer and pixel manipulation is totally different, explaining why I wrote a library for @RWB. I suspect that this library is the only one available for that display. Even Sharp had crappy documentation and I had to do a lot of trial-and-error coding to get it working, as @RWB can attest.


@peekay123 Yes, I also was not able to buy the color displays from the company that Pebble is using. They are not interested unless you want to buy 100,000 screens :smiley:


The sharp 4.4" is very nice but so expensive! 70USD at digikey! I’m impress by the response time. I might use that in a future project!


@RWB, the oled wont solve my problem as i need for direct sunlight usecase + the low power ofcourse :slight_smile:
By the way on the 128 * 128 black n white sharp display how do you guys create images. Any nice software for it is available?