<sc6502> Just dropping by during lunchtime.
<sc6502> The SSD1306 manual, chapter 7 PIN DESCRIPTION has the following.
<sc6502> FR O This pin outputs RAM write synchronization signal. Proper timing between MCU data
<sc6502> It should be kept NC if it is not used. Please refer to Section 8.4 for details usage.
<sc6502> writing and frame display timing can be achieved to prevent tearing effect.
<sc6502> I've tried optimising the output to the OLED device by reducing the number of write calls.
<sc6502> However, every attempt seems to end up with the very shearing of the display that this talks about.
<sc6502> So I'm wondering whether this FR pin is accessible in any way so that I can hopefully
<sc6502> send a new frame as a fast MCU or whether we're stuck with slow MCU.
<sc6502> If this can work, we get a 10Hz refresh rather than the 6Hz or 7Hz at the moment.
<Xogium> hmmm damn that seems to be quite bothersome
<sc6502> I had a chat about RAUC with Peter at lunchtime.
<sc6502> .
<sc6502> I propose a small utility to print messages on the OLED.
<sc6502> .
<sc6502> rauc_message -wn -sn "message"
<sc6502> Display a message on the OLED.
<sc6502> The -s<number> option picks a text size.
<sc6502> The -w<number> option specifies how long to wait (in seconds) before clearing the screen and returning.
<sc6502> The message can contain \n to specify a multi-line message.
<sc6502> The utility will centre the message on the display so it looks nice and neat.
<sc6502> .
<sc6502> rauc_message -c
<sc6502> Clears the screen.
<sc6502> back later, errands.
<Xogium> ooh, that looks fancy
peterm6881 has joined #Speedsaver
<peterm6881> hey roomies
<peterm6881> hey Xogium, I saw the chat earlier. sc6502 and I think the best approach is to have you and I try to get rauc working, and then he will come in and provide feedback to the user on the display. How do you feel about that?
<sc6502> Meh, just bought a snazzy new office/gaming chair. Except all the nuts and bolts to put it together are missing - Arrhh!!!!
<sc6502> peterm6881, do you have a URL to the actual OLED module we're using? I'd like to see if this 'FR' signal pin is going anywhere that might be visible to the processor.
<peterm6881> hi sc6502 at the minute its a generic, ubiquitous type
<peterm6881> 8y61sBmSYv9B8y3pY5ClvfqEtuFTXp0aAjo8EALw_wcB&albag=57224001810&aff_fsk=UneMJZVf&albch=shopping&albagn=888888&isSmbAutoCall=false&aff_trace_key=64316ffec9184e9c8c4aa1efbc9c52cf-1625771460465-01009-UneMJZVf&device=c&gclsrc=aw.ds
<Speedsaver`> Title: 0.91 Inch 128x32 IIC I2C White OLED LCD Display DIY Oled Module SSD1306 Driver IC DC 3.3V 5V For Arduino PIC|Replacement Parts & Accessories| - AliExpress (at www.aliexpress.com)
<peterm6881> sc6502, bummer about the chair!
<peterm6881> i dont have any technical documentation I'm afraid. I didnt think I'd need it lol!
<peterm6881> this gives some information on typical native OLED connections, without the interface board they nearly all come mounted to:
<sc6502> So that would be a 'no' then. The I2C interface seems to be essentially a write-only interface.
<sc6502> Though 10.1.5 Set Page Address (22h) in the SSD1306 manual looks like it might be interesting to explore.
<sc6502> I'm also wondering which direction the screen is refreshed in, is it top-to-bottom (as one would expect), or is everything flipped internally and it refreshes bottom to top, while we're trying to write to it top-to-bottom?
<sc6502> Enough musing for today, night all.
<peterm6881> i dont know anything about how Pierre adapted navit to use OLED screens. Although its worth bearing in mind when you mentioned about rewriting the code to use the more widespread, popular and versatile luma.oled driver, Navit was never intended to use a tiny OLED screen
<peterm6881> Navit is satnav software. Anything that was done to adapt it to i2c oled's was done by Pierre. So changing it to use the default oled driver shouldn't, I would have thought, be a monster task
peterm6881 has quit [Quit: Leaving]