DEV Community: Paul

I²C on the Pinephone

Paul — Wed, 05 May 2021 04:40:03 +0000

Overview

The Pinephone is an open source smartphone that runs Linux. It's a really neat device and will hopefully be suitable as a daily driver smartphone in the near future, but for now it's very pleasant to hack on. Short surface level overview of the device here.

The below example is a little contrived, but hopefully sheds some light on connecting external peripherals to the Pinephone. I'm also fairly new to embedded stuff, D-bus, and still shaky on my Rust knowledge, so critique on a better way to implement all this is very welcome.

I²C

I²C is a common method for interfacing with embedded peripherals. It's a fairly simple communication method. For a deeper dive checkout out the Embedded Rust Discovery Book.

Embedded rust

In order to understand how the driver works we need to understand a little bit about the embedded rust ecosystem. embedded-hal is a set of traits which can be used to create platform-agnostic drivers. The SSD1306 targets embedded-hal, so any hal that implements the embedded-hal traits will be able to use the driver. In order to use SSD1306 driver on our Pinephone we'll take advantage of the linux-embeddedhal crate.

I2c on the pinephone

Accessing the pogo pins

You'll need some way to connect your device to the Pinephone. The easiest method is to just purchase a breakout board. But, there are other ways to access these pins. I used the breakout board from this repo and ordered them from OSH Park. There is some soldering required.

Connect the display

Connecting the display is pretty straightforward.

One you've connected your breakout you just need to match up the pins (GND VCC SCL SDA) to the display.

I²C on Linux

🚨 You may need to enable the proper kernel driver. I'm using Arch Linux on my pinephone, which appears to have the I²C kernel module already enabled.

Make sure you have have the i2cdetect utility installed. On arch linux the utility is in the i2c-tools package. With that tool installed run i2cdetect -l to print out all the i2c devices:

i2c-3   unknown         mv64xxx_i2c adapter                     N/A
i2c-1   unknown         mv64xxx_i2c adapter                     N/A
i2c-4   unknown         i2c-csi                                 N/A
i2c-2   unknown         mv64xxx_i2c adapter                     N/A
i2c-0   unknown         DesignWare HDMI                         N/A
i2c-5   unknown         i2c-2-mux (chan_id 0)                   N/A

Each I²C device will have an address we use to interface with it. The SSD1306 by default has an address of 3C. In order to figure out which I²C device we need to communicate with, we can probe each of the interfaces. Here is my output after probing device 3

$ i2cdetect 3
 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f  
00:                         -- -- -- -- -- -- -- --    
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --    
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --    
30: -- -- -- -- -- -- -- -- -- -- -- -- 3c -- -- --    
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --    
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --    
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

/dev/i2c-3 appears to be the interface the SSD1306 display is connected to. With that knowledge we can start programming some Rust!

Rust!

Create a new Rust project. Use rustup if you don't already have it installed.

cargo new i2c-test && cd i2c-test

Modify Cargo.toml to add the dependencies we need:

# ...Omitted

[dependencies]  
ssd1306 = "0.5.2"  
linux-embedded-hal = "0.3.0"  
embedded-graphics = "0.6.2"

And then modify src/main.rs

use embedded_graphics::{  
   fonts::{Font6x8, Text},  
   pixelcolor::BinaryColor,  
   prelude::*,  
   style::TextStyleBuilder,  
};  
use ssd1306::{mode::GraphicsMode, prelude::\*, Builder, I2CDIBuilder};  
use core::fmt::Write;  
use linux_embedded_hal::I2cdev;  

fn main() {  
   let i2c = I2cdev::new("/dev/i2c-3").unwrap(); // Replace with the proper interface!
   let interface = I2CDIBuilder::new().init(i2c);  
   let mut disp: GraphicsMode<_, _> = Builder::new()  
       .size(DisplaySize128x64)  
       .connect(interface).into();  
   disp.init().unwrap();  

   let text_style = TextStyleBuilder::new(Font6x8)  
       .text_color(BinaryColor::On)  
       .build();  

   Text::new("Hello world!", Point::zero())  
       .intostyled(text_style)  
       .draw(&mut disp);  

   disp.flush().unwrap();  

}

Before we run this code let's take a step back and look at the permissions on the i2c-# devices.

$ ls -l /dev/ | grep i2c

crw-------  1 root  root    89,   0 May  4 12:09 i2c-0  
crw-------  1 root  root    89,   1 May  4 12:09 i2c-1  
crw-------  1 root  root    89,   2 May  4 12:09 i2c-2  
crw-------  1 root  root    89,   3 May  4 12:09 i2c-3  
crw-------  1 root  root    89,   4 May  4 12:09 i2c-4  
crw-------  1 root  root    89,   5 May  4 12:09 i2c-5

These devices are both owned by root and in the group root. If we try to run our rust code right now, the code will fail because our user lacks permission to read from the I²C device. A quick fix is to run:

chown $(whoami) /dev/i2c-# (replace # with the I²C # you found from the previous section).

Now we can run: cargo run and you should see the display light up with Hello world!.

📝 There isn't anything Pinephone specific about this code. You should be able to run this exact program (provided that it references the right device) on something like a raspberry pi.

Let's do something more elaborate

Wouldn't it be cool, although maybe a little unnecessary if we could display the cell signal on our new OLED screen? Let's do it!

D-bus modem manager

D-bus is a messaging middleware for communicating between multiple processes. What we're interested in is the ModemManager D-bus interface. Take a look at the modemmanager documenation to get an idea of what you can do with this interface. D-Feet is a great little app that can list all the different interfaces you can connect to and all the methods and properties they provide.

D-bus and Rust

Generating our D-bus interface

To actually interact with D-bus we'll generate the rust code necessary using dbus-codegen. This is surprisingly easy once you have all the pieces. First install the utility:

cargo install dbus-codegen

And then run the utility. My command ended up looking something like this:

dbus-codegen-rust -s -g -m None -d org.freedesktop.ModemManager1 -p /org/freedesktop/ModemManager1/Modem/0 > src/modemmanager.rs

Printing out the cell signal level

At this point your rust directory should look like this:

├── Cargo.lock  
├── Cargo.toml  
└── src  
    ├── main.rs  
    └── modemmanager.rs

First, let's update Cargo.toml with the dbus dependency

[dependencies]
dbus = "0.9.2"
# Extra deps omitted!

Now, we can get the signal level with the following code:

mod modemmanager;
//...
// Omitted extra packages!
//...
use dbus::{blocking::Connection, arg};

fn main() -> Result<(), Box<dyn std::error::Error>> {
    // Notice that we used `new_system`
    // This connects to the `system` dbus
    let conn = Connection::new_system()?;

    // Second, create a wrapper struct around the connection that makes it easy
    // to send method calls to a specific destination and path.
    let proxy = conn.with_proxy("org.freedesktop.ModemManager1", "/org/freedesktop/ModemManager1/Modem/0", Duration::from_millis(5000));

    // Import our generated interface!
    use modemmanager::OrgFreedesktopDBusProperties;

    // Use d-feet to make sure that this is the same on your system.
    // Look for the `SignalQuality` property
    let signal_quality:  Box<dyn arg::RefArg> = proxy.get("org.freedesktop.ModemManager1.Modem", "SignalQuality")?;

    // Cast the signal quality to an i64, yes this has some code smell, but we're just hacking this :)
    // in here
    let signal: i64 = signal_quality
        .as_iter()
        .unwrap()
        .next()
        .unwrap()
        .as_i64()
        .unwrap();

    // ...
    // I2C code from the previous omitted
    // ...
    Ok(())
}

What next?

Look at the methods generated by dbus-codegen. Instead of just running this method and closing we could listen for the PropertiesChanged signal to update the display. Or look at the existing embedded hal drivers and pick up some new hardware to play with. Any of the sensors listed there should work just as easily as the SSD1306 display. If you have something which doesn't have a driver in Rust yet, well writing embedded drivers in rust isn't that hard. Give it a try.

The Pinephone may still be a little rough to use as a daily driver, but it has a lot of potential and hackability. I hope more people invest in this device and we start seeing some more interesting projects.

Misc Sources

Unsubscribe from everyone 🎉

Paul — Mon, 15 Jun 2020 19:35:39 +0000

I found that I was subscribed to 50 users that I didn't remember following (No wonder I'm getting so many notifications!). I looked into the API and found that there wasn't a way to unsubscribe from everyone. No matter, we can do it from the followers list with a little javascript:

document.querySelectorAll(".follow-action-button").forEach(el => el.click())

Run that in Dashboard > following > uers via the console to unfollow everyone. Now you should have a squeaky clean feed ✨ 👍

jq + httpie = 💓

Paul — Sun, 14 Jun 2020 04:20:23 +0000

Setting up

You'll need to install:

jq
httpie

For this demo, we'll connect to the Spotify api. Create a new Spotify application here

Client credentials flow

There is a great little plugin for httpie which makes this very easy. It needed a little update. So, for now I'll link my fork.

To install just clone the repo and run sudo python setup.py install

OAuth2 flow

Spotify uses OAuth2. In order to get your access token to make requests relevant to your spotify account, you'll need to acquire an access token. I used this cli tool written in go to accomplish this. You can find that here

oauth2-cli \
  -id $CLIENT_ID \
  -secret $CLIENT_SECRET \
  -auth https://accounts.spotify.com/authorize \
  -token https://accounts.spotify.com/api/token \
  -scope "user-read-private user-read-email user-library-read"

Making some requests

Downloading artist images from a search and then opening them

First, we'll make some requests that only require the client credentials flow.

#!bin/bash
AUTH_URL="https://accounts.spotify.com/api"
BASE_URL_API="https://api.spotify.com/v1"
CLIENT_ID=$(cat client_id)
CLIENT_SECRET=$(cat client_secret)

http --print="b" --auth-type oauth2 \
              --auth $CLIENT_ID:$CLIENT_SECRET \
              --issuer-uri "$AUTH_URL/token" \
              --scope "user-read-private" \
              GET $BASE_URL_API/search q=="Sophie Hutchings" type=="artist"

You should see a big chunk of JSON as output. Couple things to note here:

CLIENT_ID=$(cat client_id): This is command substitution. There is a file in the directory I'm running this script that contains my client id.
--print="b" is telling httpie to print the body of the request only (we'll pipe the body into jq later). Other arguments to --print are:
- H: Request headers
- h Response headers
- B request body

Let's pipe this into jq and just get a list of images from each artist.

# Beginning lines omitted

## Simple search
ARTISTS=$(http --print="b" --auth-type oauth2 \
     --auth $CLIENT_ID:$CLIENT_SECRET \
     --issuer-uri "$AUTH_URL/token" \
     --scope "user-read-private" \
     GET $BASE_URL_API/search q=="Sophie Hutchings" type=="artist")

# List of artist images
echo $ARTISTS | jq '.artists.items | map(.images | map(.url)) | flatten(1)'

This chunk begins with more command substitution to store the response from before into the ARTISTS variable. The contents of the variable is piped into jq to print a flat list of all the images from the artist we searched on. Let's cover some of the jq functions we used:

The simplest filter we used is the "Object Identifier-Index" .artists.items. This simply accesses a property within a JSON object.

{
  "artists": {
    "href": "https://api.spotify.com/v1/search?query=Bad&type=artist&offset=0&limit=20",
      "items": [...] // <--- .artists.items is grabbing this array
  }
}

The items array is piped into the map function. The map function iterates over each item returning a new array of image urls. Let's look at the JSON at this point:

[
  [
    "https://i.scdn.co/image/23009960c33ef08d5973440cca17985a6c70a515",
    "https://i.scdn.co/image/8ff3e392402169f239bce72b3d80c701b75150b8",
    "https://i.scdn.co/image/624dd15f5bdcc1bae5fa47739601f3e0be62ebda",
  ],
  [
    "https://i.scdn.co/image/23009960c33ef08d5973440cca17985a6c70a515",
    "https://i.scdn.co/image/8ff3e392402169f239bce72b3d80c701b75150b8",
    "https://i.scdn.co/image/624dd15f5bdcc1bae5fa47739601f3e0be62ebda",
  ]
]

An array of arrays isn't useful for what we're doing next. So we use flatten to return a flat array of all the image URLs.

"https://i.scdn.co/image/23009960c33ef08d5973440cca17985a6c70a515",
"https://i.scdn.co/image/8ff3e392402169f239bce72b3d80c701b75150b8",
"https://i.scdn.co/image/624dd15f5bdcc1bae5fa47739601f3e0be62ebda",
"https://i.scdn.co/image/23009960c33ef08d5973440cca17985a6c70a515",
"https://i.scdn.co/image/8ff3e392402169f239bce72b3d80c701b75150b8",
"https://i.scdn.co/image/624dd15f5bdcc1bae5fa47739601f3e0be62ebda",

Nice! Now, let's try to download these and then open them.

# Previous lines omitted

IMAGE_URLS=$(echo $ARTISTS | jq -r '.artists.items | map(.images | map(.url)) | flatten(1) | @csv')

# Download and open all the images from a search on artists
echo $IMAGE_URLS | tr ',' '\n' | \
   xargs -I % sh -c 'wget % && xdg-open %' \

We modified a couple things in our jq command.

-r: raw output. In this example it omits "
@csv: Omits csv for further processing. Only works on arrays.

The csv output by jq is piped into tr. The tr command replaces , with new lines. Each line is piped into xargs. Let's dissect the xargs command:

--I: the replace-str command. The argument is the string that will be replaced by the value from standard input in the final command. So % will turn into our image url.

bash -c 'wget % && xdg-open %': Starts a new sub shell (each % is replaced by the image url)
wget: Downloads files from the web
xdg-open: Opens a file or URL in the user's preferred application

The result of running this should be a bunch of images being downloaded to your computer and then opened by whatever program is preferred by your user.

Inspecting your saved albums and printing all the tracks for each album

#!bin/bash
AUTH_URL="https://accounts.spotify.com/api"
BASE_URL_API="https://api.spotify.com/v1"
CLIENT_ID=$(cat client_id)
CLIENT_SECRET=$(cat client_secret)

# You'll have to run this first. Copy the access token to `auth_token` in the same directory as this script
# oauth2-cli \
#   -id $CLIENT_ID \
#   -secret $CLIENT_SECRET \
#   -auth https://accounts.spotify.com/authorize \
#   -token https://accounts.spotify.com/api/token \
#   -scope "user-library-read"

# Get a list of albums from your library
ALBUMS=$(http GET $BASE_URL_API/me/albums \
  Authorization:"Bearer $(cat auth_token)")

# List saved albums from your spotify profile and their artists
echo $ALBUMS | jq '.items | map({ "name": .album.name, "artists": .album.artists | map(.name)})'

# Get tracks from your albums
ALBUM_IDS=$(echo $ALBUMS | jq -r '.items | map(.album.id) | @tsv' )

## Separtes each album by a newline, for further processing and then make another request for each album to get a list of tracks
echo $ALBUM_IDS | tr ' ' '\n' | xargs -I % sh -c 'http --print="b" GET https://api.spotify.com/v1/albums/%/tracks \
  Authorization:"Bearer $(cat auth_token)" | jq ".items | map({ "name": .name, "artists": .artists | map(.name)})"'

Everything we covered in the previous section is used in here too! One difference is that we use map to return a list of objects instead.

Final thoughts

Using jq with httpie is powerful once you get the hang of using some of the linux utilities and idiosyncrasies of shell scripting. I'm still learning new stuff everyday. If you have any thoughts on how to improve this workflow, please share!

Making your Vim easier to follow 👀

Paul — Sat, 14 Mar 2020 22:10:50 +0000

By default Vim is hard to follow for people other than the person driving. When pair programming or doing code review, the ability to follow along with the person editing is obviously super important. My coworkers get visibly exhausted when we view code on my machine. As much as I'd like to think it's because I'm incredibly fast with Vim (I am pretty fast 🔥), it's more likely due to the fact that terminal Vim is just a little hard to keep up with for a few reasons.

Scrolling happens instantly, there is no smooth animation.
The cursor tends to jump around wildly if you're watching a seasoned Vim user.
Jumps between splits, buffers, tabs, etc. are hard to follow

A minimalistic GUI: Neovide

Neovide is a very simplistic Gui around Neovim (the Vim fork with among many improvements, an emphasis on being embeddable). It adds a few nice features, but the killer one for me is the animated cursor:

This solves so many pain points when anyone is watching a Vim user. It animates your cursor between every motion. Navigating between splits, buffers, the quickfix window, etc.

And for bonus fun you can add particle effects.

May hamper some of your usual workflows:

📓 By default <CR> V is not bound to paste to paste in Neovide. Instead, you can paste from the + (clipboard) register: ["+]p, or in insert mode: [<cr>r]+.

Smooth scrolling

Smooth scrolling is a lot easier on the eyes and makes it a lot less disorienting for your viewers when you're navigating a large file. Smooth scrolling has been discussed in the Neovide issues , but isn't added yet. Instead, it is possible to get a nice smooth scrolling experience via a Vim plugin. This works in terminal Vim too: Vim Smoothie.

These small changes can really improve the editing experience for yourself and for those following along. Happy Vimming!

Covid 19 Updates from Vim, with Python!

Paul — Fri, 13 Mar 2020 23:54:44 +0000

This was just a fun (and morbid) way to experiment with hacking on vim with Python.

If you have Vim compiled with Python and the Airline plugin installed, you should be able to just plop this into your vimrc:

💡 There is an updated version that works asynchronously below.

function! CovidUpdate()
python3 << EOF
from urllib import request
import json
import vim
def getCases():
  country = "US"
  res = request.urlopen("https://covid2019-api.herokuapp.com/country/%s" % country)
  string = res.read().decode()
  info = json.loads(string)[country]
  vim.vars["response"] = "Country: %s | Confimred:  %i | Deaths: %i | Recovered: %i " %  (country, info["confirmed"],  info["deaths"], info["recovered"])
getCases()
EOF

endfunction

call CovidUpdate()


" call airline#parts#define_function('foo', "CovidUpdate")
let g:airline_section_y = airline#section#create_right(['ffenc', response])

Thanks to this project for providing the API.

🚨 UPDATE 🚨

Threading a bit of python via the vim module is actually really easy!

Updated version:

function! CovidUpdate()
python3 << EOF
from urllib import request
import threading
import json
import vim
def getCases():
  country = "US"
  res = request.urlopen("https://covid2019-api.herokuapp.com/country/%s" % country)
  string = res.read().decode()
  info = json.loads(string)[country]
  vim.vars["airline_section_y"] = "Country: %s | Confimred:  %i | Deaths: %i | Recovered: %i " %  (country, info["confirmed"],  info["deaths"], info["recovered"])
vim.async_call(getCases)
EOF

endfunction

call CovidUpdate()

Note, the last line in the previous section:
let g:airline_section_y = airline#section#create_right(['ffenc', response])
is no longer necessary since that variable is set in the Python code. 🧠