OLED driver loading

[tehn]

when loading the driver at boot via dtoverlay the OLED is much less stable than manually loading it with modprobe.

redrawing of frames sometimes aborts mid-draw, and sometimes pixels are lost/skipped which shifts the redraw by an offset.

need to test further if this is an issue with the DC manual wiring to pin 5-- some sort of electrical unreliability.

manual driver load command is sudo modprobe fbtft_device custom name=fb_ssd1322 width=128 height=64 speed=16000000 gpios=dc:7,reset:6

[ranch-verdin]

Don't think I am observing this - display on my device looks glitch-free with current config. Just double checked - the method of OLED driver load is definitely dtoverlay.

[tehn]

ok. perhaps i somehow did an amazing job soldering the jumper wire on yours, because i can't yet account for any other differences. i'll have new pcb protos soon to test this theory.

[ranch-verdin]

@tehn, @catfact

• I always see glitches repeatably after running wifi.sh on
• Once the display starts glitching, restarting the norns software gets things back to normal.
• sometimes the display goes glitchy after boot

do you observe the same?

[catfact]

maybe i got something like that

after runnig wifi.sh on:

• some seconds (?) after switching into grid_seek from the menu, the screen starts periodically blanking
• switching back into menu it looks fine
• switching back to grid_seek, same
• reboot fixes it

[tehn]

vu may be refreshing at a rate that’s similar to the oled rate, the clear operation is fastest?

need screen buffering

https://github.com/catfact/norns/issues/72

[catfact]

i'm not drawing the VUs though, just printing them

is it possible that linux is trying to use the framebuffer for terminal output in some way?

[tehn]

i just mean rapid refresh. i’ve only seen issues with grid-seek. there’s a poll. the vu is drawn every poll value. so it’s just super rapid redrawing that i suspect has a sync issue.

[simonvanderveldt]

I always see glitches repeatably after running wifi.sh on Once the display starts glitching, restarting the norns software gets things back to normal. sometimes the display goes glitchy after boot do you observe the same?

I have exactly this as well, only difference is that I didn't use wifi.sh, but just edited /etc/wpa_supplicant/wpa_supplicant.conf and then ran wpa_cli -i wlan0 reconfigure. After this the screen started glitching and after +-40s or so it went all black and the screen/serial connection died, had to use the button on the bottom for the first time :)

After starting again wifi is still working and connected and I don't experience any issues with the display.

[ranch-verdin]

@tehn... I already mentioned this to @simonvanderveldt on the slack but putting it here so we don't forget.

Using our raspbian image with kernel-180215.tar.gz - it seems that spi_bcm2835 module is also required in order to operate the tft. You can check this by modprobe/rmmod spi_bcm2835 and observe changes on the screen.

could this explain why modprobe fbtft_device seemed more reliable than dtoverlay? I think simon is going to try building spi_bcm2835 into kernel.