@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.
This looks awesome. Love how clear that display looks.
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
RWB,
Where did you get the backlight??? Thats AWESOME!
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.
@peekay123 Is there any reason the Sharp Memory LCD library would not work or require changes to run on the Gen3 hardware?
Can you provide some more background?
(you should know the drill by now 
)
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.
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
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.
@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.
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?
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.
@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.
@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
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.
I still need to get one of the larger screens but wanted to verify the extra pixels wouldnāt cause any issues first.
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.
Hey @peekay123
I'm revisiting this Argon + Sharp LCD Combo that I had working last year but not will not work using the latest code.
It loads but all I get is scrambled image displays.
I see that since firmware 1.5.0 there is this
SPI.begin()
that may need to be called to put the SPI bus in the right mode??
https://docs.particle.io/reference/device-os/firmware/photon/#spi
The display on the brand new Photon works 50% of the time when loading images using the current firmware but I get a lot of scrambled images where in the past it was rock solid and never issues.
I feel like after coming back to some stuff that I had worked on from last year is being affected by firmware updates and I now need to find out what has changed so I can get my code running again.
Any ideas on the SPI.Begin() or if you have some free time could you see if you can get your 2.7 inch LCD working on the Argon?
I've spent the last 2 days trying to get the 4D Systems LCD's & now the Sharp LCD Displays working with code that worked just fine back around firmware version 1.3.0.
I'm just wanting to get all these bugs figured out so I can keep pushing forward with the project 
Any ideas?
Here is what I get on a brand new Photon with different LCD screens to test.
Iāve wired it up 4 different ways so I know its not a loose connection.
The code and wiring used to just work reliably back on firmware 1.3.0.
It looks like the data being sent to the screen is to slow or fast possibly. Has the SPI bus speed default been changed since 1.3.0?
