Författaren har placerat en Raspberry Pi Zero, en Bluetooth-«dongel» och en kabel inuti sin nya brödskiva Handy Tech Active Star 40. Den inbyggda USB-porten tillhandahåller ström. Det blev en självständig dator utan skärm med ARM-processor som kör Linux, försedd med tangentbord och brödskiva. Den kan laddas/drivas via USB, inklusive från en powerbank eller solcellsladdare. Därför klarar den sig utan nätström i flera dagar, inte bara timmar.

Storleksmässig differentiering av brödskivor

Först och främst varierar de i radlängd. Enheter med 60 tecken eller fler är bra vid användning med en stationär dator, medan de med 40 tecken är bekväma att bära tillsammans med en bärbar dator. Idag finns det även brödskivor som kan anslutas till smartphones och surfplattor, med radlängd på 14 eller 18 tecken.

Tidigare var brödskivor ganska klumpiga. En 40-teckens brödskiva hade till exempel storlek och vikt som en 13-tums laptop. Nu, med samma antal tecken, är de tillräckligt kompakta för att kunna placeras framför en laptop, i stället för att sätta laptopen ovanpå brödskivan.

Det är förstås bättre, men det är ändå inte särskilt bekvämt att ha två separata enheter i knät. När man arbetar vid ett skrivbord finns det inga klagomål, men man får komma ihåg att en laptop också kallas en bärbar dator, och försöka rättfärdiga detta namn; det visar sig att en kompakt 40-teckens brödskiva är ännu mindre bekväm.

Så författaren väntade på utgivningen av den länge utlovade nya modellen i serien Handy Tech Star. Redan 2002 släpptes den föregående modellen Handy Tech Braille Star 40, där det fanns tillräckligt med yta för att kunna sätta en laptop ovanpå. Och om den inte får plats – finns det en utdragbar stativ. Denna modell har nu ersatts av Active Star 40, som är i stort sett densamma men med uppdaterad elektronik.

Och den utdragbara stativet finns kvar:

Men det mest bekväma i nyheten är Fördjupningen som har ungefär samma storlek som en smartphone (se KDPV). Den öppnas genom att flytta plattformen bakåt. Det visade sig vara obekvämt att hålla en smartphone där, men man måste ju på något sätt använda det tomma utrymmet, där det till och med finns en strömutgång.

Det första som författaren kom på var att placera en Raspberry Pi där, men när skärmen köptes visade det sig att stativet som täcker facket inte passar med "hallonen". Om bara kortet hade varit 3 mm tunnare...

Men en kollega berättade om Raspberry Pi Zero, som visade sig vara så kompakt att det skulle rymmas två... eller kanske till och med tre i facket. Den beställdes omedelbart tillsammans med ett 64 GB minneskort, Bluetooth, en "dongel" och en Micro USB-kabel. Några dagar senare kom allt detta, och synsättande vänner hjälpte författaren att förbereda kortet. Allt fungerade genast bra.

Vad som gjordes för detta

På baksidan av Handy Tech Active Star 40 finns det två USB-portar för enheter som tangentbord. Ett kompakt tangentbord med magnetfäste medföljer. När tangentbordet är inkopplat och skärmen fungerar via Bluetooth, identifierar datorn det dessutom som ett Bluetooth-tangentbord.

Så om man kopplar en Bluetooth-"dongel" till Raspberry Pi Zero, som placerats i facket för smartphones, kan det utbyta data med punktskärmen via Bluetooth med hjälp av BRLTTY, och om man dessutom kopplar tangentbordet till skärmen kommer "hallonen" även att fungera med det.

Men det är inte allt. Själva "hallonen" kan också få tillgång till internet via Bluetooth PAN från vilken enhet som helst som stöder det. Författaren har ställt in sin smartphone och datorer hemma och på jobbet på det sättet, men planerar att anpassa en annan "hallon" — den klassiska, inte Zero, för att koppla till Ethernet och en annan Bluetooth-"dongel".

BlueZ 5 och PAN

Sättet att konfigurera PAN med hjälp av BlueZ visade sig vara otydligt. Författaren hittade ett Python-skript bt-pan (se nedan), som gör det möjligt att konfigurera PAN utan GUI.

Med det kan man konfigurera både server och klient. När det får motsvarande kommando via D-Bus i klientläge skapar det en ny nätverksenhet bnep0 så snart den ansluter till servern. Vanligtvis används DHCP för att tilldela en IP-adress till det här gränssnittet. I serverläge kräver BlueZ att en bryggenhet anges, till vilken den kan lägga till varje ansluten enhet för att koppla upp sig till varje klient. Att konfigurera adressen för bryge-enheten och starta DHCP-server samt IP-masquerading på bryggan är vanligtvis allt som krävs.

Bluetooth PAN Access Point med Systemd

För att konfigurera bron använde författaren systemd-networkd:

Fil /etc/systemd/network/pan.netdev

[NetDev]
Name=pan
Kind=bridge
ForwardDelaySec=0

Fil /etc/systemd/network/pan.network

[Match]
Name=pan

[Network]
Address=0.0.0.0/24
DHCPServer=yes
IPMasquerade=yes

Nu måste vi få BlueZ att konfigurera NAP-profilen. Det visade sig att det inte går med de standardverktyg som tillhandahålls av BlueZ 5.36. Om författaren har fel, rätta honom: mlang (kan röra öronen) blind (kan ha tillgång och kvant) guru

Men han fann ett blogginlägg och ett Python-skript för att göra de nödvändiga anropen till D-Bus.

För bekvämlighetens skull använde författaren en Systemd-tjänst för att köra skriptet och kontrollera beroenden.

Fil /etc/systemd/system/pan.service

[Unit]
Description=Bluetooth Personal Area Network
After=bluetooth.service systemd-networkd.service
Requires=systemd-networkd.service
PartOf=bluetooth.service

[Service]
Type=notify
ExecStart=/usr/local/sbin/pan

[Install]
WantedBy=bluetooth.target

Fil /usr/local/sbin/pan

#!/bin/sh
# Ugly hack to work around #787480
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

exec /usr/local/sbin/bt-pan --systemd --debug server pan

Den andra filen skulle inte behövas om Debian hade stöd för IPMasquerade= (se. #787480).

Efter att ha kört kommandona systemctl daemon-reload och systemctl restart systemd-networkd kan Bluetooth PAN startas med kommandot systemctl start pan

Bluetooth PAN-klient med Systemd

Klientdelen är också enkel att konfigurera med hjälp av Systemd.

Fil /etc/systemd/network/pan-client.network

[Match]
Name=bnep*

[Network]
DHCP=yes

Fil /etc/systemd/system/pan@.service

[Unit]
Description=Bluetooth Personal Area Network-klient

[Service]
Type=notify
ExecStart=/usr/local/sbin/bt-pan --debug --systemd client %I --wait

Nu, efter att konfigurationen har startats om kan du ansluta till den angivna Bluetooth-åtkomstpunkten så här:

systemctl start pan@00:11:22:33:44:55

Parning via kommandoraden

Naturligtvis måste server- och klientkonfigurationerna göras efter att de har parats via Bluetooth. På servern måste du köra bluetoothctl och ge den kommandon:

power on
agent on
default-agent
scan on
scan off
pair XX:XX:XX:XX:XX:XX
trust XX:XX:XX:XX:XX:XX

När du har startat skanningen, vänta några sekunder tills den enhet du vill ha visas i listan. Notera dess adress och använd den när du ger kommandot pair, och om nödvändigt — kommandot trust.

Från klientens sida behöver du också göra samma sak, men kommandot trust behövs definitivt inte. Servern behöver det för att acceptera anslutningen via NAP-profilen utan manuell bekräftelse från användaren.

Författaren är osäker på om detta är den optimala sekvensen av kommandon. Kanske är det allt som behövs - att para klienten med servern och utföra kommandot trust på servern, men så har han inte försökt göra än.

Tillstånd för att använda Bluetooth-profilen HID

Det krävs att "hallonet" känner igen tangentbordet som är anslutet till den taktila displayen via kabel och som redan överförs av själva displayen via Bluetooth. Det görs på samma sätt, bara istället för agent on måste du ge kommandot agent KeyboardOnly och bluetoothctl hittar enheten med HID-profil.

Men att konfigurera Bluetooth via kommandoraden är ganska krångligt.

Även om författaren lyckades konfigurera allt, inser han att det är obekvämt att ställa in BlueZ via kommandoraden. Först trodde han att agenter bara behövdes för att ange PIN-koder, men det visade sig till exempel att för att aktivera HID-profilen måste man skriva "agent KeyboardOnly". Det är förvånande att för att aktivera Bluetooth PAN måste man leta genom repositories efter rätt skript. Han minns att det i den tidigare versionen av BlueZ fanns ett färdigt verktyg pand — vart tog det vägen i BlueZ 5? Kanske finns det en ny lösning som författaren inte känner till, men som är alldeles uppenbar?

Performance

Dataöverföringshastigheten var ungefär 120 kbit/s, vilket är fullt tillräckligt. En 1 GHz ARM-processor är mycket snabb för kommandoradsgränssnittet. Författaren planerar fortfarande att använda enheten främst för ssh och emacs.

Konsoltypsnitt och skärmupplösning

Upplösningen på skärmen som används av framebuffer på Raspberry Pi Zero som standard är ganska konstig: fbset rapporterar att den är 656×416 pixlar (monitor, förstås, är inte ansluten). Med ett konsoltypsnitt på 8×16 fick man 82 tecken per rad och 26 rader.

Att arbeta med en taktil display med 40 tecken på detta sätt är obekvämt. Författaren skulle också vilja att Unicode-tecken visas på displayen i taktil form. Lyckligtvis stöder Linux 512 tecken, och de flesta konsoltypsnitt har 256. Genom att använda console-setup kan man använda två 256-teckens typsnitt samtidigt. Författaren har lagt till följande rader i filen /etc/default/console-setup:

SCREEN_WIDTH=80
SCREEN_HEIGHT=25
FONT="Lat15-Terminus16.psf.gz brl-16x8.psf"

Obs: för att typsnittet brl-16×8.psf ska bli tillgängligt måste console-braille installeras.

Vad händer härnäst?

Braille-skärmen har en 3,5 mm "jack", men författaren känner inte till adaptrar för att ta ljudsignalen från Mini-HDMI. Författaren lyckades inte aktivera ljudkortet inbyggt i "Raspberry Pi" (konstigt, översättaren var säker på att Zero inte har ett sådant, men det finns sätt att få ut ljud via PWM på GPIO). Han planerar att använda en USB-OTG-hubb och ansluta ett externt kort för att få ljudet att spelas genom den inbyggda högtalaren i braille-skärmen. Två externa kort fungerade av någon anledning inte, och just nu letar han efter en liknande enhet med en annan chipset.

Det är också otympligt att manuellt stänga av "Raspberry Pi", vänta några sekunder och stänga av braille-skärmen. Det beror på att den vid avstängning tar bort strömmen från kontakten i facket. Författaren planerar att sätta in ett litet buffertbatteri i facket och via GPIO informera "Raspberry Pi" om att skärmen har stängts av, så att den kan börja stänga ner. Så en slags UPS i miniatyr.

Systemavbildning

Om du har en likadan braille-skärm och vill göra samma sak, är författaren beredd att tillhandahålla en färdig systemavbildning (baserad på Raspbian Stretch). Skriv till honom om detta på adressen ovan. Om tillräckligt många personer är intresserade, kan det till och med bli aktuellt att släppa kit som innehåller allt som behövs för en sådan ombyggnad.

Tack.

Tack till Dave Mielke för att korrekturläsa texten.

Tack till Simon Kainz för fotoillustrationerna.

Tack till kollegorna vid Graz tekniska universitet för att snabbt introducera författaren till världen av Raspberry Pi.

P.S. Första tweeten från författaren om detta ämne (öppnas inte — översättaren) gjordes bara fem dagar innan publiceringen av originalartikeln, och man kan säga att, med undantag för ljudproblemet, så är uppgiften i stort sett löst. För övrigt redigerade författaren den slutliga versionen av texten efter att han anslutit den egenproducerade "självständiga braille-skärmen" via SSH till sin hemmadator.

Källa: habr.com