Miniszámítógépek, SBC-k

Tengelyen léptetés közös végállás logikával hogyan?

Van egy arduino uno-ba illeszthető 4 léptető motor vezérlésére képes lapom. Az érdekessége az, hogy mindegyik tengely esetében a kétoldali végálláskapcsolók direktben össze vannak kötve a nyomtatott áramkörön. Tehát hiába van külön tüske az X+ és az X- végállás észlelésére, a szoftver felé mindkét végállás esetén egyetlen bit információ jut csak el.

Eddig a léptető szoftverem tudta, hogy melyik végénél értem el a tengelyt, és így csak az azirányú lépéseket nem adta ki, a másik irányú lépéseket engedélyezte. Ez így kerek, jól is működik.

De hogyan tudom a közösen kezelt végállást korrekten és megbízhatóan kezelni?

Eddig a legjobb ötletem, hogy végállás esetén az utolsó ismert pozíció vagy lépésirány alapján megsaccolom, hogy melyik végállásban van a kettő közül. De ezt nem érzem korrektnek. Például áramszünet esetén, vagy csak elinduláskor, ha a végállás jelez, nem ismerek lépéselőzményeket. Persze minden lépés után el is tárolhatnám az utolsó ismert pozíciót, de - tudtommal - ez olyan mennyiségű írást eredményezne a FLASH memóriában, amivel már hamar tönkre menne.

Tehát mi a korrekt, és teljesen megbízható végállás észlelés logikája, ha a két végálláskapcsoló egy közös jelet küld?

ESP32 Hardver SPI

Van egy Wemos D1 R32 ESP32 lapom. Ezen a hardwer SPI csatlakozói ki vannak vezetve az alaplapra, ezeket szeretném használni.

Az általam eddig talált kapcsolási rajzok alapján, ezek a kivezetések közvetlenül az ESP32 hardver SPI portjaira vannak kötve (SD2 - IO9, SD3 - IO10, CMD - IO11, CLK - IO6, SD0 - IO7, SD1 - IO8).

Azonban akárhogyan is akarom használni ezen keresztül az SPI eszközöket (pl.: display), nem megy. Szoftveres SPI-vel gond nélkül működik, de a hardver SPI számomra használhatatlan. Hardver SPI esetén resetel, hibaüzeneteket dob, nem megy.

Bár több helyen írták, hogy a szoftver SPI jobb (gyorsabb) mint a hardver, mivel porthiányban szenvedek, jó lenne, ha tudnám használni ezeket a portokat is.

Használta már bárki, bárhogyan is az ESP32 hardver SPI portjait? Lehetséges ez egyáltalán? És ha nem, akkor miért van kivezetve az ESP32-n?

Házimozi média lejátszó ami 4k dolby dts mkv bluray

Helló

Rakom össze a házimozim itt a nagy bezártságban és kérnék segítséget. Usb hármas külső ssdn vannak Bluray filmek ac3/dts/dolby digital hangformátumban, van Denon házimozi erősítőm amit 7.1ben akarok hallgatni. Viszont nincs még hozzá semmi lejátszóm, az asztali gépem nem akarom oda vinni. Ismerősöm panaszkodott, hogy az Lg tvje nem játsza le ezeket jól, főleg a hanggal van gondja, néha a kép is akad vagy nem játsza le egyáltalán. Mit vegyek ami mindenféle ilyesmit tökéletesen le fog játszani? Láttam szekérnyi noname android tv boxot, 15000 és 50000 között ezekről a coreelec-et futtató eszközökről. UGOOS AM6+ ahogy olvasom Amlogic S922X-J miatt tud Dolbyt hardveresen. Másik amit dícsérnek a Beelink gt-king pro, de az nem tetszik a koponya miatt. Nem sokat használom, nem akarok rá sokat költeni, szívesen frissítem Coreelecre az eszközt, ha úgy mindent visz. Jó lenne ha menne a Youtube 4k hdrben meg dolbyval. Nem akarok egy Htpct építeni emiatt, sem Barbone vagy Nucot venni, az nem állna meg 100k alatt. A márkásabb lejátszók elvileg mindent tudnak, csak drágábbak. Ti milyen olyan tv boxot használtok vagy javasoltok, ami tud 4k felbontást, mkv-t meg mindent és tud HDMI Pass-Throught hogy átdobja a hangot a házimozi erősítőnek? Ha a házimozi erősítő dolgozza fel a hangot, akkor nem kell Dolby támogatás hardveresen, jól sejtem? Hdr10nek kell hardveres támogatás, vp9 codec hardver dekodolas?

[ Megoldva(?) ] Heltec Wifi Kit 32 Spiffs méret állítása Arduino IDE alatt

Készítek itthon egy ESP32-es alkalmazást Heltec Wifi Kit 32-re Arduino IDE környezetben. Nem a legszerencsésebb választás, de a kódok már mennek, egyelőre nem szívesen állnék neki portolni valami más környezetbe.

A problémám, hogy nem tudom állítani a SPIFFS méretét. Ha minden igaz, a Heltec Wifi Kit 32 V2-es változata van meg - pinek alapján -, amit elvileg már 8MB FLASH memória van szereltek. Ennek ellenére az Arduino környezet a "Sketch Data Upload" menüponttal csak egy 1MB-os SPIFFS fájlrendszert hoz létre. Sajnos sem a FLASH méretét, sem a partíciót nem tudom menün keresztül kiválasztani.

Ha más ESP alaplapot választok, akkor megjelennek a FLASH méretét és partíciókiosztás kiválasztását lehetővé tévő menüpontok, de azokkal feltöltve a SPIFFS-t, továbbra is csak 1MB fájlrendszer lesz. Egyébként más ESP32 lapot választva a kódom már nem fordul le, mivel használ Heltec specifikus részeket (például Heltec display).

Amire szükségem lenne:

- Hogyan tudom eldönteni, hogy fizikailag tényleg 8MB FLASH van-e a board-ban, vagy csak 4MB?

- Hogyan tudok nagyobb (3MB illetve 7MB) SPIFFS fájlrendszert létrehozni ebben a környezetben, Heltec Wifi Kit 32 lapot kiválasztva?

Hogyan tartotok frissen több eszközt?

Best practice érdekelne.

A saját Linuxos laptopomon (most épp Debian stable, néha Debian testing) időnként kézzel aptitude-ot indítok és telepítem a frissítéseket. A KDE-nek van egy frissítés figyelő cucca, szóval néha szól, hogy van x frissíthető csomag, vagy van y biztonsági frissítés. Ilyenkor indítom az aptitude-ot és frissítek. De ha nem szól, akkor is időnként ránézek, hogy van-e újdonság.

Sok évvel ezelőtt, amikor még Linuxos szervereket is karbantartottam, hasonló volt a megközelítés: Debian stable, és időnként ránéztem, hogy van-e frissítés. Ha a saját laptopomon láttam, hogy biztonsági frissítés van, akkor a szervereken is végignéztem azonnal, de egyébként ugye Stable-hez nem jön túl gyakran frissítés, és nem okozott gondot az, ha mondjuk egy csomagból egy újabb verzió nem a kiadás után 2-3 hanem mondjuk 8-10 nappal került fel.

Volt olyan gép, ahol telepítettem az unattended upgrade vagy valami hasonló nevű csomagot, és rábíztam, hogy rendszeresen nézze meg, van-e frissítés, és ha van security, akkor azt ő maga tegye is fel.

Biztos ezt is lehetne sokkal profibban csinálni, központilag vezérelve, automatikus figyeléssel riasztással akármi, de nem ez a része érdekel a dolognak.

Mostanában a linuxos laptop mellett van néhány raspbian-t vagy armbian-t futtató kis céleszközöm, amikre nem szoktam belépni interaktív shellbe gyakran. Ha belépek nagy ritkán, akkor persze szoktam frissíteni, de ez pl. zavar, hogy ritkán történik.

A másik gond, hogy ezeken az eszközökön vannak olyan programok, amik nem a Debian részei, és így a szokásos frissítési eljárásomból kimaradnak.

Pl. BananaPi-ből épített NAS-on van egy docker, és a dockerben egy Plex. Az aptitude boldogan frissíti a docker keretrendszert (nagy ritkán, amikor valami miatt épp belépek), de maga a Plex image nem frissül, ha épp nem jut eszembe, hogy a NAS admin weboldaláról indulva több lépésen keresztül oda nem jutok, hogy megnézzem, van-e frissítés, és ha van, akkor ott a weboldalról fel is tegyem azt.

Szóval az érdekelne, hogy ti a hasonló dolgokat hogyan csináljátok. Kézzel? Scripttel? Valami felügyelő programmal?

Nem néztem utána, de bizonyára a Plex docker image-et lehetne az admin weboldal helyett simán docker parancsokkal is frissíteni, és ezekből bizonyára lehetne könnyen shell scriptet készíteni és azt meg betenni a crontabba.

De ez a jó irány? Vagy van jobb? Vagy nem kell ez se?

Milyen SBC-t?

 

  Sziasztok!

Keresek olyan Single Board gépet, aminek a következőket kellene tudnia:
* Linuxot futtat. Tök jó lenne ha egy normál ubuntu server-t vagy hasonlót lehetne rá telepíteni, és távolról lehetne managel-ni.
* Legyen nagyon stabil, ne legyenek túlmelegedési gondjai. Ha bekapcsolom, akkor képes legyen leállítás nélkül hosszú ideig működni.
* Alacsony a fogyasztása (lehetőleg nem ATX táp, hanem passzív 12V-os vagy valami hasonló)
* USB-s mobil HDD-t tudjak hozzá kapcsolni (lehetőleg USB 3.0-át ismerje). Ha ez nem megy és csak SATA van rajta az se nagy gond.
* Legyen rajta gigabites net (de ha emiatt kétszer annyiba kerül akkor legyen inkább 100Mbit)
* Az nagyon pozitív lenne, ha támogatna titkosítást hardware-ből (Luks-hoz), mivel ezek bizalmas adatok lesznek amiket titkosítva kell tárolni.
* Memória és CPU annyi kell, hogy fusson rajta egy samba (workgroup, nem domain controller!), és egy syncthing. Más nem nagyon fut majd rajta.
* Legyen neki normális háza, ne nekem kelljen hozzá 3D nyomtatni meg forrasztgatni és csavarozni.
* Nem gond ha SD-ről boot-ol, de az se baj ha EMMC-ről, vagy ha egy külön SATA drive-ot kell beletenni amin a rendszer van. Ez igazából mindegy.

Erre lenne használva: speciális NAS-ként, ami egy syncthing-gel szinkronizált SMB share-t biztosít a hálózaton. Ebben a (titkosított) megosztott mappában nagy méretű videó felvételek lesznek tárolva, több terrabyte.

Az ára nem annyira nagyon kritikus, szóval nem kell a legolcsóbb. De nyilván jó lenne ha nem kerülne annyiba, mint egy komplett számítógép.

Egyébként az is jó lehet, ha már egy kész NAS-t vásárolok erre a célra, feltéve hogy van ilyen ami megfelelő. Sajnos NAS téren nem vagyok nagyon otthon. Egy kicsit tartok attól, hogy saját custom szoftverrel rendelkező NAS-t vegyek, amiben speciális módokon kell beállítani a dolgokat.

 

Köszönöm!

ARM-os Mac Mini M1 alternativat keresek (Linux) - letezik ilyen?

Keresek egy olyan ARM-os, Linuxot bootolni kepes mini-szamitogepet, amin vannak a kovetkezok:

  • Legalabb ket USB-C (vagy Thunderbolt3/Thunderbolt4/USB4) port
  • Legalabb az egyik USB-C port tudjon DisplayPortkent is mukodni (eggyel kevesebb kabel, mert aramot is tud adni nehany kisebb monitornak)
  • Az aramellatas USB-C-n tortenjen
  • Legalabb 4GB RAM
  • Normalis SSD a hazban/hazba beszerelheto (mindegy, hogy SATA vagy NVMe), ne 16GB-os meg 64GB-os SD kartyakkal kelljen rajta bohockodni
  • Ethernet port
  • Lehetoseg szerint ne legyen kijelzoje es akkumulatora, de ha csak laptopban van ilyen, talan lenyelem
  • Elerheto, nem 3-6 honapot kell ra varni, meg kethetente ranezni, hogy meg mindig out of stock-e (Pinebook Pro)
  • Legyen hozza mindenhez Linuxos driver es egy elerheto leiras legalabb egy ismertebb Linux distrora (ArchLinux ARM es Void Linux ARM mar ismertebbnek szamit)
  • X11-et tudja a GPU driver kiszamolni

Letezik ilyen? Ha letezik: buy link?

Gyakori kerdesek:

"Intel Atom jo lesz?"

Nem. ARM kell.

"Intel i3/i5/i7/i9 jo lesz?"

Nem. ARM kell.

"Sajat tapja van, jo lesz?"

Nem. USB-C-s kell.

"Raspberry Pi miert nem jo?"

Kicsi a teljesitmeny es keves a RAM.

"Banana Pi miert nem jo?"

Mert ott is kicsi a teljesitmeny es keves a RAM.

"Linux X11 helyett Android jo lesz?"

Nem.

"Pinebook Pro jo lesz?"

Jo lenne, de honapok ota out of stock. Figyelem. Meg az SD kartya + hordozhatosag miatt nem a legtokeletesebb.