Adafruit GFX library

Was trying to see if I could use a Sharp Memory Display with the Spark, so I tried throwing the tutorial/sample code into the Spark IDE, eg:


All of these are from the Adafruit tutorial pages:

Fixed a bunch of compiling errors, but now I hit one that I don’t know what to do with:

In file included from Adafruit_GFX.cpp:34:0:
Adafruit_GFX.h:68:18: error: conflicting return type specified for 'virtual void Adafruit_GFX::write(uint8_t)'
In file included from ../inc/spark_wiring_stream.h:38:0,
from ../inc/spark_wiring.h:32,
from ../inc/application.h:29,
from Adafruit_GFX.cpp:33:
../inc/spark_wiring_print.h:58:20: error: overriding 'virtual size_t Print::write(uint8_t)'
make: *** [Adafruit_GFX.o] Error 1

So, questions:

  1. Is there an easier/better way to get this display working?
  2. If there’s an easy fix for the above, what is it? Am not clear yet on the main differences between the Spark and the Arduino code-wise.
  3. Has anyone else gotten the Adafruit GFX library working, and if so, with what display?

Another generous member has a few Sharp Memory LCD’s in the mail to me so I’ll be porting a library for it by this weekend. Another member has started ported a graphics primitives library over so we can use that in place of Adafruit_GFX! :smile:

1 Like

There is code in GFX lib header file that looks to see if we are in Arduino 1.00 or greater:

#if ARDUINO >= 100
  virtual size_t write(uint8_t);
  virtual void   write(uint8_t);

I would try removing the test and just using the virtual size_t return type as if ARDUINO is greater than 100.


spongefile, I got the “package” to compile with several modifications to the files to remove the arduino-dependent code. I can’t test it since I don’t have a display unit but perhaps you can. I posted the code on my github if you are interested.



peekay123, I just wired up the display like so:

VIN - 3v3
CLK - A3 (SCK)
DI - A5 (MOSI)
CS - A2 (SS)

Uploaded the code and libraries (everything verified nicely) but no response on the display. Next I’m going to check the display with an Arduino to make sure the display itself is ok(EDIT: Display works fine with Arduino Uno), but is there anything else I could try with the code itself? Did I wire it correctly?

Massive thank you for getting the package to compile in the first place, hoping that it’s some small overlooked thing that’s the problem. :smile:

spongefile, the Adafruit library uses soft SPI and I suspect there may be an issue with using the hardware SPI pins. So there are two options. 1) Use three other pins (D3, D4, D5) as the SPI pins and change this line at the top of sharpmemtest.cpp (don’t forget to change your wiring):

Adafruit_SharpMem display(SCK, MOSI, SS); to

Adafruit_SharpMem display(D3, D4, D5);

UPDATE: I found some Spark-specific issues with the code which I will fix and repost on my github. More specifically, the timing on the software SPI may be too fast for the display since the Spark is 4.5x faster than a 16MHz arduino. You will need to update sharmemtest.cpp and Adafruit_SharpMem.cpp. The timing on the softtware SPI may still be too fast but I will not know until you try it out. :smile:

The Sharp Memory displays works at 1MHz. It expects a high for CS enable and high for the data and clock pulses. Data needs to be sent MSB first.

I’m having issues getting it to work via hardware SPI on the from-scratch library I started last night as well.

timb, the Adafruit code has sendbyte() and a sendbyteLSB() They use the latter for sending actual data. From looking at the display specs, that made no sense to me as it looks like it should go out MSB first. They use sendbyte() to send MSB first, it seems, for sending command bytes. Does this sound right? :smile:

I noticed that too! According to the display specs and programming guide from Sharp, all data should go out MSB first…

I’m basing my driver off this:

timb, the weird thing is that spongfile said:

(EDIT: Display works fine with Arduino Uno)

From what I can see, they use MSB first for the commands and then LSB first for the display data, which according to the specs is up to the implementation:

Depending on your graphics software, the left-most pixel may be the MSB or the LSB within that byte.

So that is why Adafruit’s library works. However, without the mods I made, I can’t tell if the timing is good of not. I may run the demo and scope the pins since it write-only.

@peekay123 Ah yeah, good catch!

Here’s a hardware SPI implementation for Arduino:

I’m going to try your library out now.

Okay, got it to compile! You forgot to add init to the header. It’s flashing now!

@peekay123 Okay, so it does seem to be clearing the display (if I plug and unplug this display, I get random static on the screen, your sketch seems to clear it) however it’s not drawing anything. I also noticed the Core resetting itself a few seconds after startup.

timb, just noticed I had the init() before the begin(). DOH!

I am concerned about the timing on the adapted Adafruit library. I suspect that delays will have to be injected in the soft SPI code like we did for the Digole lib. I added some delay for the _SS line but not for the actual toggling of the data and clock bits. In my estimation they are too fast.

Yeah that’s what I was thinking. Something in the code is also causing the Core to reset a few seconds after starting and then never finish the initial loop (I have to do a factory restore).

I’ll look to see what could be causing that.

What/where was that other GFX library mentioned in this thread? Does that one make the Sharp Mem display talk nicely to the Spark?

spongefile, timb is working on the Sharp memory display library as we speak. I’m not sure what his ETA is.

Right, sorry, I thought someone else was working on an alternative library, but I couldn’t find it :smile:

@spongefile Hey Spongefile I sent @timb 3 Sharp Memory LCD screens to get working when he has time because I also would like to use them.

If you come up with code for the core that will work with the Sharp Memory LCD before @timb does then be sure to come back and share it with us.