Sharp Memory LCD Displays = Ultra Low Power


#162

@amitkumarsharma008 I would create the 128 x128 pixel bitmap image in Corel Draw software.

Then I would load that file into this software and export the image to HEX formatted data and use that HEX array in the code so it would display correctly on the LCD when I called it up.

http://en.radzio.dxp.pl/bitmap_converter/

The software worked pretty good for the job.


#163

This looks awesome. Love how clear that display looks.


#164

Hey RWB,

I know this post is about as old as dirt itself, but if you are still active here, can you tell me where you found this font? I just now got my first Sharp Mem 2.7 and got it working with the Adafruit Lib.
The fonts offered are just not great for a display this size…

Hope you’re still around!
Vince


#165

RWB,

Where did you get the backlight??? Thats AWESOME!


#166

I found most of the fonts were found on dafont.com

You can use any true type font you can install on a PC and convert it using Peekay123 conversion process and it will work just fine. That’s how I did all mine.


#167

@peekay123 Is there any reason the Sharp Memory LCD library would not work or require changes to run on the Gen3 hardware?


#168

Can you provide some more background?

  • What device OS version?
  • What’s your wiring?
  • What are the symptoms of “not working”?
  • Have you got any other circuitry attached?

(you should know the drill by now :wink: )

The only thing that potentially may cause some issue with the SPI implementation on Gen3 could be the bit order flipping in the library.
Maybe that is not taken too well there.


#169

I’m thinking low power BLE + Sharp memory LCD’s would be a great combo.

Device OS Is of course 1.3.0 for now.

Wiring is SPI I’m pretty sure, that’s what @peekay123 's Memory LCD library uses.

I think I remember him needing to change some timing settings on the Photon & Electron devices to get it to work best. I’m wondering if he remembers this timing change and if there are any expected issues when trying to run this library on the Gen3 Lineup.

I’m just assuming all the Gen3 devices are the same when it comes to the main processor.

No other equipment in the mix, just a Boron + 2.7 Inch Memory LCD.

How does the Argon / Boron compare to the Photon/Electron when it comes to actual usable flash and ram space?

Going to need to figure out where to find this Flash & RAM usage on Workbench now that I’ve switched over, it’s so much better and more integrated than the previous Particle DEV :wink:


#170

More of both but the application flash “segment” is still 128K.

I couldn’t really see anything timing specific in the library, however, it could probably do with the addition of SPI transactions.

I still don’t really see an explicit statement about the actual nature of “not working”.

Also

while this is true, that doesn’t tell us how you wired everything.


#171

@RWB, the libraries for both the black & white (public) and colour (private) Sharp Memory displays should work with Gen3 devices. I agree with @ScruffR’s suggestion of using transactions since it removes the platform-specific SPI clocking assumptions. The colour display uses SPI tricks to improve performance but again, I don’t believe there are any show stoppers.

As for flash and RAM, you will have to do some testing. Workbench provides proper resource usage metrics (vs the web IDE) so you can see the effect of extra fonts, etc.


#172

How would I change the SPI (A3,A5,A2) used for the Photon & Electron on the Boron since the A3 on the Boron is not SCK.

Would the below changes be correct?


#173

It works with only changing the SPI pin names as I did above.

With the Boron in SYSTEM_MODE(SEMI_AUTOMATIC); mode and this code running as you see it in the video the power consumption when feeding the Boron via USB input at 5.22v = a steady 5mA. I consider that pretty damn good!

I need to test having BLE broadcasting data to a WEB BLE page and see where the power consumption is at then. I don’t anticipate the BLE Broadcast to add much extra power consumption, the BLE may already be running and cause no extra power consumption.

I’m loving the new low power BLE features, along with the ability to broadcast to a Chrome Webpage via BLE that can be viewed on any device without the need to build a iOS or Android Application you have to manage for all devices.

The Memory LCD gives us an almost no power way to display data without messing up the low power abilities of the nRF52.

Now if we can get @rickkas7 to create a nice 2-way WEB BLE demo that mimics the features that SoftAP provided for passing data and variables between the Gen3 Devices & a Chrome BLE webpage we will then have a lot of new possibilities that only BLE and it’s low power nature provides for constant local wireless communication.


#174

@peekay123 There is a bigger Sharp Memory LCDs available with more pixels and I’m wondering how the bigger required screen buffer would work on the Gen3 devices?

The new LCD is 336 x 536 pixels for a 3.16 inch display which is about 86,000 more pixels than the 2.7 inch LCD pictured below.


#175

@RWB, the way to calculate the RAM necessary for the display buffer is:

RAM in bytes = (#pixels in row x #pixels height) / 8

Since the display is monochrome, we can pack 8 pixels per byte. In your case:

RAM = 336 * 536 / 8 = 22,512 bytes

:wink:


#176

So this is no problem for the Gen3 devices? Is the 256k of ram available for usage?

I realize a full screen bitmap would double in size and therefore memory space.

I’m wondering if plugging it into and changing the pixel dimensions in your library is all that would be needed to get it working of if the bigger buffer would push things out of bounds.


#177

@RWB, should work. Give it a shot!


#178

I still need to get one of the larger screens but wanted to verify the extra pixels wouldn’t cause any issues first.


#179

The Argon in System.Sleep() Mode with the 2.7 inch Memory LCD attached is sleeping at 0.6 mA when powered by 4v on the battery terminals.

The Boron consumes 1.1mA in System.Sleep() Mode with the same screen attached. So that’s a almost 100% reduction in sleep current which is pretty good.