is anyone successfully using i2c OLED / LCD?

feels like it doesn't get the time to fully write the contents of the buffer to the screen before refreshing.
i totally appreciate the effort, but i'm not sure if it's worth it. not for my use case, anyway..

Try removing the if(!sent) line from the bottom

hmm. same.

this is the LFO example.

And increase the usleep in the next line to 100000 ?

@Remork I added another commit that should fix that . Try it pls

yes! definitely the best one yet.
don't know what you did exactly, but it seems to work.

i mean, you can still see it struggling.. parameter blocks are jumpy and especially on the sine waveform you can see the screen rolling. However! timing is as accurate as it will be and the buffer buildup is gone. yay!

i wouldn't use it for waveform displays as they are nowhere near smooth enough, but for most other functions this is beautiful. hats off to you sir.
mind explaining your process? am i correct in thinking this is at 1/4 refresh rate now?

Remork mind explaining your process? am i correct in thinking this is at 1/4 refresh rate now?

see the diff here: https://github.com/giuliomoro/O2O/compare/only-latest

Sending data to the screen has been moved out of the receiving thread (parseMessage()) and moved to the main thread (main()). parseMessage() parses all incoming messages and updates the in-memory buffer with the bitmap representation that has to be sent out to the display. When this buffer has been modified, it notifies the main thread (by setting the global gShouldSend per each display whose buffer has been updated), which proceeds to send the buffer to the display(s), ultimately causing the output to be visualised. Access to the in-memory buffers and the gShouldSend flags are protected by the mutex mtx, so that at any given time only one of parseMessage() or main() can read from or write to the buffer. The rate limiting is done by the fact that it doesn't matter how many times parseMessage() has updated the buffer while main() was sleeping: only the latest version of it will be written to the output. As parseMessage() will in principle run much faster than main()'s sleep, main() will be dropping frames, thus avoiding the backlog.

The max frame rate is sort of limited by the time it takes to send data to the screen plus any sleep in main(). There is usleep(50000) in main(), but actually this sleep is only observed if no data has just been sent out, so that this should only affect the jitter of isolated messages (delaying their visualisation by up to 50ms), so if you are sending a steady stream of messages, there will be no sleep and it will immediately try to lock the mtx again.

Now that I think of it again, we are sort of over-relying on the Linux scheduler to ensure we have enough CPU time to process incoming messages and you could find yourselves having both threads either busy or waiting on a lock and so little progress may be made on the parseMessage() side, still potentially leading to a backlog. This is because the "critical section" (i.e.: the section where the mutex is held) in main() is rather long (i.e.: it takes a lot of time because it's sending a lot of bits over I2C, whereas best practice suggests to keep critical sections as short as possible and without I/O. It is possible that a better approach would be to make a deep copy of the U8G2 object that we want to send out to, but this requires changing things deep inside it.
I understand you are not seeing such issue right now, but I am thinking it could happen if the CPU gets busy with something else (e.g.: running Bela audio). One option here would be to change the priority of parseMessage() thread so that it is higher than main() (they are both at priority 0 right now. Alternatively, more simply, you could just force a sleep even in case something has just been sent.
Back of the envelope (optimistic) frame rate calculation:

payload (bits): 128*128*4 = 65536
transfer rate: 400000 bits/s
min transfer time (optimistic, assumes bus fully occupied and no transaction overheads): 65536/400000 = 0.16s
max frame rate = 1/0.16s = 6.25Hz

So even adding 1ms of sleep after just sending some data will not significantly slow down the frame rate, but may give parseMessage() more CPU time to process incoming messages. Something like this would be nice:

		if(sent)
			usleep(1000); //short sleep
		else
			usleep(50000); //long sleep

Further note:

I scoped the I2C bus on Bela and it looks like instead of running at the nominal 400kHz it is doing 333kHz. This means we are actually below that, but I see no straightforward way of increasing that (the datasheet lists 100kHz or 400kHz as the only values) and it's probably not worth the effort here as the display's sampling rate wouldn't actually improve much here.
Table 13-6 of the SSD1327 datasheet shows that min "Clock Cycle Time" is 2.5us, i.e.: 400kHz seems to be the highest clock you could use here and we are already close to that.

giuliomoro I scoped the I2C bus on Bela and it looks like instead of running at the nominal 400kHz it is doing 333kHz.

correction: with pull-up resistors this actually goes higher. I am at 384kHz with 10k pullups. Probably reaches the nominal 400kHz with more reasonable 2k2 pullups.

giuliomoro Sending data to the screen has been moved out of the receiving thread (parseMessage()) and moved to the main thread (main()). parseMessage() parses all incoming messages and updates the in-memory buffer with the bitmap representation that has to be sent out to the display. When this buffer has been modified, it notifies the main thread (by setting the global gShouldSend per each display whose buffer has been updated), which proceeds to send the buffer to the display(s), ultimately causing the output to be visualised. Access to the in-memory buffers and the gShouldSend flags are protected by the mutex mtx, so that at any given time only one of parseMessage() or main() can read from or write to the buffer. The rate limiting is done by the fact that it doesn't matter how many times parseMessage() has updated the buffer while main() was sleeping: only the latest version of it will be written to the output. As parseMessage() will in principle run much faster than main()'s sleep, main() will be dropping frames, thus avoiding the backlog.
The max frame rate is sort of limited by the time it takes to send data to the screen plus any sleep in main(). There is usleep(50000) in main(), but actually this sleep is only observed if no data has just been sent out, so that this should only affect the jitter of isolated messages (delaying their visualisation by up to 50ms), so if you are sending a steady stream of messages, there will be no sleep and it will immediately try to lock the mtx again.

okay. i understand that part couldn't have come up w/ that myself, as i don't grasp the concepts used enough to know that such a move would result in more stability. it makes sense when you explain it, though.

the part about the linux scheduler i'll have to read twice.
but i understand that if we're at 333kHz, without pullups, we're slower than the max rate of 6.25Hz?
which seems sort of slow to begin with - how does that compare to 'standard' monochrome Oled?
i mean, i can clearly see the difference, maybe that's all that matters.

thinking of which, would these adjustments also improve speed on a regular SSD1306, for example?

If the processor on Bela was only sending I2C data to the OLED, it would take 128*64/8*10/400000 = 25.6ms to send a frame (10 being the number of clock slots required to transmit 8 bits via I2c), so that's the hard limit for refresh rate. Considering the communication overhead of the I2C bus and that the processor is also doing other things (at the very least processing audio and OSC), I think 50 ms is a good result and I am not sure it can be pushed much faster. If you want to go faster than that, you should be looking at SPI displays that allow much higher transfer rates.

albert But I have a 7-Segment Serial Display which can communicate via SPI.

Do you have a datasheet for it ? This could be probably driven from two Bela GPIOs using soft-SPI, given the very small bandwidth it will probably require ...

albert Or would you have a recommended SPI display tested with Bela? Thank you very much!

there were some posted here in the past, including an RGB one ... I should note that on Bela there is no spare SPI bus, so you'd have to sacrifice either audio inputs or analog inputs. On Bela Mini, on the other hand, there is a spare SPI bus available and ready.

giuliomoro this is the Display I have https://www.sparkfun.com/datasheets/Components/LED/7-Segment/SFE-0012-DS-7segmentSerial-v41.pdf

I have a Bela Mini too, I can tri with the SPI bus

thx