Sharp Memory Display + SparkCore

Thank you so much, I have been able to get the mfGFX sample compiled, but when I run it it seems like it tries to start up, and flashes red (as others have posted), memory problems right?

What confused me was this post saying that it works great on the 128x128 (which I have as well)

Then this post saying that the out of memory thing was indeed problematic for the same 128x128 which I presume was previously working?

Is there something I can do to reduce the size to get a “hello world” sample going? In all reality, I only need a single font.

Thanks, cant wait to see this LCD in action!

@peekay123 Did you ever have that Sharp LCD up and running on the Spark yourself? I know I sent you the boards to LCD’s and Breakout boards and you did indeed get the library up and working for me but you provided me with the Arduino version.

I ran the Arduino version of your code on the Teensy 3.1 just fine. The multifont library works great also but takes awhile to figure out exactly whats going on.

Just wanted to chime in and tell @peekay123 that I never actually ran that library with either the Sharp 128 x 128 Pixel display or the 400 x 240 pixel version which can really only be ran the Teensy 3.1 due to the RAM size requirements to buffer every pixel in the the display.

@peekay123 While we are talking about the Sharp Memory LCD’s I was wondering if you could help me understand better what exactly the vCom refresh line does. It says it keeps the LCD’s from biasing? Or maybe that means it keeps the pixels from fading out or loosing charge?

I know that the vCom requires a square wave pulse every second but still do not understand exactly whats happening.

If you look at the Sharp Memory LCD at an angle in daylight you can see the vCom refreshing the LCD’s, and every time the vCom is refreshed the LCD will get darker black, then fade just a tad when looking at the screen from an angle and when the vcom signal is trigger again you can see the LCD’s darken back up again.

When looking at the LCD from the front its not even noticeable. But I can tell that the vCom keeps the screen dark but I still wonder whats technically going on when the vCom is refreshed.

Any ideas?

@RWB and @anthonywebb, the display driver I have was adapted from the Arduino driver that uses software SPI. Mine is adapted to hardware SPI and as I have discovered today, the clock speed is crucial to proper operation (DIV16 is fastest reliable speed). My original demo used DIV8 which cause issues and prevented the “hello world” portion of the demo to show up on the display.

The driver uses a local display buffer since the SharpMem display requires single-line or multi-line data transfers. The 96x96 and 128x128 Sharp Memory displays require a 1152 byte and 2048 byte buffer respectively. Both will work with the Core assuming you don’t have any other heavy memory requirements in your code. The 400x240 display, however, requires a 12KB buffer which is not possible on the Core (but will be on the Photon!). As such, I developed a special driver that uses SPI based FRAM to create the large necessary display buffer. However, due to the FRAM’s speed and the fact that it shares the SPI bus with the display, the display refresh speed is considerably slower. For static displays or ones that are updated slowly, the driver is ideal.

@RWB, the SharpMem display uses a VCOM signal to prevent a DC bias voltage (think capacitor) from building up within the panel which reduce the pixel “intensity” as you noticed. Using VCOM resets any DC bias, preventing an accumulation of charge. Typically, VCOM is changed once a second. The existing driver uses software-base VCOM toggling and does it as often as possible. An external timer (eg 555) could be used to refresh VCOM without CPU involvement. Ideally VCOM is driven at 60Hz.

I will be posting a repo with a complete working set for the Sharp display including mfGFX. If anyone is interested, I can also post the 400x240 FRAM-based library which requires specific wiring for the FRAM and display to work. :smile:

1 Like

Thank you for the update. Looking forward to trying out my 128x128. Of course I am on pins and needles anxiously awaiting the photon which will solve a lot of these issues. Let me know when you have something workable posted. Thanks.

@peekay123 Thanks for the info Paul.

About VCOM, so is it like were just hitting it with more power every second to keep the pixel nice and black because if we didn’t they would just fade out to the point that we don’t see them anymore? That makes sense to me if thats whats happening.

I ended up picking up a special ultra low power square wave pulse generating chip that only consumes 1.35uA when generating a Square Wave at 49Hz.

So you could have the Spark Core or any Micro draw out the Sharp LCD Screen Data and then put the micro controller back to sleep while the Sharp LCD holds that image forever while only consuming only 12uW on the smaller screen and the 135uW on the 2.7 inch screen.

Sharp says the screens consume about 100 times less power than it takes to blink a LED as a status indicator.

Here is a link to the Chip on Digikey.

Finding the Demo Board is tricky but here is the part number for it: TS3005DB

You could just buy the chip and get this board to evaluate it.

And some pictures for the screens I have tested along with @peekay123 custom font library which is pretty sweet. I’m going to be putting this to good use really soon.

I was too lazy to update the git repo for the SharpMem library so I put all the files in a dropbox here :stuck_out_tongue:

The library defaults to a 128x128 display and I tested everything with Spark CLI.

@RWB, cool timer chip and great pics! :smile:

1 Like


Also just a quick note to anybody interested in Sharp Memory LCD’s.

The 4.4 Inch Sharp Memory LCD’s are now available for purchase. Nobody carried them back 6 months ago but now there are a few suppliers who have them instock. The 2.7 inch screen is very sharp and high rez but you have to be right up on it if you want to put lots of data on the screen at one time.

The 4.4" display is 320 x 240 and uses the same connector as the 1.28 inch, 2.7" displays so the current break out boards will work just fine for it.

Here is one place selling them:

Here is the Datasheet:

I’m going to order one and check it out. You can’t go wrong with these displays if they are used in a system that runs on batteries.

What is the latest on trying to use 4.4" Memory Display w/Spark Core? Initially there was some talk of not having enough memory until photon arrived. Is that still true? Was there anything measured on power consumption of 4.4" display and Spark Core connected to the WEB. Can a battery provide “months of use”, or is the power consumption more?

@Dogan, the Core does not have enough RAM to support the display buffer required for the Sharp Mem display driver. I wrote a special driver to make use of SPI FRAM to act as a display buffer but it requires a 32K byte FRAM. The Photon will have enough RAM to support the larger display without problems.

As for power, if you read above, you will find data on the display power consumption. As for the Core/Photon, you will need to make extensive use of deep sleep modes to get “months” of battery time. :smile:

When is Photon sample available? Is there are extra memory add hack to Spark Core just to test my concept with Spark Core till Photon arrives? I am tasked to have a working proto type 4.4" Display with Spark/Photon to wirelessly change screen content over WiFi and Internet.

Shipping of the photon starts at the end of March, according to @zach

@Dogan, there is no “hack” to add more memory. However, as I mentioned before, you CAN add a FRAM (16K bytes) module to test your code with the only thing being affected is the display refresh rate. When the Photon comes out, you simply put the “regulare” Shap Mem library and use onboard memory as the buffer (9600 bytes).

Has or can Zach make a pre-run functional Photons vailable?

Has anyone actually used Spark Core + FRAM to push content to 4.4" Sharp Memory LCD over WiFi and Internet without using a Development Board. I also need to estimate the footprint to deal with existing housing limitations.

@Dogan, I used the 2.7" display with FRAM to develop the library. That display is 400x240 and uses a 12KB display buffer in FRAM. I used this Adafruit 32K byte FRAM breakout, a Core and a protoboard for testing. @kennethlimcp created an SD/FRAM shield but I am not sure he is selling them anymore. Besides a different library, the FRAM configuration requires a minor change to the way the display MOSI line is wired to the Core/FRAM. The library is here on my repo.

1 Like

Is it possible to display a bitmap image with the Spark or is that really pushing the RAM?
It seems most of these replies revolve around displaying the custom font bitmap, can we display bitmaps just the same using TheDotFactory?

@robertcedwards, what size display and bitmaps are you considering?

It’s a 96x96 display…I suppose our bitmap would be the same size.
I just haven’t since an example with the Spark and we’ve failed at our attempts to make it work with your examples by adding our custom bitmap.

@robertcedwards, defining a bitmap with the mfGFX library is straight forward but needs to be in the correct format. What have you tried?

I’ve tried

const unsigned char image[] = 



I used a converted bitmap from this tool but still have trouble compiling.
I’ll use TheDotFactory to generate a new converted bitmap once I get home to a PC.
Could the converter be causing the problem?
Thanks for your help!

@robertcedwards, the tool link is not working. I will look into the bitmap format required but it should be pretty straight forward. :smile: