On an unrelated purchase, I got a small 1.8 inch TFT display that can do 128x160 with a bunch of colours using the st7735 chip. That's shown above running the qtdemo on the framebuffer. Of course, an animation might serve to better show that off. The display was on sale for $10 and so it was then on it's way to me :) My original plan was to drive that from an Arduino... Looking around I noticed that Matt Porter had generously contributed a driver to run the st7735 over SPI from the Linux kernel. The video of him talking at ELC about this framebuffer driver was also very informative :) It seems the same TFT can be run from the Raspberry or Beagle series of hardware.
The wiring for the panel I got was a bit different than the adafruit one that Matt used. But once you have the pinouts its not so hard to figure out. I've currently left the 5V rail unconnected on my TFT. On the BeagleBone Black the HDMI output captures a whole bunch of pins when it starts. Unfortunately some of those pins are needed for the little TFT. One might be able to reroute the SPI to the other bus or mux the pins differently to get around that and have HDMI and the TFT at once. But I wanted to get the TFT going to see if/how it worked before changing the pins.
I had found some info on putting a line in eEnv.txt to stop the HDMI cape from loading but that didn't work for me. On my board I saw that in /sys/devices/bone_capemgr.9/slots the HDMI was the 5th cape. When I first echoed "-5" into the slots file to unload that cape the kernel gave a backtrace. If I did the same on a freshly booted bone it would cleanly remove the HDMI cape though. So something was using the HDMI cape driver before which didn't want to be removed.
With the HDMI cape unloaded the next step is to load a "firmware" file that reserves the pins that the st7735fb driver wants to use. Since I used the same pins on the bone as the adafruit display wants I could just use the below.
echo cape-bone-adafruit-lcd-00A0 > /sys/devices/bone_capemgr.9/slots
A dmesg showed that a new framebuffer device fb0 had come into existence.
[ 85.280471] bone-capemgr bone_capemgr.9: slot #6: Requesting firmware 'cape-bone-adafru-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
[ 85.284645] bone-capemgr bone_capemgr.9: slot #6: dtbo 'cape-bone-adafru-00A0.dtbo' loaded; converting to live tree
...
[ 86.235178] fb0: ST7735 frame buffer device,
[ 86.235178] using 40960 KiB of video memory
[ 86.236687] bone-capemgr bone_capemgr.9: slot #6: Applied #5 overlays.
After a bunch of searching around trying various things, I found that prescaling in mplayer can display to the framebuffer:
# mplayer -ao null -vo fbdev2:/dev/fb0 -x 128 -y 160 -zoom ArduSat_Open_Source_in_orbit.mp4
The qtdemo also runs "ok" by executing the below. I say ok because it obviously expects a higher resolution display than 128x160.... qtdemoE -qws
It is tempting to have two screens and add a touch sensitive film to them. With a QML/QtQuick/TodaysRebrand^TM interface the GUI should work well and be flickable to many screens.
A great hack I look forward to is running a 32x16 LED DMD using a deferred rendering framebuffer driver like the st7735fb does. I see the evil plan now, release the BeagleBone Black for $45 and draw more C/C++ programmers to being kernel hackers rather than userland ones :)
9 comments:
Nice writeup on using the fb! I linked it over from the BeagleFu forums for the members to see it.
How did you remove the HDMI? I found the kernel panic, but I am unsure of how you solved the problem.
Post is very helpful. Thank you.
When I got it to work I had just booted the BeagleBoneBlack and didn't have any HDMI cables connected to it. I think perhaps if there was some usage of the hdmi cape then it doesn't like being removed.
I just booted up without HDMI again, echo -5 removes the cape without an oops.
When I echo -5, I just get a kernel panic in Debian. I was able to do it by recompiling the kernel with device tree hdmi blocks commented out.
However, the preferred method we found was to edit /boot/uboot/uEnv.txt
Cool. I'll have to RTFS to work out how to tinker uEnv.txt properly on the BBB. Seems like the cleanest way, especially if one plans to use the full range of headers.
I'll probably post a comment with info how I got that going once I do that.
What kernel are you using? You're using the BBB but how did you manage to compile ST7735 driver for a recent BBB kernel?
What kernel are you using? You're using the BBB but how did you manage to compile ST7735 driver for a recent BBB kernel?
Post a Comment