The basic Adafruit_GFX library used by many members only includes a single font and none can be added easily. I have created a new version called Adafruit_mfGFX which supports multiple fonts and allows users to add their own. The fonts are based on data generated by TheDotFactory which generates the correct data from existing truetype TTF fonts.
The library posted on my github includes 4 fonts and instructions for defining your own. I also include the Sharp Memory Display drivers (with soft SPI) though and compatible driver will work - I tested everything using the Adafruity_ILI9341 display driver I created for cheap 2.2" 320x240 LCD displays from China!
NOTE: The files can be placed in a single directory and cloud compiled with the Spark CLI.
@peekay123 I’m using this with the Teensy 3.1 and Arduino IDE. The Teensy 3.1 is the only Micro I found that had enough ram to run the 2.7 inch Sharp Memory LCD. The Spark Core didn’t have enough memory to run the Sharp Display. So it looks like you also got the Sharp Memory Display working with the Spark Core also? If so thats awesome.
So this will not work with the Arduino IDE? I’m about to try it out.
@RWB, I have just finished porting the GLCDFONT to the new library and made it the default font so older code that expect that font should work without any problems.
@RWB, i got the 128x128 panel installed and all works well. I did a bunch of research and found that the display can only be written to one line or one panel at a time. So single pixel writing is out. What I want to work on now is to use SPI FRAM or MRAM to do the screen buffering then do SPI to SPI from the F/MRAM to the SharpMem. That would slow down the buffer to display write time but so what! It will be faster than 60Hz for sure!
I bet FRAM to SharpMem would be just as fast or faster than using normal RAM since FRAM is so quick but I’m not sure.
So what did you find out about the Vcom pin that should be toggled every 1 or .5 seconds? It seems that the more frames per second your pushing to the Sharp Displays the more you should toggle the Vcom pin.
On the Sharp Memory demo library from Adafruit it runs smooth with new pixels just showing up as the demo progresses. But when I try to just write text data to the Sharp Memory LCD from my battery fuel gauge app it looks as if the whole screen blinks every time its refreshed which does not look right. I figure it just has something to do with needing to toggle the Vcom pin more frequently.
Does the Adafruit Demo Libarary speed up Vcom during the demo? Or what can you tell me about this?
P.S. I was going to share the new GFX library on Adafruits Show and Tell tonight but the wife had family pictures scheduled at the same time so I couldn’t do it. Giving you all the credit for it of course.
So do you have the 128x128 pixel displays working with the Spark Core?
@RWB, using FRAM will be slower because the process would go like this:
Write pixel data to FRAM screen buffer via SPI until the screen “operations” are complete
From the start of the FRAM buffer, read the data one byte (or perhaps a bigger amout) at a time into a Spark buffer (small, perhaps a few screen lines).
Write the buffer to the SharpMem via SPI and loop to 2 until all data is written.
So it takes several SPI bus operations to get the data moved around. Nonethless it is still fast.
The Adafruit_GFX library uses software VCOM and not hardware. That is done in the refresh() function so if you don’t call refresh enough or too much, you may have the problem you see. You need to call refresh() or sent the VCOM command at intervals between 50ms to 1000ms. The Adafruit demo program essentially calls refresh() every 500ms.
You could also use hardware VCOM and toggle it with a hardware timer or a timer delay in loop(). By default the Adafruit display is set for software VCOM.
Oh, and YES I have the Adafruit_mfGFX library running on the Spark Core quite nicely thank you!
@peekay123 So how much ram does the 128x128 pixel display require on the Spark Core? How much memory is left for your program is what I’m curious about.
So with the added FRAM to a Spark Core there should be no problem running the larger 400 x 240 pixel Sharp Display also?
On the VCOM Refreshing. If I don’t include a refresh() function in my main loop then its not going to refresh the screen so it looks fluid right? I did not copy the refresh() function into my main loop so that is probably the cause for the quick flash during screen refreshes. I’ll test that out soon. I wasn’t sure if it was in the actual library working in the background or if the refreshing of the screen was called in the main loop.
I though I saw the refresh code in the library files (.CPP or .H) and just assumed it was refreshing like it should automatically in the background but it must not if the demo displays fine and my code doesn’t and the only difference is I’m not calling the refresh() function in my main loop.
Now say you wanted to put the Spark Core or the Teensy 3.1 into deep sleep mode yet wanted to keep the Sharp LCD displaying data 24/7. Since the Sharp Displays require the VCOM to be toggled every half second does that mean you can only deep sleep between those half second intervals?
I was thinking that maybe using a CMOS 555 timer to toggle the VCOM vs making the Micro Controller come out of deep sleep all the time which consumes much more power than a CMOS 555 timer. How would you try to keep the sharp display on 24/7 with screen data updates every 1-24 hours while the microcontroller stays in a deep sleep mode except when you want to do a screen data update and then back to sleep?
I see the Spark Core being used this way. Have Sharp Display on all day long and then just have the Spark Core wake out of a deep sleep to get online and pull new weather data or whatever and update the LCD screen and then go back to sleep. This could be done with very little power consumption yet the display could say on 24/7 constantly displaying data.
Does that make any sense?
Oh yea, and which LCD screen do you like best? The silver or black 128x128?
@RWB, the 128x128 display takes 2048 bytes of RAM on the Spark. It is difficult to say how much RAM is left over but I suspect starting a TCP or UDP client instance would result in panic. A 400x240 panel requires 12000 bytes of buffer so a 16Kx8 or more FRAM would do nicely.
Now that I understand how you want to use the display, a 555 driving VCOM (at .5Hz is fine) is a great and simple idea. To write data to the screen, it is put in dynamic mode. Once you have finished writing to the screen, you put it in static mode which freezes the image so you can then put the Spark or Teensy to sleep. The only other condition is the VCOM which you have covered with the 555. Based on my measurements so far, a deep sleeping Spark uses about 9ma and the Sharp and 555 is negligible.
I like both screens but the 128x128 unit is my favourite
@RWB, you are awesome. I wish you could come to the Maker Faire! I will be discussing the FRAM/Display thing with the Elites to get their input but I believe this is the correct way to go. One possibility is to use SPI DMA to transfer chunks of data from the FRAM to a small RAM buffer then to the display. Currently, the SPI firmware does not user DMA. @kennethlimcp has created a FRAM/SD shield that would be great to test with.
@peekay123@kennethlimcp Yea if there is one thing that the Spark Core needs its more RAM and Memory, LOTS of IT! They should build it into the next super charged version of the Spark Core.
And Yes I wish I could make it to Maker Fair also but not this year, maybe next though.
@RWB, I see this challenge as having a two-pronged solution. First, optimize an SPI-to-SPI solution that can handle different SPI configurations. Create code that optimizes SPI-to-SPI transfers, possibly using DMA. Then create a new mfGFX library that uses FRAM-to-Display SPI solution.
There may be an opportunity for “smart” display shield that appears as both RAM and display to the Spark SPI. It would have a processor (MPS430?) that could handle the SPI transactions between the FRAM and the display, as well as, those between the shield and the Spark. I am just thinking out of my butt right now but I will discuss this with @timb.
The second prong is in the works with the next version of the Spark Core. More flash and RAM are already a given but the rest is still in the works. Stay tuned!
I tried to compile the Arduino sketch and it would not compile. First there was a reference in the Fonts.h file to #include Application.h which I presume may be a Spark file. When I removed that line, there are many errors when compiling.
Am I missing something?
@MagicTech, it seems I rushed the Arduino code a bit. It needed some fixes to the fonts.h and .cpp files which I pushed to the github repo. Grab the new files and compiling should be all good now
Thank you, that is awesome. Do you know why this library compiles with such different sizes in Arduino IDE 1.0x and Arduino IDE1.5.6? It seems 5 times bigger in 1.5.6.
Sorry to hijack this thread but I have hit a wall and looking for some help.
@MagicTech, I only tested on v1.55 so I will test with v1.05 to get a feel for what you are saying. Did you select the same arduino board for each compile?
UPDATE: They compile to almost the same exact size (24,758 vs 24,758) when I select the Uno board for both versions
