Here are the steps I used to get it up and running (everything works!)
Step 0: Make sure you only log into the DietPi using a non-Root account (eg. dietpi:dietpi)
Step 1: Make sure the following components have been installed using the DietPi Software configuration tool.
=> 130 Python Pip
=> 16 Build Essentials
=> 17 Git
Step 2: Execute the following code
sudo apt-get install libfreetype6-dev libjpeg-dev
Step 3: Execute the following code
sudo pip install --upgrade ssd1306
Step 4: Execute the following code (system will reboot at the end)
git clone https://github.com/friendlyarm/NanoHatOLED.git && cd NanoHatOLED && sudo -H ./install.sh
Once the system reboots you should see the FriendlyElec logo flash up and then everything should just work!
HOWEVER …
After running mine 24x7 for about a month I discovered that my little OLED screen had developed a nasty case of “screen burn”
This inspired me to do a little hacking and make a few fixes.
Executing the following code will do two things:
Replace the default script with one that turns off the screen after five(ish) minutes (as soon as you click a button it will turn back on for another five minutes).
Replaces the boot image with a muuuch better one. dietpi logo
That’s pretty cool! Btw just a quick question - would this work with a NanoPi-NEO2? I should be receiving one very soon and would want to use this OLED … and with DietPi.
Have bought a NanoPi NEO2 LTS. Managed to get the NanoHatOLED working using instructions above.
However after a while having to reboot, the OLED display went all black. Did complete DietPi re-install and it worked till I installed other software (Pi-Hole in casu), now it has stopped working again.
Have re-run install.sh a couple of times but that does not help…
maarten
Ah jep, please note the following:
rc.local is an outdated/obsolete feature that is disabled on fresh Debian images by default and DietPi just follows that. It is however still implemented via compatibility systemd unit and can be enabled as you did.
But nowadays one should create a systemd unit directly to start custom scripts on boot.
Another possibility is to place the custom script into /var/lib/dietpi/postboot.d/my_script.sh. Name can be chosen, only .sh ending required.
This is our own compatibility implementation that has the same effect and is used by some optional DietPi features as well.
I had to recompile the kernel and then installed DietPi over it. Now it shows “Linux DietPi 4.19.25-sunxi64 #5.76 SMP” under uname.
I can’t make NanoHatOLED work.
When I try “systemctl enable rc-local.service” I get this message :
dietpi@DietPi:~$ sudo systemctl enable rc-local.service
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
A unit may be statically enabled by being symlinked from another unit’s
.wants/ or .requires/ directory.
A unit’s purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, …).
In case of template units, the unit is meant to be enabled with some
instance name specified.
Just updated from 6.19.7 to 6.24.1 and everything is working for me, I’m assuming the more recent versions of DietPi have a workaround in place for whatever gremlins were affecting people.
.