The article is a combination of various articles I found on the web, referencing older versions of one part or another, and this is a reference for my setup should I need to rebuild it.

Hardware

• Raspberry Pi Zero W – Purchased one of those kits on Amazon and it came with various cases and cables I needed, so I was happy with it.
• Logitech USB Webcam
• Power/HDMI/USB
• Keyboard/Mouse

Fresh Raspbian Install

I’m utilizing the latest version of Raspbian as of this writing, which was released around February, 2020. Flashing that to a simple 16 GB Micro SD Card for a blank slate:

Assuming you’re relatively familiar with the Pi, here’s the minimum I’m generally doing as post boot up task work:

• Changing default password
• Setting Up Wifi
• Enabling SSH
• Setting Hostname
• Setting Locale/Internationalization Options
• Rebooting

After that, the obligatory ‘update’ install:

sudo apt update
sudo apt upgrade

I can now SSH into the Pi Zero W, disconnect the keyboard, and move along with the install.

Build Dependencies

We need to download some things first before we can build mjpg-streamer. I found some references to articles that pulled from the SVN repo to retrieve and compile, but I ended up getting a large amount of compile errors that look like some library was swapped but the source wasn’t updated. It’s the 'redefinition of ‘struct statx_timestamp’' error.

Instead of pulling the SVN version, I’m going to be pulling the Git repo of mjpg-streamer that was created by jacksonliam. This (https://github.com/jacksonliam/mjpg-streamer) is the ‘official’ successor to the now abandoned SVN version at https://sourceforge.net/projects/mjpg-streamer/.

We’ll now install our dependencies before we download and compile mjpg-streamer code:

sudo apt-get install build-essential libjpeg9-dev imagemagick libv4l-dev cmake git -y

Git, Make, Install

mkdir ~/mjpg-streamer
cd ~/mjpg-streamer

git clone https://github.com/jacksonliam/mjpg-streamer.git
cd mjpg-streamer/mjpg-streamer-experimental

make
sudo make install

The make install will copy binaries, libraries and the www pages to the /usr/local/ directory structure:

• /usr/local/bin/mjpg_streamer – The primary binary
• /usr/local/lib/mjpg-streamer/ – The directory of input/output modules
• /usr/local/share/mjpg-streamer/www – The www server interface

Test The Build

I’m going to test the build by plugging in a webcam into the Pi Zero W’s lone USB port. Executing dmesg shows that it was loaded properly:

[ 1275.662775] usb 1-1: New USB device found, idVendor=046d, idProduct=082d, bcdDevice= 0.11
[ 1275.662796] usb 1-1: New USB device strings: Mfr=0, Product=2, SerialNumber=1
[ 1275.662806] usb 1-1: Product: HD Pro Webcam C920

Let’s test by trying to run mjpg-streamer against the input_uvc.so plugin, since I”m not using a Raspi-Camera, but a USB one instead. (See notes at the bottom about Raspberry Pi Bullseye and Raspi-Cameras). I’ll also output using the http plugin. So my testing command line looks like this:

/usr/local/bin/mjpg_streamer -i "input_uvc.so -f 15 -r 640x480" \
 -o "output_http.so -w /usr/local/share/mjpg-streamer/www"

Executing that line gives us a dump of data – here’s the relevant info:

MJPG Streamer Version: git rev: 5a6e0a2db163e6ae9461552b59079870d0959340
 i: Using V4L2 device.: /dev/video0
 i: Desired Resolution: 640 x 480
 i: Frames Per Second.: 15
 i: Format............: JPEG
 i: TV-Norm...........: DEFAULT
 o: www-folder-path......: /usr/local/share/mjpg-streamer/www/
 o: HTTP TCP port........: 8080
 o: HTTP Listen Address..: (null)
 o: username:password....: disabled
 o: commands.............: enabled

Our key variables to tweak are -f for frame rate, and -r for resolution. I’ll change those later, but for a quick test I head on out to my browser and point it at the www server at http://cam-pi-zero.local:8080/

Not only do we see the web interface, but a snapshot of the web cam, which was, clearly, laying down on a workbench behind me while I tried this out.

Validating the stream worked (by clicking ‘Stream’) and turning around, I could see myself moving:

You can now hit CTRL-C in your SSH window (or terminal) and quit the stream. After this point, I could delete the build files I downloaded.

Tweaking configuration

I wanted to run my camera at its intended resolution and at least a frame rate of 30fps. To do that I modified my command line:

#30fps, 1080 HD
/usr/local/bin/mjpg_streamer -i "input_uvc.so -f 30 -r 1920x1080" \
 -o "output_http.so -w /usr/local/share/mjpg-streamer/www"

I then loaded my own stream up in VLC by opening the direct network path to the stream:

http://cam-pi-zero.local:8080?action=stream

That worked, and I get about a 1-2 second delay from Pi to VLC. So I wouldn’t use this with audio feeds unless I was planning on creating a sync delay. I’m using this to monitor 3D prints, or watch birds outside, so my use case does not demand low latency. Is it exactly 30 frames per second? No…. NO it’s not.

At 1280×720, it seemed closer, but at 1920×1080, when set at 30fps, it definitely wasn’t even close. I’d guess more like 15.

The PI wasn’t maxed out on CPU, but it could just be the nature of USB 2.0 at this point. I’m not sure how I can tell if it’s overloaded there or not, but, once again, this is a light monitoring video stream, I don’t care too much about latency. It could be WiFi as well. Someday I may dig in a bit more and find out where the bottleneck is.

I think you could probably choose either 1920×1080 15fps or 1280×720 30fps routes and be okay.

v4l2-ctl --list-formats-ext

Running On Startup

I liked Jacob Salmela‘s script – all I did was change it for my command line on the stop and restart section for my resolution and frame-rate. Save the following script by doing a sudo vi:

sudo vi /etc/init.d/livestream.sh

#!/bin/sh
# /etc/init.d/livestream.sh
### BEGIN INIT INFO
# Provides:          livestream.sh
# Required-Start:    $network
# Required-Stop:     $network
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: mjpg_streamer for webcam
# Description:       Streams /dev/video0 to http://IP/?action=stream
### END INIT INFO
f_message(){
        echo "[+] $1"
}

# Carry out specific functions when asked to by the system
case "$1" in
        start)
                f_message "Starting mjpg_streamer"
                /usr/local/bin/mjpg_streamer -b -i "input_uvc.so -f 15 -r 1920x1080" -o "output_http.so -w /usr/local/share/mjpg-streamer/www"
                sleep 2
                f_message "mjpg_streamer started"
                ;;
        stop)
                f_message "Stopping mjpg_streamer…"
                killall mjpg_streamer
                f_message "mjpg_streamer stopped"
                ;;
        restart)
                f_message "Restarting daemon: mjpg_streamer"
                killall mjpg_streamer
                /usr/local/bin/mjpg_streamer -b -i "input_uvc.so -f 15 -r 1920x1080" -o "output_http.so -w /usr/local/share/mjpg-streamer/www"
                sleep 2
                f_message "Restarted daemon: mjpg_streamer"
                ;;
        status)
                pid=`ps -A | grep mjpg_streamer | grep -v "grep" | grep -v mjpg_streamer. | awk ‘{print $1}’ | head -n 1`
                if [ -n "$pid" ];
                then
                        f_message "mjpg_streamer is running with pid ${pid}"
                        f_message "mjpg_streamer was started with the following command line"
                        cat /proc/${pid}/cmdline ; echo ""
                else
                        f_message "Could not find mjpg_streamer running"
                fi
                ;;
        *)
                f_message "Usage: $0 {start|stop|status|restart}"
                exit 1
                ;;
esac
exit 0

Then we enable this on startup by performing:

sudo chmod 755 /etc/init.d/livestream.sh
sudo update-rc.d livestream.sh defaults

Now you can reboot your pi, or use commands like ‘sudo service livestream start’ I rebooted my pi, and my fed was running, and running a status command on my service yields:

pi@cam-pi-zero:~ $ sudo service livestream status
● livestream.service - LSB: mjpg_streamer for webcam
   Loaded: loaded (/etc/init.d/livestream.sh; generated)
   Active: active (running) since Thu 2020-05-14 11:46:09 CDT; 2min 51s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 411 ExecStart=/etc/init.d/livestream.sh start (code=exited, status=0/SUCCESS)
   Memory: 2.2M
   CGroup: /system.slice/livestream.service
           └─416 /usr/local/bin/mjpg_streamer -b -i input_uvc.so -f 15 -r 1920x1080 -o output_http.so

May 14 11:46:07 cam-pi-zero.local mjpg_streamer[416]: MJPG-streamer [416]: TV-Norm...........: DEFAUL
May 14 11:46:08 cam-pi-zero.local mjpg_streamer[416]: MJPG-streamer [416]: www-folder-path......: /us
May 14 11:46:08 cam-pi-zero.local mjpg_streamer[416]: MJPG-streamer [416]: HTTP TCP port........: 808
May 14 11:46:08 cam-pi-zero.local mjpg_streamer[416]: MJPG-streamer [416]: HTTP Listen Address..: (nu
May 14 11:46:08 cam-pi-zero.local mjpg_streamer[416]: MJPG-streamer [416]: username:password....: dis
May 14 11:46:08 cam-pi-zero.local mjpg_streamer[416]: MJPG-streamer [416]: commands.............: ena
May 14 11:46:08 cam-pi-zero.local mjpg_streamer[416]: MJPG-streamer [416]: starting input plugin inpu
May 14 11:46:08 cam-pi-zero.local mjpg_streamer[416]: MJPG-streamer [416]: starting output plugin: ou
May 14 11:46:09 cam-pi-zero.local livestream.sh[411]: [+] mjpg_streamer started
May 14 11:46:09 cam-pi-zero.local systemd[1]: Started LSB: mjpg_streamer for webcam.

Conclusion

Using the Raspberry Pi for video streams is good enough if we’re looking for low frame rate monitoring without audio. I’ve yet to find anything that really gives me the frame rate and audio (regardless of latency) that a standard USB webcam directly into my OBS machine would give. Maybe if NDI ever makes it on to the raspberry Pi, or if there is ever SLDP support.

Have you tried streaming across the network on a Raspberry Pi with a USB webcam? Did you fare better than I? Let me know!

Nevertheless, with that, I’m done! I can now embed this into OBS via the VLC media source or anything that can handle an HTTP Motion JPEG video stream. I won’t have audio, but that’s okay for what I’m using this for.

Raspi-Cameras (libcamera is in, raspivid is out in Bullseye)

Mjpg-Streamer won’t have the raspicam input module anymore if you compile on Bullseye, because I believe the headers don’t exist as the Bullseye version is going the way of libcamera. While I was able to hack around that and build it, I got HORRIBLE artifacts using a raspberry pi camera with the h264 codec and libcamera. I tried switching codecs to MJPEG instead of H264 and had less artifacts, but worse frame rate. So for now I decided to go with gstreamer instead of mjpg-streamer at 1280×720 for a nice 30fps solution.

For me, what worked was to enable the legacy raspi-camera support (so we’re not using libcamera, we’re using v4l2).

Here are the rough steps:

• Started out with Bullseye, latest install with sudo apt update/sudo apt upgrade executed.
• Edit /boot/config.txt and change the following:
  • start_x=1 //add this line
  • gpu_mem=128 //probably no higher
  • #camera_auto_detect=1 //Comment this line out
• Restart
• Installs:

sudo apt-get install gstreamer1.0-tools gstreamer1.0-plugins-base \
     gstreamer1.0-plugins-good gstreamer1.0-plugins-bad

Then execute this on the command line:

/usr/bin/gst-launch-1.0 v4l2src ! video/x-h264,width=1280,height=720,framerate=30/1 ! h264parse config-interval=1 ! matroskamux streamable=true ! tcpserversink host=::0 port=9000 sync=false sync-method=2

Once that’s up and running, I ran VLC against it using :network-caching=250 and a URL of tcp://<yourhostname>:9000 and was able to get a decent stream. That’s about the extent I’ve been pushing the raspi-cameras as I typically use the USB side. I did notice it was nice and fluid, along with less power consumption by a 100 milliamps or so, so I think I’ll use this as a portable battery powered wireless camera to use around the house on streams. Hmmm, I may need to look at getting a microphone on here somehow and streaming audio with gstreamer as well.

References

• https://einar.slaskete.net/2018/08/16/using-a-raspberry-pi-as-a-surveillance-camera-in-home-assistant/
• https://picamera.readthedocs.io/en/release-1.12/fov.html
• https://qengineering.eu/install-gstreamer-1.18-on-raspberry-pi-4.html
• https://www.raspberrypi.org/documentation/configuration/wireless/wireless-cli.md – Raspberry Pi Document on WIFI Setup
• https://www.amazon.com/Vilros-Raspberry-Starter-Power-Premium/dp/B0748MPQT4 – The Raspberry Pi Zero W kit I purchased
• https://sourceforge.net/projects/mjpg-streamer – The original source forge project.
• https://github.com/jacksonliam/mjpg-streamer – The successor to the abandoned Sourceforge project.
• https://jacobsalmela.com/2014/05/31/raspberry-pi-webcam-using-mjpg-streamer-over-internet/ – Reference for build information
• https://www.acmesystems.it/video_streaming – Another build reference
• https://qiita.com/xeno14/items/e32e52c688d969d182e2 – Another build reference

The post MJPG-Streamer on a Raspberry Pi Zero W with a USB Webcam Streaming Setup appeared first on Krystof.IO.

Downloading and Updating

The obligatory apt update/apt upgrade, along with installing dependencies:

cd ~

sudo apt update
sudo apt upgrade
sudo apt-get install -y build-essential tk-dev libncurses5-dev libncursesw5-dev libreadline6-dev libdb5.3-dev libgdbm-dev libsqlite3-dev libssl-dev libbz2-dev libexpat1-dev liblzma-dev zlib1g-dev libffi-dev tar wget vim

wget https://www.python.org/ftp/python/3.8.0/Python-3.8.0.tgz

Compile and Install

tar zxf Python-3.8.0.tgz
cd Python-3.8.0
./configure --enable-optimizations
make -j 4
sudo make altinstall

Validation

Executing this on the command line should work just fine and return the version installed:

pi@vice-pi:~ $ python3.8 -V
Python 3.8.0

Making our install the default version

I prefer to do this by adding the alias to a (potentially new) file .bash_aliases in your home directory by adding this line to the file:

alias python='/usr/local/bin/python3.8'

Example PIP updating

Based on some current reading it looks like it’s a good practice to use the python version specific pip for the version you’re running instead of assuming any default. Here’s the example I used to update the python package manager and installing the RPi.GPIO library.

sudo python3.8 -m pip install --upgrade pip
sudo python3.8 -m pip install RPi.GPIO

References

• https://www.scivision.dev/compile-install-python-beta-raspberry-pi/
• https://installvirtual.com/how-to-install-python-3-8-on-raspberry-pi-raspbian/
• https://www.ramoonus.nl/2019/10/23/how-to-install-python-3-8-on-raspberry-pi/
• https://stackoverflow.com/questions/2812520/dealing-with-multiple-python-versions-and-pip

The post Installing Alternative Python Versions on Raspberry Pi appeared first on Krystof.IO.

Previously in the series, we installed VICE on our Raspberry Pi and made sure it worked. Now we want to mirror the HDMI output to our tiny LCD for the diorama.

Here’s our video that covers this article at a high level:

Two LCDs enter, One LCD leaves

The OLED Breakout Board – 16-bit Color 0.96″ w/microSD holder was a contender. At about 1/12 scale this would have worked out nicely, though it felt a little ‘wide screen’ compared to the monitors I knew of my youth. I was also concerned with resolution, as it supports 96×64, a far cry from the Commodore 64’s 320×200.

The other, and my ultimate winner – the Adafruit 1.3″ 240×240 Wide Angle TFT LCD Display with MicroSD – ST7789 at least got me closer with 240×240, though it was a touch larger. To that end, I’d try both with the Raspberry Pi and compare. Once I plugged in the 240×240 display and saw the Commodore 64 Ready screen, I was sold. Even though you’d be able to make out what I was playing on the OLED display mirroring my HDMI output, with the 240×240 you can actually read a good amount of text, as well. We have a winner.

A Couple of Quests for the Chosen One

Adafruit has a great page in terms of how to wire this up to an Arduino and Raspberry Pi located here. It’s where I learned that the ST7789 chip is used to drive two different LCD displays – 240×240 and 320×240. This becomes important later as I struggle with getting that working on the Raspberry Pi. Regardless of what display I chose – I knew I needed to have the following requirements satisfied:

• The LCD should mirror HDMI output – I didn’t want this to be the primary display, but a mirrored display.
• The LCD screen needed to be in a specific orientation – pins on the bottom – so they could more easily hide inside the 3D printed monitor ‘bottom’

Wire Before You Fire

The display doesn’t come with header pins pre-soldered, so after remembering which end of the soldering iron is the hot end, I was able to move forward by placing the display into my breadboard:

I followed the basic Adafruit directions for wiring the ST7789 driven 240×240 display into my Raspberry Pi. Key points:

• This is an SPI mode device. We’re using the Raspi’s SPI0 mode, so that some of the LCD pins need to wire up to specific Raspberry Pi Pins. More on SPI here.
• We have a choice on the LCD’s reset pin, we went with a loose default of 24 on the Pi.
• We have a choice on the D/C pin, we went with a loose default of GPIO 25 on the Pi.

Here’s from Adafruit’s page specific to our ST7789 driven LCD display: (Editors Note – If you compare this to Adafruit’s wiring page, you may notice I swapped my RST and D/C pins – Adafruit uses 24/25 and I’m using 25/24 – It’s fine as long as you’re consistent with your physical pins and the command line options you’ll use later. Thanks, Thomas!)

• Vin connects to the Raspberry Pi’s 3V pin
• GND connects to the Raspberry Pi’s ground
• CLK connects to SPI clock. On the Raspberry Pi, thats SCLK
• MOSI connects to SPI MOSI. On the Raspberry Pi, thats also MOSI
• CS connects to our SPI Chip Select pin. We’ll be using CE0
• RST connects to our Reset pin. We’ll be using GPIO 25 but this can be changed later.
• D/C connects to our the data/command pin. We’ll be using GPIO 24, but this can be changed later as well.

Remember that the Raspberry PI has numerous GPIO pins, but GPIO pin 24 doesn’t mean pin 24 on the pin-out diagram – always refer to some cheat sheet like this one from RaspberryPi.org shown below. Also, another great Raspberry Pi pin-out page that’s interactive is made available by Gadgetoid.

Okay, so we’ve got it wired now, and there’s a promising backlight barely illuminating the LCD when we turn the PI on. We’re one step closer to mirroring our Raspberry Pi to the ST7789 driven LCD Display. Now what?

LCD Driver Powers activate! Form of a mirrored display

While I could have used Python to draw some Commodore images, screenshots, and other static media on the display, I want to actually mirror the display. What shows on the HDMI output should show on the LCD, but I need the mirror scaled. My monitor I’ll play games on doesn’t support 320×240 as a resolution, the bare minimum is 800×600 to make it work well enough. So I searched around the internet and found a couple of solutions that did NOT turn the LCD into the only display or require me to overwrite with a new image.

This is where things might get a little confusing. Both solutions I’m presenting here involve taking the HDMI display output and doing a little frame-buffer copy and manipulation magic.

1. Notro’s fbtft LCD device drivers, which create an LCD frame buffer at /dev/fb1, then utilizing tasanakorn’s fbcp program which copies /dev/fb0 (HDMI output) to /dev/fb1 (LCD output), effectively mirroring the display.
2. juj’s fbcp-ili9341 display driver that effectively does the same thing as #1, though it doesn’t technically create it’s own framebuffer, and it’s not just for ili9341 displays (it supports my ST7789!)

Which one to use? Well, if only one works for you, choose that one. Otherwise, I found that the second, fbcp-ili9341 worked the best, but it does utilize a little more CPU, so you may very well want to test both (the Raspberry Pi 4 handled it fine)

The primary issues I had with both of these solutions involved rotation. My requirements for either solution were to have the header pins aligned with the bottom of the display so I could more easily hide them in the mini-LCD monitor’s bottom piece.

Option 1 – fbtft and fbcp

The Journey to a working LCD mirror

Notro’s fbtft driver repo seems to be still a good reference point but may not be forever. There’s a lot of discussion around the future of this project, as part of it has been brought into the Linux staging structure, and that it may stay there forever stagnating based on some discussions on the development page. Nevertheless, it did end up working.

There’s a lot of good information to sift through on that wiki, but I’ll keep this page more towards my journey in getting it working.

I saw some references in the staging code base to the ST7789 driver, so it felt promising:

https://github.com/torvalds/linux/blob/master/drivers/staging/fbtft/fb_st7789v.c

Now, the key here is that if these drivers are effectively already part of my Raspbian install, I should be able to use the Linux modprobe commands to load these modules in. By looking at other sample modprobe commands I tried this against my Raspberry Pi with the LCD on the breadboard:

#Screen mirrors but inverted colors and rotation
sudo modprobe --first-time fbtft_device name=fb_st7789v custom width=240 height=240 speed=32000000 gpios=reset:25,dc:24

The command above loads the fbtft_device module with a custom configuration based on the provided driver fb_st7789v. Notice that we didn’t have to declare the standard SPI pins but we need to reference our two custom GPIO pins from the wiring section – reset and dc.

Remember that this command just creates a framebuffer for the LCD at /dev/fb1, it doesn’t actively mirror the display. We need the fbcp program for that. I just run fbcp as a background process and voila. The LCD came to life … but it’s a little off. (Also, don’t worry, the full setup steps are at the end)

Here’s the result when I ran ‘htop’:

If you don’t know what that should look like, I can tell you that display screen is rotated 180 degrees off my desired layout (pins on the bottom), and the screen color is ‘negative’. It should be a black screen with white text.

Now I’m off to figure out how to rotate and how to invert the colors. I dug around the issues page on the wiki and found this reference:

https://github.com/notro/fbtft/issues/425

Github user tr1p1ea references an init string argument you can also pass along in the modprobe argument, which probably was setting some ST7789 specific codes I needed to set.

init=-1,0x11,-2,120,-1,0x36,0x00,-1,0x3A,0x05,-1,0xB2,0x0C,0x0C,0x00,0x33,0x33,-1,0xB7,0x35,-1,0xBB,0x1A,-1,0xC0,0x2C,-1,0xC2,0x01,-1,0xC3,0x0B,-1,0xC4,0x20,-1,0xC6,0x0F,-1,0xD0,0xA4,0xA1,-1,0x21,-1,0xE0,0x00,0x19,0x1E,0x0A,0x09,0x15,0x3D,0x44,0x51,0x12,0x03,0x00,0x3F,0x3F,-1,0xE1,0x00,0x18,0x1E,0x0A,0x09,0x25,0x3F,0x43,0x52,0x33,0x03,0x00,0x3F,0x3F,-1,0x29,-3

What is all this crap? These are initialization parameters you can send directly to your LCD driver chipset. Notro’s page has some information there, but understanding the specifics for your LCD require the datasheet. Nevertheless, I tried it out and we got farther…

The fbtft_device page on the wiki references other parameters – one of them being rotate:

rotate
Angle to rotate display counter clockwise: 0, 90, 180, 270 

Okay, so we rotate with our updated command – I figured 180 degrees to start.

sudo modprobe --first-time fbtft_device name=fb_st7789v custom width=240 height=240 speed=32000000 rotate=180 gpios=reset:25,dc:24 init=-1,0x11,-2,120,-1,0x36,0x00,-1,0x3A,0x05,-1,0xB2,0x0C,0x0C,0x00,0x33,0x33,-1,0xB7,0x35,-1,0xBB,0x1A,-1,0xC0,0x2C,-1,0xC2,0x01,-1,0xC3,0x0B,-1,0xC4,0x20,-1,0xC6,0x0F,-1,0xD0,0xA4,0xA1,-1,0x21,-1,0xE0,0x00,0x19,0x1E,0x0A,0x09,0x15,0x3D,0x44,0x51,0x12,0x03,0x00,0x3F,0x3F,-1,0xE1,0x00,0x18,0x1E,0x0A,0x09,0x25,0x3F,0x43,0x52,0x33,0x03,0x00,0x3F,0x3F,-1,0x29,-3

Which now leaves us with something completely different – I thought I saw rotation but couldn’t tell easily – so I ran VICE and saw it fill up only part of the screen!

During my research on fbtft and fbcp, I ran across that the ST7789 driver chip supported 320×240 and 240×240 displays. So it looked like to me that my 240×240 lcd was acting as a viewport into the ‘opposite end’ of the video ram that stores the 240×240 image as configured by our modprobe command.

I had a rough idea now of what I was looking for – I need to ‘scroll’ up about 320-240 = 80 pixels. How the **** am I supposed to do this? At this point I started looking for the ST7789 data sheet so I could see if there was some ‘mode’ or related setting. After perusing this for a while, I found something quite interesting in the PDF:

At this point it looked like I wanted to add to our init string. Something with instruction 37h, with 2 parameters. I defaulted the first to zero and the second to the number of pixels I wanted to ‘scroll’. I wasn’t sure if my rotation settings ‘inverted’ the pixel count so I just started with the difference of 320-240 = 80. Of course, we’re dealing with hex, so thats 0x50. The full piece of the initialization string I inserted after the 0x36 instruction follows:

-1,0x37,0x00,0x50
-1 (break for new instruction)
0x37 Instruction for Vertical Scroll Start Address Of RAM
0x00 First Parameter  (defaulted this to 0)
0x50 Second Parameter (set this to 80 pixels, converted to hex)

So now my init string, with the extra 37h instruction added, yielded this result:

Install Instructions for Option 1 – fbtft and fbcp

So, we at least have something working. That was the entire goal of this first stage – just get the LCD mirroring the HDMI output of my Raspberry Pi with VICE. Good to go! So let’s finish off option 1 by building the list of instructions.

Since fbtft drivers are already part of Raspbian Buster, all we really need to do is download and copy fbcp, and basing the instructions off that GitHub page: https://github.com/tasanakorn/rpi-fbcp

mkdir ~/fbcp-src
cd ~/fbcp-src

git clone https://github.com/tasanakorn/rpi-fbcp.git
cd rpi-fbcp/

mkdir build
cd build
cmake ..
make

After that point, a new fbcp binary now exists in the build directory we just made.

To just test the general execution of these two, I’ll enter the commands into the shell. Afterwards I’d see the LCD activate and mirror the screen properly.

#start LCD Driver - create fb1 frame buffer
sudo modprobe --first-time fbtft_device name=fb_st7789v custom width=240 height=240 speed=32000000 rotate=180 gpios=reset:25,dc:24 init=-1,0x11,-2,120,-1,0x36,0x00,-1,0x37,0x00,0x50,-1,0x3A,0x05,-1,0xB2,0x0C,0x0C,0x00,0x33,0x33,-1,0xB7,0x35,-1,0xBB,0x1A,-1,0xC0,0x2C,-1,0xC2,0x01,-1,0xC3,0x0B,-1,0xC4,0x20,-1,0xC6,0x0F,-1,0xD0,0xA4,0xA1,-1,0x21,-1,0xE0,0x00,0x19,0x1E,0x0A,0x09,0x15,0x3D,0x44,0x51,0x12,0x03,0x00,0x3F,0x3F,-1,0xE1,0x00,0x18,0x1E,0x0A,0x09,0x25,0x3F,0x43,0x52,0x33,0x03,0x00,0x3F,0x3F,-1,0x29,-3

Then, we need to run fbcp so it can copy the framebuffer from HDMI (/dev/fb0) to the LCD (/dev/fb1) – run this from your fbcp’s build directory you created earlier:

./fbcp &

What if we want this to run on start up? There are numerous ways to do that, here’s a simple one – pop it into rc.local. We’ll cover alternate methods later in the series, this article is just about getting the LCD going.

#Copy fbcp and start it up and the fbtft drivers  (run from your fbcp build dir)
sudo cp fbcp /usr/bin 
sudo chmod +x /usr/bin/fbcp

sudo nano /etc/rc.local

Add the following lines to rc.local before ‘exit 0’. Remember the sudo modprobe is all one single line.

sudo modprobe --first-time fbtft_device name=fb_st7789v custom width=240 height=240 speed=32000000 rotate=180 gpios=reset:25,dc:24 init=-1,0x11,-2,120,-1,0x36,0x00,-1,0x37,0x00,0x50,-1,0x3A,0x05,-1,0xB2,0x0C,0x0C,0x00,0x33,0x33,-1,0xB7,0x35,-1,0xBB,0x1A,-1,0xC0,0x2C,-1,0xC2,0x01,-1,0xC3,0x0B,-1,0xC4,0x20,-1,0xC6,0x0F,-1,0xD0,0xA4,0xA1,-1,0x21,-1,0xE0,0x00,0x19,0x1E,0x0A,0x09,0x15,0x3D,0x44,0x51,0x12,0x03,0x00,0x3F,0x3F,-1,0xE1,0x00,0x18,0x1E,0x0A,0x09,0x25,0x3F,0x43,0x52,0x33,0x03,0x00,0x3F,0x3F,-1,0x29,-3

#
#Add a little sleep before starting fbcp to allow fbtft to initialize
#(your display might stay blank otherwise)
#
sleep 2

/usr/bin/fbcp &

Reboot and you should see the screen mirror after the boot process initializes some. If you don’t have your HDMI output active, VICE may not load (it doesn’t get a good hook into /dev/fb0) – so you may need to edit your /boot/config.txt and add:

hdmi_force_hotplug=1

Option 2 – fbcp-ili9341

A faster alternative to fbtft/fbcp that uses a little more CPU

I was initially happy with option 1 – I wasn’t planning on playing games using the tiny LCD, just mirror it so the diorama looked alive. However, I still perused a few other search threads and found out about this other option called fbcp-ili9341, and while the name may be confusing (it doesn’t create a framebuffer, and it’s not just for the ili9341 driver), I was able to get it working with our ST7789 1.3″ LCD display.

Why did I try it out? Turns out, SPI doesn’t have the inherent bandwidth as it stands with libtft and fbcp – and since I’m playing games, which inherently implies video as opposed to text, I noticed the refresh rate on the LCD was always a little stuttered while playing C64 games and demos. Through some optimizations and shortcuts, the author juj has created an alternative that is faster than our option 1, all the way to 60fps. Ohhhhh yeah.

So here’s the journey to making that work. A little easier, and a bit nicer payoff. This option, while using a little more CPU (Our Raspi has 4 cores, so it’s not a big deal), is fast. In fact, it says so on it’s GitHub page, so you know it’s true!

Since the name is also confusing, here’s why it’s named the way it is:

The fbcp part in the name means framebuffer copy; specifically for the ILI9341 controller. fbcp-ili9341 is not actually a framebuffer copying driver, it does not create a secondary framebuffer that it would copy bytes across to from the primary framebuffer. It is also no longer a driver only for the ILI9341 controller. A more appropriate name might be userland-raspi-spi-display-driver or something like that, but the original name stuck.

So I downloaded the source and compiled it, and there’s effectively just one execution line since this takes the place of fbtft and fbcp – in fact, you can’t run both at the same time – test with Option 1 or Option 2 separately.

The cmake command to the build takes a few options in, and I chose these as my initial settings so I could see what it would do:

-DST7789=ON 
There's built in support for our chip set, so this was a natural choice.
-DGPIO_TFT_DATA_CONTROL=24
Same as option 1 - our custom pin we chose for data control.
-DGPIO_TFT_RESET_PIN=25
Same as option 1 - our custom pin for LCD display reset.
-DSPI_BUS_CLOCK_DIVISOR=30
My sensible default based on the GitHub page - lower is more responsive but may cause screen artifacts on LCDs.

Compiling with those options successfully, I now had a fbcp-ili9341 binary to execute. Survey says…

Okay, we can fix this. Reading up on a reported issue in the project’s GitHub issues list, I found reference to a couple of items to change in the code:

define DISPLAY_OUTPUT_LANDSCAPE - If we comment this out, we'll rotate the display 90 degrees - which way though?  Let's try and find out what happens.

So we’re rotated properly, but we’re reversed. The text should be on the left. So we need to reverse the image, not just a simple rotation. Here’s the next changes I tried:

madctl ^= MADCTL_COLUMN_ADDRESS_ORDER_SWAP;  - Adding this line into another file will mirror image the display - Sold!

-DSTATISTICS=0 Remove that debug information

So, we try this change and rebuild, and we now have…

Now we’re getting there! We’re oriented in the right way, and the image reads left to right. Only thing now is to change the scaling, which is how my research led to this option:

-DDISPLAY_BREAK_ASPECT_RATIO_WHEN_SCALING=ON - I expected something like this because our display is 240 wide, so it's scaling 180 on the vertical to maintain aspect ratio.  Let's just make it fill the whole thing so we don't have the black bars of doom.

And now….

So now I’ve got both options working in the same fashion. There are differences though, and we’ll cover that in the next section below, after the ‘install instructions’

Install Instructions for Option 2 – fbcp-ili9341

Our goal is to download fbcp-ili9341, perform some quick modifications to the code, set our options, compile, and execute it.

If necessary, download the dependencies required:

sudo apt-get install cmake

Then let’s download our source code:

mkdir ~/fbcp-ili9341
cd ~/fbcp-ili9341
git clone https://github.com/juj/fbcp-ili9341.git

This creates and downloads the source to /home/pi/fbcp-ili9341/fbcp-ili9341 (Yeah, it’s a double directory, I always make my own root directories for compilation work)

Before we compile, we need to make the edits referenced in our previous section on figuring out how Option 2 was going to work.

Edit your config.h file:

nano ~/fbcp-ili9341/fbcp-ili9341/config.h

Comment out the line below (the example is already commented out)

//#define DISPLAY_OUTPUT_LANDSCAPE

Next, we’ll edit our ST7789 (actually it’s a file that handles a couple of ST-made chips) specific file to do the ‘mirroring’ swap. Edit the following:

nano ~/fbcp-ili9341/fbcp-ili9341/st7735r.cpp

and add the following line:

madctl ^= MADCTL_COLUMN_ADDRESS_ORDER_SWAP;

somewhere before this line:

SPI_TRANSFER(0x36/MADCTL: Memory Access Control/, madctl);

Optional Gamma Change: I’ve also, over time, discovered that I like the screen a little darker, primarily because I have a camera pointed at it at the Twitch stream and it causes some overexposure of the screen compared to the diorama itself. So you can make the gamma 1.0 by changing this line in the same file:

SPI_TRANSFER(0x26/Gamma Curve Select/, 0x04/Gamma curve 3 (2.5x if GS=1, 2.2x otherwise)/);

Change the 0x04 to 0x08:

SPI_TRANSFER(0x26/Gamma Curve Select/, 0x08/Gamma curve 3 (2.5x if GS=1, 2.2x otherwise)/);

That’s it for file editing, let’s get back to the compile.

cd ~/fbcp-ili9341/fbcp-ili9341
mkdir build
cd build
cmake -DST7789=ON -DGPIO_TFT_DATA_CONTROL=24 -DGPIO_TFT_RESET_PIN=25 -DSPI_BUS_CLOCK_DIVISOR=30 -DSTATISTICS=0 -DDISPLAY_BREAK_ASPECT_RATIO_WHEN_SCALING=ON ..
make -j

This will create the fbcp-ili9341 binary in the build directory. Try it out by running it and hitting CTRL-C when you’re done.

sudo ./fbcp-ili9341

If that works nicely for you, you could also make a quick hack to your /etc/rc.local file and make it boot on startup. (This is a quick hack)

#Copy fbcp-ili9341 and start it up on boot
sudo cp ./fbcp-ili9341 /usr/bin 
sudo chmod +x /usr/bin/fbcp-ili9341

sudo nano /etc/rc.local

Add the following line to rc.local before ‘exit 0’.

sudo /usr/bin/fbcp-ili9341 &

Comparing Mirroring Options

You may notice right off the bat that the default initialization of our option 1 vs option 2 have a stark difference in brightness. I didn’t investigate further in making the first option brighter, because I was just so happy with option 2 as a whole I never looked back.

Option 2, as you can see in the video segment at the beginning of this article, has a much higher frame rate as promised. While I did try two different arguments to the SPI_BUS_CLOCK_DIVISOR option (30 and 8), I really didn’t see much of a difference in my eyes. The big difference is between fbtft/fbcp being much slower than fbcp-ili9341.

What’s the trade-off? As you see in the video, there’s about a 20-40% spike in one of my Pi’s cores on FBCP-ILI9341 vs regular old FBCP. Given I’m using a beefy Raspberry Pi, I detected no issues in game play. Your mileage may vary.

So we’ve now got part of our diorama circuitry working – we successfully mirrored the Raspberry Pi HDMI output to the ST7789 driven LCD display, showing whatever we play on our VICE Commodore emulator’s HDMI output. There’s more to come, though! Remember those 1541 disk drives that Commodore computers utilized? Well, we need to make sure that the LEDs we plan on putting in those floppy drives light up according to activity in VICE. To do that, we’ll need to create a custom VICE build (we’ll be doing a small bit of C programming) so we can drive LED activity and power LEDs based on whatever VICE is doing. That will be the next article in the series, coming soon.

References and Further Reading

SPI – Serial Peripheral Interface

https://learn.sparkfun.com/tutorials/serial-peripheral-interface-spi/all
https://en.wikipedia.org/wiki/Serial_Peripheral_Interface
https://www.raspberrypi.org/documentation/hardware/raspberrypi/spi/README.md
https://learn.adafruit.com/circuitpython-on-raspberrypi-linux/spi-sensors-devices

Option 1 – FBTFT/FBCP

https://github.com/notro/fbtft

https://github.com/notro/fbtft/wiki/Development

https://github.com/torvalds/linux/blob/master/drivers/staging/fbtft/fb_st7789v.c

https://github.com/notro/fbtft/issues/425

https://www.rhydolabz.com/documents/33/ST7789.pdf

https://github.com/tasanakorn/rpi-fbcp

Option 2 – FBCP-ILI9341

https://github.com/juj/fbcp-ili9341

Raspberry Pi GPIO Information

https://www.raspberrypi.org/documentation/usage/gpio/

Adafruit

.96″ OLED Product Page (Not the display I ended up going with for resolution reasons, otherwise it’s very nice.)

1.3″ 240×240 TFT LCD Product Page (My ultimate choice for this diorama)

Tutorial/Learning Page for the 1.3″ display (wiring, python, etc.)

VICE

The Elder Scrollers Demo by Booze Design

The post Mirroring Raspberry Pi HDMI Video to a ST7789 1.3 inch LCD Display appeared first on Krystof.IO.

Step 1 – Install pmount

pmount is a wrapper around the standard mount program which permits normal users to mount removable devices without a matching /etc/fstab entry. This is how we’ll manage to auto mount our USB drives.

sudo apt install pmount

Step 2 – UDEV Rule

Udev allows for rules that specify what name is given to a device, regardless of which port it is plugged into.

sudo vi /etc/udev/rules.d/usbstick.rules

ACTION=="add", KERNEL=="sd[a-z][0-9]", TAG+="systemd", ENV{SYSTEMD_WANTS}="usbstick-handler@%k"

Step 3 – Create Systemd service

sudo vi /lib/systemd/system/usbstick-handler@.service

[Unit]
Description=Mount USB sticks
BindsTo=dev-%i.device
After=dev-%i.device

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/bin/automount %I
ExecStop=/usr/bin/pumount /dev/%I

Step 4 – Create Mount Script

sudo vi /usr/local/bin/automount

#!/bin/bash

PART=$1
FS_LABEL=`lsblk -o name,label | grep ${PART} | awk '{print $2}'`

if [ -z ${FS_LABEL} ]
then
    /usr/bin/pmount --umask 000 --noatime -w --sync /dev/${PART} /media/${PART}
else
    /usr/bin/pmount --umask 000 --noatime -w --sync /dev/${PART} /media/${FS_LABEL}_${PART}
fi

sudo chmod +x /usr/local/bin/automount

Step 5 – Should be working, but if not…

You’ll see your USB drives mounted under /media

Per the comment from James:

And rather than reboot, UDEV should automatically detect new rules[2], but if it fails to:

udevadm control –reload

If that doesn’t work… you can always try turning it off and on again 🙂

References

• pmount
• Stack Exchange Post

The post Auto mounting a USB drive in a Raspberry Pi appeared first on Krystof.IO.