Hirdetés
- Huawei Mate 10 Pro - mestersége az intelligencia
- Honor 200 Pro - mobilportré
- Magisk
- Milyen okostelefont vegyek?
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Samsung Galaxy Watch5 Pro - kerek, de nem tekerek
- Garmin Instinct – küldetés teljesítve
- Google Pixel 9 Pro XL - hét szűk esztendő
- iPhone topik
- VoLTE/VoWiFi
-
Mobilarena
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
-
#38901
AXisBOLD
addikt
wassermann
#38900
AXisBOLD
addikt
-
retesz147
addikt
Sziasztok!
Kérdessel fordulnék hozzátok.
Volumio-ról szertnék érdeklődni.
Tudja azt, ha rákötöm jack-el egy hangcuccra, akkor arra a házban lévő összes eszközről (laptopok, tabletek, android teló, iphone, macbook... ) tudok "küldeni" zenét?
Ez a zene lehet Spotify, Youtube, telón lévő zene, pc-n lévő hangfájl, netrádió?
Ha jól látom, pluginokat kell aktiválni, de ezek jól és megbízhatóan működnek?
Ismerősnek kellene.
Amolyan iEast cucc kellene. Vagy ne szórakozzunk és rögtön iEast?Köszönöm szépen!
Xiaomi 13 eu dev...
-
SD-hez képest szerintem számít, de ha transmission-t használsz akkor nem sok különbséget fogsz valószínűleg észrevenni.
Kifejtenéd?
- A program a memóriában fut, teljesen mindegy hogy honnan lett betöltve. Miért befolyásolná a sebességét, az, hogy SD-ről, HDD-ről, vagy SSD-ről tölti be a programot?
- Miért csak transmissionnál nincs difi?Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews
-
t72killer
titán
válasz
T-master
#38909
üzenetére
1Gbit ugyebár 128MB/sec, ennyivel nem fog tudni sd-karira cache-elni a progi (ha csinál ilyet egyébként), de normál írni se.
Ha megvannak a hozzávalók, én kipróbálnám pár tuti gxorsan jövő cuccal, hogy mennyivel jönnek pc-n és mennyivel egy full alap sd-kari pi-n.
[ Szerkesztve ]
30€ Meta store bónusz Quest headset aktiváláshoz, keress priviben :)
-
-
V.Stryker
nagyúr
Találtam egy érdekes beta-t a raspberry oldalán, de hiába csináltam frissítést, a mappákba nem került bele. Hol kéne keresni?
2020-07-31 Standardize USB port power control accross board revisions - BETATurn off USB port power for 1-second regardless of boot-mode. This appears to resolve an issue on R1.3 and older board revisions where some USB devices would fail upon reboot. On R1.4 USB port power is turned off automatically by the PMIC so this is just held in reset for longer. For earlier board revisions the USB port power is explicitly turned off via XHCI. This can be overriden via USB_MSD_PWR_OFF_TIME in the EEPROM config.Update to the latest Broadcom memsys FW - no significant functional change.
-
-
Tehát ismét jelentkezem -- eltelt némi idő, és a Raspbian HDMI-kimenetén nem jelenik meg olyan jel, amit a tévé képként értelmezne. "HDMI - nincs jel".
Ezt ugye pár nap/hét után rendszerint eljátssza.
SSH-n elérem, és a tanácsodra kiadott parancs eredménye a következő:
Tuning nincs, a videomemória 256 MB (RPI2).Köszönettel: MaCS
Fán nem lehet motorozni, motoron viszont lehet fázni!
-
#38916
wassermann
Topikgazda
V.Stryker
#38913
wassermann
Topikgazda
válasz
V.Stryker
#38913
üzenetére
"...találtam ki be kapcsoló gombra alíg egy-két hónapos leírást..."
Ez így szerintem félrevezető: inkább hívnám magyarul program-leállítónak, -elindítónak, mint bekapcsoló gombnak, ugyanis a PI-k kiegészítő hardver nélkül nem tudják kikapcsolni magukat, mint egy PC (nincs ACPI-hez hasonló áramkörük). Olyan keveset fogyasztanak, hogy állandó üzemre vannak tervezve.
Érdekes: visszakerestem és annak idején a ZX Spectrumnak sem volt kapcsolója :-)
-
Sziasztok,
egy rpi3-ason 6.1-es PiCorePlayert használok(nék) egy újraindítást követően azonban nem lehet erlérni a hálózaton. Fizikai link van az rpi hálókártyáján, a TV-re kötve, parancssorban nézelődve azonban látszik, hogy nem kapott ip-t, és a setup parancsot pedig nem lehet lefuttatni, hogy újra beállítsam pl a hálózatot.
Tönkremehetett az sd kártya, (nem létezik a pcp mappa a kért útvonalon)?
-
BalanceR
addikt
Csak egy tipp:
Ne vegyetek aliról filléres, kapcsolható USB kábelt...
- Gondoltam, ha már nincs a PI-ken kapcsoló, és néha azért lelőné az ember, jó megoldás lesz egy ilyen: [Kábel]
Hát sajnos nemy nyert, akkora ellenálása van a kapcsolónak, hogy a 60W-os töltő is csak 4.8V max 0,7A -tud átpréselni rajta, szóval hiába van fasza töldőd, kábeled, emiatt már villám ikont dobál a Pi.
Ugyanitt kapcsolós USB kábel eladó
#Raspberry #Orangepi #HassOS #Esp32
-
azbest
félisten
válasz
BalanceR
#38921
üzenetére
Valóban előfordulhat, hogy nagy az ellenállása. Viszont esélyes, hogy az a "60W-os" töltő (5v 12A??) valóban ki akarna adni nagy teljesítményt. Az okos töltők általában valamilyen kézfogással vagy legalább ellenállásokkal megadott terhelés értékek szerint adnak áramot. Szóval hiába van hűdeerős tápod, ha a pi buta tápcsatlakozójával nem tud kommunikálni és ezért 500mA-t ad ki mondjuk, mert az a szabványos usb2-es mód, vagy esetleg 900mA-t ha usb3-as terhelésre céloz.
-
BalanceR
addikt
-
azbest
félisten
válasz
BalanceR
#38923
üzenetére
Ez például pont lehet azért, mert az adatlábak nincsenek bekötve a kapcsolón. Így nem tud kézfogást csinálni és se a Pd se a QC nem tud működni, így visszavált buta és biztonságos, kisteljesítményű módra. A régi pi-khez kifejezetten mondták, hogy buta töltő kell. Az újabbaknál, ahol már chip-ben van a betáp kezelése, nem tudom van-e kézfogás.
A pi4 első szériánál viszont kifejezetten mondták, hogy nem működik a nagyobb teljesítményű typec töltőkkel, mert rosszul implementálták. Szóval az is buta töltővel biztos, okosból meg van amelyik laptop töltővel sem működik. Plusz a pi4-nél pont a butább, nem szabványos type-c kábellel esélyesebb a működés. Neked gondolom korábbi fajta van, nem pi4, mivel a kapcsoló sem type-c.
-
vtechun
veterán
Sziasztok!
Raspbian van a 3B+-omon. Van rajta Kodi is. Egész jól működik, de ha a Kodi fut és kikapcsolom a TV-t, akkor magátol vissza-vissza kapcsolgatja... Fut még Home assistant is a gépen, amivel tudom kapcsolgatni a tv-t, bemenetet váltogatni, de az mindig fut. Kifejezetten Kodi futása esetén kapcsolódik be véletlenszerűen a TV. Valaki tudja mitől lehet?
Köszi! -
t72killer
titán
válasz
BalanceR
#38921
üzenetére
Mico végű kapcsolós kábelem van aliról, simán gyorstölti a cuccaimat. Sajna végponti feszmérő kütyüm nincs hozzá, és micro-ra már nem is veszek. Egy c-s végű kábel úton van, esetleg c-n mérő kütyüt nézek valahol.
#38924: noigen, ha nincs meg a stabil 5.0+V/2A páros a valóságban, akkor cseszheti az ember a 40-60-100W-os csudákat. Azok a számok 20V-on értendők.
[ Szerkesztve ]
30€ Meta store bónusz Quest headset aktiváláshoz, keress priviben :)
-
#38927
wassermann
Topikgazda
vtechun
#38925
wassermann
Topikgazda
válasz
vtechun
#38925
üzenetére
"... Kodi futása esetén kapcsolódik be véletlenszerűen a TV. Valaki tudja mitől lehet?"
A HDMI kábelen nem csak a video és a hang megy át, hanem egy CEC-nek nevezett protokoll is működik a TV és a PI között (beszélgetnek). Ezt a CEC-et kell a Kodiban és/vagy a config.txt-ben letiltani.
-
-
#38929
wassermann
Topikgazda
MaCS_70
#38928
wassermann
Topikgazda
válasz
MaCS_70
#38928
üzenetére
Nem lehet, hogy téged is a CEC szivat?
Pl 1. a TV alvásba megy és ezt "közli" a Pi-vel, ami erre kikapcsolja azt a HDMI-kimenetet
Pl 2. Bekapcsol a Pi, megkérdezi a TV-t "mi van veled": erre az, a CEC-en keresztül "ki vagyok kapcsolva" választ adja, erre a PI nem kapcsolja be azt a HDMI kimenetet[ Szerkesztve ]
-
#38930
MaCS_70
félisten
wassermann
#38929
válasz
wassermann
#38929
üzenetére
Könnyen lehet, bár tudtommal a tévén nincs CEC.
Köszönettel: MaCS
Fán nem lehet motorozni, motoron viszont lehet fázni!
-
atesss
addikt
Üdv !
Hogyan lehet módosítani a Raspbian-nak (vagyis pontosabban most már Rasberry Pi OS-nek) a hálózati idő szinkronizációs beállításait ?
Még jobb lenne, ha valamilyen formában tudnék róla, hogyha módosítás történt a rendszeridőn.
Olyan python programkódot írtam, ami jó pár dolgot a rendszeridőt felhasználva csinál (lekérdezem a time.time()-al, és úgy mérem hogy épp mennyi idő telt el).
És ha futás közben megváltozik a rendszeridő, az adott esetben okozhat kavarodást a működésében.
De teljesen letiltani se akarnám, mert az nem lenne rossz ha induláskor egyszer lekérdezné (ha tudja), ha ez viszonylag gyorsan lefut. -
válasz
BalanceR
#38921
üzenetére
Pontosan mire jó ez a kapcsolós USB kábel? Értem én hogy áramtalanítsa a Pi-t, de attól a tápegysége még a 220-ban marad. Ugyanúgy fogyaszt, adott esetben felgyújtja a házat. Miért nem a 220-as ágat kapcsoljátok le?!
atesss
A script elejére letiltod a szinkronizálást
sudo timedatectl set-ntp false
A végén pedig engedélyezed
sudo timedatectl set-ntp true[ Szerkesztve ]
Freeware, és akciós programok egy helyen https://www.facebook.com/freewarenews
-
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 Studio 15.6 G8 Mobile Workstation - Windows 11
-
atesss
addikt
válasz
cog777
#38935
üzenetére
Igen, van olyan része is a kódnak, aminél a pontos idő a fontos.
Jól mondtad, ez a log, a releváns része így néz ki most a programomnak:import timefrom time import localtime, strftime...# MAIN függvényTimeStamp_Failure_Left = strftime("%Y-%m-%d %A %H:%M:%S", localtime())print("A hiba ideje: ", TimeStamp_Failure_Left)with open(LOG_PATH, "a") as logfile:logfile.write(TimeStamp_Failure_Left)logfile.write(' - Hiba az A motornal (LEFT) \n')Hát annyi, hogy viszont egyelőre - Pi elindulásakor - a rendszeridő beállításához szükség van a netes szinkronizációra. (Van ugyan RTC modulom, de nem nagyon akarnám használni, csak ha nagyon muszály.)
De később meg ha már fut a Pi, felesleges.
Bár ok, elvileg ekkor nem is kellene már ugrálnia.[ Szerkesztve ]
-
atesss
addikt
Ezt akkor valahogy így kellene a Python scriptembe írnom ?
os.system("sudo timedatectl set-ntp false")
Ha kilépek a python scriptből (pl most még a tesztelésnél, Ctrl+C-vel), akkor ez hogyan áll vissza ?
Ha valami ilyesmi van a main ciklusban ?except KeyboardInterrupt:GPIO.cleanup()os.system("sudo timedatectl set-ntp true") -
atesss
addikt
válasz
cog777
#38935
üzenetére
Ja és igen, most én is ezt az Epoch-os megoldást használom - a log kivételével mindenhol.
Pl. a legegyszerűbb ezek közül egy a kód működését/futását jelző ledet villogtató függvényem. Bár ugye ez pont nem annyira kritikus dolog, de most önálló példaként ezt tudtam egyszerűen leírni.SLOW_CYCLE_TIME = 1slow_time_previous = 0def run_flasher():global run_led_stateGPIO.output(RUN_LED, run_led_state)run_led_state = not run_led_state...# MAIN függvényslow_time_elapsed = time.time() - slow_time_previousif slow_time_elapsed > SLOW_CYCLE_TIME:slow_time_previous = time.time()run_flasher()[ Szerkesztve ]
-
-
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 Studio 15.6 G8 Mobile Workstation - Windows 11
-
atesss
addikt
válasz
cog777
#38940
üzenetére
Igen, ez jogos.
De a #38936-ben írt kódomban [link] azstrftime("%Y-%m-%d %A %H:%M:%S", localtime())
nem az Epoch-ot használja alapként ?
Azzal a különbséggel, hogy az oprendszer localisation -jét is beleszámolja, azaz - ha be van állítva a Magyarország - akkor mindig a megfelelő időzónában van, és állítja az időszámítást is. Így mindig a pontos helyi időt kapom.
"nagyobb idotavlatbol viszonylag pontos osszehasonlitasokat vegezzunk."
Nekem első körben arra kellhet a log, hogy tudjam mikor történt a hiba, össze tudjam hasonlítani a kamerák képével (ezt másodperc pontosan), tudjak beszélni az épp akkor dolgozó kollégával, stb. És ugye ő is a saját óráján ezt az időt "használja".
Második körben meg statisztikára (milyen gyakran fordult elő hiba összesen, pl. egy hónap alatt, illetve volt-e olyan hogy egy óra alatt nagyon sokszor).Az időszámítás miatti ugrálás viszont bizonyos esetekben tényleg gond lehetne...
Viszont az átállás ideje, az éjjel 3 óra az én esetemben abszolút üzemidőn kívül van, úgyhogy ez nem lesz gond most nekem.
Mondjuk máshol a LOG-ba lehet be kéne írni azt is, hogy egy óra-átállítás történt.time.monotonic() → floattime.monotonic_ns() → int
A felsőt én az eddigi time.time()-omhoz hasonlóan tudnám használni ?
Annyi, hogy jóval kisebb értékekről van szó. De a rendszerindítás után egy 15-20 sec úgyis biztosan el fog telni, mire elindul a python scriptem.
Mondjuk ezt akkor át kell gondolnom, mert asszem van ahol úgy adtam meg egy kezdeti értéknek (a program-induláskor) a time.time() visszatérési értékét, hogy az "Úgyis jó nagy lesz", és így - amíg nincs külön esemény, ami módosítaná ezt a változót - addig a "Jó nagy" miatt biztosan nem lesz igaz az egyik if szerkezetem.[ Szerkesztve ]
-
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 Studio 15.6 G8 Mobile Workstation - Windows 11
-
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 ]
-
atesss
addikt
válasz
azbest
#38943
üzenetére
"hogy kikapcsoláskor elmenti az utolsó ismert időt és újraindításkor alapból azzal indul a rendszer elvileg"
Az én gyakorlati tapasztalataim alapján így működik a Raspberry.
"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."
Igen, ez tényleg okozhat bizonyos esetekben problémát. Sőt, igazából a programozási esetek döntő többségében tényleg jobb az UTC, ez jogos.
De most nálam, ha gyakorlatban a #38941-ben írt felhasználása van a log-nak, akkor én úgy érzem hogy pont hogy jobb ha nem UTC időt használom. És így rögtön a szemem előtt az az időpont szerepel, amivel a többi dolgot össze tudom hasonlítani.Vagy - ha valamiért lényeges a helyi idő is - ti hogyan szoktátok azt fejben tartani ? Vagy egyszerűen kiszámolni ?
Mentsem le a fő logban mindkét időt ?
Vagy egy ilyen esetben ez hogyan lenne célszerű ?"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."
Hát, igazából van is. Konkrétan több darab ilyenem van: [link]
Sőt, - ehhez a projekthez - a nyákon meg is van már neki a hely, és a modulon át is forrasztottam a tüskéket derékszögűre, így be is dugható.
De ez most igazából egy teszt lenne, hogy mennyire kell a HW-es RTC. A későbbiekben lesz remélhetőleg több olyan projektem is, ahol nem lesz nyák az RPI-hez, így a HW-es óra körülményesebb és drágább. Nem lenne a GPIO-ra csatlakozó nyák, meg még egy - amúgy jó drága - HAT RTC modul se nagyon férhet el egy standard RPI házban, stb.
És most jelen esetben elég megbízható netkapcsolata lesz az eszköznek. Nem is egy otthoni/kisvállalati, hanem egy bérelt vonali kapcsolatról kapja az RPI a netet, fixen kábelen.
MOD:
"A lényeg, hogy sosem jár visszafelé az óra, mindig csak előre halad így."
Igen, ezt én is így sejtettem.
De ez is okozhat problémát.
Pl. van egy folyamatom, aminek megadok egy kívánt időtartamot. Legyen ez mondjuk 4 perc (240 sec). Ha a folyamat indítása előtt nem sokkal történt pl. egy rövid áramszünet (esetleg véletlen áram-lekapcsolás, stb.), akkor lehet hogy a rendszeridő már a folyamat futása közben frissül (növekszik). Így a végén a 240 sec-ből lesz aztán valami sokkal kevesebb.[ 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 ]
-
t72killer
titán
válasz
t72killer
#38946
üzenetére
Lejárt a szerk idő:
De 230V-os rendszerben is el tudok hasonlót képzelni, egy combosabb többágú mobiltöltő, ami egy rakat egyéb cucc mellé van dugva az elosztóba, etethet még egy telefont is, pláne ha a pi ki van kapcsolva. És ha van egy kapcsoló akkor nagyon egyszerű az újraindítás.Elgondolkoztam, hogy vajon az extra hosszú, pl 3m-es kábeleken mennyi feszültség eshet
?30€ Meta store bónusz Quest headset aktiváláshoz, keress priviben :)
-
atesss
addikt
válasz
azbest
#38945
üzenetére
"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."
Akkor ezzel a függvénnyel az alapból UTC-ben kiolvasott TimeStamp-ot alakítsam át ?
Most a konkrét esetben amúgy nem végeznék semmilyen műveletet vele, csak kiírnám a log-ba a már részletezett célokra.
De amúgy arra jó lehet az UTC használata, hogy akkor ezt a megoldást szokom meg már most. És így írom meg a kezelő-függvényeimet, amit akkor később - amikor már tényleg kell is az UTC - egyszerűbben újra tudok hasznosítani/ ismét fel tudok használni."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. "
Igen, ez teljesen jogos.
Annó Atmega-n használtam Timer Interruptokat. És nem a - HW-es működést elég komolyan elfedő - mostanában nagyon népszerű Arduino alatt, hanem a gyári IDE-vel (akkoriban még AVR Studio-nak hívták), közvetlen a regiszterek bitjeit címezve. Sőt, asszem még AVR-assembly alatt is használtam timereket.
Viszont mivel úgy tudom hogy a Raspberry Pi ilyen szempontból elég gyenge ehhez képest, így első körben nem erőltettem a Timer Interruptot.
(Lehet kivétel ha valami RealTime OS-t rakok fel rá, de ahogy sejtem az RTC hiánya miatt még az alatt sem lesz teljes értékű.)
De persze nem lenne rossz, csak kérdés mennyire bonyolult használni. Illetve ezekre a feladatokra még oké lesz, ledet villogtatni, meg ADC-t átlagolni.
De kicsit valamiért úgy érzem, hogy - bizonyos szempontból - hiába tanulnám meg. Mivel amit te írtál, hogy:
", de komolyabb feladatokra túl kell lépni ezeken."
Az a sejtésem, hogy bizonyos komolyabb feladatokra, ahol pontosabb időzítés kell, oda meg mégsem lesz elég ez sem."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."
Jó igen, ha olyan a feladat, hogy ez fontos, akkor ilyen eseteket tényleg csak így lehetne profin. De most erről azért nincs szó.
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"."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."
Igen, már a téma-indító hsz-emben is feltettem ezt a kérdést. Hogy hogyan lenne arról információm, hogy egy netes idő-szinkronizáció történt.
cigam ötlete közvetlenül ezt nem oldja meg, mert azzal csak letiltani tudnám meg engedélyezni a funkciót. De arról nem lenne információm, hogy egy rendszerindulás után megtörtént-e a "kezdeti" szinkronizáció."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."
Egyrészt: az internet-csatlakozás, és a hálózati idő-szinkronizáció megtörténte nem feltétlenül esik egybe.
Másrészt: azért ha esetleg nincsen net, attól még nem lenne rossz ha elindulna a scriptem.
Vagyis akkor be kéne rakni ide egy plusz timeout-ot is, hogy ha nincs netkapcsolat x idő után sem, akkor viszont indítsa el a scriptet, ne várjon a végtelenségig.[ Szerkesztve ]
-
atesss
addikt
válasz
t72killer
#38947
üzenetére
Akkor viszont ha az 5V-os oldalon akarsz kapcsolni, akkor itt a feszültségesés miatt valami normálisabb kapcsoló kell. Abba a kínai kapcsolós kábelbe minden bizonnyal az elérhető leggagyibb kapcsolót rakták bele...
Nekem is volt ilyesmi kábeles kapcsolóm. Egyik fele 5,5/2,1-es DC aljzat másik fele dugó, közte a kapcsolóval. Használhatatlan volt, már 12V-on is olyan feszültségesést produkált némelyik infrás analóg CCTV kamerával, hogy szakadozott a képe.
A 3m-es kábelnél már tényleg nagyon nem mindegy milyen minőségű. Mennyire vastag benne a réz.
Én mértem be annó microUSB kábeleket. Direkt pont Raspberry-vel való használatra. Volt egy olyan - minőségi, márkás, nagyobb magyar informatikai boltból beszerzett - 3m-es kábelem, amin a hosszához képest abszolút nem volt nagy a feszültségesés. Jobb volt mint némelyik ránézésre is gagyi 50-70cm-es... -
atesss
addikt
válasz
azbest
#38945
üzenetére
Közben rájöttem hogy az én függvényem ezt az időkonvertálást már nagyjából így is csinálja.
# Time in RFC 2822 Internet email standard: strftime("%a, %d %b %Y %H:%M:%S +0000", gmtime())# Magyar formátum szerinti: strftime("%Y-%m-%d %A %H:%M:%S", localtime())
Vagyis akkor jól gondolom hogy az alsó sor függvénye is az UTC időt számolja alapból, csak a végén csinál egy formázást, és a localtime-os formátumban írja ki (időzóna, időszámítás-t beleszámolja) ?
Kifejtenéd?
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 
Új hozzászólás Aktív témák
Hirdetés
- Az AI és a felhő számít, a tiszta energia nem: jó a szén is a tech szektornak
- Kecskemét és környéke adok-veszek-beszélgetek
- PlayStation 5
- PlayStation 5 Pro teszt
- Viccrovat
- VR topik (Oculus Rift, stb.)
- Socket AM5-ös ASRock alaplapok az AMD X870E/X870 platformon
- Konzolokról KULTURÁLT módon
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Számtech boltosok memoárjai, azaz amikor kiborulunk...
- További aktív témák...
- UItra 9 185H / 32GB DDR5 / Intel Arc GPU / 1TB SSD - Beelink mini PC
- i7 es Lenovó IdeaCentre pc
- AKCIÓ!!! GAMER PC SZUPER ÁRON: i5-12400F/14600KF - RTX 3060 Ti - Új 16/32GB DDR4 - GAR/SZÁMLA!!!
- JGamer PC V2 R7 1700 RX 5700 XT 16GB DDR4 512GB NVME 1TB HDD
- Gamer PC , i5 13400F , RTX 3070 , 32GB DDR5 , 512GB NVME , 1.2TB HDD
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest