-
PROHARDVER!
Arduino hardverrel és szoftverrel foglakozó téma. Minden mikrovezérlő ami arduinoval programozható, és minden arduino program, board, és hardverrel kapcsolatos kérdések helye.
Új hozzászólás Aktív témák
-
zsolti_20
senior tag
válasz
Janos250
#13498
üzenetére
Ezek egész jónak tűnnek. Főleg a második az automata érzékelő miatt, pont amilyen nekem is kellene. Nem tudom ez össze hangolható vagy sem arduinóval, esetleg olyan megoldást kell keresnem, hogy először wndowsra szkenneli be mondjuk egy excel fileba aztán abból dolgozik az arduino a továbbiakban.
-
Janos250
őstag
Srácok!
Érdemes gyalog megcsinálni a vonalkód olvasást, amikor 10-20 dollárért
kész Uart/USB/WiFi csatlakozású vonalkód olvasót lehet kapni?
Ami mellékesen többnyire még QR kódot is tud olvasni, ha esetleg a későbbiekben arra is szükség lesz. Van kézi, és beépíthető egyaránt.
Webáruházakban "barcode scanner"
Például:
link
link -
-
FeniX-
senior tag
válasz
FeniX-
#13493
üzenetére
Összeállítottam még egyszer: valóban, közös testtel működik. De ez nem gond? Egy 12v-os meg egy 5v-os "hálózat" közösre kötése?
Időközen látom a választ is, szóval köszönöm szépen, igen, így már jó.
50-80-100%-on változtatom. Tök jól megy!
(A konyha kamra részéhez akarok egy miniatűr szellőztető 'rendszert', ami a hűtő mögül kiszívja a meleg levegőt, egy másik részéből pedig hideg levegőt fúj be a kamrába.) -
válasz
FeniX-
#13493
üzenetére
Szia! A tranzisztor emitterét mindenképp össze kell kötni az arduino gnd-jével, különben nem jön létre az áramkör.
A ventilátort pwm-mel szeretnéd szabályozni? Először próbáld ki 100% kitöltéssel, és onnan csökkentsd a kitöltést, ne 0-ról felfelé, mert 30-40%-ig valószínűleg meg sem fog mozdulni. -
FeniX-
senior tag
Sziasztok, egy kis segítségre lenne szükségem. Egy viszonylag egyszerű áramkört akarnék összeállítani, de nem áll össze a kép, vagy nem értek valamit.
Egy arduinoval szeretnék irányítani egy 12v-os ventillátort, tranzisztor segítségével.Az arduinot egy 4b-os cerkaelem csomag hajtaná meg, a ventit pedig egy 8db-os cerkaelem-pakk. (tehát, 2 külön, független áramforrás)
Ha simán az arduino bármelyik PWM lábára programozok egy pár századmásodperces delayt és "kapcsolgatást", majd azt a tranzisztor bázisára kötöm, a 12v-os ventit pedig a saját áramforrásán keresztül a tranzisztor kollektorához, akkor ezzel nagyjából fel is vázoltam az egész kapcsolást.
Mégsem működik a cucc..
közös test kéne nekik?
(elvileg a tranzisztornak működnie kéne, 'ctbc 639 NPN', ha jól néztem) -
Remélem látszik a lényeg a képen.
Olyan optokapu kellene, ami nem infra fényt használ, hanem látható fényt, vagy egy egyszerű vörös lézerdióda + fototranzisztor, mert a fekete nyomtatófesték sajnos az infravörös fényt nem igazán nyeli el, nem lesz elég kontraszt a két jelszint megkülönböztetéséhez.
Rajzoltam egy lencsét a fény fókuszálásához, hogy a vékony vonalakat be lehessen olvasni, de ez egy lézerdiódánál talán el is hagyható. -
válasz
zsolti_20
#13490
üzenetére
Két teljesen különböző dolog, nem lézeres, és nem mér távolságot, bár közelség mérésére szokták használni (proximity sensor).
A lényeg, hogy a fekete és fehér felület más fényvisszaverő képességgel rendelkezik, egy fototranzisztorral pedig tudod mérni a fényerő változását, ahogy a csíkok sorban elvonulnak a szenzor előtt. Ehhez persze úgy kell nyomtatni, hogy ne keresztben, hanem hosszában jöjjön ki a vonalkód a nyomtatóból, tehát ha az optikát elhelyezed a nyomtató papírkiadó tálcája fölött, a csíkok maguktól átmenjenek alatta.
Megpróbálom lerajzolni neked. -
válasz
zsolti_20
#13485
üzenetére
Szia! Tudni kéne, hogy milyen bar code - magyarul vonalkód - lesz a matricán. Ha sima 1D (vmilyen EAN) kód lesz, akkor a legegyszerűbb egy reflektív optokapu lenne! A kód egy egyszerű bitsorozat, ha a nyomtató papírmozgató mechanizmusa egyenletes sebességgel tolja ki a papírt, akkor egyszerűen mérni kell a jelek hosszát, és visszafejteni belőle az adatot.
-
Dißnäëß
nagyúr
Sziasztok !
Tudom, hogy alapvetően komponens szórástól függ, mennyire pontos, de: használtatok már Arduino féle állatot feszültség és áram mérésre (akár logolás, akár kijelzés, akár csak védelemként) valamilyen elektronikai eszközben ?
Lenne egy második kérdésem is: mennyi RFI/EMI-t okoz egy Arduino egy "muszály csendesnek lenni" környezetben ? Gondolom, töredékét még egy Pi-nek is, de kb. számottevő, vagy nem kell foglalkozni vele, annyira szinte semmi ? Most csak úgy árnyékolatlanul ott van egy sarokban a sasszi aljára csavarozva négy műanyag távtartóval. (És egyelőre jó így). Ja, wifi és bluetooth mentes eszközről kérdezem ezt. (Leonardo).
-
zsolti_20
senior tag
Üdv emberek!
Van valakinek tapasztalat bárkód (bar code) szkenneléssel kapcsolatban? Érdemes arduinora építeni vagy legalább egy raspberry pi szükséges?
A feladat annyi lenne, hogy kb minden műsodik mp-ben jön egy matrica egy nyomtatóból amin van 3 bárkód. Ebből csupán az egyiket szeretném használni de ezt sima szűréssel kitudom majd a későbbiekben választani. Először azt szeretném megoldani, hogy tudjak egy olyan eszközt készíteni ami minden matricáról képes beszkennelni azt a 3 bárkódot és elmenteni azt bárhová amit a későbbiekben elő tudok venni. Találtam pár projektet az USB bárkód szkennelőhöz, de úgy gondolom jobb lenne a csillagszkennelő ami a boltokban is található. Folyamatosan kellene olvasnia, nem gombnyomásra hiszen beidőzíteni a szkenelést lehetetlen lenne mert van olyan ami matrica ami 2.5mp múlva jön de van olyan ami mondjuk 4. Így csak akkor működhet a dolog ha folyamatosan be van kapcsolva a szkennelés funkció.
Létezik vagy lehetséges hasonlót csinálni? Sajnos PC-ről nem tudom kiolvasni ezeket, mert fizikálisan kinyomtatott matricáról szükséges a bárkódot leolvasni. -
repvez
addikt
válasz
Gergosz2
#13483
üzenetére
mindenképp valami 3d nyomtatásos megoldás lenne csak előtte egy működőképes megoldást kell találni amihez már lehet tervezni a kialakitást.
Egyébként azon gondolkodtam, hogy nem feltétlenül kell kör keresztmetszet. így nem kellene a cső közepében elforgatni a szűkítő lapot hanem elég valamelyik oldalhoz csatolni, viszont az alábbi probléma akkor is fennáll, hogy hogy lesz a szűkítés után mérés és hogy marad meg a megváltozott paraméter
-
repvez
addikt
[link]
Első körben olyasmire gondoltam mint a hajtómüvek gáz sugár fokozó redőnyei.vagy a videon látott sugárforditó
Ami nem is lenne rossz ötlet csak az a gondom vele, ha a csö végére teszem akkor ott már nem tudom mérni a levegő nyomását vagy a sebességét , mert a külsö térrel érintkezve már nem ad jó eredményt. ha beteszem egy cső közepébe ,hogy az elötte utánna értéket össze tudjam hasonlítani, akkor is hasonló a helyzet, hogy a szűkület után visszatágul a cső és ezzel a levegő értékei is megváltoznak és a csö végén már nem a megfelelő hatást éri el.
Bár ha ez a változás statikusan mindig ugyan annyi akkor talán lehet vele korrigálni.A probléma lényege, hogy egy közös nagyméretű csövön jövő levegőt kellene 4 vagy több kisebb részre elosztani, hogy mindegyiknek külön külön lehessen mérni, szabályozni a paramétereit (mennyiség, nyomás, sebesség.)
-
atesss
addikt
válasz
repvez
#13475
üzenetére
"DE a legjobb valami olyan lenne ami csak a keresztmetszet szűkítésével operál és nem zavarja meg az áramlást a csőben mint egy keresztbe tett lap."
Ez nem is rossz ötlet.
Ha tényleg elég rugalmas és tartós a csöved, akkor esetleg lehetne olyat csinálni, hogy egy szalagot/kötelet meghúzva, "összehúzod" a csövet. Nyilván ez csak egy bizonyos határig működik (csőtől függő, de szerintem a min. olyan 1/4 átmérő lehetne, még valami spécin rugalmas csővel is).
Tehát egy motor tengelye egy szalagot húz meg/enged el (ami mondjuk egy kis orsóra/rúdra fel van tekerve). Amikor meghúzza, akkor ezzel összehúzza a csövet. Amikor meg elengedi, akkor a cső a saját rugalmassága segítségével nyomja magát vissza eredeti állapotába.
Persze még külön kiépített, megfelelő végállások is kellenének, hogy biztosan ne húzza túl a csövet.
Elvileg a motor-fordulatok száma az orsó kerületével szorozva megadja az áramlási cső kerületének csökkenését. De a gyakorlatban itt is ki kellene a léghozamot úgy mérni, mint ahogy az előzőre is írtam. -
atesss
addikt
válasz
tibi-d
#13477
üzenetére
"mert a szelep zárásával nem lineárisan változik a levegő mennyisége."
Ha szervóról beszélünk, akkor azzal elvileg viszonylag pontosan szabályozható a szelepnek a szöge. Persze ha az egyéb mechanikai elemek is eléggé merevek ehhez.
Szerintem ha egyszer kiméred műszerrel, hogy milyen szervó állásnál mennyit szállít (mondjuk 10-20 különböző állásban), akkor abból már tudsz csinálni egy függvényt. Vagy akár csak egy look-up-table-t, interpolációval. És onnantól az alapján már vezérelheted. Nyilván nem lesz óriási a pontossága, de ha nem speciálisabb ipari rendszerbe kell, akkor szerintem a célnak megfelelhet. -
tibi-d
tag
válasz
repvez
#13475
üzenetére
Sajnos ez a feladat még ipari technikával is nehéz feladat, mert a szelep zárásával nem lineárisan változik a levegő mennyisége. A szelep fél állásában, szinte még semmit nem csökken a légáram. Ha precízen kéne légáramot szabályozni, akkor kéne egy ballon, aminek a nyomását lehetne szabályozni, és egy állandó keresztmetszetem elszállítani a levegőt. Így a nyomással arányos lesz a szállított levegő mennyisége. Ehhez szabályzó elemeket nem könnyű beszerezni, és az áruk nincs arányban a lehetőségekkel.
-
repvez
addikt
válasz
gyapo11
#13474
üzenetére
ilyesmire gondoltam, de nem találtam sehol ekkora méretben vagy aminél már alapbol be lenne épitve arduino kompatibilis servoelektronika a vezérlésre.
DE a legjobb valami olyan lenne ami csak a keresztmetszet szűkítésével operál és nem zavarja meg az áramlást a csőben mint egy keresztbe tett lap.
-
repvez
addikt
valaki tud olyan szelepről ami a levegő mennyiségét tudja szabályozni 0-100% között és elég gyorsan ?
Pl ha van egy ventilátor ami fújja be a levegőt egy csőbe akkor ezen a szelepen keresztül haladva lehetne szabályozni a levegő mennyiségét?
kb 1-2 cm es átmérőben kellene -
Tankblock
aktív tag
válasz
atesss
#13471
üzenetére
Schmitt trigger alkalmazol, vagy a gomb helyett egyszerű érintő panelt pl TTP223
Problem solved.Ha meg szálaid vannak akkor meg nem mind1? írsz egyet ami figyeli h 1be vált-e az interrupt ban lévő flag. Amint lefutott amit szerettél volna és eltelt + 50 ms akkor 0 -ra váltog a flaget...
-
atesss
addikt
"Azért ettől még nem raknám be a main-be."
Mármint ezt magára a port-lekérdezésre és a feldolgozásra értettem.
Az "órás mérés" az, amit viszont beraknék a main-be.Közben viszont kiderült, hogy az event detection függvény:
- Tud olyan kapcsolót is, hogy ... , bouncetime=xxx [msec]
Ez így kb. azt valósítja meg készen, amit te írtál első opciónak. Amint van egy interrupt, onnantól vársz 80ms-ot (ilyenkorra ugye már biztosan nem lesz 0-sban az INT pin, mivel pont ez a cél vele).
Szóval ez most nekem nem túl jó megoldás.
- Alapból Threading-ként, többszálúan működik [link] (Install RPi.GPIO version 0.5.2a for multiple threaded callback interrupts)
És nem találtam rá opciót, hogy kikapcsolható lenne a Threading (egy ezt még nem tudó régi verziót - csak ezért - meg nem akarnék felrakni)."Ezért is nem érdemes az interruptot letiltani."
Pedig ezzel próbálkoztam most. Első körben csak hogy csak egy gombra megoldjam a pergésmentesítést kb. valahogyan.
De hát nem akar így sehogy se menni, szóval megyek tovább úgy, hogy nem tiltom le az interruptot. -
válasz
gyapo11
#13468
üzenetére
Az ilyen gyors reagálást igénylő feladatokhoz sokkal alkalmasabb a gumi kontaktusos nyomógomb (pl. távirányítók, gamepad-ek gombjai stb), az ugyanis nem pereg, így nem kell prellmentesíteni.
Cserébe nem zár nullára, de ez egy nyomógombnál többnyire nem is okoz problémát.A zongorabillentyűkről jut eszembe: akár optokaput is lehet ilyen célra használni (szerintem a szintetizátorok sebességérzékelős billentyűmechanikáját is valahogy így oldhatják meg).
-
válasz
atesss
#13467
üzenetére
"Viszont itt már figyelni kell rá, hogy mi van ha pl. két gombot egyszerre nyomtál le."
Erre egészen egyszerű a válasz: minden gombhoz külön-külön kell egy számláló, nem az interruptok közti időt kell számolni. Ezért is nem érdemes az interruptot letiltani.
"Azért ettől még nem raknám be a main-be."
Ezt írtad: "Lehetne az Interruptot ugyan letiltani ilyenkor, de helyette a MAIN ciklusban "órával" mérni, hogy mikor telt el már több mint 80ms."
-
gyapo11
őstag
Sokszor jó a sw megoldás, az én teszt óraprogramomat is egy sima kontaktussal vezéreltem, 50 ms körüli időt vártam, és tévesztés nélkül működött jól. De koszosabb vagy oxidos, szulfidos stb. érintkezőkkel, lassúbb nyomással, remegő kézzel adódhatnak problémák, vagy már olyan hosszúra kell nyújtani a várakozást, ami gondot okoz. Az én tesztem mikrokapcsolóval az volt, hogy a legrövidebb pöccintés is 50 ms körüli időre zárta az áramkört. Ez nyilván kapcsolótól és kéztől függ. De így 150 ms-on belül simán be tudok vinni két pöccintést, viszont ha 100 ms-ot vár a program, akkor már nem. Hw megoldással pedig bármennyit, ott az emberi képesség a határ. Pl. zongora billentyűket 4 ujjal simán lehet gyorsabban nyomogatni. 4 billentyűt egymás után. De akár egy db mikrokapcsoló is képes gyorsabb működésre, ha nem ember nyomogatja, hanem szalagon haladó dobozok vagy ilyesmi.
-
atesss
addikt
"de ha kiveszed a feldolgozást az interruptból és a main-be teszed"
Azért ettől még nem raknám be a main-be. Az Interrupt megtörténte átállítana egy Flag-ként használt változót. És akkor innentől indulna el az időmérés a main függvényben (innentől minden ciklusban lefutna a mainben az, ami ellenőrizné mennyi idő telt el).
Amint az eltelt idő több mint 50ms, akkor indítanám a "tényleges interrupt-handler" , azaz a PCF8574-et kiolvasó, és utána az ezt a kiolvasott értéket meg feldolgozó függvényeket.
"Ennek a módszernek a hátulütője, hogy minimum 50ms-al lassítja a program reagálását."
Ez sajnos így van, ez speciel tényleg nem tetszik ebben a megoldásban.
"Ha fontos az azonnali reagálás, pl vmi időzítő kapcsolódik a gombnyomáshoz, akkor az első interruptra indulhat a művelet, és utána kell figyelni, hogy a mondjuk 80ms-belül érzékelt újbóli gombnyomást figyelmen kívül kell hagyni."
Ez tényleg gyorsabb. Viszont itt már figyelni kell rá, hogy mi van ha pl. két gombot egyszerre nyomtál le.
Akkor ha tényleg eléggé egyszerre történt a megnyomás (80ms-on belül), akkor simán előfordulhat, hogy ugyan az első beolvasás időpontjában (1-2ms után) még csak az egyik gomb volt lenyomva. De viszont a 80ms vége után (amikortól megint újra figyelnénk a változásokat), viszont már mindkettő, és így már többé nincs változás --> nincs Interrupt.
Vagyis a második gomb lenyomása így akár el is veszhet. -
válasz
atesss
#13465
üzenetére
Ez jó ötlet, de ha kiveszed a feldolgozást az interruptból és a main-be teszed, akkor nem is kell letiltani az interruptot, csak azt vizsgáld, hogy a gomb állapota mikor változott utoljára. Mented az utolsó változás idejét, és ha eltelt azóta pl. 50ms, akkor mehet a művelet.
Ennek a módszernek a hátulütője, hogy minimum 50ms-al lassítja a program reagálását. Ha fontos az azonnali reagálás, pl vmi időzítő kapcsolódik a gombnyomáshoz, akkor az első interruptra indulhat a művelet, és utána kell figyelni, hogy a mondjuk 80ms-belül érzékelt újbóli gombnyomást figyelmen kívül kell hagyni. Ennek pedig a zajérzékenység a hátulütője. -
atesss
addikt
válasz
gyapo11
#13462
üzenetére
2db egy-áramkörös záró mikrokapcsoló van, ilyesmi: [link] (Hiába nézne ki elsőre két-áramkörösnek a 4 lába miatt, nem az.)
Illetve van még 4db DIP-kapcsoló, ilyesmi: [link]
Utóbbinál is lehet pergés tulajdonképpen, szóval azt is meg kellene oldani akkor már.
És ráadásul már elég kevés helyem is van a nyáknak azon a területén, szóval helytakarékosnak is kellene lennie (pl. 1-2 raszteres alkatrészekből).
MOD:
aryes
Hát igen, a SW-es megoldás jobban tetszene.
Bár most ugyan nem számítana, de - kvázi tanulási célból is - olyan megoldást szeretnék ami azért kicsit elegánsabb.
Szóval sleep-et nem szívesen raknék be, mert amúgy indokolatlanul lassítja a program működését, sőt fixen egy időre megakasztja.
Ami az ötletem lett helyette:
Lehetne az Interruptot ugyan letiltani ilyenkor, de helyette a MAIN ciklusban "órával" mérni, hogy mikor telt el már több mint 80ms. És ha ez eltelt, csak akkor indulna el a tényleges interrupt-handler függvény. A függvény végén pedig újra engedélyezni az Interruptot, globálisan. -
válasz
gyapo11
#13462
üzenetére
De jelen esetben is egyszerűbb a szoftveres megoldás: interrupt esetén kell egy kb. 50-80ms sleep (ezalatt természetesen az interruptokat letiltani, hogy ne okozzon zavart a pergés miatt a többszörös interrupt), csak utána beolvasni a portok állapotát. A gomb elengedése esetén ugyanez, csak itt az eredményeket eldobjuk, ha nincs művelet gomb felengedésre.
-
válasz
atesss
#13461
üzenetére
"Na de ténylegesen ez a GPIO-olvasási művelet lassú (az adott programkód lefutása sok idő)? "
Nem tudom pontosan hogy működik, mert sosem merültem el ilyen szinten a raspberry lelkivilágában, de úgy olvastam, hogy a python nem közvetlenül éri el a gpio-t, mint a C programok, hanem fájlként kezeli (talán a /dev/pigpio-t (?) írja-olvassa), ezért elég lassú, ~1ms egy művelet. Ha hülyeséget írtam, akkor javítson valaki.
-
atesss
addikt
Igen, ez a hardveres pergésmentesítés tényleg probléma forrás.
Ezt milyen kapcsolással tudnám megoldani a lehető legegyszerűbben ?
Ugyanakkor ezt az elég fura, programkód-alapú hiba forrást (konkrétan én ezt valami bug-nak sejtem már) valószínűleg nem oldaná meg.
Miért lesz teljesen más az INT pin működése - a szkópon is láthatóan - , ha beteszek egy már kész (fixen feltöltött) változót kiprintelő függvényt ??
(Jó párszor lefuttattam direkt, szóval a pergés miatti különbséget ebből a szempontból kizárhatjuk.)
"És az INT láb értékét ne olvasd közben, mert ahogy írtam, python-ból ez is lassú, talán még lassabb, mint az i2c."
Na de ténylegesen ez a GPIO-olvasási művelet lassú (az adott programkód lefutása sok idő)? Vagy pedig amit már írtál egyszer korábban hogy bizonyos időn belül újra meghívva nem frissíti a korábban lekérdezett állapotot ?
Bár azt azért kipróbálnám, hogy mi van ha kiveszem, azif GPIO.input(I2C_IO_INTERRUPT_GPIO) == 0:
feltételvizsgálatot, és úgy olvasom be folyamatosan i2c-n a port állapotot. -
válasz
atesss
#13458
üzenetére
Azt hiszem végre sejtem, mi lehet a háttérben.
Van hardveres pergésmentesítés a nyomógombon? A kolléga már kérdezte, de nem adtál rá választ. Ha nincs, az egész teszt ebben a formában értelmetlen, mivel a lenyomástól számított 50-100ms-on belül a kapcsoló a pergés miatt random időközönként nyit-zár, mire megnyugszik. És mivel - ahogy Te magad is írtad - az INT láb az elengedésre is triggerel, ha interruptot állítasz be a gombnyomásra, a legelső kiolvasás után még számtalanszor tüzelhet az INT, mire beáll.
Ha igazam van, akkor ezt akkor fogod látni a szkópon, ha sleep nélkül folyamatosan olvasod az i2c port állapotát végtelen ciklusban (ezzel törölve az INT láb aktív állapotát). És az INT láb értékét ne olvasd közben, mert ahogy írtam, python-ból ez is lassú, talán még lassabb, mint az i2c. -
atesss
addikt
No már elkezdtem írni hogy mi lehet ennek az "anomáliának" az oka.
Aztán miközben írtam, esett le hogy mi is van:
Mivel a --változásokat-- figyeli a PCF8574, akkor is van ugyanúgy interrupt, amikor elengedem a gombot (az INT pin akkor is 0-ba megy).
És a gombot jelző sárga jel ugye így pont az inverze. De amúgy semmi más különbség nincs, most teszteltem.
Valószínűleg csak annyi történt, hogy a 3. képnél még nyomva tartottam a gombot, amikor csináltam a képet. Vagy esetleg STOP-oltam a triggerelést a szkópon.
A sárga mérőfej magán az input porton volt (illetve egy 20cm-es hozzáforrasztott kábel végén).
A kék mérőfej pedig magán az INT porton (szintén egy 20cm kábelen).
A felhúzó ellenállás még nem került fel. Írtam, hogy direkt úgy tesztelem most a szkóppal, hogy még nem forrasztom fel őket.
Az I2C-s mérés is egy jó ötlet lenne. De közben még tesztelgettem, és egyértelműen programkód-oka van a dolognak.
Ámde azon belül valami nagyon is fura oka...
Direkt kiszedtem a GPIO interruptot. Illetve a PCF8574 beolvasását is közvetlenül a MAIN-be raktam (kiszedtem még a MAIN-ből meghívott függvényből is). De erre nem lett változás.
Eddig amit találtam hogy "megoldja" a problémát, ha kiprintelem a tömböt, amibe előtte már beolvastam a PCF8574-nek a portját.
Próbáltam, hogy kiprintelek egy másik, teljesen ugyanilyen adat-szerkezetű tömböt, de arra meg nem.
Szóval egyelőre tiszta X-akták...if GPIO.input(I2C_IO_INTERRUPT_GPIO) == 0:# i2c_io_readed_array = i2c_io_reader()print("------")io_interrupt_flag = GPIO.input(I2C_IO_INTERRUPT_GPIO)print("Interrupt pin állapota - olvasás előtt: ", io_interrupt_flag)print("--")i2c_io_readed_array = i2c_io.portif len(i2c_io_readed_array) == 8:# passprint("az előző kiolvasás megfelelően megfordított értéke: ", i2c_io_readed_array_reversed)teszt = i2c_io_readed_array# print("A beolvasott port tömbje egy külön [teszt] nevű változóba átmásolva: ", teszt)# print("PCF8574 Port beolvasva. A beolvasott port tömbje:", i2c_io_readed_array)time.sleep(0.125)io_interrupt_flag = GPIO.input(I2C_IO_INTERRUPT_GPIO)print("Interrupt pin állapota - 0.125 sec-el olvasás után: ", io_interrupt_flag)print("------")i2c_io_readed_array_reversed = i2c_io_reverser(i2c_io_readed_array)i2c_io_state = i2c_io_namer(i2c_io_readed_array_reversed)i2c_io_evaluator(i2c_io_readed_array_reversed, i2c_io_state)i2c_io_printer(i2c_io_readed_array_reversed, i2c_io_state)
A legbelső if-ben láthatóak a tesztelt "feltételeim".
Csak az utolsó két, most #-el kikommentezett print() bármelyike oldja meg a problémát (természetesen a teszt változós csak akkor ha előtte megvan az értékadása is).
Ez valami eléggé érdekes bug lesz... -
And
veterán
válasz
atesss
#13456
üzenetére
Az nem világos, hogy ha gombnyomásra indul a folyamat, és az input portra kerülő jelet - vagyis a gombnyomást, ami GND-re húz - a sárga görbe írja le, akkor miért csak a 3. képen szerepel ez a jel lefutó éllel, a másik kettőn pedig felfutóval? Egyáltalán, hol volt a mérőfej, magán az input porton, vagy a soros ellenállás előtt? Amúgy végül került arra a portra felhúzó vagy sem? Bocs, ha említetted volna, de nem találom ezt az infót.
Az is egy érdekes mérés lenne, ha a második csatornán nem az INT-jelet vizsgálnád, hanem magát az I2C-jelfolyamot, hogy az hogyan viszonyul időben a fizikai bemenet változásához képest. -
atesss
addikt
No a szkópos mérés alapján úgy néz ki hogy mégiscsak valahogy a programkód okozza a problémát.
Az 1. ábrán nem volt sleep a python scriptben a kiolvasú függvényemben a PCF8574 kiolvasása után: [kép]
A 2. ábrán 35 ms sleep() volt: [kép]
A 3. ábrán pedig 125 ms sleep() volt: [kép]A kék az INT pin.
A sárga pedig a nyomógomb amit megnyomtam, és a PCF8574 egyik bemenetét húzza földre egy ellenálláson keresztül. -
And
veterán
válasz
atesss
#13452
üzenetére
"Mondjuk már így előre felmerült bennem, hogy ilyen "egy-impulzusos" jelre hogyan fog tudni szinkronizálni a szkóp.
Minek kellene lennie majd a trigger-forrásomnak ?"
Egyszerűen nem automata triggerelést választasz (amikor ész nélkül fut a sugár akár van trigger, akár nincs), hanem normál vagy 'one shot' módot - hívják akárhogyan, a lényeg, hogy csak triggerre induljon a mérés. A trigger szintjét féltápfesz környékére választod, a típusát pedig lefutó élre. -
atesss
addikt
válasz
gyapo11
#13450
üzenetére
De mivel többször is mértem, így eléggé valószínűtlen hogy minden mérésnél pont a rövid impulzusba mért volna bele.
Mindegy, ma du. végre kiderül, ma meg tudom mérni szkóppal.
A PCF8574 bemeneti pinjeire erősen ajánlott ellenállásokat is megveszem, de még direkt nem forrasztom be, előtte kimérem szkóppal ezt az anomáliát.
Mondjuk már így előre felmerült bennem, hogy ilyen "egy-impulzusos" jelre hogyan fog tudni szinkronizálni a szkóp.
Minek kellene lennie majd a trigger-forrásomnak ?
Rigol, digitális, elég nagy tudású (és sajnos a bonyolultabb funkciókat nem is nagyon tudom használni). -
gyapo11
őstag
válasz
atesss
#13448
üzenetére
A multiméter másodpercenként 2-3 mintát vesz, és azt kijelzi 0.5-0.33 másodpercig. Nem tudom a konkrét mintavétel meddig tart, de ha rövid ideig, és a tárolt mintát méri meg, akkor ha egy 1 ms-os 5 V-os impulzusba éppen belemér, akkor akár fél másodpercig mutathatja, hogy 5 V, ez szemmel már jól észlelhető. Az analóg műszer más, de azt nem hívjuk multiméternek.
-
atesss
addikt
Na most próbálkoztam tovább még más sleep időtartamok megadásával.
Illetve a main függvénybe (ami másodpercenként kb. 70-80x lefut) is beraktam egy kiiratást.
Nekem úgy tűnik, hogy hiába adok meg kb. bármilyen időtartamot...Viszont a main függvényben lévő kiiratás meg már az első alkalommal is HIGH-nak írja az INT pint. Mindegy, hogy ez az előbbi sleep idő most éppen néhány msec volt, vagy 400msec...
Lehet hogy amint kilépek ebből a i2c_io_reader() függvényből, akkor frissülhet csak a GPIO pin állapota ?? -
atesss
addikt
Hát én erősen kétlem.
A PCF8574-hez ezt a python library-h használom: [link]
Most közben frissítettem a kódomat, és az INT pin-t most már nem pollinggal, hanem interrupttal kezelem le.
De a problémás résznél nem történt semmi változás.
Bemásolom akkor az összes releváns részét a kódomnak.
Bár ez már így kicsit OFF kezd lenni, mert az Arduino miatt általában C vagy C++-t szoktatok írni a topicba.import RPi.GPIO as GPIOI2C_IO_INTERRUPT_GPIO = 26 # Board (physical) Pin Number 37GPIO.setmode(GPIO.BCM)GPIO.setup(I2C_IO_INTERRUPT_GPIO, GPIO.IN)from pcf8574 import PCF8574I2C_PORT_NUM = 1I2C_IO_ADDRESS = 0x20i2c_io = PCF8574(I2C_PORT_NUM, I2C_IO_ADDRESS)def i2c_io_reader():io_interrupt_flag = GPIO.input(I2C_IO_INTERRUPT_GPIO)print("Interrupt pin állapota - olvasás előtt: ", io_interrupt_flag)i2c_io_readed_array = i2c_io.porttime.sleep(0.001)io_interrupt_flag = GPIO.input(I2C_IO_INTERRUPT_GPIO)print("Interrupt pin állapota - 0.001 sec-el olvasás után: ", io_interrupt_flag)return i2c_io_readed_arraydef i2c_io_interrupt_handler(channel):i2c_io_readed_array = i2c_io_reader()i2c_io_readed_array_reversed = i2c_io_reverser(i2c_io_readed_array)i2c_io_state = i2c_io_namer(i2c_io_readed_array_reversed)i2c_io_evaluator(i2c_io_readed_array_reversed, i2c_io_state)i2c_io_printer(i2c_io_readed_array_reversed, i2c_io_state)GPIO.add_event_detect(I2C_IO_INTERRUPT_GPIO, GPIO.FALLING, callback=i2c_io_interrupt_handler) -
atesss
addikt
A kódba beraktam debug-nak plusz lekérdezéseket, ami lekérdezi az INT lábat, és kiírja a terminalra.
Közvetlenül az I2C-s kiolvasó függvény elé is raktam be, illetve közvetlenül utána is.
Plusz kipróbáltam azt is, hogy az I2C-s kiolvasó függvény után beraktam még sleep()-et. Először egészen rövidet (0.0001 sec asszem), gondolva hogy oké, alapból akkor "túl gyors" a Raspberry, de ha berakom a sleep()-et, utána már tényleg újra HIGH-ban lesz.
Aztán utána, hogy láttam hogy még mindig LOW maradt, növeltem ezt a sleep()-et. Elmentem egészen 0.1 sec-ig, és még akkor is LOW maradt. -
-
atesss
addikt
Adatlap 11.oldala:
Resetting and reactivating the interrupt circuit is achieved when data on the port is changed to the original setting or data is read from, or written to, the port that generated the interrupt. Resetting occurs in the read mode at the acknowledge bit after the rising edge of the SCL signal, or in the write mode at the acknowledge bit after the high-to-low transition of the SCL signal.
...
This device does not have internal configuration or status registers. Instead, read or write to the device I/Os directly after sending the device address (see Figure 16 and Figure 17).
By sending an interrupt signal on this line, the remote I/O can inform the microcontroller if there is incoming data on its ports without having to communicate by way of the I 2C bus. Therefore, PCF8574 can remain a simple slave device.Úgy néz ki ez nem tud ilyet, nem tudom felülírni az INT regisztert, mert nincs olyan neki (vagy legalábbis ha van is valami belső, kívülről nem hozzáférhető).
-
atesss
addikt
Hát a kódom elég gyorsan fut (kb. pár msec lehet egy teljes ciklus), ennyi időnként pollingolja a Raspberry-nek azt a GPIO bemenetét, amire rákötöttem a PCF8574-nek az INT pinjét.
Amint azt érzékeli a fő programszám, hogy 0-ban van ez a GPIO, rögtön meg is hívja a PCF8574-et I2C-n kiolvasó függvényt. A PCF8574 pedig a kiolvasás után magától, rögtön (adatlap szerint, ha jól olvastam ki, 4usec-en belül) alaphelyzetbe (azaz 1-esbe) állítja az INT Pint.
Tehát elvileg pár msec időre kellene csak megváltoznia az INT pinnek. Amit pedig egy multiméter észre se venne.
Szerintem - maximális eltérésként, de ez tényleg csak egy pillanatra (a multiméter-kijelzőt szemmel olvasva) - az a -1,5V körüli érték azt jelenti, hogy ennél jóval több időre megváltozott.
Nem tudom pontosan mekkora egy mezei multiméter sebessége, milyen ADC van benne, de kb. pár tized sec lehet a mérési illetve átlagolási ideje. A -1,5V kb. azt jelenti, hogy a megváltozott érték időtartama nem éri el az átlagolási időt, de közelít hozzá (nagyon durva becsléssel fele körül van).
De hát sokkal pontosabb lenne ezt szkóppal kimérni
Most már kíváncsi vagyok, asszem inkább várok, és nem is forrasztom be fixre a felhúzó ellenállásokat mielőtt letesztelném szkóppal.Nincs bekapcsolva a pulldown a raspberry-n.
-
And
veterán
A kötelező felhúzót a PCF8574-re írtam, az MCP-kben valóban van 100k-s belső kapcsolható ellenállás. A PCF INT-polaritásában igazad van, de ez eddig nem is tűnt fel
. Az adatlapon első blikkre kicsit megtévesztő. Még jó, hogy az MCP-k esetén az INT-jel polaritása is megszabható, meg az is, hogy csak open-drain kimenet legyen, vagy push-pull. -
atesss
addikt
Pedig nagyon úgy néz ki hogy kell külső felhúzó ellenállás a PCF8574-nél.
Legalábbis az adatlap 15. oldalán a "Typical Application" ábrájára gondolom hogy nem véletlenül rakták fel.
De most megint átnézve az adatlapot, igazából olyan infót viszont nem találtam leírva, hogy "muszály" tenni.
Az MCP23017 az könnyen lehet hogy más, simán lehet hogy abba viszont már építettek be. (Ez akkor még egy - nem is kicsi - előnye lenne akkor annak az IC-nek, illetve a rá épülő moduloknak.)Na ezt elírtam. Javítva így néz ki:
Amikor változás van, rendben 0-ba vált az INT pin. Utána kiolvasom az összes bemenetet, rendben látszik is hogy a PCF8574-nek melyik bemeneti pinje változott meg.
De az INT 0-ban marad ez után is, nagyon sokáig.És a multiméteres mérést is pontatlanul írtam:
"Multiméteren is felugrik az érték az INT pin-t mérve (ha pár msec lenne, akkor ezt nem mutatná ki), de szkóppal sajnos most pont nem tudom megnézni pár napig."
Ebben az esetben az INT pin-t a VCC-hez (3,3V-hoz) képest mértem.
Vagyis alapból 0-t mutat a multiméter (1-esben, azaz 3,3V-on van az INT). És ha Interrupt van akkor pedig a felugró érték egy negatív lesz (nem megy el -3,3V-ig, de kb. olyan -1,5V-ig igen).
De a lényegen ez igazából nem változtat. Az a probléma, hogy olyan hosszú időre megváltozik az Interrupt pin, hogy ezt még egy mezei multiméter is simán kimutatja. -
Nem kell külső felhúzó ellenállás, az MCP23017-ben például van belső felhúzó (asszem 100k).
atesss:
"Amikor változás van, rendben 1-be vált az INT pin. Utána kiolvasom az összes bemenetet, rendben látszik is hogy a PCF8574-nek melyik bemeneti pinje változott meg.
De az INT 0-ban marad ez után is, nagyon sokáig.
Direkt beraktam sleep-et, hogy teszteljem ezt, és még 0.1s után is maradt."Elolvastam vagy 5x, de nem értem.
Amikor változás van, miért vált 1-be az INT pin? A PCF8574 INT kimenete active low, vagyis az alaphelyzet az 1, és akkor vált 0-ra, ha van interrupt.
Szerintem fordítva ültél fel a lóra. -
And
veterán
válasz
atesss
#13432
üzenetére
"2,2kOhm-os ellenálláson keresztül húzzák földre a pineket, amikor átkapcsolom a kapcsolót/lenyomom a gombot."
A bemenettel soros ellenállás nem igazán kell, de ha maga a port nincs elhúzva a Vcc felé, az nem oké. Lehet 10kΩ is a felhúzó, az csak annyit eredményez, hogy aktív (alacsony) inputnál, megnyomott gombnál a rajta átfolyó áram nagyobb lesz. Nagyimpedanciás inputot amúgy sem szokás szabadon hagyni: extrém alacsonyra tervezett nyugalmi áram (pl. telepes táplálásnál) helyett megnövekedett nyugalmi áramfelvétel, határozatlan szint az eredménye.
16 portos MCP-verzió: MCP23017 (I2C) vagy MCP23S17 (SPI). -
atesss
addikt
Ahha, látom, igazad van.
100kOhm-ot ajánl felhúzónak. Most csak 10kOhm van itthon (már ha egyáltalán megvan az a maradékom még 8db), az esetleg jó lehet ?
A bemenetek közül 4db mikrokapcsoló, 2db meg mikronyomógomb. Ezek most egy-egy 2,2kOhm-os ellenálláson keresztül húzzák földre a pineket, amikor átkapcsolom a kapcsolót/lenyomom a gombot.
Így is jó lehet még a 10k ?Mondjuk azt még mindig nem annyira értem, ez hogyan okoz ilyen hibát. A - felhúzóellenállás hiányában - ha pl. a mosfet feltöltődik, akkor hogyhogy pont ilyen tizedmásodperc nagyságrendű idő lesz mire visszaáll ?
Illetve nem is. Ha az Interrupt Pin 1-es, akkor ez azt jelenti, hogy változott a bemenet.
Vagyis akkor lebeg a Pin, azaz 0 és 1 között ugrál folyamatosan ?Hát hozzávetőleges támpontnak jó az IC ára.
De igazából az a kérdés, a kínaiak mennyiért építettek rá kész modult.
Azt meg nem mindig lehet ilyen egyszerűen magyarázni. Pl. volt hogy néztem, hogy egy teljes modul ára a nagy(1000+) db-os tételben kapható IC áránál is jelentősen olcsóbb volt...MCP230xx-ból amúgy van 16 portos, vagy akár még annál is nagyobb kivitel ?
-
And
veterán
válasz
atesss
#13429
üzenetére
"Hát igazából felhúzó ellenállást nem raktam fixen a Raspberry GPIO pinekre, csak egy soros 330 Ohm-os ellenállást."
Nem is a RasPI GPIO-pinjeire gondoltam, hanem a PCF8574-re: ha a portjait csak inputnak használod (másképp fogalmazva: az I2C-busz csak olvassa a chip-et, sosem írja), akkor a portok mindegyikére illik 1-1 felhúzót tenni, lásd a rajzot a 15. oldalon, amire korábban hivatkoztál. Lebegve hagyni csak akkor lehet a Px-portok bármelyikét, ha kimenetként írod azokat (a többivel együtt).
"Utánanézek részletesen akkor ennek az MCP230xx-nek is. Csak persze az is kérdés, hogy mennyivel drágább ez a modul..."
Maga az MCP23008-as chip (ez a 8-portos, a PCF8574-hez hasonló kivitel) nettó 300 Ft körül kapható a hazai forgalmazónál, szóval van rá esély, hogy ha valaki nagy tételben veszi a gyártótól és modulra építi, akkor nem lesz veszett drága a PCF-es modulhoz képest. Ha nyákot is tervezel a kész kivitelhez, akkor meg mindegy, maga a chip is elegendő.
Emlékeim szerint volt már említve ebben a topikban az MCP23..-as I/O-extender, és mások is jó véleménnyel voltak róla. Létezik belőle SPI-buszos kivitel is, MCP23S08 típusjellel. Elég jól felépített, valódi kétirányú portokkal rendelkezik, 11 belső regisztere van és szanaszét konfigurálható. -
Tankblock
aktív tag
válasz
gyapo11
#13422
üzenetére
Egy normális SSDben van támogatva a wear leveling figyelése és nem ugyanoda irogat vissza, plusz a cachelése is jobb. SD nél meg max ha az oprendszer figyel rá....
Nálam SD kártyából több hallt már meg mint ssd/hdd ből...
Igen lehet RPi4 is SSDről futtatni/bootolni.
Attól én még hiszek a különböző lokációkon tárolt adatokban, azok nehezebben sebezhetőek... Bármely gépről hozzáférehetőek. -
atesss
addikt
Hát igazából felhúzó ellenállást nem raktam fixen a Raspberry GPIO pinekre, csak egy soros 330 Ohm-os ellenállást.
Mondjuk belegondolva ez - ha a GPIO bemenet Mosfet-es, amire jó esély van - akár okozhatna is problémát. Bár eddig még sehol nem fordult elő ebből problémám.
De ha pont ez okozná a gondot, akkor miért lesz a "GPIO-nullázódás" ideje pont ilyen "emberi léptékű" tized-másodperces időtartományban ?
Igen, mind a 8 pin bemenetként van használva.
Illetve pontosabban a 8-ból 2 nincs is használva, azt én nem is kötöttem be sehova.
Ugyan nem tudom a modulon belül van-e bárhova kötve, de igazából nem nagyon kellene. Főleg nem VCC-re.
Igen, azt néztem is hogy ezt "quasi-bidirectional" -nak írták. De eddig még nem mentem bele, hogy ez pontosan mit is jelent elektronikai szempontból.
"maszkolni a megszakítást (adott input eredményezzen-e olyat)" - Ez is hasznos mondjuk.
Hát ezek tényleg nagy előnynek hangzanak azért így együtt már. Utánanézek részletesen akkor ennek az MCP230xx-nek is.
Csak persze az is kérdés, hogy mennyivel drágább ez a modul...
Meg mennyivel nagyobb a modul nyákja, stb. -
And
veterán
válasz
atesss
#13426
üzenetére
A bemenetek mindegyikére tettél felhúzó ellenállást? Nincs prell a bemenet(ek)en? Egyáltalán: csak adatot olvasol a PCF-ből, vagyis minden portot bemenetnek alkalmazol?
Ennek a port extendernek az előnye - nem kell külön belső regisztereket konfigurálni - egyben hátrány is lehet. Egy jobban beállítható extender, pl. az MCP230xx esetén portonként be lehet lőni az adatirányt, maszkolni a megszakítást (adott input eredményezzen-e olyat), és az INT-kimenet működése is elég részletesen befolyásolható. -
atesss
addikt
Üdv !
Használt már itt valaki PCF8574 alapú I2C-s I/O modult ?
Azon belül is a különálló Interrupt Pin működése érdekelne.
Én ugyan most Raspberry Pi-n használom, Python kóddal, de ez a probléma nem úgy néz ki hogy ettől függene, a modul működésében lehet valami hiba vagy furcsaság.Ez az Interrupt pin arra szolgálna, hogy ha történik bármelyik PIN-en változás, akkor ez a pin megváltozik. A fő kontroller így elég ha csak annyit csinál, hogy ezt a pin-t figyeli (akár interrupt-al, de akár csak polling-al). És csak akkor állok neki az I2C-n keresztül kiolvasni a bemenetek állapotát, ha ez a pin jelzi hogy változás történt.
Az hátrány, hogy egy külön pin-t fel kell használni hozzá.
Cserébe a kód gyorsabb tud lenni, meg kevesebb erőforrást használ (nem használom folyamatosan az I2C buszt). Egy Arduino-n ez szerintem még inkább fontos tud lenni.Én konkrétan ezt a modult használom: [link]
Ahogy láttam, nem mindegyik modulnál van sajnos kivezetve ez az Interrupt pin.
Az IC adatlapja [link] elég részletesen leírja a működését (az INT működése részletesen: 11.old).
A 15. oldali példakapcsolás alapján kötöttem be (10 kOhm pullup VC-re). Annyi, hogy nálam nem rögtön megy a fő kontrollerre, hanem még van ott egy 330 Ohm ellenállás is sorosan (ezt biztonsági okból a Raspberry-nek minden használandó GPIO pinjére felraktam, kapásból, fixen).
Én úgy vettem ki a leírásból (meg ez is lenne a logikus), hogy ahogy csinálsz a modulról egy kiolvasást, akkor az INT pin rögtön "nullázódik" is. Ez elvileg mindössze 4us kéne legyen (adatlap: 5.old).
Amikor változás van, rendben 1-be vált az INT pin. Utána kiolvasom az összes bemenetet, rendben látszik is hogy a PCF8574-nek melyik bemeneti pinje változott meg.
De az INT 0-ban marad ez után is, nagyon sokáig.
Direkt beraktam sleep-et, hogy teszteljem ezt, és még 0.1s után is maradt.
A programkódom ennek ellenére jelenleg ellátja a feladatát, és épp a következő gomb-megnyomáskor vagy elengedéskor mégis újra meghívja a kiolvasó függvényt. Ezt még nem teljesen értem hogyan, most próbálom kideríteni
De attól még a modul nem működik úgy ahogy kellene.
Multiméteren is felugrik az érték az INT pin-t mérve (ha pár msec lenne, akkor ezt nem mutatná ki), de szkóppal sajnos most pont nem tudom megnézni pár napig.
Van valakinek ötlete ? -
gyapo11
őstag
Nekem volt XP-m ssd-n, és nem volt trim, mert az oprendszer nem támogatta. Win7 már igen. Nem lehet, hogy a Raspberryn futó oprendszeren múlik a dolog?
Másrészt a trim csak az írást gyorsítja, inkább a wear levelinget kellene megoldani sd-re, és akkor annyit bír mint az ssd. -
Tankblock
aktív tag
válasz
Gergosz2
#13419
üzenetére
Pont ezt mondom én is...
igen azt ki kell tapasztalni, hogyan működik jól. Masterben működő verziót, vagy Release branchekben a működő verziót erre vannak stratégiák....
Az biztos h minnél több helyen van akkor diverzifikáltad az adatvesztést mint rizikófaktort.
sd kártyára még 1x semmit se bíznék, a raspimen is csak a rossz tapasztalat van vele... Én ezért szeretnék olyan mini pc-t amibe SSD/HDD lesz....
-
Gergosz2
veterán
válasz
Tankblock
#13418
üzenetére
Local GITnek nem sok értelmét látom, mert oké hogy valamilyen szinten verziót követsz, de a remote nyújtotta lehetőségeket pedig nagyon szépen bukod. Nem is kell beszélni róla hogy ez a távoli, más gépen lévő backup, másrészt remote/masterben rendszerint a tényleg forduló verziót szoktuk tartani, localban meg a kismillió branchen lehet fejleszteni amit kell. Jómagam egy rasberry pin hostolom a saját GIT szerveren, egy minőségi SD kártyát használva. Igen, sajnos ugye az utóbbi sem triviális, volt vele tapasztalat (szivás) anno.
-
-
-
lmaresz
aktív tag
-
gyapo11
őstag
válasz
Tankblock
#13412
üzenetére
Igen, volt már rá példa. Inkább az a kérdés, hogy észreveszem-e ha meghal a hdd, igen, és mekkora a valószínűsége annak, hogy a munka hdd és a mentésre használt hdd egyszerre hal meg. Ez nagyon kicsi esély, mindig van időm az egyik meghalt wincsit cserélni, és a másikról a mentést újra létrehozni. Bár mostanában már olyan gyorsak a flash-ek is, hogy akár pendrive, akár microsd kártya is megfelel a lokális mentésre. Sokkal egyszerűbb és gyorsabb, mint felhőbe szinkronizálni. Ha programot írok, akkor én akár percenként is mentek egyet, általában sorszámmal megkülönböztetve a mentéseket, aztán addig megyek vissza ameddig akarok, mind ott van. Egy 32 GB-os drive-ra 32 millió db 1 kB-os program változat fölfér.
A githubot nem használom, egyszer néztem valami verziókövető programot lokális változatban, az nem tűnt túl egyszerűnek, nyilván időt kell rá szánni és megtanulni. De nekem jól bevált a helyben mentés sorszámmal. -
-
robertka
tag
Sziasztok, sajnos véletlenül kitöröltem egy projektemet de egy vissza állító programmal elvileg meg tudtam menteni a fájlt viszont nem értelmes karaktereket tartalmaz. Amikor megnyitom a fejlesztő programban az automatikus formázás felismeri a sortöréseket meg hasonlókat de nem értelmes a szöveg.
Lehetséges ezzel valamit még kezdeni vagy valamilyen helyreállítási metódus?
Köszönöm szépen.
Iyenek a sorok:
���l)=��uz����?m^���ߴ#�_tZ���ض�5{w5��Vi��N
Vagy TXTben:
ÅZ\ÐóÖé}— ùÖyëÃÍ sÑó?ØR^þ Š}«šk¤´ -
zsolti_20
senior tag
Szep napot emberek.
Egy eszkoz felfogatasat a falra szeretnem megoldani. Talalhato ott egy fem alatamasztas, arra gondoltam hogy csinalok egy burkolatot amibe magneseket raknek es igy siman fellehetne tapasztani oda.
Aztan eszembe jutott hogy lehet megsem lenne olyan jo otlet, mert az eszkozben van egy NRF24L01 modul, arduino nanoval, TP4056-al.
Van valakinek tapasztalata a magneses ter mennyire befolyasolja ezeket a modulokat?
Ti hasznalnatok ilyesmit ebben a helyzetben?
Ha nem, akkor marad a duppla oldalu ragaszto aztan remenykedjunk hogy megtartja.
Tudna valaki segíteni?
. Az adatlapon első blikkre kicsit megtévesztő. Még jó, hogy az MCP-k esetén az INT-jel polaritása is megszabható, meg az is, hogy csak open-drain kimenet legyen, vagy push-pull.
Új hozzászólás Aktív témák
Hirdetés
ekkold- E-roller topik
- Fujifilm X
- Kazy Computers - Fehérvár - Megbízható?
- sziku69: Fűzzük össze a szavakat :)
- exHWSW - Értünk mindenhez IS
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Luck Dragon: Asszociációs játék. :)
- Gyúrósok ide!
- Kínai és egyéb olcsó órák topikja
- Megérkezett a Google Pixel 7 és 7 Pro
- További aktív témák...
- Azonnali készpénzes Intel i3 i5 i7 i9 12/13/14 gen processzor felvásárlás személyesen / csomagküldés
- AKCIÓ! MSI Z690 i7 12700K 32GB DDR4 1TB SSD RX 6800 16GB Phanteks P600S Cooler Master 750W
- 4 év gari - magyar bill. - Lenovo ThinkPad Z13 G1 - AMD Ryzen R7 Pro 6850U, 13.3" 2.8K OGS érintő
- BESZÁMÍTÁS! Asus M5A99FX PRO R2.0 990FX chipset alaplap garanciával hibátlan működéssel
- Telefon felvásárlás!! iPhone 11/iPhone 11 Pro/iPhone 11 Pro Max
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest