Hirdetés
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Autós kamerák
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Házimozi belépő szinten
- Videós, mozgóképes topik
- Melyik tápegységet vegyem?
- SSD kibeszélő
- AMD Navi Radeon™ RX 9xxx sorozat
- Mikrokontrollerek Arduino környezetben (programozás, építés, tippek)
- 5.1, 7.1 és gamer fejhallgatók
Hirdetés
(használd a CYBSEC25PH kuponkódot további 20 ezer ft kedvezményért!)
-
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
-
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.
-
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. -
-
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. -
-
válasz
Janos250
#13396
üzenetére
Nem gondoltam, hogy valaki használja a Windows beépített keresőjét bármire is.
Ajánlom a Total commandert ilyen célokra (is).
Nem Te linkeltél régebben egy oldalt, ahol arduino-hoz készült, újraírt/memóriatakarékos String class-ról írnak? Csak úgy eszembe jutott, hogy régebben szó volt róla, hogy nem ajánlott Arduino alatt a String osztályt használni. -
válasz
Dißnäëß
#13384
üzenetére
$7.90?
Na ebből se fogok nagyon bevásárolni. "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 ?"Dehát a lassú azt jelenti, hogy milliszekundumok alatt történik!
8-10ms, ami - tekintve, hogy μs tartományban gondolkodunk, amikor egy μcontroller sebességéről van szó - lassú. Nem? Legalább 10ms-ig fenn kell tartani a tápellátást, hogy sikeres legyen a művelet. Erre gondoltam. Ettől nemigen kapsz gyorsabbat, esetleg lehet próbálkozni SD kártyával, de szerintem emiatt nem éri meg."Nem vagyok nagy szaki, hogy külön wear levelinget írjak, törjem rajta az agyam"
Nem is kell, ott a lib, használd!
Egyébként sem kell újra kitalálni, leírtam a módját, viszonylag egyszerű elven működik. -
válasz
Dißnäëß
#13382
üzenetére
Ja, ez cuki. Hol kapni ilyet?
Miért kell alternatív hely? Egy ATmega32U4-ben 1kB eeprom van, ha jól tudom. Egy cella kb. 1000x írható. Ha az általam írt wear levelinget alkalmazod, vagy még egyszerűbb, ha 15 bit elég az időpont tárolására, a legfelső bittel meg lehet oldani a wear levelinget (van hozzá külön library is ám! ), akkor akár 512000 alkalommal írhatsz az eepromba, nem létezik, hogy ne legyen elég. 
-
válasz
Dißnäëß
#13380
üzenetére
Szia! Ha nem fontos a nagy pontosság (mondjuk naponta 5-10 perc eltérés nem okoz problémát) akkor nem kell az RTC, nyugodtan támaszkodhatsz a belső órajelre. Ha nem használsz megszakításokat, akár önmagában a millis() is használható időmérésre.
A táp megszűnését úgy értetted, hogy valamelyik pin-jén keresztül figyeli, és érzékeli, ha megszűnik a táp, de egy puffer kondiról még valameddig működik? Ez szerintem járható út, de számíts rá, hogy az EEPROM írás elég hosszú folyamat, és nem árt, ha közben kap végig stabil tápot, tehát egy konvertert én mindenképp tennék a trafó/diódahíd/pufferkondi után (meg egy plusz diódát a kondi és a diódahíd közé, hogy ne tudjon a hídon át visszafelé kisülni a kondi)!
Az EEPROM életét pedig, mivel kevés adatot kell rá gyakran írnod, szépen meg tudod növelni egyfajta szoftveres wear levelinggel: nem mindig ugyanazt a cellát írod felül, hanem minden írásnál a következő szabad cellát használod, egy számlálóval együtt, és ha elfogy az üres hely, akkor kezded újra elölről.
Minderre pedig kár egy Leonardo modult használni, egy Attiny85 is tökéletesen megfelelne a feladatra, van belőle olyan, amelyik 2,5V-tól 6V-ig működik (akár a konvertert is el lehet hagyni). -
válasz
zsolti_20
#13368
üzenetére
Ez jó ötlet
feltéve, hogy a dugó helyére tennéd a mikrokapcsolót. Kellően kicsi tank kellene, hogy kis vízmennyiségnél is kapcsoljon, és ne maradjon benne sok víz, mikor lekapcsol.
De 3D nyomtatással nemigen lehet víz- és légmentesen záródó dolgokat nyomtatni, lásd a forró vizes videót a 3D printer topikban. Úszónak megtenné viszont egy pingpong labda, vagy talán egy jól záródó, kis méretű gyógyszeres doboz is. -
válasz
JozsBiker
#13365
üzenetére
Itt arról beszélgetnek, hogy proximity szenzorral közvetlenül a víz jelenlétét lehetne érzékelni, de 0Ft-os barkács megoldásként lehetne akár alufóliából is kapacitív szenzort készíteni.
A nedvesség érzékelést be lehetne egyébként úgy is állítani, hogy ne a csőben érzékeljen, hanem a tartályban a cső felett, így nem fogja szárazra szívni a tartályt, viszont mindig maradna benne egy kevés víz. Az mondjuk legfeljebb a szúnyogok miatt okozhat gondot.
-
#13348
Aryes
nagyúr
Scooter86101
#13313
válasz
Scooter86101
#13313
üzenetére
Tudnátok ajánlani bevált 5V-os boost és buck konvertert meg 18650-es akksit Aliról a kollégának?
-
válasz
repvez
#13344
üzenetére
Hát ezt nemigen fogom megépíteni
Olyan kódra gondoltam, ami teszteli a sebességet."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."
Én egészen biztosan nem így készíteném, ha ilyen kis távolságok pontos mérésére lenne szükség (pl bútorok közt navigáláshoz). A szenzort vagy a forgástengelyre tenném, vagy mögé, hogy nagyobb legyen a minimális távolság a mérendő tárgy és a szenzor közt. Amúgy ez a lézeres szenzor meglepően pontos, milliméteres pontossággal lehet vele mérni. Ahhoz viszont azt hiszem 100ms-nál nem lehet rövidebb a mérési idő.
-
válasz
repvez
#13341
üzenetére
Szia! Nekem van ilyenem itthon, ha küldesz rá teszt kódot (mondjuk UNO-ra), akkor letesztelem neked szívesen. Még nem építettem belőle semmit, csak tesztelgettem a pontosságát, úgy emlékszem, hogy néhányszor 10ms egy mérés, de nem fix az idő, a pontosság rovására lehet csökkenteni vagy növelni, erre van beállítás a hozzá tartozó library-ben.
"Illetve láttam, hogy páran próbáltak csinálni belöle LIDAR-t , de a legtöbben ugyan azt másolták le egy külső motorral hajtották meg a modul házát egyenlö sebességgel. "
Hát nagyon máshogy hogy lehetne?
"kötelezően csak egyenletes sebességgel kell hogy forogjon mérés közben vagy váltózó forgási sebességnél is ugyan ugy müködik a távolságmérés?"
A mérést, mivel ahogy írtad, fénysebességgel történik, nem befolyásolja, hogy milyen sebességgel forog a szenzor maga körül, inkább az adatok könnyebb feldolgozhatósága miatt számít a szögsebesség.
-
#13314
Aryes
nagyúr
Scooter86101
#13313
válasz
Scooter86101
#13313
üzenetére
-
#13311
Aryes
nagyúr
Scooter86101
#13309
válasz
Scooter86101
#13309
üzenetére
Teljesen kizárt.
Ezt magadnak kell megoldanod. -
Nem.
Ezt írtad:
"A weller páka 20 fokon ~22 ohm, és 350 fokon ~50 ohm."
...
" a forrasztópáka ellenállását mérném"Ha külön van rajta PTC, akkor a módszer minden további nélkül működhet, de vedd figyelembe, hogy ha az ellenállásosztó másik tagjának túl kicsi értéket választasz, nagy áram fog keresztülfolyni a PTC-n, amitől melegedni fog. Bár ez 350 fokon nem tudom mekkora hibát okozhat.
-
#13306
Aryes
nagyúr
Scooter86101
#13302
válasz
Scooter86101
#13302
üzenetére
Ha minden igaz ennek működnie kell. Tesztelni nem tudtam, mert nincs nálam a hardver.
#include <TM1638.h>
TM1638 module(9, 8, 7);
byte display[8];
char cadena[20];
int alarma,contador,time1;
#define MILED 13
#define PIN_SOUND 12
//#define RETRASO 597
#define RETRASO 97
char fcontador;
void setup()
{
pinMode(MILED, OUTPUT);
pinMode(PIN_SOUND, OUTPUT);
digitalWrite(MILED, LOW);
module.setupDisplay(1,7);
module.setDisplayToString("L.u.L.u.",0,0);
delay(1500);
module.setDisplayToString("--------",0,0);
display[2]=0;
alarma=60;
}
void loop()
{
byte keys;
int z;
keys = module.getButtons();
switch(keys)
{
case 1:
if(fcontador==0)
{display[0]++; if(display[0]>2) display[0]=0;}
break;
case 2:
if(fcontador==0)
{display[1]++; if(display[1]>9) display[1]=0;}
break;
case 4:
if(fcontador==0)
{display[2]++; if(display[2]>5) display[2]=0;}
break;
case 8:
if(fcontador==0)
{display[3]++; if(display[3]>9) display[3]=0;}
break;
case 16:
fcontador=0;
contador=alarma;
digitalWrite(MILED, LOW);
module.setLEDs(16);
break;
case 128:
time1=RETRASO;
fcontador=1;
contador=alarma;
digitalWrite(MILED, LOW);
module.setLEDs(128);
break;
}
if(fcontador==0 && keys>0)
{
alarma=display[0]*600+display[1]*60+display[2]*10+display[3];
//sprintf(cadena,"%04d%04d",alarma,contador);
sprintf(cadena, "%01d%01d%01d%01d%01d%01d%01d%01d", alarma/600, (alarma/60)%10, (alarma%60)/10, alarma%10 , contador/600, (contador/60)%10, (contador%60)/10, contador%10);
module.setDisplayToString(cadena,0,0);
delay(200);
}
time1--;
// {if(display[2]>5) display[2]=0;}
if(fcontador==1 && time1<=0)
{
module.setLEDs(0);
time1=RETRASO;
contador--;
//sprintf(cadena,"%04d%04d",alarma,contador);
sprintf(cadena, "%01d%01d%01d%01d%01d%01d%01d%01d", alarma/600, (alarma/60)%10, (alarma%60)/10, alarma%10 , contador/600, (contador/60)%10, (contador%60)/10, contador%10);
module.setDisplayToString(cadena,0,0);
if(contador<1)
{
fcontador=0;
for(z=0;z<10;z++)
{
//sprintf(cadena,"%04d0000",alarma);
sprintf(cadena, "%01d%01d%01d%01d0000", alarma/600, (alarma/60)%10, (alarma%60)/10, alarma%10);
module.setDisplayToString(cadena,0,0);
delay(500);
//sprintf(cadena,"%04d ",alarma);
sprintf(cadena, "%01d%01d%01d%01d ", alarma/600, (alarma/60)%10, (alarma%60)/10, alarma%10);
module.setDisplayToString(cadena,0,0);
delay(500);
}
//sprintf(cadena,"%04d----",alarma);
sprintf(cadena, "%01d%01d%01d%01d----", alarma/600, (alarma/60)%10, (alarma%60)/10, alarma%10);
module.setDisplayToString(cadena,0,0);
digitalWrite(MILED,HIGH);
for(z=0;z<300;z++)
{
digitalWrite(PIN_SOUND, HIGH);
delay(10);
digitalWrite(PIN_SOUND, LOW);
delay(10);
}
}
}
delay(1);
} -
válasz
gyapo11
#13292
üzenetére
"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ó."
Most csak a kiegészítő elektronika nélküli lehetőségeket mondtam.
"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."
Hát ezen sajnos az sem segít, ha több lábra vannak elosztva a szenzorok.
-
#13297
Aryes
nagyúr
Scooter86101
#13296
válasz
Scooter86101
#13296
üzenetére
Tudom, percben adod meg és másodpercben írja ki. De legalább nem ír hülyeséget.
Most van időm, megnézem rendesen. -
#13294
Aryes
nagyúr
Scooter86101
#13289
válasz
Scooter86101
#13289
üzenetére
Ezt Te már módosítottad? Az idő beállítás részben már át van írva perc/másodpercre, csak a többi rész nincs hozzá igazítva.
Most épp telefonról vagyok, a leggyorsabb módosítás amit innen tudok javasolni ez lenne:
A 68. sort írd át erre:alarma=display[0]*600+display[1]*60+display[2]*10+display[3];Akkor perc/másodpercben adod meg az időt, de másodpercben fog visszaszámlálni.
-
válasz
Dißnäëß
#13286
üzenetére
"Például 3-4 hőmérséklet szenzort 1 digi bemenetre, 3-4 másikfajtát másik digi bemenetre...
Vagy ha analóg szenzoroznék, I2C ?"
Egy szenzor vagy analóg, amit nem tudsz multiplexelni, vagy digitális, i²c vagy SPI, ezt értelemszerűen multiplexelni kell, mert erre találták ki. Az uno/nano lapokon tudtommal 1db hardveres i²c és 1db hardveres SPI van, ha többet szeretnél, vagy más lap kell, ami többet tud, vagy szoftveresen kell megoldani, ami vagy működik, vagy nem.
"mi történik, ha egy szenzor meghibásodik."
Szerintem az i²c szenzorok egyszerűen nem válaszolnak többet, de saját tapasztalatom nincs róla. Nem hinném, hogy az egész buszt magukkal rántanák, persze most nem villámcsapásról beszélek, vagy hogy a kutya elrágja a drótot és rövidzárlatot csinál.
"Mivel csinálnátok ? (Wifi, BLE, egyéb rádió kizárt, optikai rálátás nincs, szintén kizárt)."
Ez esetben természetesen vezetékkel. Jól leszűkítetted a lehetőségeket.
Ha nagyobb távolságot kell áthidalni, vmilyen csavart érpáros vezeték, pl a hobbi elektronika topikban láttam ezt a megoldást UTP kábelre, vagy mostanában többször olvastam az rs485-ről, de ez külön hardvert igényel. -
válasz
Gergosz2
#13283
üzenetére
Gondolom a LED csak egy példa volt, az igazi feladat a nano-tömb belső kommunikációja lenne. Na nem mintha el tudnék képzelni olyan feladatot, amit ilyen hardverrel kéne megoldani, de maga a feladat érdekes.
Annyira, hogy ezt a 1wire megoldást, amit fent leírtam, ki is fogom próbálni néhány attiny μC-el, ha lesz rá időm, mert lehet, hogy gyakorlati haszna is lesz valamelyik projektemben. -
válasz
gyapo11
#13282
üzenetére
Ha a vezérlő egy, a TX lábon keresztül vezérelt H-bridge-en keresztül látná el a többi lapot táppal, a vezérelt lapok Vcc lába előtt pedig egy dióda + puffer kondenzátor lenne, a tápvonalat közvetlenül az RX lábukra kötve sima serial kommunikációval lehetne a tápvonalon keresztül kommunikálni velük. Jól gondolom?
-
válasz
zsolti_20
#13276
üzenetére
NRF modulokkal? Többe kerülne a leves, mint a hús. Szerintem nem is működne ennyi rádióadó ilyen kis távolságban. De ha lenne is értelme a vezeték nélküli összeköttetésnek, akkor ott lenne még az 50 külön táp problémája.
Bár jobban meggondolva nem írtad, hogy a sorok/oszlopok közt milyen távolság lenne. Szóval adj több információt. -
válasz
zsolti_20
#13274
üzenetére
Ha van 50 felesleges nano-d, abból eggyel simán meg lehet oldani ezt a feladatot, a többi 49-et pedig nekem adnám.
Kell keresni egy szabványos kommunikációs csatornát, amire 50 node-ot rá lehet akasztani. Például az i²c-hez gyárilag hardveres támogatás van a nano-ban. Az elsőt kinevezem master-nek, a többit pedig slave-nek, mindegyik kap saját azonosítót, aztán a master irányítja az egész folyamatot.
Ha kell, tudok ettől bonyolultabb megoldást is kitalálni, de ahhoz idő kell.
-
#13272
Aryes
nagyúr
Scooter86101
#13271
válasz
Scooter86101
#13271
üzenetére
Szia! Én szívesen segítek benne, ha tudok, feltéve, hogy nem fizetsz érte, mert az hirdetésnek minősülne, ami ugyebár a szakmai topikokban tiltott...
-
válasz
Janos250
#13254
üzenetére
A TCP szerintem nem is való ilyen folyamatos kapcsolatra, bár nem megoldhatatlan, én régen csináltam push szerverhez hasonló folyamatos kapcsolatot PHP-val, böngésző felé, úgy emlékszem mobilneten keresztül is működött órákon keresztül. Én eleve azt hittem, hogy weblapot küldesz. Talán egy "Connection: keep-alive" header-ön múlik az egész, vagy a küldő oldalon egy buffer flushing beállításon, ezeket nézd meg a küldő oldalnál, hogy van-e ezekre beállítás a library-ban.
Weblap törzsben bináris adat küldésére a legegyszerűbb a base64 encoding. -
válasz
Janos250
#13251
üzenetére
Ja, azt hittem valami php/szerver oldali script/apache szerver a küldő.
Én akkor is a küldő oldalt nézném át először, a client class-ban milyen timeout, buffer méretek vannak megadva.
Olyat próbáltál már, hogy nem csak másodpercenként küldesz adatot, hanem a kettő közt folyamatosan néhány byte-os dummy adatcsomagokat küldesz megszakítás nélkül? A másodpercenkénti adatküldés holtbiztosan bekövetkezik mindig, nincs olyan, hogy kimarad egy-egy csomag és olyankor szakad meg a kapcsolat? -
válasz
Janos250
#13245
üzenetére
Ehhez jó lenne tudni azt is, hogy hogyan épül fel a kommunikáció, milyen weboldalt vagy mit szeretnél folyamatosan elérni, mert az a gyanúm, hogy nem az ESP oldalán van a difi, hanem a kapcsolat nem jól van felépítve (pl http fejlécek).
Ha gondolod írj privit, elég sokféle webes applikációt írtam már, hátha meglátom a hibát. -
válasz
repvez
#13236
üzenetére
Én arra gondoltam, hogy annyira nem vagy jártas sem a programozásban, sem az elektronikában, hogy nem tudod felmérni, hogy azzal a módszerrel, amivel szeretnéd, nem fogod tudni ezeket megtanulni. Ez egyszerűen nem így működik. De igazad van, nem volt jó példa.
A programozás részét akár le is tudhatnád egy Blockly/Scratch/MIT App inventor (Android) típusú grafikus (kockatologatós) programozó környezetben, ott van ez, hogy egymásba kell tolni a kockákat, némi angol tudás mellett egyszerűen lehet benne működő programokat készíteni. Biztos, hogy mérnök tervezte ezeket, mert nem az én gondolkodásomnak való, talán Neked pont ezért lesz szimpatikus.
Az elektronika résznél elég jól el lehet igazodni a breakout board-okon, mert a pin-ek fölött mindig felirat mutatja, hogy VCC, GND, MOSI, MISO, CLK, DIN stb, igazából ezt sem lehet elrontani, ha az ember történetesen nem diszlexiás.
-
válasz
repvez
#13230
üzenetére
Szép terv.
Az az igazság, hogy - ne sértődj meg - némi Dunning-Kruger hatást érzek a nyilatkozataid mögött.
Mielőtt futóversenyen akarsz indulni, előbb tanulj meg járni.
Én 3 éve arduino-zom, és van mögöttem 17+ évnyi programozói gyakorlat, de én nem mernék egy ilyen projektbe vágni saját kútfőből. Viszont mivel tudom, hogy a legtöbb problémát már megoldotta más, valamint nagyon sok kész kódot/projektet tanulmányoztam, átolvastam pár adatlapot elejétől a végéig és vissza, rengeteg saját tapasztalatom van, hogy mi mivel tud összeakadni és ennek mi lehet az oka, hogyan lehet orvosolni, tudom, hogy meg tudnám csinálni.
De hogy gépész analógiánál maradjunk: képzeld el, hogy azzal jövök hozzád, hogy megvettem az alkatrészeket, hogy összerakjak egy autót otthon a kertben, de még soha nem láttam csavart meg villáskulcsot, fogalmam sincs a mechanikai kötésekről, se a belső égésű motorok működéséről. Te mit javasolnál? Kezdjek Scrap Mechanic-ozni?
A drón projekt esetében - mivel már tudod, mi az az i²c - nézz utána, hogy hogyan kell több eszközt egy buszra kötni.
Rendeld be az olcsóbb alkatrészeket, egy 9axis gyro nem hiszem, hogy 5$-nál drágább. A távolságmérő, légnyomásmérő + egy humidity+temperature modullal együtt nagyon max 20$. Teszteld le külön-külön mindet, aztán rakj össze kettőt, majd hármat. Ha az olcsóbb alkatrészeket kitapasztaltad, jöhetnek a drágábbak, ezeket is egyesével próbáld ki. Mire idáig eljutsz, garantálom, hogy összeszedsz annyi tudást, hogy a folytatás nem fog gondot okozni. -
válasz
repvez
#13224
üzenetére
Hát hol is kezdjem... Ezzel a hozzáállással továbbra is csak egy helyben fogsz toporogni.
"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."
Ha megtanulsz 10 funkciót, abból lehet, hogy csak 5-öt fogsz felhasználni, viszont legközelebb egy másik feladat megoldásakor eszedbe fog jutni, hogy "mintha lenne erre egy függvény, melyik is az?" Eklatáns példa: kovalens kötés. Az általános iskolai tananyagban a rengeteg különböző, látszólag felesleges ismeret az általános műveltség része, a látókörödet bővíti. Remélem ezt nem kell magyarázni. Ugyanígy van ez a többi 5 függvénnyel."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 kell"
Erre az egyetlen megoldás: elkészült, működő kódokat nézni!!!
Példa: szeretnél egy LCD kijelzőt. Kiválasztasz egy Neked tetsző típust. Megnézed, hogy van-e hozzá library. Letöltöd, megnézed az "examples" könyvtár tartalmát. Ott lesz pár működő példakód, amit egy-az-egyben lefordítva működő programod lesz. Megnézed, mi van a kódban, rákeresel az összes benne lévő függvényre az https://www.arduino.cc oldalon, így csak azokat fogod megtanulni, amik éppen Neked kellenek.
Utána módosítod a kódot az igényednek megfelelően. -
válasz
gyapo11
#13222
üzenetére
Dennis M. Ritchie C könyvét ismerem (nekem is megvan) és egyáltalán nem csodálkozom, hogy nem értetted.
Én C64-en kezdtem BASIC-ben, még a 90-es évek elején. Az alapokat azzal tanultam, de sokan mondják a Pascal-t is, mint jó kezdő nyelv, az nekem kimaradt. Később C64 assembly-ban is próbálkoztam, ami nagyon jól jött nemrég, amikor egy Attiny12-t programoztam assembly-ban. -
válasz
repvez
#13220
üzenetére
Nézd, úgy látom, hogy Te szeretnéd megúszni a tanulással járó kudarcokat, valamint szeretnél úgy tudni programozni, hogy nem akarsz megtanulni programozni. Ez nem fog összejönni.
"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?"
Ezért kell megtanulni az alapokat, ahogy fentebb írtam, a ki-bemenetek kezelését. Erre a Tinkercad is alkalmas, ha mindenképp emulátorozni szeretnél.
Én személy szerint teljesen autodidakta módon tanultam meg programozni, internetes példakódok, online dokumentáció és egy barátom segítségével. Én PHP-val kezdtem, ami sokkal, de sokkal egyszerűbb, mint a C++, mert script nyelv, a világ tele van példakóddal, magyar nyelvű tutoriallal, dokumentációval, mi lenne, ha Te is ezzel kezdenél? A PHP-val gyors sikerélményeket tudsz szerezni, a szintaxisa hasonló, és ha magát a programozói gondolkodást sikerül magadévá tenni, már egyszerűbb dolgod lenne az arduino-val is.
Én nagyon szívesen segítek, ha kérdésed van, akár itt, akár privátban is, de engedd el ezt az emulátor dolgot. Hidd el: az építés se drága, se nehéz nem lesz, szinte minden szenzor breakout board-ra szerelve kapható, forrasztani sem kell, annyi a dolgod, hogy összekötöd a megfelelő lábakat jumper kábellel."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."
Ezt például itt a topikban is ki tudod deríteni, mert ha leírod/lerajzolod a terveidet, megnézzük, és szólunk, ha nem fog működni.
A pro micro joystick jó tanuló projektnek tűnik, azt írtad van hozzá leírás és kód is. Próbáld meg a programot módosítgatni.
-
válasz
repvez
#13218
üzenetére
Úgy érzem ez a rókafogta csuka esete: nem mersz a hardverekkel kísérletezni, mert nem tudsz programozni, illetve nem tudsz elkezdeni programozni, mert nem tudod, mit kezdj a hardverekkel.
Valahol meg kell törni ezt az ördögi kört. Én a programozás részénél fognám meg a dolgot, ugyanis egy programról könnyen el lehet dönteni, hogy sikerült, vagy nem, mert már a fordító szól, ha elrontottál valamit.
Kezdetnek olvasgass arduino és C tutorial-okat, ismerkedj meg az alapokkal. Szerezz pár ledet, ellenállást és nyomógombokat, és kezdj velük játszani. A ledvillogtatás az arduino "hello world"-je. Ha mennek a digitális inputok és outputok, akkor fogj egy potmétert, és olvass be analóg bemenetet. Ezzel az arduino lehetőségeinek a 70%-át fel is fedezted. Minden további külső periféria kezelése ezeken alapul. -
válasz
repvez
#13211
üzenetére
Valahol javasolták a Tina nevű szoftvert, ezt még nem próbáltam, de analóg áramköröket lehet vele tesztelni.
Igazából nem értem, hogy mit szeretnél/mitől tartasz. Amikor egy szenzort postaköltséggel együtt megveszel mondjuk az Aliról 2$-ért, nincs miről beszélni.
Balesetek előfordulnak, én is sütöttem már meg alkatrészeket, mert elnéztem a lábkiosztását, de ez ellen pont nem véd semmilyen emulátor: ehhez odafigyelés és gyakorlat kell. Át kell olvasni az adatlapokat figyelmesen, megépített és tesztelt kapcsolásokat keresni a neten (ebből rengeteget fogsz találni fotóval, példakóddal), és ha valami nem világos, kérdezz! Elég sok tapasztalt hobbista gyűlt össze ebben a topikban ahhoz, hogy egy általad használni kívánt alkatrésszel kapcsolatban akadjon valaki, akinek van gyakorlati tapasztalata, esetleg tud jobbat javasolni helyette.Kérdezted, hogy "hogy érdemes elkezdeni az arduinoba való programozás dolgokat meg a fejlesztést?"
Először is ne céltalanul kísérletezz, döntsd el, hogy mit szeretnél építeni. Pro micro-ból nagyon jó dolgokat lehet csinálni, mert számítógépre kötve tud USB HID eszközöket emulálni (egér, billentyűzet, joystick/gamepad, midi vezérlő). Keress már megvalósított projekteket, onnan megtudod milyen alkatrészekre lehet szükséged, rendeld meg és játssz vele, tapasztald ki, hogy mik a határai, mi másra lehet még használni. Nálam általában egyik projekt szüli a másikat, mert menet közben eszembe jut, hogy ezt a cuccot másra is lehet használni. Aztán van egy csomó alkatrészem, amit csak úgy rendeltem, hogy valamire csak jó lesz. Van pl egy robot porszívóm, csak minden alkatrész külön dobozban van, össze kéne végre rakni. Nézd meg ezt a két pdf-et, hátha segít, ötletet kapsz belőle:
[link]
[link] -
válasz
repvez
#13209
üzenetére
Szia!
Én csak a tinkercad.com-ot ismerem, azt írtad is. Igazából a legtöbb kiegészítő filléres eszköz, érdemes inkább beszerezni, és úgy próbálgatni.
Amiből korlátlan mennyiségre lesz szükséged, az a jumper kábel, minden változatban, esetleg breadboard, bár én azt nem szoktam használni, mert amikor prototípust építek, vagy légszerelek, vagy próbanyákot használok. -
válasz
Janos250
#13202
üzenetére
Köszi a választ!
A verzió: van tippem. De tudod, hogy én meg mazochista vagyok, úgyhogy eldöntöttem, hogy attiny85 lesz, punktum. B verzió: nem elég kidolgozott, mi van, ha nyomva tartott gomb mellett küldöm ki a PWM-et? Rövidzárlat.
Nekem van egy elképzelésem, csak nem akartam leírni, hogy ne befolyásoljam az ötletelést. Viszont azt nem írtam le, hogy a 3 féle funkció milyen viszonyban áll egymással.
A gombnyomás következménye a fény és a hang. Néha lesz fény és hang gombnyomás nélkül is.
Az én elképzelésem szerint az alap beállítás az input, belső pullup-al. A gomb sorba kötve egy mondjuk 1000Ω ellenállással, az se a PWM-et, se a LED-et nem befolyásolja különösebben. A LED a +5V és a kimenet közé, fix LOW output-ra erősen világít, a PWM-re villog, de ez nem kimondottan okoz problémát, mert a kettő általában együtt fog működni. Folyamatos LOW output-ra és a gomb megnyomására a hangszóró elvileg egy kattanással fog reagálni, de a DC jel leválasztása érdekében lesz előtte egy felüláteresztő szűrő.
Ettől keresnék jobb ötleteket! -
válasz
atesss
#13191
üzenetére
Én ezt egy tetszőleges AVR-rel és a benne lévő analóg bemenetekkel, illetve komparátorokkal oldanám meg. 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. Itt nem kell vizsgálni, hogy két szegmens világít. Tovább megyek, ezt egy aluláteresztő szűrővel és egy schmitt-triggerrel is meg lehetne csinálni, μC nélkül. Ez egyúttal kiiktatja a multiplexelés problémáját is.
Bocs, ez nem volt válasz a kérdésedre, csak ötleteltem. -
válasz
csongi
#13171
üzenetére
Nem jó a link.
A kolléga arra utalt, hogy UNO helyett érdemesebb csak egy ESP-re építeni az egész rendszert, ahogy írta, egy ESP8266 alapú Sonoff vagy valamilyen Wemos/Lolin/NodeMCU jobb erre a célra, vagy ESP32, ha több kimenetre / nagyobb számítási teljesítményre van szükséged.
Arduino UNO+WIFI összeállításra akkor lehet szükség, ha önmagában kevés az ESP8266 kimenete, vagy sok analóg bemenetre van szükséged, de egy ESP32 ma már minden szempontból agyonveri. -
#13163
Aryes
nagyúr
Drótszamár
#13159
válasz
Drótszamár
#13159
üzenetére
A hardveres reset gomb megnyomása hosszabb ideig tart, mint a szoftveres reset, mert aránylag sokáig nyomva marad a gomb. Esetleg az is lehet, hogy a hardveres reset alatt a kimenetek hi-z állapotba kerülnek, a szoftveres reset alatt pedig talán nem. Próbáld ki, hogy a setup-ban minden lábat bemenetre állítasz pullup nélkül, és utána teszel egy delay-t.
-
#13157
Aryes
nagyúr
Drótszamár
#13155
válasz
Drótszamár
#13155
üzenetére
Ha az i²c okozza a problémát, akkor szerintem nem fog segíteni a hardveres reset sem! Az i²c szenzort is kellene ilyenkor resetelni, illetve ha nincs rajta külön reset lehetőség, akkor próbáld meg a tápellátását megszakítani, pl. fet-tel. Szerintem a szoftveres reset azért hatástalan, mert a WD a μC-t hiába reseteli, a rákötött eszköz utána sem kommunikál.
-
válasz
Dißnäëß
#13149
üzenetére
Az Ohm törvényt értem... Nekem az nem világos, hogy mi garantálja nálad azt, hogy 20mA fog folyni a két sorba kötött alkatrészen és nem 50mA? Nem ismerem a kijelző szegmenseinek a saját ellenállását. Ha az - tegyük fel - 0Ω, akkor 50mA fog rajta folyni. Érted, mire gondolok?
-
válasz
Dißnäëß
#13135
üzenetére
Nem néztem utána, hogy ez hogy működik, de közvetlenül nemigen köthetsz egyet sem egy UNO-ra például, mert ugyan portonként 20mA-rel lehet terhelni, de az össz terhelés nem mehet 80mA fölé.
Egyébként nézd meg ezt az oldalt, talán itt jobban kapsz választ! Én led driver helyett mpc23017 port sokszorozót használnék hozzá, az pont 16 port, és a terhelést is bírni fogja. Van hozzá library. Az arduino-ról pedig csak 2 portot fog elfogyasztani az i²c miatt.
-
válasz
XP NINJA
#13123
üzenetére
Szia! Én első körben megpróbálnám a szenzort 3,3V-ról megtáplálni, ha szerencséd van, működni fog.
Úgy tudom egyébként, hogy az ESP32 ADC-je elég vacak, talán megérné egy külső 5V-os ADC-t beiktatni, i2c-n keresztül, azt pedig jó eséllyel tudod külön illesztés nélkül az ESP-re kötni oly módon, hogy az i2c busz felhúzó ellenállásait az ESP 3,3V-ra húzod fel. -
válasz
Directors
#13102
üzenetére
Hiányzik valami a sor elején, legalábbis az indent erre utal, szerintem véletlenül töröltél pár karaktert. Honnan szedted a programot?
Próbáld meg, hogy az "initdata" elé odaírod, hogy "matrix."matrix.initdata();
De ez csak egy gyors tipp.És legközelebb légyszives illeszd be kódot például ide, és linkeld, hogy lássuk, mert így csak sötétben tapogatózunk.
-
válasz
Atesz.d
#13078
üzenetére
Nem. Első indítás előtt csinálni kell egy "portable" nevű mappát az arduino könyvtárban, onnantól kezdve oda pakol mindent a user/appdata könyvtár helyett. Így lesz portable.
Mondjuk azt van értem, hogy miért nem tud feldobni egy dialógus ablakot telepítés előtt, hogy mindenki értesüljön erről a lehetőségről, én is itt hallottam róla először, hogy van ilyen.Tényleg kéne már csinálni egy összefoglalót a topiknak.
-
válasz
Atesz.d
#13075
üzenetére
Ezért van nálam az arduino ide portable módban. Hátránya, hogy több helyet foglal, ha több verzió is fent van párhuzamosan, mert az összes kiegészítőt minden verzióhoz külön le kell tölteni (és a legújabbat még le se töltöttem). Előnye, hogy több verziót is lehet használni.
-
válasz
Janos250
#13068
üzenetére
Természetesen csak vicceltem.
Minden feladatot próbálok a legkevesebb alkatrészből, a legminimálisabb hardver felhasználásával megoldani, azért gondolkodom mindig célhardverben. Az AVR-eket meg azért szeretem annyira, mert lenyűgözően egyszerű és átgondolt a működésük, és szeretem, hogy nagyjából mindent értek, ami bennük zajlik. Mint régen a C64.
A másik, hogy szeretek hackerkedni, élvezem, ha egy adott hardverből a lehető legtöbbet tudom kihozni. Az ESP32 mindent (is) tud, azzal nem kihívás bármit elkészíteni. ![;]](//cdn.rios.hu/dl/s/v1.gif)
Ajánlom a Total commandert ilyen célokra (is).
Na ebből se fogok nagyon bevásárolni. 
feltéve, hogy a dugó helyére tennéd a mikrokapcsolót. Kellően kicsi tank kellene, hogy kis vízmennyiségnél is kapcsoljon, és ne maradjon benne sok víz, mikor lekapcsol.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Ha nagyobb távolságot kell áthidalni, vmilyen csavart érpáros vezeték, pl a hobbi elektronika topikban láttam 
A gombnyomás következménye a fény és a hang. Néha lesz fény és hang gombnyomás nélkül is.
Új hozzászólás Aktív témák
ekkold
- ASUS TUF F15 gamer laptop, i5-11400H, RTX 3050 Ti, makulátlan állapotban+ajándék
- SONY NEX-5N (SONY E bajonett)
- Samsung 870 QVO 8TB - keveset használt, 2026-ig garanciális - 100/100
- Garanciális // Lenovo Legion 5 // i9-14900HX // 32GB RAM // 1TB SSD // RTX 4070 // 240Hz
- Acer Predator Helios 16 // i7-13700HX // 32GB RAM // 1TB SSD // RTX 4070 // 240Hz
- LG UltraGear Gaming Monitorok -30%
- ÁRGARANCIA!Épített KomPhone i5 14600KF 32/64GB RAM RTX 5060Ti 16GB GAMER PC termékbeszámítással
- iPhone 12 mini 128GB Black -1 ÉV GARANCIA - Kártyafüggetlen, MS3460, 94% Akkumulátor
- Azonnali készpénzes Apple Macbook Air felvásárlás személyesen / csomagküldéssel korrekt áron
- Update 10.08. Lenovo ThinkPad, X1 carbon, X1 Yoga 5-13. gen 12,5-15" all-in-one, Workstation
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest