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:
Is there an easier/better way to get this display working?
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.
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!
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.
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.
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.
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?
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 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).
