microgeek.eu

Tytułowe `NAS z e-Radio` to eksperymentalna konstrukcja-ulepek (z nazwą włącznie, dla Małolaty respekcik), w zamyśle mająca jednak (co u mnie rzadkie) głębsze walory użytkowe. Inicjatywa wykluła się w sumie przypadkiem, podczas rodzinnego porządkowania starych pudeł. Znalazło się nieuruchamiane od kilku lat Raspberry PI, jedna z pierwszych wersji. Znalazła się stara obudowa (zwłoki) timera Polmet do antracytowego zestawu Diory, przywleczone z Wolumenu jakiś czas temu. Potrzeba magazynku na pliki (głównie mp3) to odkopana paczka płytek CD z nutami typu 'Домашняя коллекция музыки', bywalcy Wolumenu zapewne kojarzą pomarańczowe okładki... O pierdyliardzie zdjęć i filmików różnej maści już nie wspominam, no - sporo tego po starych gwizdkach usb i kartach sd, szkoda skasować, ponieważ to urozmaicenie przednie wszelkich naszych domówek, a trzymać na stacjonarnym komputerze już nie ma gdzie, po prostu.

I tym sposobem aktualnie powstaje hybryda, która:

* ma być odtwarzaczem mp3 i radia internetowego
- sterowanie pilotem od Tosca PA-506
- sterowanie guzikami na obudowie
- sterowanie ze smartfona (wifi)
- sterowanie z dużego komputera (wifi)
- wyświetlacz co i jak na przedzie, chyba raczej LCD

* ma pełnić rolę prostego NAS do zastosowań raczej zabawowych
- dostęp w sieci domowej zarówno dla Linuksów jak i Windows
- dysek (może dwa) SSD (via USB) (muzyka, zdjęcia/filmy), pierwsze testy na pendrive 64GB

* ma zutylizować stare Raspberry PI wersja B, sieć przewodowa

* ma zagospodarować obudowę Timera do zestawu Diora (urządzenie jest nienaprawialne, zostaje dawcą pudełka) przy minimalnej ilości pracy pilniczkiem i wiertarką

* urządzonko dedykowane do pracy ciągłej, gdy nie gra jest (jednak) zegarkiem

Wyjście audio póki co z wbudowanego Jack-a stereo, jak się całość sprawdzi to może zainwestujemy w jakąś kartę muzyczną USB. Wyświetlacz LCD jest sprawą otwartą, może uda się zdobyć pasujący do okienka moduł VFD lub wykoncypować inne fajne rozwiązanie. Zasilanie, spróbuje wykorzystać to truchełko zasilacza, które jest w obudowie (zapewne jakaś przetwornica step-down się przyda), alternatywnie mocniejsza ładowarka do telefonu wrzucona do środka. Wszystko może i wszysto - jakoś to będzie.

Oprogramowanie (aktualnie już działający draft)
* główna aplikacja w Python (+RPLCD +WiringPI), ubrana w serwis systemowy
* zdalne sterowanie - LIRC, nauczone kodów pilota PA-506
* odtwarzacz - mpd (Music Player Daemon), lokalnie dostawiony MP Client
* zabawowy NAS - oczywiście Samba

Klient na PC - okienkowa Cantata

Klient na smartfona - MALP i/lub MPDroid

No, to w skrócie tyle chciejstw, a nie bazgrałabym tego, gdyby nie mocny progres w pracach naszych i już działający (grający) prototyp. Na dniach przechodzimy do fazy upychania klamotów w obudowie, ową pierwej trzeba uzdatnić i tu się jak zakładam nieco zejdzie.

Garść zdjęć (do wczoraj włącznie) w załączniku - wyświetlacz jest tymczasowy, będzie mniejszy, 2x20, na dużym na zdjęciach gra raz mp3, a raz radio, klawiatura ilością guzików już dostosowana do możliwości pudełka Polmetu.

#slowanawiatr

Ciekawie się zapowiada

wojtek pisze:Ciekawie się zapowiada

No dziękuje, ale jak głosi staropogańskie świętokrzyskie przysłowie - nie chwal skóry na niedźwiedziu przed zachodem słońca. A póki zapału starcza, to walczę z tym złomkiem, fotoplastikon poniżej, zdjęcia w miarę opisane.

Tak w skrócie - pudełḱo rozmontowane, odkurzone, na zadku rozwiercone dwa otworki pod gniazda RCA, wiertło Φ 8mm było jak znalazł. No wiem, gniazda jakoś tak rozkraczone, zwyczajowo są bliżej, ale ta obudowa to jest profil gięty z blachy w takie L, trudno byłoby od zera otworek zapunktować i wywiercić, już z wierceniem był cyrk, wykorzystałam zatem te, które były.
Wstępne przymiarki co i gdzie mogłoby leżeć na Banana PI i dyskach przenośnych.
Zabieram się za plastikowy przód - szybka zabezpieczona kawałkiem materiału, bo jakby się zadrasnęła czym twardym na biurku, to bym się chyba zapłakała. Guzik opisany `outputs` dostał push-button oraz ledzik na kawałku uniwersalki, dokręcone, sprawdzone że działa.
Norma na dziś wykonana.

Popołudnie w opiłkach, ale chyba z grubszych piłowań to jest już wszystko zrobione.
W sumie obawiałam się wycinania otworka 16x12 mm pod złączkę sieciową RJ45, wielkim ułatwieniem był ten gotowy okrągły otwór od nie-wiadomo-czego. Kwadratowy średniego kalibru iglak, nieco ADHD i gotowe, gniazdo siedzi. Sprawa zadziorków na brzegach i po wierceniu pod RCA - stary, zjeżdżony stożkowy kamyk szlifierski wycyganiony od sąsiada, do takich wykończeń na wolnych obrotach jest idealny.

Dalej przymiarki z dyskami czyli wewnętrzna MaCiesz SSD ® ^** - jeden dyseczek laptopowy z szuflady i zupełna nówka, przywleczona na próbę z Media Expert po drugiej stronie ulicy, akurat takie leżały. Docelowo będą dwa SSD, ale to potem.

Celem ćwiczenia było wymyślenie, jak łatwo te dyski osadzić w obudowie, aby się nie narobić. No i z prac ogrodowych zostały nam takie kątowniczki stalowe, możliwe, że nieco toporne, ale wymiary akceptowalne no i powiercone już. I z nich właśnie można sprawić taką jakby kanapkę-stelażyk z napędami, w obudowie się mieszczą jakoś i być może uniknę skracania tych stópek szlifierką kątową (piłką do metalu to masakra, blacha jednak za gruba). Zastanawiam się cały czas jakie tam śrubki idą - póki co przymiarka jest na króciutkich M3, ale nie mogę oprzeć się wrażeniu że to jednak jest calowy gwint. Tylko że calowe, niby-pasujące, też się do końca nie wkręcają, dziwne to jest i temat śrubek zostaje otwarty.

** - kolejna nazwa autorska zastrzeżona

Do otworków polecam wiertło stopniowe, tzw choinkę. Robi gładkie krawędzie które przy okazji można zakonczyć fazką.

Zasiedlanie

No i kolejny przyrost, choć nie tak efektywny jak oczekiwałam. Panel przedni ma już mniej więcej opracowaną płytkę z przyciskami, przymiarki to masakra, wszystko na czuja, ale jakoś udało się te pięć push-buttonów wpasować. Zasiedlanie obudowy - dysk SSD jednak na słupkach dystansowych, Malina w swojej czarnej trumience - plastik przekręciłam do blachy spodu, udało się bez wiercenia nowych otworków.
Z zasilaniem wyszła popelina, to znaczy ten zewłok zasilacza oryginalnego z timera nie dał rady. Raspberry wraz z pendrive i SSD w trakcie zapisu momentami życzyło sobie ponad 800mA, średni pobór w okolicach 500-600mA, to za dużo jak na taki mały transformatorek. Szybka przeróbka na większy (12V / 1.7A) i póki co jest ok. Radiator pod LM7805 ma jakieś 55`C (mierzone termoparą), więc dramatu nie ma. Jednak myślę o zamówieniu przetwornicy.
Z przygód - "tytanowe profesjonalne wiertła" z Biedronki, taaa... koło tytanu to one leżały, tylko chyba za krótko.
Póki co zauważam, że posadzenie na tym SSD systemu plików FAT32 było chyba słabe...Samba zamula się niemiłosiernie, to do ogarnięcia w najbliższe dni.

Fajne, sam myślałem o takim "komputerku" do odtwarzania muzyki.

Jaką kartę dźwiękową będziesz stosować?, mam DAC z FiiO, tylko muszę ogarnąć jakiś SPDIF z raspi zero, albo kartę na płytę z Atomem.

Jeżeli chodzi o wyjście dźwiękowe to chwilowo korzystamy z audiofilskiego filtru RC, tego co fabrycznie na płytce Malina posiada, zaraz przed niebieskim gniazdkiem mini-jack... No, a docelowo, jak się sztuczka cała uda, to do obudowy pójdzie stara karta dźwiękowa USB, co ją Nieletnia aktualnie eksploatuje, a do laptopa pewnie zakupimy cosik nowego i szpanerskiego. A tak troszkę na poważniej - to całe ustrojstwo ma zapewniać jakby tło muzyczne, pogrywać sobie w tak zwanym międzyczasie, podczas prac i w sumie w nocy najbardziej, stąd brak wszelkich źródeł hałasu. Ale to nie jest jakiś grajek hi-fi, nawet o tym nie myślałam. Poresztą sam materiał audio to ripy z płytek CD, te to jeszcze niezłe są 192 czy niektóre 320 kbps, ale konwersje z Youtube to czasem Program I Polskiego Radia na długich. Stąd inwestycje z jakieś lepciejsze audio to raczej innym (następnym) razem.

A popołudnie dziś w sumie owocne, tak myślę.
Okablowana płytka pod guzikami po prawo obudowy, wiązka do wpięcia w Malinkę. Na kawałkach blaszek i słupkach dystansowych wycyrklowany wyświetlacz LCD, wstępnie podłączone zasilanie, aby zobaczyć jak całościowo wygląda przez okienko obudowy i jest całkiem. Kolejna sprawa to wynik refleksji nad zasilaniem LCD-ka, głównie podświetlenia, które jest wewnątrz modułu zapięte na VCC-GND a nie luzem, więc całościowo modułek nieco prądu zabiera. NO i gdzie potek do kontrastu? I tu powstał pomysł na mini płytkę - punkt dystrybucyjny +5V na tę cześć obudowy, wespół z dzielnikiem do Vo wyświetlacza. Od kostki zasilanie idzie grubszą linką, równolegle do zasilania RPI. To przy okazji odciąża główne zasilanie Maliny, jakby nie patrzeć chudym kabelkiem uciętym ze starej, przegrzanej ładowarki. Wysepka zasilająca ma dwa grzebyki GND oraz VCC, do tego dedykowane piny dla LCD, będzie do wszelkiej drobnicy wymagającej 5V. W obudowie całkiem zgrabnie się to wszystko poukładało, po okablowaniu klamotów czas na test, co to warte. No, cykora troszkę miałam, nie ukrywam, zawsze jakieś takie emocje są, choć to tylko kawałek elektroniki.

Oto program testowy na bazie szkicu z prototypu radyjka-ulepka, które do tej pory działało w tekturowej pokrywce:

lcdtest.py pisze:

Kod: Zaznacz cały

from datetime import datetime
from RPLCD import CharLCD
import RPi.GPIO as GPIO
from pathlib import Path
import subprocess
import time
import os

# pelna sciezka do mnie, to na potrzeby serwisu
def myFolder():
    return str( Path(__file__).resolve().parent )

# aktualne IP radia
def getCurrentIp():
    return subprocess.run( [ myFolder() + '/myip.sh'], stdout=subprocess.PIPE ).stdout.decode('utf-8').splitlines()[0]

#-------------------------------------------------------------------------------------

GPIO.setwarnings( False )
                                                                        # D4...D7
lcd = CharLCD( cols = 20, rows = 2, pin_rs = 26, pin_e=24, pins_data=[16, 18, 22, 7], numbering_mode=GPIO.BOARD )
ip = getCurrentIp()
lastSecond = 0
while True:   
    now = datetime.now()
    if lastSecond != now.second:
        lastSecond = now.second   
        lcd.cursor_pos = (0, 0)
        # linijka         |01234567890123456789|
        lcd.write_string( "   NAS z e-Radio    " )
        lcd.cursor_pos = (1, 0)   
        lcd.write_string( ( now.strftime("%H:%M:%S") + " "  + ip + "            " )[:20] )   


do kompletu jest mały skrypcik do wydłubywania w ludzkiej formie IP komputerka przyznanego przez router:

lcdtest.py pisze:

Kod: Zaznacz cały

#!/bin/sh
ifconfig | grep "inet " | grep "broadcast" | awk '{print $2}'


Uruchomienie to jak łatwo zgadnąć:

konsola pisze:

Kod: Zaznacz cały

python3 lcdtest.py


Oczywiście, aby zabawka zadziałała potrzeba nam bibliotek kilku, a mianowicie:

https://pypi.org/project/RPLCD/
https://pypi.org/project/RPi.GPIO/ ( to na potem, ale też ważne )

Instalacja jest dobrze opisana w artykułach, szkoda zatem strzępić dzioba, dwa słowa za to o programiku. Jak widać w testowym (jak i docelowym) programie LCD sterowany jest czterema bitami, pracuje w trybie tylko do zapisu (linia R/~W) jest zwarta na stałe do masy. To sterowanie 4-bit i na delay-ach jak wykazują moje obserwacje może powodować czasem zakłócenia w pracy modułku, LCD potrafi się rozprogramować. Mam już to obcykane i potem pokaże - dobrze jest raz na jakiś czas wykonać reinicjalizacje (co za słowo) wyświetlacza, tak aby człowiek niczego nie zauważył, a moduł się ogarnął na nowo. W końcu pudełko jest dedykowane do pracy ciągłej.

https://youtu.be/NTiuDu-B1zk

No, skoro pierwszy programik sobie działa, a pudełko stoi w kącie w roli zegarka to ja idę w bety, dobranoc.

Dzisiejsze popołudnie pod znakiem podczerwieni, czyli dorabiamy oczko IR.

Całość była wstępnie (na drutach) uruchomiona sporo wcześniej, teraz czas nadszedł na ucywilizowanie instalacji no i wpasowanie odbiornika IR w timerową obudowę. Sztuczkę wykonałam za pomocą okruszka laminatu przyciętego tak, aby dał się przykręcić do jednego z rogów wyświetlacza LCD. Z boku, ale jeszcze w ramach przezroczystego okienka jest nieco miejsca, udało się tak uplasować odbiornik, że wygląda sobie przez szybkę, ale w sumie to prawie go nie widać. Z elektroniką dość prostą to wielkiego halo nie było, podłączanie odbiornika IR do Maliny jest dobrze udokumentowane w sieci.

Teraz oprogramowanie - lirc i reszta

Zacznijmy od tego, że wyjście OUT odbiornika podczerwieni jest zapięte do pinu GPIO18 procesora Maliny, to jest wartość domyślna konfiguracji modułu jądra i jeżeli nie ma racjonalnych przesłanek do zmiany, to nie polecam tam grzebać. Fajna sztuczka jak wydobyć tę informację to podmontowanie debugfs-a i podejrzenie co jest na prawdę, a nie co nam się wydaje, że jest, czyli:

konsola pisze:

Kod: Zaznacz cały

sudo mount -t debugfs debugfs /sys/kernel/debug
sudo cat /sys/kernel/debug/gpio


I u mnie jest tak:

konsola pisze:

Kod: Zaznacz cały

gpiochip0: GPIOs 0-53, parent: platform/20200000.gpio, pinctrl-bcm2835:
 gpio-16  (                    |led0                ) out hi   
 gpio-18  (                    |ir-receiver@12      ) in  hi IRQ


Instalacja wsparcia programowego zgodnie z tutorialami, kłopoty zaczynamy jak zwykle:

konsola pisze:

Kod: Zaznacz cały

sudo apt-get install lirc liblircclient-dev


Warto zapamiętać, że w pliku /etc/lirc/hardware.conf siedzi konfiguracja sprzętowa lirc-a, w /etc/modules mają być obecny moduł jajka odpowiedzialny za komunikację IR czyli lirc_rpi (jego ustawienia pokazuje debugfs). W tle działa nam demonek lircd, który bezpośrednio komunikuje się z oczkiem. No i co z tego?

Zatem teraz jak skorzystać z dobrodziejstw tego kanału łączności. Po pierwsze trzeba nauczyć Malinę kodów naszego pilota. Może nie tyle interpretacji zer i jedynek co zakucia na pamięć sekwencji bitowych przypisanych do kolejnych, potrzebnych nam guzikow. Lirc nie obsługuje (dekoduje) jakichś konkretnych systemów np. RC5 czy coś, po prostu zapamiętuje sekwencje i je rozpoznaje gdy pojawią się z oczka IR, tyle. Ja już wcześniej miałam przygotowaną konfiguracje pod pilot PA-506, ale mam pomysł pewien i on wymaga naumienia się także klawiszy 0..9 dostępnych na pilocie, jest okazja to pokazać na żywo. Wyłączamy demona lircd aby nie zawadzał podczas nauki (sudo systemctl stop lircd) i zabieramy się za tresurę. Na filmiku poniżej widzimy jak wygląda surowa numeryczna wartość odbierana przez oczko IR po naciśnięciu klawisza na pilocie, tu Standby. Oglądnąć możemy ją programikiem mode2

konsola pisze:

Kod: Zaznacz cały

mode2 -d /dev/lirc0


Tresowanie wykonujemy za pomocą irrecord, przykładowe uruchomienie:

konsola pisze:

Kod: Zaznacz cały

irrecord --disable-namespace -d /dev/lirc0 ~/nauka1.conf


No i na żywo:

https://youtu.be/oV-4JaNEhnE

Jak już mamy zebrane liczbowe wzorce interesujących nas guzików - umieszczamy je w pliku konfiguracyjnym demona lircd, u mnie, dla Toscowego pilota PA-506 wygląda to następująco:

/etc/lirc/lircd.conf pisze:

Kod: Zaznacz cały

begin remote

  name  PA506
  bits           11
  flags SPACE_ENC|CONST_LENGTH
  eps            30
  aeps          100

  one           278  7156
  zero          278  4676
  ptrail        279
  gap          118951
  toggle_bit_mask 0x0
  frequency    38000
 
      begin codes
          SKIPPREV                 0x6A8
          SKIPNEXT                 0x4AA
          STOP                     0x6A7
          SEARCHPREV               0x4AC
          SEARCHNEXT               0x6AE
          PLAY                     0x4A5
          TITR                     0x6A1
          TAPE                     0x484
          PAUSE                    0x4A3
          STANDBY                  0x498
          BTN_0                    0x697
          BTN_1                    0x489
          BTN_2                    0x68B
          BTN_3                    0x48D
          BTN_4                    0x690
          BTN_5                    0x492
          BTN_6                    0x694
          BTN_7                    0x491
          BTN_8                    0x693
          BTN_9                    0x495
      end codes
     
end remote


Mamy zatem naumiany i skonfigurowany podczerwony demon - czas zbudować zdalne sterowanie. Do tego ja wykorzystałam programik irexec, taki jakby klient lirc-a. Tylko że w naszym radyjku on musi działać w tle i startować wraz z resztą klamotów, stąd potrzeba ubrania go w prostą usługę systemową, konfiguracja prawie z pudełka:

/etc/systemd/system/irexec.service pisze:

Kod: Zaznacz cały

[Unit]
Description=IR Remote irexec config .lircrc loaded on startup
After=lircd.service
Wants=lircd.service
[Service]
ExecStart=/usr/bin/irexec --daemon /home/pi/.lircrc
Type=forking
User=pi
Restart=always
[Install]
WantedBy=multi-user.target


Drobne udziwnienie mojego rozwiązania polega na tym, że serwis działa na koncie użytkownika pi a nie na root, a to ze względu na sposób komunikacji z resztą stada, która odbywa się via pliki sygnalizacyjne.
W pliku konfiguracyjnym lircrc są zdefiniowane akcje, które ma podjąć irexec gdy otrzyma sygnał z konkretnego klawisza. Ja na tę okazję tworzę niewielkie pliki w folderze tymczasowym, one są sprawdzane i kasowane przez główną usługę radyjka. A zatem plik lircrc (fragment, bo długi i nudny):

/etc/systemd/system/irexec.service pisze:

Kod: Zaznacz cały

begin
    prog   = irexec
    button = STOP
    config = echo "STOP" > /tmp/remote_key.txt   
end

begin
    prog   = irexec
    button = PAUSE
    config = echo "PAUSE" > /tmp/remote_key.txt   
end

begin
    prog   = irexec
    button = BTN_0
    config = echo "BTN_0" > /tmp/remote_key.txt
end

. . . . .

begin
    prog   = irexec
    button = BTN_9
    config = echo "BTN_9" > /tmp/remote_key.txt
end


No i na koniec = programik testujący działanie zdalnego sterowania, głównie dla sprawdzenia czy demonek rozkminia poprawnie wszystkie potrzebne mi guziki pilota. Oto on:

lcdtest-ir.py pisze:

Kod: Zaznacz cały

from datetime import datetime
from RPLCD import CharLCD
import RPi.GPIO as GPIO
from pathlib import Path
import subprocess
import time
import os
import socket
#-------------------------------------------------------------------------------------
# pelna sciezka do mnie, to na potrzeby serwisu
def myFolder():
    return str( Path(__file__).resolve().parent )
#-------------------------------------------------------------------------------------
# aktualne IP radia
def getCurrentIp():
    return subprocess.run( [ myFolder() + '/myip.sh'], stdout=subprocess.PIPE ).stdout.decode('utf-8').splitlines()[0]
#-------------------------------------------------------------------------------------
def checkIrButtons():
    BUTTON_TEMP_FILE = "/tmp/remote_key.txt"
    if os.path.exists( BUTTON_TEMP_FILE ) == False : return ""
    file = open( BUTTON_TEMP_FILE, "r" )
    irKeyName = file.read().strip()
    file.close()
    os.remove ( BUTTON_TEMP_FILE )
    print( "guzik: " + irKeyName )   
    return irKeyName
#-------------------------------------------------------------------------------------
GPIO.setwarnings( False )
lcd = CharLCD( cols = 20, rows = 2, pin_rs = 26, pin_e=24, pins_data=[16, 18, 22, 7], numbering_mode=GPIO.BOARD )
ip = getCurrentIp()
lastSecond = 0
lastKey = ""
while True:   
    time.sleep( 0.1 )
    currentKey = checkIrButtons()   
    if currentKey != "":
       lastKey = currentKey
    now = datetime.now()   
    if lastSecond != now.second:
        lastSecond = now.second   
        lcd.cursor_pos = (0, 0)
        lcd.write_string( ( lastKey + "                     ")[:20] )       
        lcd.cursor_pos = (1, 0)   
        lcd.write_string( ( now.strftime("%H:%M:%S") + " "  + ip + "            " )[:20] )   
        lastKey = ""


W roli głównej to oczywiście pokraczna funkcyjka checkIrButtons(), sprawdzająca czy irexec nie zostawił pliku, odczytująca go i w końcu usuwająca, jako skonsumowany. Wiem, że są biblioteki lirc-a do Python, chyba nawet coś tam eksperymentowałam z nimi ale finalnie pozostało to może i siermiężne ale mające pewne zalety rozwiązanie. A zaleta taka, że mogę te pliczki remote_key.txt podkładać do /temp przez ssh, czy jakkolwiek inaczej, co ułatwia znakomicie testowanie zabawki. Poszycie lirc-a z główną aplikacją (choćby przez sockety /bo taki lirc ma interfejs/ nie daje takiego komfortu), no ale to dywagacje. Każdy może zrobić jak tam sobie chce. Na koniec filmik z testów na żywo - wybrane guziki, ale przed uruchomieniem Pythona pokazuje status dwóch demonków lircd i irexec-a:

https://youtu.be/lX8wTw8L0iQ

No i tym sposobem temat pilota dla kanapowych leniwców mamy z głowy.

Kolejny drobny przyrost - temat przycisków na panelu przednim timerowego pudełka

Fotka płytki klawiszy była wcześniej, teraz tylko zdjęcie z pełnym okablowaniem w okolicach złącza Maliny. Hmmm, zbliża się chwila, że trzeba by schemat ideowy połączeń radyjka zaprezentować, tylko najpierw muszę go narysować, bo generalnie to on jest w łepetynie i klecę na żywioł.

Odnośnie programowej obsługi klawiatury na froncie to względem prototypu zmieniam podejście. Jednak były wcześniej problemy z drganiem zestyków, pythonowe sposoby na debouncing jakoś nie wydawały mi się mega skuteczne. Teraz eksperyment inny - programik zgadujący wciśnięcia klawiszy będzie osobnym bytem (docelowo: kolejną usługą), po rozpoznaniu przycisku - będzie zrzucał pliczek sygnalizacyjny /tmp/remote_key.txt, do konsumpcji przez główny program radia. W ten sposób mam spójny interfejs na nadchodzące zdarzenia guzikowe, przecież to samo robi demon irexec, tylko z guzikami od pilota. Zestaw klawiszy na front panelu jakoś wpasowuje się w pule dostępną na pilocie, wyjątkiem jest guzik reset, ale jego przypisałam do pilotowego BTN_0 - i myślę, że będzie to miało głębszy sens. Sam programik kbd.py to mega prostactwo, no popatrzmy:

/home/pi/radio/kbd.py pisze:

Kod: Zaznacz cały

import RPi.GPIO as GPIO
import subprocess
import time
import os
import socket

KEY_SKIP    = 13        # SKIPNEXT
KEY_NEXT    = 15        # SEARCHNEXT
KEY_START   = 23        # START
KEY_RESET   = 21        # BTN_0
KEY_STOP    = 19        # STOP
KEY_OUTS    = 8         # STANDBY
#--------------------------------------------------------------               
def onKeyPressed( channel ):
    time.sleep( 0.1 )
    if GPIO.input( channel ) == True: return     
    BUTTON_TEMP_FILE = "/tmp/remote_key.txt"
    keyMapping = { KEY_SKIP : "SKIPNEXT", KEY_NEXT : "SEARCHNEXT", KEY_START : "START", KEY_RESET : "BTN_0", KEY_STOP : "STOP", KEY_OUTS : "STANDBY" }
    file = open( BUTTON_TEMP_FILE, "w" )
    file.write( keyMapping[ channel ] )
    file.close()
    print ( str(channel) + " " + keyMapping[ channel ] )   
#--------------------------------------------------------------               
# program glowny   
GPIO.setwarnings( False )
GPIO.setmode( GPIO.BOARD )
GPIO.setup( KEY_SKIP,   GPIO.IN, pull_up_down = GPIO.PUD_UP )     
GPIO.setup( KEY_NEXT,   GPIO.IN, pull_up_down = GPIO.PUD_UP )     
GPIO.setup( KEY_STOP,   GPIO.IN, pull_up_down = GPIO.PUD_UP )     
GPIO.setup( KEY_START,  GPIO.IN, pull_up_down = GPIO.PUD_UP )     
GPIO.setup( KEY_RESET,  GPIO.IN, pull_up_down = GPIO.PUD_UP )
GPIO.setup( KEY_OUTS,   GPIO.IN, pull_up_down = GPIO.PUD_UP )     
GPIO.add_event_detect( KEY_SKIP , GPIO.FALLING, callback = onKeyPressed )
GPIO.add_event_detect( KEY_NEXT , GPIO.FALLING, callback = onKeyPressed )
GPIO.add_event_detect( KEY_STOP , GPIO.FALLING, callback = onKeyPressed ) 
GPIO.add_event_detect( KEY_START, GPIO.FALLING, callback = onKeyPressed ) 
GPIO.add_event_detect( KEY_RESET, GPIO.FALLING, callback = onKeyPressed )
GPIO.add_event_detect( KEY_OUTS,  GPIO.FALLING, callback = onKeyPressed ) 

while True:   
    time.sleep( 0.1 )       

#fin   


Po skonfigurowaniu garstki pinów Maliny na wejście i włączenie rezystorów podciągających, na każdym z nich zasadzamy handler czuły na opadające zbocze czyli zwarcie guzika do masy. W zawołanym handlerze, odczekawszy 100ms (#JDS) omijamy stan H (czyli puszczony guzik) to nam pozwoli z grubsza zignorować fałszywe stany wynikające z drgań styków (a że mam przyciski wylutki na chińskiej, papierowej uniwersalce, to jest tam co drgać). Następ z hash-mapy (słownik/dictionary), której kluczem jest numer pinu a wartością - napis/identyfikator biznesowy klawisza wyciągamy ów i zapisujemy do pliku o nazwie dobrze znanej pozostałym uczestnikom zamieszania. Gdyby jednak jakimś cudem handler zawołał się więcej niż raz - zrobi to najwcześniej 100ms po poprzednim uruchomieniu i ... zgłosi ten sam klawisz, nadpisując plik. Sprawdzanie zawartości pliku sygnalizacyjnego też jest z pewnym interwałem czasowym - sumarycznie daje to prawie 100% eliminację dziwnych, wielokrotnych zgłoszeń. Zmiana wartości opóźnień to swoboda na ewentualny tuning, aby radyjko było responsywne i nie sprawiało wrażenia `zamulonego`. Póki co jest ok, choć finalnie Malina zostanie dociążona jeszcze trzema komponentami (demonem-grajkiem mpd i główną usługą radia oraz incydentalnie wołanym klientem - mpc), ale będzie dobrze, chyba. Testy programiku na sucho na krótkim filmiku poniżej.

https://youtu.be/S8BDieyERaI

Skoro działa, został zainstalowany jako serwis, oczywiście na koncie pi i w folderze domowym, tak prościej. Plik serwisu:

/lib/systemd/system/kbd.service pisze:

Kod: Zaznacz cały

[Unit]
Description=Plastic Box Keyboard Service
After=multi-user.target
[Service]
WorkingDirectory=/home/pi/radio
User=pi
Type=idle
ExecStart=/usr/bin/python3 /home/pi/radio/kbd.py &> /dev/null
Restart=always
[Install]
WantedBy=multi-user.targe


a przygotowanie do pracy po skopiowaniu do /lib/systemd/system to kolejno:

konsola pisze:

Kod: Zaznacz cały

sudo systemctl enable kbd
sudo systemctl start kbd
sudo systemctl status kbd    # sprawdzamy czy na pewno pracuje


Do pisania tego posta jeszcze zerknęłam co tam słychać na podłodze, o i po zalogowaniu:

konsola pisze:

Kod: Zaznacz cały

pi@radio:~ $ ps -aux | grep python
pi        1657  0.1  1.7  24068  7816 ?        Ssl  22:35   0:04 /usr/bin/python3 /home/pi/radio/kbd.py &> /dev/null
pi        1742  7.7  1.9  15488  8448 ?        S    22:40   3:08 python3 lcdtest-ir.py
pi        1828  0.0  0.4   7332  2012 pts/0    S+   23:21   0:00 grep --color=auto python
pi@radio:~ $


Serwisik od klawiszy chodzi, program testowy z zegarkiem chodzi, można iść spać, zatem dobranoc.

No cóż, radosne dłubanie z dniem dzisiejszym na chwilę zawieszam, ponieważ rozległy się głosy dezaprobaty, że wcześniej jak było to pudełko po butach z elektroniką to chociaż grało, a to nowe do wieży ciągle jest na stole lub podłodze, wypatroszone i nie działa. Pewna racja w tym jest i może lepiej na kilka dni dać rodzince do poużywania grajka , zobaczymy co i jak będzie.
W ramach finalizacji prac - schemat elektryczny załączam, choć w sumie to sprowadza się do podłączenia do RPI modułu LCD oraz odbiornika IR wespół z garścią przycisków. Kompletny kod tej wersji programu radio.py także załączam, jest to ulepek różnych pomysłów ale ma tę cechę, że działa. Nabazgrałam to w sumie dziś do południa, zupełnie zmieniając podejście względem prototypowej wersji, gdzie była maszyna stanu i inne bajery, tylko to kulało . Tu jest prościej, może i siermiężniej, ale stabilniej. Zatem dwa słowa o działaniu.

Grajek na starcie buduje (czy raczej odbudowuje) listy odtwarzania na podstawie zawartości z zewnętrznego nośnika, listy te w formie plików m3u (btw, zwykłe pliki tekstowe) składuje w folderze wskazanym w konfiguracji demona mpd (wpis playlist_directory w pliku /etc/mpd.conf). Lista stacji radiowych (strumieni) jest traktowana jak lista zwykłych mp3, tylko że posiada specyficzną nazwę 000_radio i jest na początku kolekcji. Tak ogólnie to urządzenie jest w dwóch stanach - albo gra i jest możliwa nawigacja po listach i utworach, albo wyświetla ekraniki informacyjne biegu jałowego. Specyficzną sytuacją jest zamykanie urządzenia - po zainicjowaniu tego procesu mamy kilka sekund na potwierdzenie wyłączenia dedykowanym klawiszem (STOP), urządzenie albo zamkniemy albo (w przypadku rezygnacji) wykonany zostanie coś jakby restart programu i przebudowanie list.
Gałkologia aktualnie jest taka i została komisyjnie zaakceptowana przez rodzinkę jako ogarnialna:



Garść zdjęć z dzisiejszych prac w załączniku, jak i dwa filmiki z urządzeniem bardziej na żywo - ekraniki prototypowe i te, które aktualnie pracują.
Prototyp
https://youtu.be/YM_043WHFGU
Prawie finalne
https://youtu.be/pJlFH-FSmXw

W formie wniosków - zapanowanie nad demonkiem-odtwarzaczem mpd nie jest zbyt trudne, wywoływanie klienta mpc z poziomu python i podkładanie odpowiednich poleceń załatwia sprawę. Znacznie trudniejsze jest wydobywanie z niego informacji o bieżącym stanie odtwarzania. O ile w przypadku plików mp3 prezentowane informacje o utworze są w jakiś sposób przewidywalne to dla strumieni radiowych jest zupełna dowolność. Na tym poległam w pierwszej wersji oprogramowania siląc się na interpretację tego co pokazuje mpc. No i zdarzały się załamania usługi. Aktualna wersja nie przetwarza informacji tytułowych z mpc, po drobnych manipulacjach wystawia je na ekranik LCD prawie 1:1 i tak jest ok.

Pozostaje kwestia zamykania urządzenia, kadłubek tego jest zrobiony i sekwencja klawiszy OUTPUTS/STANDBY + STOP finalnie wyła systemowe `shutdown now`. Pozostaje pytanie - kiedy można bezpiecznie wyciągnąć wtyczkę z gniazdka? Opisów typu `RPI power on/of` jest sporo, ja chyba zacznę rozmyślania w kierunku obserwacji poziomu zespolonego sygnału video na złączu Maliny. Skuteczny shutdown objawia się brakiem owego sygnału - można ten fakt jakoś na panelu frontowym zaznaczyć, choćby miganiem LED-a lub wygaszeniem podświetlenia LCD, to się okaże.

Z sucharów - jest problem z grzaniem się części zasilającej, po zamknięciu w obudowie, mimo perforacji całość zaczyna robić się niepokojąco ciepła i radiator z LM7805 i sam transformator. Docelowo grajek będzie stał pod amplitunerem i chciałabym uniknąć dodatkowego ogrzewania Toski od spodu, już piecyk z tranzystorów sterujących potencjometrem głośności mi wystarcza (btw, chyba dość znany problem w AWS504/Tosca2). Mam zaklepany zasilacz impulsowy w niewielkiej blaszanej obudowie, 5V i na kilka amper, jak się uda - w połowie tygodnia będzie przekładka i mam nadzieję, że problem zasilania zniknie.

A tak naprawdę co to wszystko jest warte - dowiem się jak grajka poużywają domownicy, czas pokaże.

#slowanawiatr

jak z fabryki

Pudełko pobrzękuje z cicha stację Morow, a ja kombinuję co z tym włączaniem zasilania Maliny.

Bo to jest tak: po włączeniu +5V Malina uruchamia się, po dłuższej chwili w pełni gotowa do pracy i reaguje na otoczenie, czy to przez sieć, czy od myszy/klawiatury. Na wyjściu RCA jest wtedy obecny zespolony sygnał wideo.
Wykonanie polecenia `shutdown` powoduje zamknięcie systemu (zatrzymanie procesów użytkownika, odmontowanie dysków, w końcu stop kernela), finalnie komputerek przestaje pracować, choć zasilanie jest nadal podawane. W tym stanie na gniazdku RCA nie ma sygnału video. Ponownie włączenie RPI to konieczność `mignięcia zasilaniem`, wprowadzenia chwilowej (choćby 1 sek) przerwy, komputerek po takim strzale wystartuje jakby na nowo. No i tego się właśnie uwiesiłam - gdyby wykryć obecność sygnału video - to mam detekcję stanu Maliny bez dotykania jakichkolwiek pinów GPIO. Tak, jest teoria o obecności 3V3 na wyjściu TxD podczas działania Maliny, ale tym się zajmie gdy pierwsza myśl nie wypali. Googlowanie pod naiwnym hasłem `video switch relay` naprowadziło mnie na schemacik, który wydał się niegłupi i od jego parafrazy zaczęłam klecić pająka.
http://www.seekic.com/circuit_diagram/C ... OLLER.html
Z braku innego RPI - pobudzenie testowe z AD2 (po raz kolejny udowadnia przydatność swą) - szpilki kilkaset kHz o niewielkiej amplitudzie, tak myślę - jak mi układzik to wykryje to i video z Maliny też złapie, fotkę oscyloskopu zrobiłam profilaktycznie wcześniej. No i posiłkując się jeszcze stronką o TTL `123 https://eduinf.waw.pl/inf/prg/010_uc/74123.php powstał schemacik jak w załączniku (póki co pierwsza połowa uruchomiona, ale już działa). A działa tak:

gdy nie ma sygnału video

nie ma impulsów na bazie T1, tranzystor jest całkowicie odetkany, stąd baza T2 zapięta przez R2 do VCC, T2 wysterowany, czyli jego kolektor prawie na GND czyli na wejściu B przerzutnika monostabilnego U1A mamy L logiczne. I to nam zapewnia, że jego wyjścia są odpowiednio U1A.Q = L, U1A./Q = H. To dla odmiany oznacza wyłączenie tranzystora T3 - nie działa podświetlanie wyświetlacza LCD na złączce J2. Niski stan logiczny z U1A./Q idzie na wejście B drugiego przerzutnika, ponieważ /CLR jest na H to opadające zbocze podane guzikiem SW1 na wejście U1B./A spowoduje wyzwolenie ustrojstwa i wygenerowanie impulsu o czasie zadanym R7 i C2 (wycyrklowane na ~1.2 sek, ale to się okaże jeszcze). Jedynka z U2B.Q steruje tranzystorem T4, który dla odmiany na chwilę kłapnie przekaźnikiem PK1. A ponieważ linia zasilająca Malinę idzie przez styk normal-close - nastąpi mignięcie zasilania i komputerek wystartuje na nowo.

no i gdy pojawi się sygnał video

impulsy na bazie T1 przeniosą się w postaci mocnych stanów H i L na wejście U1A.B - przerzutnik podtrzyma stan wysoki na wyjściu U1A.Q, stała czasowa R4,C1 jest aż nadto, aby zakryć impulsy sygnału wizji. Jedynka z wyjścia przerzutnika U1A.Q wysteruje T3 - włączone będzie podświetlanie LCD. Na wyjściu U1A./Q mamy wtenczas L - to skutecznie zablokuje nam jakiekolwiek wyzwolenia drugiego przerzutnika - jego wejście U2B.B będzie przecież nieaktywne. Wciskanie SW1 na przerzutnik już wprawdzie nie wpłynie, ale jest spora szansa, że zostanie zauważone przez oprogramowanie, które wykona shutdown, zniknie sygnał video i wrócimy do pierwszej części rozkminiania układu. No to taki debug słowny, mam nadzieje że błędu tam nie ma.

Aha, te diody - D3 i D4. Malina nie jest `5V tolerant`, wyprowadzenie GPIO odczytujące stan guzika ma ustawiony wewnętrzny rezystor podciągający do 3V3 - wymuszenie tam z zewnątrz stanu H przy pomocy +5V uznałam za...nie do końca mądre. I stąd taki potworek z diodami, zero logiczne wprawdzie przeniesie, ale GPIO piątki nie dostanie. Tak teraz zerkam pisząc...dioda D3 w sumie chyba niepotrzebna jest....to do sprawdzenia zatem.

Przekaźnik z cewką na 5V i o większej obciążalności nie jest wielką egzotyką, idzie zdobyć. Możliwe, że ładniej byłoby tam wstawić jakiś MOSFET, ale póki co niech będzie na przekaźniku, modernizacje później.

Monologu odcinek kolejny...

Na wstępie errata drobna do schematu powyżej - bez sensu narysowałam część RC drugiego przerzutnika, to znaczy nie zauważyłam że Rext i Cext są w drugiej części zamienione miejscami, lipa trochę choć i tak nikt nie zauważył, ale już poprawione. Przy okazji usunęłam tę diodę nad push buttonem SW1, jednak bez sensu była.

Z układowych zmian to wstawienie 2N2222 jako T1 i T2, wstępne testy na BC108 w ładnych metalowych retro-kubełkach, fajnie to działało na symulowanych impulsach, ale po zwiększeniu f. poległy całkowicie. Impulsowe tranzystorki (też metalowe) pracują doskonale i takie zostaną. Następna sprawa to czerwona dioda-indykator nad przyciskiem `outputs` panelu przedniego. Wymyśliłam sobie tak, że gdy urządzenie normalnie pracuje to ona świeci ciągle, sygnalizując obecność zasilania i aktywność radyjka. Ale gry wejdziemy w shutdown i pudło jest gotowe do wyłączenia z gniazdka (lub wznowienia pracy ponownym wciśnięciem guzika `outputs`) to dioda ma powoli migać. No i tu z pomocą przyszedł oklepany do znudzenia ale nad wyraz przydatny układzik timera 555. Na motywach pierwszego z brzegu schematu typu `555 blinking led` znalezionego w Google zmajstrowałam migacz ale dość szczególnie podłączony. Zatem kontynuując opis działania...

Sterowanie diodą sygnalizacji zasilania

Timer 555 (U2) pracuje w konfiguracji generatora przebiegów prostokątnych o częstotliwości ~1 Hz. Dioda LED (na panelu frontowym) włączona jest pomiędzy zasilanie a wyjście U2.Q przerzutnika (aktywna w stanie L wyjścia Q), powoduje to miganie diody gdy przerzutnik pracuje lub świecenie ciągłe gdy jest on zatrzymany w stanie reset. Wejście kasujące 555 (U2./R) sterowane jest z zanegowanego wyjścia detektora sygnału wideo (U1A./Q) - daje to oczekiwany efekt migania przy braku sygnału wizyjnego lub ciągłe świece w razie jego obecności.

Na żywo prezentuje się to mniej więcej tak:

https://youtu.be/VfwPuEx5slM

Poprawiony schemat jaki i fotka zbiorcza z rozbudowanego prototypu w załączniku. Szał na Analog Discovery 2 już tu chyba minął, ale może ktoś jeszcze pamięta tę mini płyteczkę-protezkę do stykówek... Uzbroiłam w grzebyki drugi egzemplarz, w pracach sprawdza się całkiem dobrze.

No i teraz mam dylemat - realizacja na płytce prototypowej czy dziergać dedykowany laminat. Od czasu instalacji najnowszego Kubuntu zmuszam się do Kicad 5.1 i już rysowanie schematu jest traumą. Jak o płytce drukowanej myślę, to mi się futro na karku jeży. Kicad 4.7 był fajny, miał swoje przywary ale szło go okiełznać, a ten...masakra. Kolejna dobra kurde zmiana Tak wiem, kiepskiej baletnicy to i tak dalej, ja wiem.

Płytki drukowanej się zachciało, no żesz...
No nic, to taki jest stan aktualny jak w załącznikach i lepiej, aby tam nie było grubszego, niemożliwego do posztukowania drucikiem błędu. Płyteczkę sobie puściłam właśnie na firmową laserówkę, a wydrukiem będę się zachwycać jutro z samego rana jak dotrę do fabryki, uwielbiam teletubisiowy VPN Płytka jak widać nie ma otworków montażowych, ma za to nieco miejsca pod U1/74123 - tam coś wpasuję że tak powiem `z ręki`, teraz, bez rozbierania radyjka (bo nie wolno) nic nie przymierzę.

O, i taki oto zasilacz sobie przyjechał, całkiem niewielki (niczym paczka fajek), oczywiście wyprodukowany gdzieś w Chinowie.
Tak o nim piszą: https://www.meanwell.com/Upload/PDF/RS- ... 5-SPEC.PDF Zakładam, że jednak będzie w pracy ciągłej bezpieczniejszy (w sensie grzania) niż ta samoróbka, co ją teraz eksploatują, ponieważ ma nadmiar mocy jak na moje potrzeby.

Z sucharów to zagadka się wykluła ze zmianą list odtwarzania zdalnym klientem, zarówno ze smartfona jak i z PC. Jęczy jakimś `Access denied` choć demon mpd działa na koncie root. Także na root działa samba (o ile cokolwiek to wnosi) którą wrzucamy pliki, a dysk SSD ma ext4 i właścicielem folderów z muzyką jest tenże root.

/var/log/mpd/mpd/log pisze:

Kod: Zaznacz cały

May 27 22:01 : client: [58] command returned 0
May 27 22:01 : client: [58] process command list
May 27 22:01 : client: process command "add "/mnt/usb_hdd_1/MP3/100_inne_chill/03.I Won't Hold You Back.mp3""
May 27 22:01 : exception: Access denied
May 27 22:01 : client: command returned 2
May 27 22:01 : client: [58] process command list returned 2
May 27 22:01 : client: [58] process command "playlistinfo"


Póki co nie ogarniam o co mu chodzi, listy zmieniamy sobie guzikami i pilotem, bo to działa. Pewne sygnały z google wskazują na to, że problem występuje przy składowisku plików trzymanym na domontowywanych bokiem systemach plików, jak gwizdki USB... no i mój SSD też się na to łapie, bo jest na przelotce USB/SATA. Temat to rozmyślenia. I w sumie tyle....

#slowanawiatr

I dalej dłubanie wieczorne, tym razem materializacja układu sterowania zasilaniem Maliny.
Dla spokoju sumienia (ponoć nie mam, ale tak się mówi) pokleciłam otoczenie R,D,C drugiego przerzutnika, tego od klapania przekaźnikiem.
No i wtedy się okazało, że artystka jedna pomyliłam na płytce numerację elementów R,D,C przy przerzutnikach. W poście powyżej plik 'naszeradio-onoff-top.png' podmieniam zatem na skorygowany: elementy D3,R7,C2 zamieniają się odpowiednio miejscami z D2,R4,C1. Już podczas obserwacji druciaka coś mi nie grało, ale jakoś machnęłam ręką, dopiero polutowany układ i finalne testy ujawnił tę zbukę - przekaźniczek zbyt szybko puszczał kotwicę, miało być grubo ponad sekundę, a nie tyk-tyk. Szczęściem udało się opanować tę niezręczność. W załączniku garstka zdjęć z przygotowania płytki jak i gotowego do zamieszkania w obudowie układu. Montaż całości jutro.

Grafomanii porcja na niedzielę.

Zacznę od tego, że nie lubię określenia `hotfix`, ponieważ w pracy spotykam je nader często i niestety kojarzy mi się z drutowaniem na kolanie pseudo-ratunkowych prowizorek, które mają wytrzymać do czasu, aż wymyślimy bardziej profesjonalne i kompleksowe rozwiązanie. I zdarza się, że czas ów to ∞, bo zaimprowizowany hotfix to najlepsze, co można było wykoncypować.

Radocha z modułku sterującego i nowego prawie niegrzejącego się zasilacza była wielka i w sumie ... krótka.
Dziś rankiem budzi mnie harmider - Nateeek! radio się zepsuło i cyka!

Cyka?

No i proszę - wylągł się smutek, wynikający z tego głównie, że zlekceważyłam te 800 mA poboru prądu przez Malinę i klamoty towarzyszące, może nie tyle pobór sam w sobie, co efekty uboczne nagłej zmiany takiego obciążenia.

Testy jak sprawuje się moduł sterujący z dwoma przerzutnikami monostabilnymi robiłam jeszcze na liniowym zasilaczu, żadnych efektów specjalnych nie było, zarówno usypianie jak i wybudzanie przebiegało prawidłowo. A potem, po zamontowaniu impulsowego (o w sumie twardej charakterystyce, w końcu ma te swoje 5A) rzeczywiście nie sprawdziłam wake-up, tylko na półkę - niech gra. Rano chcieli włączyć ponownie i klops...cykanie. Teorię mam taką, że podczas załączania Maliny szedł tak duży impuls prądowy (i po zasilaniu i po masie) że powodowało to ponowne wyzwolenie sterującego nim przerzutnika. Była to tego podstawa, ponieważ sygnał video pojawia się odrobinę po włączaniu zasilania, więc nic nie blokowało ponownego wyzwolenia. Klapanie było ze stałą czasową ustawioną dla przekaźnika, taka czkawka. No i co teraz?

Hotfix

Pomijając namóżdżanie się co i jak by tu zaekranować, albo jak zniwelować rozwleczenie masy po całym urządzeniu - jeszcze raz zastanowiłam się nad samym konceptem chwilowego rozłączania zasilania RPI, które to w zamyśle miało zrestartować system.
No i z pomysłów realnych do wykonania na błysk wyszło mi, że potrzeba jest jakby bramki NOR zbierającej sygnał obecności video i z stanu guzika i ona bezpośrednio może sterować przekaźnikiem wg zależności:

Jak się dobrze zastanowić to powyższe realizuje właśnie bramka NOR, oczywiście kostki takiej nie mam i w niedziele z rana znikąd u nas nie wyczaruję. Za to 7400 się znalazło - jak zrobić z czterech NAND-ów jednego NOR-a to przerabia się w szkole. No i powstała na okruchu uniwersalki proteza wpasowana w oryginalny układ prawie bezinwazyjnie - schemat w załączniku - z dokładnością do przecięcia jednego połączenia U1B.Q-R8.

Zachowanie układu jest nad wyraz poprawne, choć o czasie rozłączenia zasilania decyduje teraz czynnik białkowy. Powstaje pytanie co dalej z tym, bo aktualnie w obudowie zamknięta jest nie ukrywajmy - nieco lipa. Wypadałoby przeprojektować ten układ w kierunku przerzutnika 74121 i tegoż NOR-a na `00 lub wstawić tam PIC-a, choćby 16F84. Tego drugiego się obawiam nieco, ze względu na potencjalną wrażliwość na takie zakłócające strzały, może to głupie, ale w takich wypadkach bardziej ufam zwykłym TTL... Okazja do grzebania w pudełku jeszcze będzie, ponieważ zamówiłam sobie LCD ale 24x2 i w negatywie, więc do nadejścia paczuszki mam czas na ewentualne zmajstrowanie docelowego układu.

Na laptopach naklejają sobie szpanersko `Intel i7 inside`, to ja sobie nakleję na pudełku `powered by 7400`, a co!

Nooo, dorwałam się do graja i normalnie z kamerą wśród zwierząt.

Oto niniejszym przedstawiam instalację do zdalnego debugowania programiku testowego malującego duże cyfry na małym wyświetlaczu LCD. Przywleczona z bazarku na Olimpii ethernetowa kamerka Pixord choć poobijana to jest genialna, bez kitu, a wszelkie niedomagania załatwia regulacja jasności i kontrastu w VLC. Reszta przez ssh.

Technika robienia semigrafiki przetrenowana na uśmieszku znalezionym w sieci (google:"rplcd custom character" https://www.raspberrypi.org/forums/view ... p?t=187555 ), skoro ten maleńki przykład z czyjegoś posta zadziałał - dalej pracowita dłubanina kolejnych cyfr.

Dobrnęłam do 5 i na dziś dziękuje.
Dobranoc.

ps
Aha, to będzie do wyświetlania numeru listy/otworu podczas wprowadzania pozycji klawiszami pilota z kanapy, a przynajmniej w tym kierunku wiosłuję.

wieczorna transplantacja wyświetlacza

Odrobinę nerwów było, bo to delikatne wszystko jednak w środku jest, ale finalnie operacja się udała i pozytywnie świecący 20x2 zastąpił negatywowy 24x2, o taki: http://www.artronic.com.pl/o_produkcie.php?id=824

Jedyna zmiana w kodzie to w funkcyjce ograniczającej długość napisu, zamiast do 20 działa do 24, no i poprawka ilości kolumn w inicjalizacji modułu, drobiazgi. Modułek odpalił się bez zbędnych dyskusji, nawet udało się przetestować jak wyglądają duże cyfry w negatywie, tyle mojego na dziś.

Do poprawienia jest pozycja w okienku obudowy, blaszki mocujące są odsunięte od podstawy na podkładkach i LCD jest nieco za wysoko. No i oczko IR jakoś koślawo się wpasowało (bo moduł ma jakieś 10 mm więcej niż poprzednik), wprawdzie pilota zbiera całkiem dobrze, ale i tam drobna poprawka by się przydała, to przy najbliższym rozkręcaniu ogarnę. A teraz chillujemy.

Kolejne wieczorne majstrowanie przy oprogramowaniu radyjka, nooo...zaczyna to jakoś wyglądać.
Ponieważ już raz Malina zaliczyła zwieszkę i przez chwilę nie mogła wstać - kluczowe kawałki kodu i konfiguracji trzymam na GitHub, commity prosto z środka Raspberry. Tu adres https://github.com/bienata/radio jak kto ciekaw.

A z nowości to dorobiłam spory zegarek dla stanu jałowego radyjka przełączany pilotowym klawiszem TI/TR na zmianę z informacjami o systemie (albumy, utwory, ip, zajętość dysku). Tak, wiem - za sekundnikiem znaczek-śmieć się zapodziewa, jutro poprawię.

Listy odtwarzania wybiera się cyferkami na pilocie, tak jak w telewizorze - numer to przewijana kolejka cyfr, jeżeli po naciśnięciu ostatniej w ciągu kilku sekund nie naciśnie się PLAY to grajek wraca do poprzedniego stanu, zapominając wprowadzoną sekwencję. Wpisany numer jest pierwszymi trzema cyframi (w zasadzie literami) nazwy foldera z mp3, szukanie jest od najmniejszych w górę, więc tak naprawdę ustawiamy się na początek "obszaru" (np. 200 - ATB, 300 - Nightwish-e, 400 - Tangerine Dream-y i tak dalej), dalsza nawigacja klawiszami PREV/NEXT, każdy się może doklikać do tego co lubi.

Filmik z testów taki:

https://youtu.be/fhXfkGwbcO0

Drobne modernizacje radyjka, głównie po kilku incydentach typu zawiśnięcie i niemożność zdalnego zalogowania się przez ssh. Ostatnia awaria wymogła chwilowe podłączenie telewizora aby zobaczyć co się na standardowym wyjściu wyprawia, zdjęcie wprawdzie jest z poprawnego rozruchu, ale był i ekran zapłakany od góry do dołu błędami odczytu karty SD. I w sumie to nie wiadomo czy na skutek temperatury objawiły się problemy natury kontaktowej, czy to może wiekowa jakby nie patrzeć 4GB karta SD zaczęła dogorywać, a może to całość ogólnie za ciepła?
Zatem dwie rzeczy doraźnie - radiatorki na elementy Maliny i nowa karta pamięci z pobliskiego Media Experta za dwadzieścia parę złotych. Radiatorki są po sklepach internetowych, to raptem kilka złociszy i od razu gotowe do montażu, taśma 3M naklejona. Podobno nawet jest termoprzewodząca.
Nowa karta to konieczność przeniesienia oprogramowania, instalacja i konfiguracja wszystkich klamotów od zera to ja dziękuje. W ruch poszła zatem konsola i programik dd, to taki niskopoziomowy kopier do plików, tylko trzeba uważać. Jak nazywa się napęd z kartą źródłową dowiadujemy się po włożeniu owej do czytnika i zawołaniu

konsola pisze:

Kod: Zaznacz cały

sudo fdisk -l

I to jest ważne, ponieważ dalsze operacje wykonujemy jako root, gdy jako docelowy dysek podamy niechcący napęd z systemem to będzie zamiecione.
Kopia binarna oryginalnej karty 4GB do pliku *.img

konsola pisze:

Kod: Zaznacz cały

sudo dd if=/dev/sdd of=sd-4g-radio-2020.06.10.img status=progress

Z tegoż pliku *.img wykonujemy klona, ale na nowej, świeżutkiej karcie 32GB:

konsola pisze:

Kod: Zaznacz cały

sudo dd if=sd-4g-radio-2020.06.10.img of=/dev/sdd status=progress

Po skopiowaniu obrazu możemy sobie jeszcze uruchomić program do zarządzania partycjami, wskazać kartę i rozszerzyć tę z nazwą rootfs do pełnych 32GB, skoro jest miejsce to czemu nie. Po tym zabiegu karta wylądowała w Malinie.

No cóż, przećwiczona sztuczka z klonowaniem karty przydała się kwadrans później, bo zachciało mi się nowości. Po wykonaniu `apt-get update` i `apt-get upgrade` radyjko wzięło się i zdechło, przestała działać kontrola głośności i dwa buttony z panela frontowego oraz możliwość wykonania `shutdown now` z poziomu konta użytkownika pi, bez sudo. Po namyśle zdecydowałam, że walka o najnowsze wersje pakietów nie ma sensu - to co jest teraz i działa to z powodzeniem wystarczy, w końcu to jest dedykowane rozwiązanie i raczej nie będzie już rozwijane.

Mam wrażenie, że zamiast to wszystko pisać powinnam nakręcić sobie dodatkowych kilometrów na hulajnodze, większy byłby pożytek.
Tak więc tym oto krótkim wpisem grafomanię na temat malinowego odtwarzacza kończę.

Jak zwykle dokładny opis i z pewnością kogoś zainspiruje do podobnych wyczynów