Headphone Amp for Raspberry Pi with fbtft

Support
1

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?

3

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.

5

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: ST7789V not working · Issue #515 · notro/fbtft · GitHub

6

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:

https://forums.slimdevices.com/showthread.php?111502-Jivelite-on-a-Pirate-Audio-240x240-screen
https://forums.slimdevices.com/showthread.php?110727-BETA-piCorePlayer6-0-0-PI4-support&p=956684&viewfull=1#post956684

7

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.

8

Thanks, indeed it only works on Stretch. Even got buttons working with a device tree overlay[1]. One of the button directly binds to gpio-shutdown[2]. Thus the player command now looks like this:

mpg123 --long-tag -Z --list playlist.m3u 2>&1 | grep --line-buffered -e Title -e Artist -e Album -e Year | sed -r 's/^\s+\w+:\s+//'

One caveat is random playing on RPi hardware. Somehow mpg123 doesn’t take hwrng into consideration – hwrng works and spits out sufficiently random data. Therefore I shuffle the playlist before shutdown. This seems to be sufficiently random with enough entropy available. And after the next reboot the playlist starts somewhere else and plays a totally different pattern. (Otherwise the playlist was always the same, even with random play option.)

It is up and running within 24s on a RPi Zero. I also carved out all services (logging, cron, networking, …) so power loss isn’t a problem for the SD card. There are no writes anymore.

[1] http://blog.gegg.us/2017/01/setting-up-a-gpio-button-keyboard-on-a-raspberry-pi/
[2] https://www.stderr.nl/Blog/Hardware/RaspberryPi/PowerButton.html

9

Regarding fbconsole support for Pirate Audio hardware running raspbian buster, I finally found something that works. Note: This does not appear to work on the raspberrypi os version of buster using the 5.x kernel but it does work for 4.19.x kernels running on raspbian buster and stretch.

  1. Install “buster-lite” and run “sudo apt update” but DO NOT run “sudo apt upgrade”
  2. run “sudo raspi-config” and enable “SSH”, “SPI”, and “I2C” within “Interfacing Options” then reboot.
  3. login as the pi user.
  4. run “wget
    https://gist.githubusercontent.com/hgroll/2731ae6d05350df663b123615f765bf5/raw/f8fe3829136296c20ba670dcd572e8a5c60da995/pidi-overlay.dts”
  5. run “dtc -@ -I dts -O dtb -o pidi.dtbo pidi-overlay.dts”
  6. run “sudo cp pidi.dtbo /boot/overlays/”
  7. edit “/boot/config.txt” and add the line “dtoverlay=pidi”
  8. edit “/boot/cmdline.txt” and append " fbcon=map:10 fbcon=font:VGA8x16" (with the beginning space) to the 1st line after the word “rootwait”
  9. run “sudo dpkg-reconfigure console-setup” then select “UTF8”, “Guess optimal…”, “Let the system select…”, “8x16”, “Ok”
  10. run “sudo reboot”

The pirate audio hat should come up in fbconsole mode.
It will break if you try to “apt upgrade” but at least it’s running in buster (4.19.x).

I found the information at the following url:
https://github.com/pimoroni/pirate-audio/issues/15

10

I was tested and worked with Raspberry Pi OS using kernel 5.4.

Perhaps the reg parameter means the SPI chip select (CE) parameter. The Pirate Audio uses “SPI0 CE1(BCM7)”, not “SPI0 CE0(BCM8)”. So we needed to modify pidi-overlays.dts little bit.

-                                 reg = <0>;
+                                 reg = <1>;

1.3" SPI Colour LCD (240x240) Breakout also works fine.

11

Akkie, have you had any luck with 180 degree rotate? I added this in config.txt:

dtoverlay=pidi:rotate=180

But it creates a noise artifact on half the screen…

12

Nevermind, this worked in cmdline.txt because I’m using fbconsole:

fbcon=rotate:2