This article is still a Draft, it's just temporarily published for personal convenience
Foreword : This article is a log of the process I followed to develop a simple compass app for Manjaro Plasma Mobile on the Pinephone (the app in itself should be compatible with more systems and devices but this is my primary target and test device incidentally). It should be considered as such and certainly not as a tutorial to develop a new app. Further disclaimer, I am not even a developer, I am just an electrical engineer playing with Linux and software, my knowledge is really lacking and I'm sure several steps are unnecessary and/or plain wrong
In the last article, we established that the magnetometer is part of the device tree, that it's properly recognised by the linux kernel and made accessible in the userspace as an IIO device.
May not be working properly though... pb with readdevice;..
Improving the internal working
readdev not working ...
pb with buffer
due o a problem with triggers
pb with interrupt
device tree setup or hardware impossibility ??
=>> trmporary solution http://analogdevicesinc.github.io/libiio/master/libiio/group__Channel.html
using the channel API !!
waiting for D-Bus anyway, not spend too much time in thus !
Foreword : This article is a log of the process I followed to develop a simple compass app for Manjaro Plasma Mobile on the Pinephone (the app in itself should be compatible with more systems and devices but this is my primary target and test device incidentally). It should be considered as such and certainly not as a tutorial to develop a new app. Further disclaimer, I am not even a developer, I am just an electrical engineer playing with Linux and software, my knowledge is really lacking and I'm sure several steps are unnecessary and/or plain wrong
Genesis of the project
I was looking for a small project to put me back on track with my Braveheart smartphone since I haven't been playing much with it since the last article. On the plasma-mobile "random project assignor" I got this.
The linked problem to solve is this one
Seems like a perfect project, simple enough, small so that it doesn't takes up a ton of time, with a useful and concrete result. I'm sold !
STmicroelectronics LIS3MDL ultra-low-power three-axis magnetometer, LGA-12 2.0x2.0x1.0 mm [datasheet]
Note: The LIS3MDL is currently unavailable, so it has been replaced in the PinePhone Beta Edition with the Voltafield AF8133L e-Compass, which is unlisted on the Voltafield web site, but the AF8133J is listed. Presumably U1200 will be unpopulated and U1203 will be populated in the Beta Edition, since they appear to be alternatives.
And :
U1203:
Asahi Kasei Microdevices (AKM) AK09911 3-axis electronic compass IC with Hall sensor, 8-pin WL-CSP (BGA), 1.2×1.2×0.5 mm
or
Voltafield Technology Corp. (VTC) AF8133J 3-axis electronic compass with proprietary anisotropic magneto resistive (AMR) technology, 8-pin WLCSP 1.2x1.2x0.5 mm
Note: These parts appear to be alternatives to be used if the LIS3MDL is unavailable, so U1203 was probably unpopulated in BraveHeart and the Community Editions, but will be populated in the Beta Edition.
It's a little bit more complicated but given that I have the BraveHeart edition I apparently have a LIS3MDL
Eventually, I suppose the default Plasma-mobile (let's dream :)) compass application (Kompass obviously :)) will have to support every Pinephone configuration (and every supported smartphone). I'm not sure about how an application is supposed to handle that but I have the feeling that if the magnetometer is correctly managed by the kernel as a device, it should be exposed in a generic way in the user space...
I started to poke around a little bit and found this ST driver for ST mems (what about the other brands ??) following a link from this thread.
Also this random repo, not sure what it does.
After flashing a fresh Manjaro Plasma-mobile on my Pinephone, i tried :
[sylvain@plasma-mobile /]$ sudo find . -name "*lis3mdl*"
[sudo] password for sylvain:
find: ‘./proc/28998’: No such file or directory
./sys/firmware/devicetree/base/__symbols__/lis3mdl
[sylvain@plasma-mobile /]$
This is great news ! Apparently, the magnetometer is in the device tree !
And it's connected on an I2C bus ! (From the datasheet it could also have been SPI)
This means if I'm not mistaken that the device is mapped in memory at the address 0x1c2b000.
So I tried :
[sylvain@plasma-mobile /]$ sudo hexdump -C --skip 0x1c2b000 /dev/mem | head
hexdump: /dev/mem: Bad address
01c2b000
Without success...
Same happens for the following addresses.
According to this, it's apparently normal :
You should also notice that there is no ranges property in the i2c@1,0 node. The reason for this is that unlike the external bus, devices on the i2c bus are not memory mapped on the CPU's address domain. Instead, the CPU indirectly accesses the rtc@58 device via the i2c@1,0 device. The lack of a ranges property means that a device cannot be directly accessed by any device other than it's parent.
So let's install some tools to play with I2C devices. With
[sylvain@plasma-mobile /]$ pacman -Syu i2c-tools
Now we can scan the I2C bus to fincd which devices are connected:
[sylvain@plasma-mobile /]$ sudo i2cdetect 0
[sudo] password for sylvain:
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0.
I will probe address range 0x08-0x77.
Continue? [Y/n] Y
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: 30 31 32 33 34 35 36 -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 52 -- 54 55 -- 57 58 59 5a 5b 5c 5d -- 5f
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
[sylvain@plasma-mobile /]$ sudo i2cdetect 1
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1.
I will probe address range 0x08-0x77.
Continue? [Y/n] Y
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- UU -- -- -- UU -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- UU -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
[sylvain@plasma-mobile /]$ sudo i2cdetect 2
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-2.
I will probe address range 0x08-0x77.
Continue? [Y/n] Y
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- UU --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
[sylvain@plasma-mobile /]$ sudo i2cdetect 3
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-3.
I will probe address range 0x08-0x77.
Continue? [Y/n] Y
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
[sylvain@plasma-mobile /]$ sudo i2cdetect 4
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-4.
I will probe address range 0x08-0x77.
Continue? [Y/n] Y
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
[sylvain@plasma-mobile /]$ sudo i2cdetect 5
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-5.
I will probe address range 0x08-0x77.
Continue? [Y/n] Y
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- UU --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
For all the I2C bus (apparently five of them) there are 11 devices managed by a driver and 20 connected devices but not managed by a driver according to this excerpt from there
"--". The address was probed but no chip answered.
"UU". Probing was skipped, because this address is currently in use by a driver. This strongly suggests that there is a chip at this address.
An address number in hexadecimal, e.g. "2d" or "4e". A chip was found at this address.
The default addresses for the lis3mdl (according to the datasheet) are marked as "UU" which means there's probably a driver already loaded for the magnetometer.
Let's try to find which kernel modules are loaded to see if some of them can be identified to a magnetometer driver :
We have st_magn_spi and st_magn (for I2C), this sound promising !
A little bit more research leads to libiio which is a library for interfacing with Linux IIO (Industrial Input Output) devices from Analog Devices.
It's actually installed on my Manjaro image and seems to be used to interface with the magnetometer.
The first iio command to see which sensors are managed by the lib already contains tons of information :
The Linux ecosystem for smartphone is still a little bit confusing for me at the minute so I decided to start small before trying to make actual contributions to the core system or useful apps by just making a dummy example app.
I've decided to go with kirigami for building the app as it seems to me to be the best compromise at the moment. Kirigami is the KDE solution to make apps work on both desktop and phones. The apps are using Qt widgets and depending on the platform, alternate versions of the widget and layout are used. As it's developed by KDE it should integrate well with Plama on Postmarketos but it should also works on Ubuntu Touch (and even Android, Windows and Mac).
However, kirigami is still a rather new technology and there is few documentation on it. I also had some difficulties on getting all the kde5 dependencies installed on the pinephone using apk because of some issues with the latest mesa driver. This will probably be fixed soon but in the meantime, i used flatpak to get all the required dependencies on both my computer and the Pinephone and i think it actually proved easier and more versatile than building directly into the pmbootstrap chroot.
Here are the websites i relied on for documentation:
Part I : Compiling the hellokirigami example app
The idea is to code the app on the computer, cross-build it with flatpak for the pinephone, send it on the pinephone and install there.
First, we need to install flatpak on the development computer, most likely.
apt install flatpak
Then we need to add those two remotes to flatpak (flathub because it's generally useful for software and kde for the Qt5 libraries)
We also need to install flatpak those same libraries but for the phone architecture. Now, most tutorials for kirigamiu are installing the arm architecture version for mobile plateform but uname -m returns aarch64 on the pinephone so we need the aarch64 version.
The application should appear on the launcher. Otherwise, it should be possible to launch it with :
flatpak run org.kde.hellokirigami
Then, to develop, it's just going to be iterations of :
Building on the computer for the phone, bundling into a flatpak package, sending to the phone, installing, ... iterate!
This is, i hope, the first of a serie of Pinephone articles summing up for myself and others what i'm learning on the Pinephone, Linux on a smartphone and contributing to the different OSs in order to turn this phone into the perfect daily driver.
I'll be learning as i write so i don't expect these articles to always represent the best or the most elegant solution but i intend them to help me figure out exactly what was needed in the middle of all i tried and maybe it can help shorten the learning path for others. Right now only 3000 "Braveheart" Pinephones have been selled and i can assume most of them are in far more knowledgeable hand than mine but come April, the software should be in a better place and Pine64 will surely sella new batch to less linux-able people and this guide might just come handy.
Je suis en ce moment en train de travailler sur un petit projet de régulateur PID universel avec une carte Arduino. Je souhaite pouvoir contrôler mon régulateur via une interface "user-friendly" sur un écran tactile. La carte Arduino n'étant pas vraiment à la base taillé pour l'affichage graphique, il n'existe pas de bibliothèque simple d'utilisation pour ce genre d'usage. J'en ai donc rédigé une. ;-)
Elle n'est clairement pas encore terminé mais si j’attends que ce soit parfait pour la mettre en ligne ..., bref, voila le code !
En l'état actuel elle peut déjà rendre des service et elle convient parfaitement à l'usage que j'en ai (ce qui explique que je ne soit pas chaud bouillant pour la perfectionner ;-)).
**
/!\ Disclaimer : C'est un travail en cours faut pas espérer que tout marche parfaitement du premier coup.
Il y a deux gros points noirs à améliorer :
tester la librairie avec un autre type d'interface que celle que j'utilise dans mon programme (3 onglets, un clavier sur le premier et des boutons sur les autres). J'ai écrit la libraire en tentant de généraliser le code de l'interface mais avec comme objectif principal de réaliser d'abord mon interface.
uniformiser les appels de fonctions. Cette librairie à été écrite au fil de l'eau au fur et a mesurer que le besoin s'en faisait sentir et l'ordre des paramètres ne suis pas de vrai logique
**
Utilisation de la librairie
Je mettrai une doc fonction par fonction sur mon wiki mais voici le principe d'après lequel je suis parti pour la librairie.
L'interface est tout d'abord divisé en onglets. Ca marche très bien avec 3 mais ca devrait marcher avec n'importe quel nombre. Chaque onglet possède un titre et une zone cliquable en haut de l'écran.
On peut ajouter du texte et des boutons sur chaque onglet. Les boutons renvoient au main leur numéros ce qui permet de savoir quel bouton à été cliqué.
On peut associer une fonction aux boutons pour qu'elle soit exécutée lorsque l'ont clique sur le bouton. Il faut fournir un pointeur vers cette fonction au constructeur du bouton. Cela permet de réaliser des claviers.
On peut modifier le texte écrit sur les onglet si l'ont a stocké le numéros renvoyé lors de sa création dans une variable.
