- Bemutatkozott a Poco X7 és X7 Pro
- Yettel topik
- Magyarított Android alkalmazások
- Hónap végén érkezik a Xiaomi Band 10, ára is van
- iPhone topik
- Nothing Phone (3a) és (3a) Pro - az ügyes meg sasszemű
- Google Pixel topik
- Milyen okostelefont vegyek?
- Fotók, videók mobillal
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
-
Mobilarena
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
-
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 -
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ó. -
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. -
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. -
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. -
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. -
gyapo11
őstag
Ha ntfs filerendszer van a wincsin, ajánlom vagy az Everythinget vagy az Ultrasearchöt. Az MFT-ben turkálnak, köröket vernek bármilyen más keresőre.
-
Tankblock
aktív tag
"100 k erase/write cycles" a pontos érték. A csatoplt forrásban a wear leveling algoritmus leírása is szerepel.
Forrás : [link]Egy ilyen szép uC elpazarolni.... Inkább ATtiny szériából akár fix külső kristállyal.... és RTC vel is. 8 láb - 2 Vcc, Gnd, 1 Gép érzékelés, 2 i2C RTC hez 1 Rst, 1 LED , 1 gombnak, vagy a resetet használni..... Mazoistáknak ATTiny13A Assemblyben
1K Bytes of In-System Self-programmable Flash program memory
– 64 Bytes EEPROM
– 64 Bytes Internal SRAM
– Write/Erase Cycles: 10,000 Flash/100,000 EEPROM
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
Dißnäëß
nagyúr
Na jó, így már más a leányzó fekvése. Emberi léptékben gondolkodtam a "lassú" alatt. Egy ilyen alapvető funkcióhoz természetesen tökmindegy, hány ms alatt történik meg a varázslat, csak léptesse
Én akciósan vettem belőle négyet, harmadáron volt darabja. Kb egy hónapig tartott.. február környékén.
-
Dißnäëß
nagyúr
Mert azt írtad, lassú az eeprom írás.
Nincs valami olyasmi, mint egy USB pendrive, hogy kiteszi milliszekundumok alatt - de legyen lassú, akár 1mp is - és kész ?Nem vagyok nagy szaki, hogy külön wear levelinget írjak, törjem rajta az agyam, kezdő C++-os vagyok, nem egy sokéves tapasztalatos zseni. Szóval a kóddal lenne gondom, ha még wear levelinget is néznem kell.
Én közvetlen tőlük rendeltem, a DFRobot-ról. Nagyon jó kis kütyük, beváltak. [link] Egész jó tempóban küldték...
(Van Beetle ESP is)
-
gyapo11
őstag
Nem tudom mennyire tiszta az a környezet, ahova a szenzort kellene tenni, de általában probléma a kosz, ami a mechanikai és optikai egységeket működésképtelenné teszi. Ezért olyan kell, amit tökéletesen el lehet szigetelni, mégis képes érzékelni a külvilágot, ez pedig a mágnes. Az egész elektronikát betenném egy vízhatlan dobozba, és csak egy úszót hagynék kint egy mágnessel, bent meg a mágnes helyzetét olvasnám le egy hall cellával.
-
JozsBiker
aktív tag
Azt szeretném megoldani, hogy egy adott esővíz árok belsejébe legalulra tennék egy csövet 5-10 mm körüli belső átmérővel, és mikor azt ellepi a(z eső) víz, akkor kellene bekapcsolni egy kis szivattyút, ami azon a csövön keresztül szívná a vizet egy tartályba. Vagyis kb. 5-10 mm vízmagasságot kellene érzékelni. Viszont nagyon fontos lenne ugye, hogy ha visszacsökken a vízmagasság, akkor azt azonnal vegye észre és kapcsoljon ki. Vagyis nedvesség érzékelő nem hiszem hogy jó lenne, mert amíg meg nem szárad, addig levegőt szívna a szivattyú.
-
zsolti_20
senior tag
Igazan nincs mit, este jelentkezek a tesztek utan.
Toltesvezerlonek pedig a TP4056-ot hasznalom, de abbo lis azt a fajtat, ahol egyszerre lehet tolteni az aksit es hasznalni rola.
[link]
Persze rendelhetsz mas forrasokbol is mert ezeket csak az elso talalat szerint linkeltem ide. Mashol lehet olcsobb vagy tobbet kapsz ugyan ennyiert. -
zsolti_20
senior tag
Ha jol emlekszem igen, mert amikor kerestem a legjobb DC-DC konvertert az egyik elonye az volt hogy boven tud mukodni 2.8v alatti feszultsegnel is, igy ha nem jon be a 18650, konnyen ceruzaelemes verziova alakithato.
Gyakorlatban soha nem neztem, de ha haza erek letudom neked tesztelni meg 1.2v ujratoltheto ceruzelem meretu akkumulatorral is.
-
-
repvez
addikt
Ahogy mondani szokták nem megy az olyan könnyen faluhelyen .
amugy azt gondolom, hogy valami fizikai limit van a mérési gyakoriságban vagy az arduino vagy a modul chip frekvenciája vagy valami más lehet a korlát és nem szoftveres.
max ugy lehet szoftveres ha a beérkező adatokat nem képes olyan gyorsan feldolgozni az arduino mint ahogy kapja.
De ennél többet egyenlöre nem tudok rola.
Hiába tervezném meg a rendszert mondjuk 1 fok szögeltéréssel 1ms os mérésgyakorisággal ha a modul nem képes fizikailag ezt teljesiteni. -
repvez
addikt
[link]
A video leirásában linkelve van minden hozzá, kód bekötés stb..A hasonloságot ugy értem, hogy nem csak a forgatást hanem a teljes kialakitás ugyan az minden alkalommal, nincs benne változatosság, hogy hátha már kialakitással esetleg egyszerübb lehetne vagy pontosabb.
-
Janos250
őstag
Még a legelején, egyből az első bekapcsolásnál kiégett a fűtőbetét, mert alacsony hőmérsékletet jelzett, és csak fűtött, fűtött, és kiolvadt a fűtő patron fűtőszála. Vettem teljes hotend blokkot, azzal működött, és utána hasonlítottam össze, és kiderült, hogy a fűtő betét ellenállása végtelen. Aztán amikor a hőmérséklet újra összevissza mászkált, akkor kezdtem vizsgálni, és akkor jöttem rá, hogy kicsúszik a termisztor.
. Mivel soha nem dolgoztam még ilyesmivel, elég sokára jöttem rá, mi a gond. Vettem olyan hotend blokkot, amiben csavarral lehet rögzíteni a termisztort, azóta csak olyat használok. -
Janos250
őstag
A schematic diagramon:
Fenn ott vannak a 7 szegmenses kijelzők. A LED9.
Balról megy bele a GR4, GR3, GR2, GR1. Gondolom ez címzi meg, hogy melyik szegmens világítson, mert a 4 vonal ehhez passzol.
De mit csinál alul a SEG1, SEG2? Hogyan működik? Lehet, hogy én teljesen félreértem a címzését, működését?Szerk: Hoppá, a második mondatod: Akkor a bal oldali négy vezeték nem kódolt cím, hanem a 4 kijelző közül egyet kijelöl?
-
Imy
veterán
-
gyapo11
őstag
analóg, amit nem tudsz multiplexelni
De vannak ilyen cmos ic-k, régen sok erősítőbe, előerősítőbe tettek ilyet, hogy ne a puruttya yaxley legyen a bemenetválasztó.
I2c-ről nem régen volt szó, hogy ha a libraryban nincs lekezelve, akkor akár az egész program futását meg tudja állítani egy hibás szenzor.
-
gyapo11
őstag
Működhet, de szerintem a soros kommunikációban elég sokat van L szint is, amikor a puffer nem tötltődne. Ide speciálisan olyan protokoll jó, amiben kevés az L szin és az is rövid, minél többet van H-n, annál kevésbé hullámos a pufferen a feszültség.
Vagy 12 V-os H, és a puffer után táp ic, ami lesimítja és 5 vagy 3.3 V-ra állítja be a tápfeszültséget. Ilyenkor kell szintillesztés, ha nem 12 V-os a soros bemenet. -
Janos250
őstag
Próbára azt csináltam, hogy nem zártam le a kapcsolatot, hanem küldözgettem egy próba szöveget.
Néhányszor átment, aztán néhány után újra kellett építeni a kapcsolatot.
Ez az újraépítés a lassú, nagyon. Ezért nincs ilyen gond az UDP-vel, mert ott nincs kapcsolat.
Az előbb írtam, hogy lehet telnetes irányban próbálkozok, mert ott percekig nem szakadt meg a kapcsolat, vagy WEB lap törzsében. Vagy fájlként, de azt nem tudom hogy kell, utána kellene nézni. -
Janos250
őstag
Köszi, de inkább ide írom, hátha valamikor más is érintett lesz.
Nincs http! Küldő oldalon ez van:if (client.connect(fogadoFel, 80)) {client.print("proba \n");client.stop();}
fogadón meg ez:while(client.available()){String line = client.readStringUntil('\r');
Ha a küldő oldalon nem zárom le, akkor is megszakad egy idő után.
Az elv:
A küldőre érkeznek adatok UART-on, minden egész másodpercben egy néhány kilóbájtos adag, ezt kell küldeni a fogadó fél számára, aki szintén továbbítja ezt UART-on a tetthelyre.
Neten keresgéltem, mások is panaszkodnak.
Lehet persze, hogy nálam a szinkronnal is van baj, majd próbálom a setTxBufferSize-al az UART pufferjét nagyobbra állítani. -
repvez
addikt
utána néztem mi ez a hatás, de pont az ellentétije vagyok, én tisztába vagyok vele, hogy nem értek hozzá és nem próbálok meg mást meggyőzni, hogy én jobban tudom.
A gépészetben meg pont ez a jó, hogy ha nem is tudod, hogy mi hova való vagy mire való, attól még ki tudod találni ,hogy melyik hova passzol akár egy kirakó.
De az elektronikában meg ahogy mondják, hogy az áram alatt lévő vezeték ugyan úgy néz ki mint amelyik nincs, csak más a fogása.
Ha meg tervezel valamit, ott meg vannak a fizikai mértetek amit látsz, hogy ha valami nem fér oda vagy megakad benne.az elektronikában meg építés közben nem derül ki ha valami nem oda való,mert a vezetéket bárhova kötheted és ki is maradhat , nem derül ki a hiba mig be nem kapcsolod.
-
repvez
addikt
Nem csodálkozom, mindenhol erre az eredményre jutnak a végén amikor elmondom, hogy hogy szeretném megoldani a dolgokat. mivel arra nincs időm, hogy csak ugy cél nélkül tanuljam a dolgokat, csak arra, hogy célirányosan valamit fokozatosan csak amire szükségem van.
Egyébként valami olyasmit szeretnék, mint egy quadro kopter csak más elveken mint a hagyományos kialakitás.
ahogy néztem ehhez kellene:
MPU9250es gryo
neo6m gps modul
egy brusless motor+vezérlő
6db távolságmérő
5db légnyomásmérő
egy humidity+temperature modulHa jol gondolom akkor I2C protokolon keresztül kellene összekötni , hogy minden modult rá tudjak kötni , máskülönben ütné egymást a jelek.
ÉS ahogy irtam ehhez kellene egy virtuális fejlesztő környezet ahol ezeket a modulokat be tudom állitani mielött fizikailag is belevágnék, mert ahogy látható igy is 15-20 ezer lenne az alkatrész és ahhoz elég sok, ha semmi nem lesz belőle és csak kidobtam rá a pénz.
De ha már virtuálisan látszik, hogy müködhet az amit elgondoltam akkor már van értelme tovább lépni az elméleti virtuális tesztekről a fizikai megvalósités felé. -
repvez
addikt
ugy értettem, hogy egy könyvben ki tudja, milyen szisztéma alapján követik egymást a dolgok vagy másvalaki projectje csak hasonlithat .
Mint ahogy látom is , hogy hiába néztem meg pár ilyen videot ami elvileg ugyan olyan eszközt kapcsoltak a kód mindegyiknél más volt.
igy ha össze is ollozom a neten találtakat a végeredmény nem fog müködni, mert más más elemekkel kellene összedolgoznia. arról nem is beszélve, ha nincs hozzá magyarázat akkor lehet hogy téves következtetéseket vagy rossz dolgokat tanulok meg rola.Arról nem is beszélve, hogy ahány fejlesztő környezet annyi beállítás, az arduiono .cc oldalon a webeditorba is hiába másoltam be egy kész kód sort ,hibát dobott a futtatásnál . a Skiid editornál meg nem tudok beimportálni egyedi libraryt a modulokhoz, vagy más modult betenni az alapok mellé. a tinkercadnál se találtam olyan menüt ahol ezeket meg tudnám tenni, vagy egyáltalán a pro micro alapmodult ki tudnám választani a kapcsoláshoz.
-
repvez
addikt
páran már mondták hasonlót, pedig ez egyáltalán nem így van csak másfajta megközelítéssel szemlélettel gondolkodom.Gyakorlatias és visuális tipus vagyok és ezért nem a száraz olvasott anyagot preferálom hanem tapasztalati úton a saját problémámon keresztül megoldva.
én úgy szeretnék megtanulni , hogy közben valami hasznosat és olyan dolgot csinálok ami érdekel és nem egy olyan dolgot amit valaki más gondolatmenetét tükrözi esetleg 20 évvel ezelőtti megoldás aminél mostanra már talán van egyszerűbb megoldása is.
Sokkal jobban megmarad és előbb is megtanulom, ha nem másvalaki példaprogramját írogatom , hogy megtanuljak egy funkciot programozni inkább úgy, hogy akkor tanulok meg egy funkciót amikor az én programomban szükség lenne rá.
Mert lehet hogy megtanulok könyvből 10 funkciot, de a problémámra csak 5re van szükség, de 2-t pont nem tartalmaz az a 10 amit már tudok. szóval addig míg nem tudok mindent addig jobban koncentrálnék arra ami épp kell .Csak az a másik, hogy azt se tudom mikor mi kellegyébként köszönöm a felajánlást, de nem tudom, hogy ez jo hely lenne e hogy összerondítsuk mindenféle very basic levellel
-
gyapo11
őstag
Saját példám, hogy egy szombat reggel leültem a géphez, akkor még dos meg 486 33 MHz volt a menő, és egy turbo pascal 4.0 könyvből kezdtem tanulni az utasításokat. Délután már írtam programokat, prímszámok, rendezés meg ami eszembe jutott.
Viszont ugyanezt megpróbáltam a Dennis M. Ritchie C könyvével, és nem értettem, egy óra után föladtam. Később példákat nézegetve azért egyszerűbb programokat meg tudtam írni c-ben, a filekezelés többször gyorsabb volt mint a turbo pascalé.
Tanulság: meg lehet tanulni egy könyvből is az alapokat, de nem mindenkinek megy minden.
Én is alapszinten érzem magam c++-ból, de ezeket az alapokat szívesen elmagyarázom, indítsunk egy alapszintű programozás csevelyt. Felőlem mehet az emulátor is, szerintem az a fontos, hogy programot tudjon írni, ami működik és azt csinálja ami a cél volt. -
repvez
addikt
Jól látod a dolgot, erre próbáltam utalni , hogy először virtuálisan próbálnám meg megcsinálni azt amit akarok, mert ott egyből kiderül ,ha valami nem működik.
És mikor már a megépítésre kerül a sor akkor egy viszonylag működő dolgot kapjak ami egyrészt nagyobb sikerélményt nyújtana, mint mikor pénzt és időt pazarolva minden egyes kudarccal több idő eltelik, mire újra forrasztom vagy másik eszközt szerzek be.De ez egyedül nulla előképzettség mellett elég nehéz. Próbáltam a c++ vagy más nyelveket is magamtól megtanulni, de hiába a könyvek és a videók, semelyik se úgy van kialakítva, hogy az abszolút nulláról is megértsék és fejlődjenek belőle. mindegyik már az első dolgok olyan kifejezéseket vagy dolgokat mond vagy mutat amiket nem értek. vagy csak egy kis részét mutatják meg, de azt nem, hogy ezt mire lehet később hasznosítani. Vagy ha minden egybe van akkor meg más fejlesztő környezetet használ más könyvtárakat és hiába másolom le szóról szóra nálam nem mülödik.
ugyan ez itt is megvan, a net tele van a kis részegységek kapcsolásával és programozásával egyenként, de arról, hogy az így kapott adatokat mire és hogyan tudom felhasználni illetve kombinálni a másik egység értékeivel az már nagyon ritka. Mert addig minden szép és jó amíg csak egy egységet kell rákötni a main boardra, de mi van ha többet kell egyszerre rákötni és elfogy a szabad láb vagy ugyan arra a lábra kellene több egységet is tenni?
tudom, hogy aki tud programozni vagy ért az elektronikához annak ezek a kérdések hülyeségnek hangzik, de egy laikusnál ezek az apró dolgok is nagy akadályokat jelenthetnek.
-
repvez
addikt
próbáltam a Tinát, meg az EAGLE és a Sprint layout programokat, de azok inkább PCB tervező szoftverek az alap alkatrészekkel.
itt meg az érzékelőket készen kapod és csak be kell kötni őket.
DE a legnagyobb problémám nem is a kapcsolás, mert azt ahogy írtad megtalálható a neten , hanem a programozás része, hogy a kapott adatokkal hogyan dolgozzon.
Mert ötleteim vannak , de programozás híján nem igen tudom, hogy azokat hogyan működtessem .Pont emiatt is akarnék belevágni hátha igy a gyakorlati dolgokon keresztül megtanulnék programozni is.A pro micróm is azért van, mert egy analóg joystikot akarok átalakítani USB-re, amihez minden adott a softver is, már csak össze kell raknom.
viszont van egy másik ötletem amihez még nincs meg csak a pro micro. de ez komolyabb lenne de mivel semmit nem tudok igy elég nagy az esélye, hogy feleslegesen venném meg a cuccokat. jelenleg nincs meg a felszerelésem se ahhoz, hogy fizikailag megcsináljam .DE addig is míg meglesznek a feltételek legalább el tudnék indulni valamerre a folyamattal.
Köszi a linkeket.
-
repvez
addikt
tudom, hogy filléres cuccok, csak ha valamiből több kell akkor a sok kicsi összeadódik és ha még ráadásul kiderül, hogy arra amire akarom használni nem is lesz jó, hanem egy másik fajta kellene akkor csak kidobott pénz lesz és még vehetem meg a másikat is mellé.
ás mivel még sose csináltam ezelőtt és nem is elektromos végzettségem van így gyanítom nagyon sokszor belefutnék ilyenbe vagy még akár abba is, hogy leégetem valamit .
DE virtuálisan ennek kicsi az esélye. -
Janos250
őstag
A verzió: (legjobb)
Keresnék egy több lábú kontrollert
B verzió: (kevésbé jó)
PWM: a fő
gomb: NAGYON rövid időre átkapcsolnám inputra, és beolvasnám
led: betennék egy, a PWM-nél rövidebb idejű tüskét, és hardver [vagy egy másik kontroller ] figyelné, ha elég rövid, akkor vált.Az A verzióhoz ugye tudod, mit használnék?
-
atesss
addikt
Egy "8D" Mozi rendszer mozgásvezérlője.
Mozognak a székek, miközben megy a film (leginkább ilyen hullámvasút meg hasonló dolgok, legalábbis ott van legjobban értelme). Meg vannak effektek is (hó, füst, szél, buborék, storoboszkóp, hirtelen sűrített levegő fújás), illetve a kép meg 3D-s.
Csak hát egy zárt kínai rendszer az egész. (Mármint ez full kínai, a tervezés is... Félig pl. a Windows XP is kínai.)
Ma du. megyek be, csinálok róla célzott fotókat/videót, felrakom akkor majd ide is -
atesss
addikt
"Akár úgy, hogy méred a világítás idejét, és ha sokáig nem alszik ki a led, akkor ERR lépett fel"
Ez viszont egy nagyon jó ötlet, köszi !
Ezt az elvet digitális bemenettel ugyanúgy alkalmazni lehet (feltéve, ha sikerül jól beállítani a kapcsolást, hogy "digitális jelet" adjon).
De amúgy ADC-t Raspberry-re is ugyanúgy be lehet kötni. Annyi hogy az AVR-el ellentétben mindenképp külső kell. Asszem van is valami egyszerűbb, 8 bites, I2C-s típusom itthon.Akarok log-ot csinálni, illetve ezt a log-ot távolról is el akarom érni.
Esetleg e-mail vagy hasonló riasztást, ha valamikor nagyon gyakori (értsd. pl. pár percenkénti) lett a hiba.
Emiatt mindenképp valamilyen távolról is elérhető (azaz Ethernet vagy Wifi képes) kontroller kell.
Sőt, majd a hibák gyakoriságától/pontos előfordulási időpontjától függően gondoltam arra is, hogy akár a kameraképekkel (meglévő analóg CCTV rendszer, jelenleg egy DVR-re kötve, de egy kis késleltetéssel RTSP-n is elérhető) együtt, egy "timeline" vonalon jó lenne visszanézni hogy mikor avatkozott be a resetelő-eszköz, és ekkor mi történt a kameraképeken. -
gyapo11
őstag
Azért jó párszor eljutunk oda, hogy nagyon jó, hogy vannak libraryk és nem kell megírni mindent, de ilyen kellemetlen meglepetések is járnak velük, hogy pl. egy egész program futása leáll egy hibakezelés hiánya miatt. Kellene ide is egy Linus Torvalds, aki eldönti, hogy mi jöhet és mi nem.
-
gyapo11
őstag
De akkor arra nem a hw wd a megoldás, hanem le kell kezelni a dolgot sw-ből. Persze ha valaki így írta meg az i2c libraryt, hogy az idők végezetéig várjon egy bitet, és a bit nem jön, ezért más feladatot a processzor nem végez, akkor bele kell tudni nyúlni a forrásba, az meg nem mindenkinek megy.
-
#13159
Drótszamár
őstag
Aryes
#13157
Drótszamár
őstag
-
Dißnäëß
nagyúr
Igen, bocs, dolgozom. Kollégának köszönöm..
Elég gyorsan felizzanak, nem úgy persze, mint egy LED, hogy pakk, és azonnal szinte púpon, de hangerô kijelzésre használható, pl. 00-99 skála mentén, vagy több csôvel bármire igazából. Másodpercmutatót nem tennék rá, a nagyonsok ki-be kapcsolást tény, hogy nem szeretik, de így is tudnak tisztességes üzemidôt.
-
PHM
addikt
Az adatlapon meg van adva, hogy 3,15 V-on 20 mA fog az izzószálon folyni.
Mivel az izzószál hidegellenállása jóval kisebb az üzeminél,
így itt annak az üzemi feszültségével számolt a kolléga, szvsz helyesen.
A bekapcsolás pillanatában több áram fog folyni a körben, azt szinte csak
a 100 ohmos ellenállás fogja korlátozni.
Ahogy felmelegszik az izzószál, (pár-pár 10 ms) beáll a kb 20 mA-es áram. -
Dißnäëß
nagyúr
-
Dißnäëß
nagyúr
Minden szegmens egy kis pici izzószál, ami a ráadott feszültségre felizzik a vákuumot tartalmazó csőben. 3.15V környéke a névleges fesz, de széles tartományt elbír, én múltkor direktben villogtattam meg 5V-ról egy kimenetről, meg dimmelgettem is, minden ilyesmire képes.
Egy soros 100 Ohm-os ellenállás elég 5V esetén, hogy névlegesre hozzuk le a feszt, tartós használathoz.
Két Leonardo-m és egy ESP8266-om van. A port sokszorozót megnézem. Köszi a tippeket.
-
Janos46
tag
Igaz hogy ez python (de lehet látni hogy min kell változtatni), de a githubon van az sh1106-hoz könyvtár, és ha másképp nem megy, akkor abból (nálam hozzáértőbbnek) talán az ssd1306.h fájlját át lehet írni, mer hiszen csak a felbontásban van különbség. Legalább is így gondolom.
-
Janos250
őstag
-
-
Janos250
őstag
Mindenki csak azt tudja megmondani, hogy hogyan lehetne az adott problémát megoldani, amit ismer.
Én nem tudom megmondani, hogyan lehetne pl. Attynivel megoldani mert nem ismerem. Én csak ezt ismerem valamennyire.
Többen többfélét ismerünk, mindenki elmondja hozzá amit ő ismer, és a kérdező vakarhatja a fejét. -
And
veterán
Igaz, nem csak a port maximális árama korlátozhat. Esetünkben az elem típusa is erős limit volt (CR2032), mivel az nem tud 10+ mA-eket leadni. A lencse is dobhat természetesen a hatótávon, de az erős nyalábolás kézi távkapcsolónál nem annyira szerencsés. Szóval a tapasztalat az volt, hogy 2032-es elemes táplálásnál, pár mA-es IR-ledáram mellett a hatótáv max. 2...3m volt viszonylag széles sugárzási szögű leddel, és ebben a formában semmilyen visszaverődést nem érzékelt a TSOP vevő már 50 centiről sem, csak közvetlen rálátással működött. Ugyanezt a ledet tranzisztorral, az előbbihez képest legalább 10x-es csúcsárammal (> 50 mA) hajtva már a szoba összes pontjáról vette a TSOP, visszaverődve is.
Vivőfrekvencia: a TSOP-adatlapokon van erre vonatkozó görbe, ami a relatív érzékenységet mutatja a frekvenciaeltérés függvényében. Például a vivő névleges frekvenciájától ±30%-kal eltérve az érzékenység az eredeti érték < 20%-ára csökken. Vagyis marad valamennyi áthallás más vivőkre, de mondjuk a statikus fény abszolút nem zavarja a vevőt. -
gyapo11
őstag
. 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.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
. Mivel soha nem dolgoztam még ilyesmivel, elég sokára jöttem rá, mi a gond. Vettem olyan hotend blokkot, amiben csavarral lehet rögzíteni a termisztort, azóta csak olyat használok.
Bíztam bennetek 
Új hozzászólás Aktív témák
Hirdetés
ekkold
- 12.000 ft tól elvihető ELITRO Bankmentes , kamatmentes vásárlás .Cooler Master GM2711S Monitor
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- Honor 400 lite 256GB, Kártyafüggetlen, 1 Év Garanciával
- LG 65BX - 65" OLED - 4K 120Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - PS5 és Xbox Ready!
- Tablet felvásárlás!! Apple iPad, iPad Mini, iPad Air, iPad Pro
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest