SPI display

As part of my testing of the Pi2, I tried booting OSMC on the Pi1 to verify the boot isn’t Zero specific (I don’t care if it failed on the Pi2, just that it tried something).
When I booted back in to RISC OS, I noticed that my OLED was not working. It responded to IIC commands, but nothing on the display. I turned off for half an hour but still nothing. I can only imagine OSMC might have done something weird with the charge pump. Unfortunately one can tell there is an OLED by detecting the display driver IIC address but there’s no way to programmatically tell what sort of display is attached. Hmm, okay…

I am wondering if I might have more fun with a cheap SPI display. However, is it possible to output arbitrary information to the display, not using it the primary display?

I’ve read this a few times. Could you please be a bit more specific?

From what you’ve said I can tell you this much.

Usually you can’t directly tell what’s attached to i2c but the address does give a hint.
What kind of i2c OLED was it? I’ve got a couple of little mono ones. The less tiny of the two I’ve had working in Raspbian (I think. Possibly an AdaFruit demo), esp8266 and Arduino. They should be pretty durable if I haven’t managed to kill one.

If you have access to the SPI bus you can feed it whatever you want. Of course it’ll need a driver / software layer. If you are determined you may be able to do something, but you’ll probably need the datasheet, and pull apart some Arduino driver code do work it out.
Otherwise, looking straight at the elephant in the room, you could use an Arduino or whatever as display hardware for the screen, then interface to it however you see fit, because that will give you access to it’s framebuffer, and the AdaFruit graphics library.

Just saying. I mean it’s one of any number of potential scenarios.

Could you please be a bit more specific?

My main question is thus: I know there is an SPI driver for RISC OS. What I’d like to know is whether or not it can be used to display something other than a copy of the screen.

What kind of i2c OLED was it? I’ve got a couple of little mono ones. […] If you are determined you may be able to do something,

http://heyrick.co.uk/software/oled/ 😄

I have a little blue 128×64 OLED. Wrote a driver for it. It worked. Now it doesn’t. And I’m wondering whether to spend €15 on a replacement, or twice that on a small (320×240ish?) SPI display panel…

Oh, I see!
I like that.
Try these or similar for a replacement

new 1Pcs white 128X64 OLED LCD 0.96" I2C IIC SPI Serial new original
http://www.aliexpress.com/item/32389025950/32389025950.html
(from AliExpress Android)

Sorry about the formatting.

If you go for an ILI9341 based SPI LCD I strongly suggest testing with various Arduino libraries to work out how the memory is mapped. On some models an offset has to be applied to the framebuffer or it’s kind of like it’s looking at the wrong bit of its memory.
Honestly I hope that means by extension is has some off-screen memory to play with but I haven’t tested it.

new 1Pcs white 128X64 OLED LCD 0.96" I2C IIC SPI Serial new original

Well, that’s cheaper than Amazon, unless postage costs a ton.

Having said that, I started up my server (that puts info on the OLED) to do some work on it, and the OLED came to life.
WTF?

Do OLEDs have a history of “just not working” (responds correctly to IIC commands, but displays nothing at all, for days) and then later on start working again? Should I blame the phase of the Moon? This is just weird…

[I’m just glad I was too lazy to unplug it and chuck it in the bin!]

Do OLEDs have a history of “just not working” (responds correctly to IIC commands, but displays nothing at all, for days) and then later on start working again? Should I blame the phase of the Moon? This is just weird…

More likely an uninitialised variable or an incorrect/incomplete initialisation of the device.

I have no knowledge of the device you’re referring to, but I know that LCD modules take significant time to execute some of the initialisation commands, and any attempt to send the next one too early will cause some kind of failure.

Rick I can’t comment on postage for you, but usually it’s free.

I really have no idea. Glad it’s working!

More likely an uninitialised variable or an incorrect/incomplete initialisation of the device.

It had worked fine through switch offs and such since May 2014 until October 2016, so I’m guessing that there isn’t a specific problem with the initialisation sequence.

However…

but I know that LCD modules take significant time to execute some of the initialisation commands, and any attempt to send the next one too early will cause some kind of failure.

I’d have thought that the IIC transfer would fail?

Well, I just power cycled the Pi so I could take an image of the SD card. Upon restarting, the OLED responds to commands, but shows nothing on the display. Yup, that again.

So I broke my initialisation down into chunks and sent each command one by one with a 10cs between each. That failed to show anything on-screen (though every command was accepted without error). So I then tried the exact init sequence given in the technical documentation. Same result. I Googled, and found several different ways to arrange the initialisation commands. So I tried them all with and without the 10cs delay. Everything was accepted. Nothing on-screen.

It seems to object to being power cycled, so maybe it is reaching the end of its service life?
Maybe it’ll wake up in a month or two. :-/

Maybe I ought to get myself one of those serial LCDs instead…

…aaaaand it is working again (went to unplug the printer, unplugged the desk multi plug thingy instead – ooops!).

You know, when I were a lad (etc etc) what was broken was broken and what was not worked.
This “sort of maybe broken unless it feels like working” rubbish is going to do my head in.

Rick sounds like my bike computer that’s been playing up the last few weeks. If I fiddle with the mounting it sometimes started to work but then quickly failed. Once I’d given up trying and then looked at it a minute or so later it would be working!

CHris, I have one like that. Spray the contacts with contact cleaner and it gets better for a while. Looking at it the plating on the contacts has worn off which I guess is the root cause of the issue. YMMV

I am using OLED version 0.03 from http://heyrick.co.uk/software/oled/ on my Raspberry Pi Zero to drive a 128×64 OLED display but I find it gets confused (the app [SatNav] seems to freeze and needs to be killed) when using the serial port at the same time. The project is a speedometer in a small box (80mm x 50mm x 25mm) using GPS to determine speed. I seem to recall that OLED turns interrupts on and off: might this be the issue?

OLED doesn’t. IIC does. It’s a real PITA as I can’t use an OLED as an MP3 player display because the time taken for OLED data is often more than the sound buffer holds, so playback from a local MP3 just stops (though streaming radio works fine -go figure).

Have you hacked your ROM? (details on my blog in the related articles) For some reason the Pi defaults to the 100kHz mode of operation which was “outdated” back when the Archimedes was released. It’s perfectly find to push it to 400kHz as anything capable of 3.3V operation is new enough to work faster. I can confirm the Pi hardware and the CJE clock/power controller and the OLED are quite happy at 400kHz.
I’ll leave you to do the maths for a ~1K data dump to see why the faster speed is far better.

Many thanks.

I’ll try the faster speed, hadn’t realised it was important (the OLED display seems to be responsive enough).

Well, with the faster speed (400kHz on IIC) the interaction between serial and OLED/IIC seems better but can’t be sure as the mouse and keyboard won’t work with the clock change (at address 9Cxx in my ROM) by changing 9C0 to 270. I am using a Pi Zero. More testing next year…

A minor bug in SatNav (which made it intolerant of certain types of serial port data errors or interrupted streams) proved to be the cause of freezes (version 1.02 cured this). However the ROM hack does not seem to work. Details to follow.