- VR topik (Oculus Rift, stb.)
- Milyen videókártyát?
- Nagy mennyiségben is gyártja új V-NAND dizájnját a Samsung
- Milyen TV-t vegyek?
- Milyen nyomtatót vegyek?
- DVB-T, DVB-S (2), DVB-C eszközök
- Azonnali alaplapos kérdések órája
- Mini-ITX
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Azonnali informatikai kérdések órája
Hirdetés
-
Bővíti a ROG Ally garanciáját az ASUS
ph Az egyes termékek, kártyaolvasóval kapcsolatos problámájára reagált a cég.
-
3 évig még biztosan nem rendelhetünk Xiaomi EV-t
it A következő 15-20 évben a Xiaomi a világ öt legnagyobb autógyártója közé akar kerülni, de a következő 3 évben még kizárólag Kínára koncentrál.
-
Mégis megjelenik Switch-re a Deliver Us the Moon
gp Közel négy évvel a hibrid konzolora szánt változat elkaszálása után a készítők úgy döntöttek, hogy mégis megjelenik a Switch verzió.
-
PROHARDVER!
Amit érdemes tudni a Raspberry Pi-kről:
A legelső változat 2012-ben jelent meg. Pici, olcsó és nagyon alacsony fogyasztású, hobby-célú kártyagép. Felépítése ARM alapú, nem PC-architektúra, hanem kb. egy régi mobilhoz hasonló. Nagyon sok mindenre használható! A Linux-nak és a magas eladási mennyiségnek köszönhetően jelentős fejlesztőtáborral rendelkezik.
Új hozzászólás Aktív témák
-
cigam
félisten
válasz atesss #38034 üzenetére
Ez mégis mekkora terhelés(írás) óránként?
- Vegyél olyan kártyát amire élettartam garancia van
- ramdrive-ba írd az adatokat, és adatürüségtől függően óránként/naponta írd csak ki kártyára
- Pendrive-ra, HDD/SSD-re írd ki az adatokat USB-n keresztül, vagy hálózati meghajtóra naplózzál
- használj ipari sd kártyát, ami jobban bírja a gyűrődést (komolyabb cellakezelés)
- az eddigi napló(ka)t rendszeres mentsdNe spilázd túl! Ez csak egy hobbi projekt
Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews
-
-
UberMutant
őstag
válasz atesss #38038 üzenetére
ha fizikaliag másutt/elérhetetlen helyen lesz , ráadásul nem hobby , akkor szerintem felejtsd el az SD kártyákat / pendriveokat és használj SSD-t.
semmi nem fogja előre jelezni, hogy megdöglött a kártya, egyszer csak fura hibák lesznek, megmagyarázhatatlan fagyások... bosszantó lesz , és nem tudod, hogy 2 év múlva vagy sokkal korábban.
3B+ szal azonnal mókolás nékül megy az usb boot.
2,5 colos hdd a határon van, vagy elviseli az 500mA-t vagy sem. bosszantó hibákat okozhat ha nem elég neki.[ Szerkesztve ]
-
zsolt_64
senior tag
válasz atesss #38038 üzenetére
Az usb boot-nak illetve annak hogy az oprendszer egy usb eszközön és ne a sd kártyán csücsüljön alapvetően 2 megoldása van:
1. boot közvetlenül az usb eszközről: 3b+ biztosan megy , most a pi4 is már.
2. egy kisméretű (256MB elég) sd kártya alkalmazása , erről boot-ol, majd átugrik az usb eszközre. elvileg ez minden pi-n működik. Erről a megoldásról többen, többször írtunk itt a PH-n. némi linuxos variálgatás fstb és config file módosítás kell..Az hogy ezen megoldások bármelyikét egy pendrájvra csináld meg , nem javaslom, kb pont ott tartanál élettartamban mint az sd , vagy még roszabb lenne.
Gyári tápegységgel egy 2.5 ös külső usb meghajtó benne merevlemez vagy ssd simán elmegy...UberMutant által jelzett táp probléma usb2 őn esetleg olyan dupla usb csatlakozóval oldható meg amilyet az usb2-es dobozokhoz adnak.
[ Szerkesztve ]
-
cigam
félisten
válasz atesss #38038 üzenetére
[link]
Ha elromlik, azt változatos módon teszi. Pl. Csak olvashatóvá válik a tartalma, vagy egyszerűen nem ismeri fel semmi. Ellenőrizni nagyon nem lehet, az ipari kártyák adnak magukról smart infót, az alapján következtetni lehet az elhasználódás mértékéről.
- Kis akkumulátorral áthidalható. Ha érzékeli hogy eltűnt a betáp, lefuttat egy vészleállítást, és utána szabályosan kikapcsolja magát.
- Talán ez még belefér(fizikailag is) [link]
- Nem hobby projekt? Ne már... Csak azt ne mond hogy ez kereskedelmi termék lesz és pénzért fogod árulni.Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews
-
Keem1
addikt
válasz atesss #38043 üzenetére
SSD egy USB2-es házba
Ez az öntökönszúrás
Én 42 ezerért vettem SSD-t és kicsit tartottam tőle, hogy 5000 forintos házba teszem. De végül mindenben príma, szóval nem gáz. De az a minimum volt, hogy a ház 3.0-s legyen, menjen rajta a TRIM, a SMART, meg hát a kábel mellett a chip is 3 Gbites legyen (hiába a 3.0-s csatlakozó+kábel, ha régi, 480 Mbites chip megy át, az a büdös életbe nem lesz gyors).Ja, és még így is agyaltam, hogy inkább 59 ezres NVMe SSD + 10 ezres ház hozzá (kisebb lett volna, az hétszentség).
[ Szerkesztve ]
-
zsolt_64
senior tag
válasz atesss #38043 üzenetére
Bocs, de az egészet passzolom, mert én 1 hobby felhasználó vagyok.
nálam jelenleg a pi4 egy havertól grátiszba kapott ssd-n fut (32GB) + egy elfekvő usb ház ami örömömre uasp és trim-es
Ehhez előkotortam a fiók mélyéről egy 1GB sd kártyát és megcsináltam bootosra , jelenleg az asszony internetezik + filmet néz rajta. erre tökéletesegy bevált külső ház: axagon ee25-xa6
De talán a többi fórumtárs segít...
[ Szerkesztve ]
-
Keem1
addikt
válasz atesss #38046 üzenetére
Ja, vagy úgy.. Arra ez a fajta megoldás tényleg fölösleges volna. Akkor erre inkább egy strapabíróbb SD kártya célravezetőbb lehet. (hangsúly azon, hogy lehet, sem erre a célra, sem ilyesmit nem használok)
Mindenki másnak:
Skacok, hogy tudom egy bőséges folderen megváltoztatni csak az "others" jogosultságait? Mint ahogy achmod +x -R /erre
végrehajtásjogot ad mindenkinek, de a többit nem piszkálja, úgy én is csak az others jogait akarom változtatni az owner és a group békén hagyásával (konkrétan minden jogot elvenni az others-től).[ Szerkesztve ]
-
vpleft
tag
válasz atesss #38056 üzenetére
Nekem rpi3 model B-m van és az a tapasztalatom vele, hogy bármilyen sd kártyát rakok a pi-be, nálam nem kicsit laggolni kezd tőle a rendszer és hamar korruptálni kezd fájlokat. Pár boot után alig akar indulni a desktop, aztán még néhány boot után már el sem indul...
Éppen tegnap egy samsung evo+ 32gb-os kártyával próbáltam, de azzal is ezt csinálta, az eredeti táppal.Szóval lazán instabilitást okozhat. Érdemes backupot készíteni mielőtt valaki kísérletezni kezd!
Van teszt is, igen. Pl. ezt találtam: benchmark
Én inkább nem piszkálom, de lehet hogy valakinek érdemes lehet kísérleteznie vele[ Szerkesztve ]
-
BalanceR
addikt
válasz atesss #38057 üzenetére
Keresgettem a témában, anno probléma volt a korábbi PI modellek esetében is, bizonyos kodekek nem voltak támogatottak, vagy meg kellett venni a liszenszet...
Jelenleg a PI 4 hardveres dekórolása H265 esetében 1080ig sima liba, de a nagyobb felbontás, illetve h264 HEVEC fileokkal gondban van, proci.
Ezt a filet Neked esetleg sikerül bármivel lejátszanod: [4K 30FPS demo]#Raspberry #Orangepi #HassOS #Esp32
-
wassermann
Topikgazda
válasz atesss #38056 üzenetére
Az SD kártyának elvileg +-10% tudnia kell a ráírt sebességet, ami azt jelenti az U1-es SD kártya ha 100 MHz-el nem is, de 90-el biztos megy, ami asszem háromszorosa a lassú kártyák miatt, kompatibilitási okokból visszavett SD-vezérlő sebességnek!
Nekem az U1-es Sandisk-em 103MHz-et bír évek óta, stabilan:dtparam=sd_overclock=103
-
BalanceR
addikt
válasz atesss #38062 üzenetére
Prociból valóban sok lenne a Pinek, de hardveres rásegítéssel azért illene egy közepes/alacsony bitrátájú 30 fps-es 4kval elboldogulnia... Megfeleő Vram, és hűtés mellett, elvileg tudja is, de a HW dekódolás liszensz / technikai okokból még nem megoldott...
#Raspberry #Orangepi #HassOS #Esp32
-
0519
senior tag
válasz atesss #38101 üzenetére
Hát ha a rendszer maga nem fontos neked és készen állsz letörölni, újratelepíteni is, akkor érdemes az egyszerűség kedvéért megpróbálni a sudo apt-get upgrade & sudo apt-get dist-upgrade
Ha nem működik, akkor lehet újratelepíteni''Vígan ülünk tort azok fölött akik ellenünk törtek'' -Addams family
-
vpleft
tag
válasz atesss #38106 üzenetére
status=progress paraméterrel, tehát pl.:
dd if=/dev/sdc of=./backup.img bs=8M status=progress
De ez amúgy nem valami informatív szerintem és dd-nél tapasztalataim szerint sokkal gyorsabban le tudod menteni, hogyha pl így csinálod:cat /dev/sdc > ./backup.img
Így a lemez/sd kártya sebességétől függően a lehető leggyorsabban végez. És pont ugyan olyan megbízható is mint a dd
Hogyha státuszt is akarsz, arra tökéletes a pv nevű program:pv /dev/sdc > ./backup.img
Ez rajzol rendesen egy progress bar-t, illetve számol egy ETA-t is, stb[ Szerkesztve ]
-
atesss
addikt
válasz atesss #38098 üzenetére
Megcsináltam a teljes újratelepítést.
És most már nem akad !
Most 1920*1200 képernyővel, 640*480 ablakban 10-15% a prociterhelés a 3B+-on.
Teljes képernyőn se lehet sokkal több, de ezt ugye csak visszanézni tudom a CPU Usage Monitor Panel Appletben, és az nem annyira pontos.Hát ahhoz képest, hogy elvileg alig egy hete jelent meg ez a legújabb image (Version:May 2020, Release date:2020-05-27, Kernel version:4.19, Size:2523 MB), eltartott neki egy darabig a frissítés. GUI-ból, az indításkori kezdőlépésekkel csináltam. Az SD kártya itt csak V10-es 16GB Adata, de azért ez is egy gyorsabb darab.
Erre a legfrissebbre most ezt írja:pi@raspberrypi:~ $ uname -a
Linux raspberrypi 4.19.118-v7+ #1311 SMP Mon Apr 27 14:21:24 BST 2020 armv7l GNU/Linux
pi@raspberrypi:~ $ cat /etc/issue
Raspbian GNU/Linux 10 \n \l
Mielőtt újrahúztam, megnéztem a régit is amiről frissítettem:
pi@RPI_CSI_VideoP:~ $ uname -a
Linux RPI_CSI_VideoP 4.19.42-v7+ #1219 SMP Tue May 14 21:20:58 BST 2019 armv7l GNU/Linux
pi@RPI_CSI_VideoP:~ $ cat /etc/issue
Raspbian GNU/Linux 9 \n \l
Ebben amúgy annyi a fura, hogy a Wikipedia alapján [link] 4.19-es kernellel már csak a Raspbian 10-es (Buster) volt.Amúgy nem túl up-to-date ez a Wikipedia oldal, 2020-02-13 a legújabb szerinte. Mindezt úgy, hogy viszont már "Raspberry Pi OS" néven írják...
Ami viszont tudtommal csak a 8GB-os verzió megjelenésével egy időben változott meg úgy egy hete [link][ Szerkesztve ]
-
vpleft
tag
válasz atesss #38114 üzenetére
Nem a cat a gyorsabb, az csak egy alternativa lehet dd helyett.
Ugye dd-nél blokkokat olvasol és írsz, szóval blokkokat passzol tovább a kimenetén is. (ennek a mérete a bs paraméter) Ha a blokkméretet nem lövöd be pontosan a cél és a forrás maximum olvasási sebességére - ami valljuk be, nem olyan könnyű feladat és értelemszerűen eszközfüggő - akkor nem lesz a maximális a sebessége a mentésnek, mert vagy az olvasás fog loholni az írás után vagy épp fordítva. (Úgy kell ugye belőni, hogy kb folyamatos legyen az írás a cél fajlba és az olvasás a forrásból)
Szóval ha kihagyod a dd-t a mókából, és közvetlenül az eszköz driverén keresztül olvasol/írsz, akkor rábízod magad az os bufferelésére, amit az próbál mindig optimálisan belőni.
Két napja jöttem erre rá én is. A dd-s mentés 7 perccel tovább tartott a sima pv-s olvasásnál úgy, hogy gyors sd kártyát használtam, lassú olvasóval. 3x teszteltem és mindig 7 perccel tovább tartott dd bs=8M -al mint dd nélkül pv-vel. Bs=4M-ot meg is szakitottam mert megtovabb tartott mint a 8M.
Amúgy ez az utasítás:pv /dev/sdc > ./bckp.img
Byte-ra pontosan ugyan azt az img-t hozza létre mint ez:dd if=/dev/sdc of=./bckp.img bs=8M status=progress
(sha1 megegyezik)
Majd később még írok erről hogy lehet kisebb img-t létrehozni -
azbest
félisten
válasz atesss #38126 üzenetére
mivel munkaeszköz és filléres tétel, érdemes venni egy komplett új szettet, tápegységgel, kártyával. Ha nem akarnak sokat szöszölni vele, akkor régi pi3 -mal.
Ha azután is érdekel valakit, hogy mi romolhatott el a régin, akkor lehet egyesével cserélgetni a komponenseket. Akár a tápnak is lehet hibája, vagy egy vihar során villámlástól kapott a gpio-kon át kapott valami lökést és a soc-ban sérült meg valami - pláne, ha nincs valami külön gpio védő áramkör közbeiktatva. Vagy akár egy sztatikus kisülés is eljuthatott valamelyik gomb felől hozzá. A pi gpio-ja közvetlenül a soc-ba vezet. De lehet kapni sokféle kiegészítőt, amit a védi és akár 5v toleránsá is teszi.
[ Szerkesztve ]
-
azbest
félisten
válasz atesss #38130 üzenetére
Ha hardverhiba, akkor ugye fizikailag hozzá kell nyúlni. Nem ismerem a képességeiket
Egyébként remélem van backup a rendszerről, rá telepített programokról, kofigjukról.Van esély rá, hogy régebbi pi-t is kapni valahol, csak nem a kiskereknél (rpi-bolt, málnapécé), hanem mondjuk farnel vagy rs-componensnél vagy azok viszonteladóinál. Persze lehet pont a 3as nem az amelyiknek több évre garantálták az elérhetőségét, a 2B -ből emlékszem ilyenre. Bár a 2B 1.2-es változata valójában egy 3-as, csak a 2-es nyákjára építve (wifi bt tnélkül).
Ahogy látom a farnell-nek elvileg van 3B készleten [link],
Régen, magánszemélyként a magyar fhd viszonteladójukon át rendeltem tőlük, úgy magyar számlát kapsz. [link]Pesze, az újabb vason egy régebben kiadott oprendszer nem indul el, mert az még nem ismeri az újabb hardvert. A friss rendszer viszont elvileg megy a régi pi-ken is. Szóval, ha egy újabbon telepíted, azt a kártyát áttéve egy régibe, akkor is elindul - hacsak direkt kézzel nem konfigurálod úgy be, hogy mindenképp az újhoz való dolgokat töltse be. Ez persze a raspbianra igaz, nem a mások által készített rendszerekre.
Azóta már maga a raspbian is 2-3 verizólépést csinált. (Múltkor cseréltem le én is egyik pimen frissre a rendszer több év után) Persze lehet próbálkozni végigtolni egy régin a több lépcsős frissítési folyamatot, de ha amúgy a szoftver nem épít kivejezetten valami régebbi megoldásra, akkor jó eséllyel kompatibilis maradt vele az új rendszer egy legújabb pi-vel is. Csak esetleg a csatlakozók fizikai helyzete, alakja más a 4-estől, ha nincs hely máshogy elrendezni a kábeleket, akkor abból lehet probléma. (type-c, mini-hdmi, felcserélt sorrendben a lan és usb)
Távolról lehet egy új készletre telepített, az ő pi-jükről lementett / backupjából kivett konfiguráció vagy python script programból lehet egy új telepítés a legegyszerűbb. Ha azt fizikailag át tudják cserélni a régi helyére, akkor még akár távolról is meg tudod oldani.
A gpio kapcsán nem az elektromos hálózatra gondoltam, hanem a vezetékekben villámláskor is indukálódhat áram, ami tönkreteheti. Ilyen védő / buffer áramkörökből rengeteg féle van [link]
(#38132) atesss
lehet nálad is az a baj, hogy ha cronba / autostartba teszed, akkor ott nem úgy indítod el, hogy a felhasználó konfigurációját is betöltse, hanem csak közvetlenül próbálod indítani és úgy még a path-ot sem feltétlen ismeri bármihez.Az lxterminal meg mintha a grafikus felületen futó terminál lenne, ami nem fut grafikus felület nélkül.
[ Szerkesztve ]
-
atesss
addikt
válasz atesss #38132 üzenetére
Közben sikerült megoldanom, de nem volt egyszerű...
Leírom részletesen, hátha esetleg másnak is segít.Úgy használom mindig a Raspberry-jeimet, hogy az
/etc/xdg/lxsession/LXDE-pi/autostart
fáljba beírok egylxterminal -e /home/pi/Desktop/start.sh
parancsot. És az asztalon van ez a start.sh fájlom, amibe beírom mindig amit automatikusan indítani szeretnék az adott rendszerrel.Ezt a vncserver parancsot is az indításkor lefutó script-csomagomba raktam bele (és újraindításokkal teszteltem), mert az volt a tapasztalat hogyha van fizikai képernyőm a PI-n, akkor mégis lefut egy a fizikai képernyőn megjelent terminalból indított
vncserver
parancs.
Míg a start.sh-ból pedig nem ment csatlakozott képernyővel indítva se. Azaz ahhoz hasonlóan mint ha nincs is csatlakoztatva képernyő.Volt egy olyan ötletem, hogy ha SSH-val megy, akkor írok egy scriptet, ami be ssh-zik a PI-n a localhost-ra, és onnan indítja a vncserver-t.
SSH-keygen-el megoldottam hogy ne kérjen jelszót az ssh-ba való belépésnél: [link]
De hiába, ez nem indult el.
Utána megpróbáltam screen-el indítani.
Ez olyan jól sikerült, hogy végtelen ciklusban futott az indulás, és hozta létre a virtual desktopokat (rájuk is tudtam csatlakozni VNC Viewerben az IP:2, IP:3 stb. címeken), míg el nem fogyott a memória és teljesen leterhelődött a CPU. Sajnos elég gyorsan eljutott ide indulás után.
SSH-n, nano-val nagy nehezen vissza tudtam írni elég gyorsan.Végül megtaláltam ezt a fórumtémát: [link] ,és az itt linkelt további hasonlót: [link]
Ez alapján sikerült, az/etc/rc.local
fájlba kellett beírni a következőt:#Start RealVNC in virtual mode with resolution 1920x1200 px
sudo -u pi vncserver -randr=1920x1200
Fontos pont, hogy pi userként kell indítani a vncservert, valószínű ez volt kezdetben a probléma a start.sh-ba beírt vncserver parancsommal.
Írja még ezt is:
"1) Do not enable VNC in raspi-config! If already done then go back and change to NOT enabled."
Ezt viszont nekem nem kellett megcsinálni, meg úgy is ha be van kapcsolva a VNC alapból.A többszörös indítást úgy néz ki nem a screen csinálta, hanem közvetve a VNCServer Virtual Desktop-jának elindítása. Ha a start.sh-ba írtam be a
sudo -u pi vncserver -randr=1920x1200
parancsot, akkor is elindult, de ugyanúgy végtelen ciklusba került.
Azt sejtem hogy egy Virtual Desktop létrehozáskor ez az új desktop ismét pi userként jelentkezik be, és lefuttatja a/etc/xdg/lxsession/LXDE-pi/autostart
-ot, és így az abba írt start.sh-t is.
Míg a /etc/rc.local csak a rendszerindításkor fut le, egyszer.[ Szerkesztve ]
-
azbest
félisten
válasz atesss #38142 üzenetére
az lxsession start természetesen a grafikus felület indítása után indul el. Azért nem volt jó oda betenni a grafikus felület elindítását. És persze azért indul el újra és újra egy újabb X, ha oda is beteszed.
Alapból valsz azért indult el, mert amikor nem dugsz rá monitort, akkor sem headless módban megy, csak akkor a kompozit kimenet az alapértelmezett (erre workaround az általad írt hdmi_force_mode, mert akkor mindneképp a hdmi-t választja és nem a kompozitot) és azon lenne kép. Szóval a már egyszer elindul alap X -ből indítottál el egy másik X szervert a start.sh-dal, ami aztán a mádodik X indulása után újra lefut és így tovább.
[ Szerkesztve ]
-
atesss
addikt
válasz atesss #38113 üzenetére
Ezzel sajnos még akadt problémám.
Mint írtam, HDMI display-el tökéletesen megy a 3B+-al is, alacsony prociterheléssel.
Rádugtam viszont a PI-re a HDMI monitor helyett ezt a DSI-s, 800x480 felbontású, gyári képernyőt: [link]
Mivel terv szerint egy kis LCD-vel lenne majd használva (persze egy ennél kisebbel és jóval olcsóbbal). Bár azt nem tudom hogy az olcsóbb képernyő is DSI-s lenne, és nem-e már SPI-os.
Amíg nem rakom teljes képernyőbe, addig megy teljesen jól.
Teljes képernyőn viszont fekete képet ad.
Mindegy hogy alapból --fullscreen kapcsolóval indítom shell-ből, vagy megnyitom shell-ből pl. 320x240-be és utólag méretezem át dupla klikkel, vagy GUI-ból indított VLC-ben GUI-ból nyitom meg a /dev/video0-s eszközt; ugyanez.
VLC-ben és CVLC-ben is. -
Keem1
addikt
válasz atesss #38160 üzenetére
és #38163 cigam
Igen, sajnos kicsit én is tartok attól, hogy a kontakt nem lesz jó, még ha esetleg látszatra bele is szorul annyira. Ha nagyon negatív akarok lenni, félek attól, hogy később kábelezésnél jönnek hibák, amiknek nem fogom megtalálni az okát.
Két ok van, ami miatt nem szeretném forrasztani:
- a Zero-t mindenféle mókolásra vettem, és nagyon frankó, hogy egy fél bankkártya méretű, kb. kétféle kiterjedéssel. Zacsiba teszem, zsebre vágom. Ez a beforrasztott headerrel elvész.
- nem tudok forrasztani: régen csináltam, sokkal nagyobb érintkezőket, és eszközeim sincsenekAlternatíva:
Találtam a Pimoroni-n solderless headert, amit kalapáccsal kell beb*szni a helyére A kivehetőség itt is elvész, viszont forrasztás nélkül meg lehet oldani. Igaz, egy 1 dolláros header helyett lesz 7 dollár - jó drága -
cigam
félisten
válasz atesss #38170 üzenetére
át kell térnem a
/etc/rc.local
-ból való indításra.
Még mielőtt, áttérsz, felejtsd is el! A systemd-s init rendszer csak kompatibilitási okokból hagyta meg ezt a régi init rendszer emulációját.
Nézd át ezt: [link][ Szerkesztve ]
Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews
-
cigam
félisten
válasz atesss #38179 üzenetére
Nekem ebből az jött le, hogy ez a vncserver indítása előtt lelövi a futó példányokat.
Pontosan. Ezzel biztosítja, hogy csak 1 példány fusson.
a
/etc/xdg/lxsession/LXDE-pi/autostart
-ot, amiben ha benne van a vncserver indítása,Nem, nincs benne.Vagy ha beletetted, veddni onnan.
[ Szerkesztve ]
Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews
-
cigam
félisten
válasz atesss #38181 üzenetére
n+1 megoldás létezik rá, és ez attól is függ milyen programokat futtatnál. Milyen jogosultság szükséges a futtatásukhoz, milyen futási szintet igényelnek (meg egy terminál sem kell hozzá, vagy grafikus felületet igenyelnek), hogy a rendszerrel induljon, vagy ha x user belép,...
Itt (és itt)felsorolnak pár módszert, hogy a különböző helyeken hogyan tudsz automatikusan programot indítani.
Fontos hogy ezeket nem szabad keverni! Természetesen használhatod mindegyiket "indítási pontot", de egyszerre ugyanazt ne próbáld elindítani különböző helyekeről. Ezért sem szabad a különböző leírások között ugrálni ha elsőre nem megy ki kell deríteni az okát, vagy visszacsinálni az eddigi módosításokat, hogy azok ne kavarjanak be, ha egy másik leírás máshol másképp indítaná az adott programot. Ezért nehéz okos tanácsot adni amikor nem megy, mert kitudja mit hol mire írtál át.Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews
-
BalanceR
addikt
válasz atesss #38267 üzenetére
Szia,
Nekem még bőven úton van a Neo-case, ha ideér, beszámokok róla...
ahogy nézem a zártsága jobb, mint az armornak, de szerintem az sem pormentes, viszont legalább valamennyire kint tartja a retket, és esztétikus.
Nem tudom, hogy egy HAT elfér-e felette, szerintem nem, viszont minden port hozzáférhető marad, és külön pacsi a GPIO kiosztás tábláért, ami benne van.
BTW... Még ezt a [házat] néztem alin, ez még szebb, és egy helyre van kivezetve minden, aktív hűtésnek is van hely, csak drága, és ez sem stackelhető...#Raspberry #Orangepi #HassOS #Esp32
-
azbest
félisten
válasz atesss #38270 üzenetére
a pi user pontosan a pi user jogosultsági szintjével fut
Egyébként van neki sudo-er engedélye is, szóval át tud váltani emelt szintűre is.
De nagyon sok esetben csupán arról van szó, hogy az emberek nem értik a jogosultsági rendszert és ezért root-ként futtatnak mindent.A felhasználó egyben csoport is, valamint léteznek technikai felhasználók is. Ez azt jelenti, hogy ha a pi-nek hozzá kell valamihez férnie, akkor általában ez azt jelenti, hogy a pi usert hozzá kell adni ahhoz a csoporthoz, ami azt az erőforrást kezeli.
A felhasználó alatt kiadott groups parancs kiírja, hogy milyen csoportoknak tagja már. Raspbianon alapból tagja például a gpio i2c spi csoportoknak, hogy plusz állítgatás nélkül tudjon a felhasználó játszani azokkal.
Az sd kártya sebessége nagyban függ a kártyaolvasó képességeitől is.
[ Szerkesztve ]
-
BalanceR
addikt
válasz atesss #38471 üzenetére
Normál desktop használat mellet soha nem éri el a throtting szintet nálam, persze, ha ráeresztenék egy stressz tesztet, ahol minden mag maxon pörög, biztosan throttolna, de nem életszerű, ha szerverként fut, vpn, syncthing + ftp, ilyen 51 fok körül volt most a 30 fokos panelban...
Ha leveszed a fedlapot, nem nagyon változik a hőmérséklet, mivel az is alu, valamennyire az is vezet el hőt..
A GPIO, Display, Camera SDI hozzáférhető, de egy HAT nem menne rá szerintem, mert az ethernet felőli oldalról beljebb lóg picit a burkolat, de jumper kábelekkel gond nélkül használtam .
Az alján nincs lyuk, de mivel az alsó panel műanyag, simán megfúrható, ha az kell.
Pi 3al sehogy nem kompatibilis.Ali normál shippinggel jött, a postás hozta fel, pedig a ládába is befért volna... Mégis itt volt bő két hét alatt...
#Raspberry #Orangepi #HassOS #Esp32
-
atesss
addikt
válasz atesss #38472 üzenetére
No közben gondolkodva a dolgon, lehet hogy - első körben legalábbis - egy 3B+, vagy akár a 4-es Pi-m lenne berakva. Legalábbis amíg a tesztelés-hibajavítás fázisában van a projekt.
Egy "8D" mozi rendszerben egyfajta kicsi vezérlőnek/automatizálónak használnám.
És jó lenne az - amúgy is meglévő - kamerák képén akkor már egyben követni, hogy amikor működésbe lépett ez a "hibajavító vezérlő", előtte/utána mi történt fizikailag.
Milyen CCTV-rendszereket ismertek Raspberry-re ?
Valami olyan megoldás kellene, ami tud külső "érzékelőt" is kezelni (ez jelen esetben fizikailag egy GPIO pin lenne). És az igazi az lenne, ha lenne idővonal nézet, ahol a külső érzékelő állapotát is látnám a kameraképek(egy, vagy több egyszerre) mellett. -
-
cog777
senior tag
válasz atesss #38933 üzenetére
Hasznalhatod a monotonic funkciojat a time-nak (python), a rendszerido valtoztatasa nincs hatassal a monotonic idore, amelyik meri hogy a bekapcsolas ota mennyi ido telt el [link]
time.
monotonic
() → floattime.
monotonic_ns
() → int
Ez eleg preciz. "The clock is not affected by system clock updates."Viszont ha az ujrainditast kell tulelnie az idobelyegnek akkor alternativakent lehet hasznalni az eltelt idot 1970-ota UTC Epoch
Ez bevett szokas ezt hasznalni hogy log-okban, vagy vezerlesre ezt hasznaljak. Nem hiszem hogy a rendszerido sokat ugralna...[ Szerkesztve ]
HP ZBook Workstation A3000 - Linux Mint; Raspberry Pi4 - Raspbian
-
cog777
senior tag
válasz atesss #38938 üzenetére
Hat, megmondom oszinten en pont forditva hasznalnam, time.monotonic-ot preciz vezerlesre mert az soha nem ugral, UTC epoch-ot a log-oknal mert arra soha nincs hatassal a teli-nyari idoszamitas ugralasa.
Magyarazat:
Elvileg, a monotonic ido az minden rendszeren a CPU ora tick-jeit meri, igy az fuggetlen az aktualis idotol.
UTC Epoch pedig jo arra hogy nagyobb idotavlatbol viszonylag pontos osszehasonlitasokat vegezzunk.[ Szerkesztve ]
HP ZBook Workstation A3000 - Linux Mint; Raspberry Pi4 - Raspbian
-
cog777
senior tag
válasz atesss #38941 üzenetére
"az Epoch-os megoldást használom - a log kivételével mindenhol."
Csak erre reagaltam hogy logra teljesen jo a localtime(), ha az eszkoz mindig 1 beazonosithato helyen marad. Nalunk a cegnel a termekek naploinal mindig UTC idot hasznalunk, igy barmely foldreszen nezik meg a naplot, nincs kavaras es atszamolas (termek USA-ban naplozott valamit, szerver svedeknel van + nyari/teli)time.monotonic() erteket ugyanugy tudod a time.time()-hoz hasonloan osszehasonlitani elozo ertekkel. En biztonsagosabbnak erzem, kivedhet par megmagyarazhatatlan esemenyt.. hacsak letiltod az ora szinkronizalast, ahogy cigam javasolta.
[ Szerkesztve ]
HP ZBook Workstation A3000 - Linux Mint; Raspberry Pi4 - Raspbian
-
azbest
félisten
válasz atesss #38933 üzenetére
Gondolom manapság is a fake hardware clock csomagot használják az idő kezelésére. Az úgy működik, hogy kikapcsoláskor elmenti az utolsó ismert időt és újraindításkor alapból azzal indul a rendszer elvileg. Utána, a netről beszinkronizálja frissre.
A lényeg, hogy sosem jár visszafelé az óra, mindig csak előre halad így.Másrészt óraátállítások is vannak és ha jól csináltad, akkot utc idővel dolgozol, nem pedig helyi idővel, ami évente kétszer urál és egyszer még visszafelé is megy.
Érdemes lenne átgondolnod, hogy jól kezeled-e az időt a programodban, mert gyanús, hogy nem. Bár rákeresve a python leírásban, lehet utc-t használ az a függvény is.A másik lehetőség, hogy szimplán veszel valami filléres hardver órát és bekötöd a pi-re egy gombelem társaságában.
szerk: tovább olvasva lehet nem is az a probléma, amire vissza szeretnéd vezetni. Csak egy tipp, de lehet rosszul fogod Nem a rendszerórára kellene alapozni a feladatodat, hanem megszakításkezelés vagy a broadcom pwm-re vagy valami más, a célra való megoldásra és nem újra feltalálni a spanyolviaszt. Nameg nem végtelen ciklussal vagy rekurzióval kellene
Amúgy igen, látom, hogy a bemutatkozó példákban sokszor sleep meg hasonló nagyon egyszerűen érthető megoldásokat használnak, de komolyabb feladatokra túl kell lépni ezeken.
[ Szerkesztve ]
-
azbest
félisten
válasz atesss #38944 üzenetére
műveletvégzéshez utc, de nem a leírt dátumra gondolok, hanem timestampre vagy más olyan reprezentációra amit használni lehet. A megjelenítés vagy kiírás pedig, ha oda helyi idő kell, akkor arra szokott lenni függvény, ami kiadja magából olyan, emberi fogyasztásra alkalmas formában.
De úgy általában, azt javaslom, hogy amikor a feladat megoldását akarod kitalálni, akkor ne a végétől állj neki, hogy a kakukkos órából kiszámolsz valami pici időkülönbséget. Hanem úgy a végcélből indulj ki és tedd fel a kérdést (akár a google keresőnek), hogy pythonban és raspi hardveren milyen létező megvalósításokat használhatnál fel rá.
Például, ha neked 1 másodpercenként kell csinálni valamit, akkor nem a kakukkos órát kell nézegetni gyakran, hanem konkrétan egy másodpercenként kellene történni valaminek. Nem foglalkoztam sokat pythonnal, de google kidobta, hogy van valami interrupt kezelés benne, ami callback függvényt hív meg, amikor esemény van.
Szóval nem azt mondod, hogy végeten ciklusban nézegeted az órát, hanem megmondod neki, hogy 1 másodpercenként történjen a végrehajtás és adott függvény végezze akkor el. Csak valami véletlen találat példának [link]
Ne tévesszen meg, hogy belül megint meghívja magát. Ott valójában azt mondja, hogy x idő után melyik függvény fusson le. Csak mivel egy következő esetet kezel, így ezért a függvény álítja be a következő időpontra. De lehet van interval vagy hasonló nevű megoldás is (mint javasciptben), ahol nem egyetlen, hanem leállításig minden egyes x idő elteltében való futtatást lehet beállítani.Az áramszünetre: az már egy teljesen más probléma és gondolom most sem tudod lekezelni. Oda már valami nyilvántartás kell (adatbázis), hogy mi történt meg és ha késik, akkor megtörténjen -e és ha igen, akkor mikor. Az a másik véglet, ha mindenre is jó megoldást akarsz, annak sem szokott lenni jó vége
Egyébként újraindulásnál érdemes azt is megnézned, hogy mikor történik az óra netes szinkronizációja. Hogy előtte elindul-e a szolgáltatásod. Egyébként systemd óta úgy emlékszem külön érdemes megadni a raspbianon, hogy várja meg a szolgáltatások indításával a netkapcsolatot. Mert anélkül ész nélkül elindít minden szolgáltatást és például hálózati meghajtók felcsatolásával is problémák vannak. Még a raspi-config utilba is tettek erre beállítást azt hiszem, szal elég lehet ott beállítani, hogy várja meg a netet.
A saját szolgáltatásodnak meg lehet függősége egy másik, példál olyasmi, ami az óra szinkronizációt elvégzi. Amíg az nem végzett, addig a tiedet nem indítja.
[ Szerkesztve ]
-
cog777
senior tag
válasz atesss #38948 üzenetére
Bocs hogy belevau ismet , nem birom ki.
Szoval szerintem tulbonyolitod, bar tanulas celzattal nem art, de egyszerubben is lehetne.
Hardveres megszakitas RPi-n felesleges, ilyen feladatokra. Pythonban sima Timer megteszi hogy bizonyos idokozonkent futtat valamit.En probaltam amugy FreeRTOS-t Arduino-n es mas MCU-kon, tenyleg preciz de sokkal sokkal jobban megbonyolitotta a fejlesztest, nekem az egyszeru feladataimhoz nem erte meg. Tanulni jo volt.
A cegnel mi markolo hidraulikat vezerlunk ahol 15 ms hataridok vannak, ezt egy linux meg rohogve tudja, real time nelkul is. (Azt hiszem 1ms-os pontossagu az alap utemezoje a linuxnak, ha fontos hogy az operacios rendszer nem vegye el a vezerlest a programodtol mas feladat futtatasahoz, akkor emelni kell a prioritasas, esetleg rootkent futtatni, vegso esetben real-time OS, vagy inkabb dedikalt hardver/MCU.)"Hanem szimplán csak arról, hogy az áramszünet okán a Raspberry órája kicsit elállítódott. És ha pont akkor áll vissza a pontos idő, amikor a scipten belül fut valamilyen"
"Itt nem arról van szó, hogy az áramszünet befolyásolt-e valamit. Hanem szimplán csak arról, hogy az áramszünet okán a Raspberry órája kicsit elállítódott. És ha pont akkor áll vissza a pontos idő, amikor a scipten belül fut valamilyen, a rendszeridőt kalkulációnak használó függvény, akkor ezt a függvényt az óra-átállítás "eltérítheti"."
En tovabbra is a monotonic orat hasznalnam kalkulaciora, pont erre van. Viszont ha nem akarod, akkor irj egy szolgaltatast ami var addig amig nincs internet, majd kenyszeritsd ki az idoszinkronizaciot.
Igy biztosan tudod hogy akkor tortent
Python program ping-el 8.8.8.8-at, ha van valasz akkor vegrehajtja a ntpdate parancsot (ezt talaltam google-ban, lehet h mas pl itt valami chrony-t emlit: [link] ), majd ertesiti a programodat (pl TCP, vagy MQTT kapcsolaton, egyszerubb esetben fajlon keresztul) hogy megtortent az idoszinkronizacio.Alternativakent, RTC-t kell hasznalni ha a logokban fontos a mp pontossagu ido.
Vezerlesre monotonic oratEsetleg kombinalni az RTC-t, UTC-t a logokhoz es a monotonicot a vezerleshez.
Szerk: azt meg beirom hogy mindig merlegelni kell hogy a gyakorlatban milyen surun lep fel a problema amit meg kell oldani. Ha surun, akkor komoly megoldas kell. Ha par evente 1x akkor felesleges tul sok energiat belelolni hacsak tanulni nem szeretnel...
[ Szerkesztve ]
HP ZBook Workstation A3000 - Linux Mint; Raspberry Pi4 - Raspbian
-
válasz atesss #38949 üzenetére
A 3m kábel projektről lemondtam*, inkább közelebb viszem a tápot/nem osztom meg mással a pi tápját.
A kapcsolós, jellemzően 1m-es kábeleket viszont tömegével árulják a kínaiak Alin és nem sok negatív feedbacket látni. OK, az is igaz, hogy nagyon kevesen terhelik 5W/1A felett a Pi-ket és ugye a fesz bukta az R*I...
Itt számolgatva egy méteren 2A már 130mV-ot bukik egy "minőségi" 20AWG/0.5mm2 kábelen, 3A pedig (Pi+HDD?) 200mV-ot, ami már egy 5,1V-os forrásból is 4,9-et csinál, amit tudomásom szerint a Pi nem szeret.
[ Szerkesztve ]
Mindig meglep milyen sokan hiszik el, hogy van ingyen ebéd.
-
cog777
senior tag
válasz atesss #38954 üzenetére
"Egyelőre csak a fájlon keresztüli menne. "
Ez egy remek "hack/workaround", ha gyorsitani szeretnel, akkor akar beteheted a /tmp-be, amit a ramba teszel tmpfs-re. Igy meg gyors is lesz es nem hasznalja az sd kartyat."De később akarok majd MQTT-vel is foglalkozni"
Irj ha kell segitseg, van mar tapasztalatom benne. TPC/UDP remek ha 2 alkalmazas kozott kell kommunikalni, MQTT pedig ha tobb alkalmazas kozott, vagy akar tavoli gepek kozott."Viszont ha már idő-alap: kisebb szervo és léptetőmotor vezérlés viszont abszolút előfordulhat."
Ajanlom az esp8266-ot, csupan 3.5 dollar raadasul WiFi kepes, szoval tud jelenteni az RPi-nek.HP ZBook Workstation A3000 - Linux Mint; Raspberry Pi4 - Raspbian
-
-
cog777
senior tag
válasz atesss #38958 üzenetére
"Erre tudsz ajánlani konkrét kódot ?"
Python-os topikban:
[link]
"Nézegettem már neten több félét, de van amit nem is teljesen értek, meg írnak az elcsúszás problématikájáról, stb."
[link]
A linked is ugyanezt csinalja csak szallal es nem Timer-rel, csak szerintem felesleges szamolgatni hanyadik iteracio tortenik.
current_time = datetime.now() f() num_calls += 1 difference = current_time - first_calledHP ZBook Workstation A3000 - Linux Mint; Raspberry Pi4 - Raspbian