Ported: Adafruit-PCD8544-Nokia-5110-LCD-library

Just a quick note to confirm that Adafruit-PCD8544-Nokia-5110-LCD-library works “out of the box”

My mistake I does not work “out of the box”. See this post by madias http://www.stm32duino.com/viewtopic.php … =424#p3954 a bit further down, with my reply.

I think Ray (mrburnette) will love it
Seriously: I think we all have done a good job with the compatibility definitions the last months, because I know about 6 or 8 months before the library didn’t worked for me (for some circumstances I ported a slimmer one -> viewtopic.php?f=13&t=7 )
So: “snake” here we come again!

Edit: For all price hunters: Meanwhile the display costs about 2USD (free shipping) for 5pcs. So they are back on place #1 of the cheapest graphic display modules. But you can grab a 128×128 ILI9163C TFT for about 4.5USD (with superb DMA driver support thanks to victor)
http://www.aliexpress.com/item/5pcs-blu … 54889.html

As well as being cheapest the PCD8544 displays also score pretty well top in the low power consumption rankings.

Assuming you power them directly from 3v3 and don’t use the on board regulator that is usually included on these boards and don’t use a back light, they consume something in the order of 200uA.

They are also usable (just) without a backlight, or with the backlight set very low.. and a lot cheaper than e-ink displays.

You don’t get many pixels for your buck, so colour displays are better for pretty much every other application, and Mr Google suggests some of the 1.8″ OLED displays get within a similar order of magnitude when it comes to power consumption.

Just one note of caution on these cheap Nokia 5110 displays

I have noticed that a lot of the cheap Nokia 5110 displays I have received recently were not new displays. They were on a new PCB, but the displays were almost certainly recycled from old mobile phones.
One had visible burn in of a smuggy logo (I could not make out what it was), another one had a scratch, other have dirt between the metal surround and the glass of the display

I complained and got a partial refund from an eBay vendor in one case – perhaps I should have demanded a full refund….

I suspect a lot of these displays are “recycled”, hence the low price. I don’t mind that too much so long as they look new. I am happier recycling them than sending them to landfill. There is no excuse for selling them in a scruffy, damaged or non working condition however.

Andy,

I’m fine with getting recycled items if I know they are recycled and in good condition.

I think I was being fair by paying half price for the ones with burn in and a scratch etc, in fact more than fair really, as I can only use them for testing, and not even for prototype items that I’d show commercially.

RogerClark wrote:Andy,

I’m fine with getting recycled items if I know they are recycled and in good condition.

I think I was being fair by paying half price for the ones with burn in and a scratch etc, in fact more than fair really, as I can only use them for testing, and not even for prototype items that I’d show commercially.

mrburnette wrote:
Post by madias » Sun Jul 12, 2015 5:46 pm

I think Ray (mrburnette) will love it

I seem to be a bit transparent …

Ray

hm. I wont run “out of the box” for me, following changes are necessary:
Adafruit_PCD8544.h
Line 69
#define PCD8544_SPI_CLOCK_DIV SPI_CLOCK_DIV8

Thanks madias!!

Sorry for that mistake by me . I did have the following in the .h file

typedef volatile uint32_t PortReg;
typedef uint32_t PortMask;

Sorry for that mistake by me
Meanwhile most of us are “slightly” advanced to call such things “out of the box” Especially all adafruit libraries are very similar.
Strangely SPI_CLOCK_DIV4 wont function to me, maybe a other module? To keep on the safe side, try it first with SPI_CLOCK_DIV8 than you can speed up (as you can “speed up” a pcd8544….)

madias wrote:
Meanwhile most of us are “slightly” advanced to call such things “out of the box”

I started with AVR-arduino about 3-4 years ago (I only wanted to build a multi switch for my guitar pedal board) with no real knowledge (soldered only stomp boxes before, but c++ what’s that?). I had to rely on other people writing code/libraries, so I didn’t care what’s under the hood. the big jump for me was switching to TIVA TMC-123 and energia with the superb datasheets from TI so I was getting into the deep. Next step was PIC32 with chipkit/UECIDE and then STM32duino. This was the next BIG jump. Only a few people involved into the project so everybody was “forced” to introduce himself: Rewriting libraries, testing and compiling upload tools, tweaking bootloaders, linker scripts… so the whole stuff a normal “arduino” user does not even know that it exists. So the frustration learning curve with this project is extremely high or you’ll leave it – but this is all the fun about it

I updated the example program on Github with the following:

// For the STM32F1:
// MOSI - on pin PA7 (Maple Mini: also know as pin 4)
// SCK - on PA5 (Maple Mini: also know as pin 6)
//
//#if defined (__STM32F1__)
// Adafruit_PCD8544 display = Adafruit_PCD8544(PA2, PA3, PA4);
//#else
// Adafruit_PCD8544 display = Adafruit_PCD8544(5, 4, 3);
//#endif

I do not know if it’s frowned upon here or not for me to latch on to other people’s threads or if you people would instead prefer me to make a whole new thread for this, but since we are talking about the Adafruit PCD8544-library I do have a port of it available at https://github.com/WereCatf/Adafruit-PC … CD-library

Currently the dev-branch is the most up-to-date, I didn’t merge it yet because I didn’t test it properly. See https://github.com/WereCatf/Adafruit-PC … /README.md for the interesting stuff (or if the branch doesn’t exist anymore then I’ve merged it and it can be found at https://github.com/WereCatf/Adafruit-PC … /README.md instead)

How do you overcome this error:

In file included from src/main.cpp:3:0:
.piolibdeps/Adafruit GFX Library_ID13/Adafruit_GFX.h:77:18: error: conflicting return type specified for 'virtual void Adafruit_GFX::write(uint8_t)'
virtual void write(uint8_t);
^
In file included from /home/jazg/.platformio/packages/framework-arduinoststm32/STM32F1/cores/maple/HardwareSerial.h:38:0,
from /home/jazg/.platformio/packages/framework-arduinoststm32/STM32F1/cores/maple/wirish.h:69,
from /home/jazg/.platformio/packages/framework-arduinoststm32/STM32F1/cores/maple/Arduino.h:30,
from src/main.cpp:1:
/home/jazg/.platformio/packages/framework-arduinoststm32/STM32F1/cores/maple/Print.h:39:20: error: overriding 'virtual size_t Print::write(uint8)'
virtual size_t write(uint8 ch) = 0;


The ported library doesn’t work with HW SPI. While defining pins PA5 and PA7(software SPI), It works.

https://github.com/KenjutsuGH/Adafruit- … CD-library

hello madias…..your solution is not working for me….. i have tried connecting nokia lcd to both pins 7,6,5,4,3 and pins 31,30,29,28,27 ….. and it didnt work on either.

[DrBanana – Mon Apr 17, 2017 4:21 am] –
The ported library doesn’t work with HW SPI. While defining pins PA5 and PA7(software SPI), It works.

https://github.com/KenjutsuGH/Adafruit- … CD-library

I made the changes in the post at the top, and it almost works with HW SPI. I get a bit of display corruption on one or two of the demo screens, but the rest works fine.

Has anyone found a solution to display corruption? I am getting this with software spi, but hardware spi so far is ok.

I don’t understand the DIV8 change.. what is being divided? If it is 72mhz, that would give spi clock of 9mhz, shouldn’t it be DIV16 instead? What is the final clock speed? It works with DIV2 so I’m not sure this change has much effect or what it is doing.

Yes. DIV8 means 72 / 8

To which pins on the BP are you connecting the LCD?

[seandepagnier – Wed Aug 15, 2018 10:45 pm] –
Has anyone found a solution to display corruption? I am getting this with software spi, but hardware spi so far is ok.

I don’t understand the DIV8 change.. what is being divided? If it is 72mhz, that would give spi clock of 9mhz, shouldn’t it be DIV16 instead? What is the final clock speed? It works with DIV2 so I’m not sure this change has much effect or what it is doing.

Is it not possible that the clock speed is just too high. Even the built-in software SPI could top 6MHz, and some of the 5110 displays I have had have been dodgy above 4MHz…

Perhaps try mod spiWrite as follows:
for(uint8_t bit = 0x80; bit; bit >>= 1) {
*clkport &= ~clkpinmask;
asm ("nop");
asm ("nop");
asm ("nop");
asm ("nop");
if(d & bit) *mosiport |= mosipinmask;
else *mosiport &= ~mosipinmask;
asm ("nop");
asm ("nop");
asm ("nop");
asm ("nop");
*clkport |= clkpinmask;
asm ("nop");
asm ("nop");
asm ("nop");
asm ("nop");
asm ("nop");
asm ("nop");
asm ("nop");
asm ("nop");
}


I tested both my port and the one by WereCatf as follows:

• BluePill programmed via ST-Link
• Arduino 1.8.5 and PlatformIO/Atom 3.6.0/1.28.2
• macOS Sierra 10.12.6

Hardware SPI:
LCD pin BP pin
1 – RESET PB9
2 - CE PB8
3 - DC PB7
4 - DIN PA5
5 - CLK PA7