Headphone Amp for Raspberry Pi with fbtft

Hi there,

I’ve tried to run the Headphone Amp for Raspberry Pi with fbtft (on Raspbian Buster) without any success. I managed to get the modules loaded and instrumented startup sequence and gpios like this (taken from the st7789 python lib):

options fbtft_device name=flexfb gpios=dc:9,cs:1,led:19 speed=4000000 bgr=1 fps=60
options flexfb setaddrwin=0 width=240 height=240 init=-1,0x01,-2,150,-1,0x36,0x70,-1,0xB2,0x0C,0x0C,0x00,0x33,0x33,-1,0x3A,0x05,-1,0xB7,0x14,-1,0xBB,0x37,-1,0xC0,0x2C,-1,0xC2,0x01,-1,0xC3,0x12,-1,0xC4,0x20,-1,0xD0,0xA4,0xA1,-1,0xC6,0x0F,-1,0xE0,0xD0,0x04,0x0D,0x11,0x13,0x2B,0x3F,0x54,0x4C,0x18,0x0D,0x0B,0x1F,0x23,-1,0xE1,0xD0,0x04,0x0C,0x11,0x13,0x2C,0x3F,0x44,0x51,0x2F,0x1F,0x1F,0x20,0x23,-1,0x21,-1,0x11,-1,0x29,-2,100,-3

I’ve also tried cs=1 and different startup sequences (skipping display reset, some Adafruit-samples) without any success.

dmesg | grep fb shows a lot of information and the framebuffer devices /dev/fb0 and fb1 appear (eg. SPI speed and mode, memory buffers). None of them can be used by fbi or other renderers (ioctl-error whereas the user is in video group and/ or adding sudo doesn’t solve this problem). I also can’t remap boot console to the display (cmdline.txt with fbcon).

The python module works fine and I can render text and images. The scrolling example is even interrupted by fbtft, which resets the display while the text scrolls (display turns black). Any hints on that?

And a general question: does it make sense to fire up a complex interpreter on something like a Pi Zero just to wiggle some GPIOs? Wouldn’t be the kernel/ framebuffer-approach be more power saving/ straight forward?

This post was flagged by the community and is temporarily hidden.

Nope, no progress. Instead I hacked something into the python-samples. It is some heavy piping like this:

mpg123 -f $VOLUME_MPG123 -Z --long-tag --list rnd.m3u 2>&1 | grep --line-buffered -e Title -e Artist | mawk -Winteractive -F: ‘{print $2}’ | python3 st7789-python/examples/any-text.py

any-text.py reads from STDIN and writes it to the display. I postponed my efforts until the support develops some kernel driver options. I had absolutely no success with nothing, no framebuffer sequence, parsing through the manual of the chip…there’s maybe something odd with the connections.

This also works on a buildroot-environment with python.

This post was flagged by the community and is temporarily hidden.

Thanks for your effort, I did all of this but it seems as if there’s a missing step. There is no such overlay:

Mopidy came up but does not play anything and only the button to decrease volume is working. It’s also quite disappointing to have that much bloatware…install.sh pulls in further package repos with additional packages that I’ll never need for simply playing music and displaying artist/ title info. (And it loads very slow, boot process takes appr. 30s.)

Console messages aren’t displayed at all. Modules are loaded properly, also tried a second display just in case something is broken (whereas mopidy displays everrything correctly on both displays as well as python samples). SPI seems to work.

Tried a dts like in this: https://github.com/notro/fbtft/issues/515

What version of raspian are you using? You might have to try ‘stretch’. I’ll eventually try it with later OS releases once I’ve got jackd configuration working. Also, you could skip the ./install step and run through the manual instructions from the shop pimoroni link in my previous post.

These links might help:


I’m using latest (buster) and I dug into the kernel docs. Some work took place esp. with fbtft. The module fbtft_device was removed completely, thus no modprobe with listing supported devices. There seems to be no working replacement out of the box. Maybe that’s why Pimoroni’s Mopidy adjustments are based on python and not the kernel modules/ native framebuffer approach.

There were no essential packages added through mopidy installation. Using the framebuffer does not work (with recent raspbian). Maybe I’ll try buildroot then, speeding up the python loading. Without the gimmicks from a ramdisk this got me up and playing within 3s. I could live with another 2s to load the python spi-thingy.