- Milyen okostelefont vegyek?
- Hat év támogatást csomagolt fém házba a OnePlus Nord 4
- Google Pixel topik
- Poco X5 Pro - ránézésre jó
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Beárazták az projektoros Ulefone-t
- iPhone topik
- Samsung Galaxy A56 - megbízható középszerűség
- eSIM, a kártyamentes szabadság
- Apple Watch Sport - ez is csak egy okosóra
-
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
válasz
Teasüti
#4122
üzenetére
Még egy kis kiegészítés:
Beállítod a frekit úgy, hogy 1.2 microsec (ha jól emlékszem) legyen a periódusidő, a kitöltöttséget (emelt szint hossza) pedig aszerint, hogy 0 vagy 1 kerül kiküldésre. Kiküldesz 1 bitet, várod az 1.2 microsec lejártát (közben bármi történhet, az se baj, ha néhány microsecre hosszabbodik) és küldöd a következő bitet. -
Teasüti
nagyúr
válasz
Teasüti
#4068
üzenetére
Nem tudom kell-e konfigurálni regiszter szinten az AVR-t a beérkező jel megjegyzésére kikapcsolt megszakítások mellett, hogy aztán bekapcsolás után rögtön kezdje meg az ISR-t, vagy alapból így működik...
De gyakorlati jelentősége úgy tűnik nem nagyon van. Ha éppen rosszkor is jön be a megszakítás, akkor is csak 10-30 ms-et csúszik az időzítés a következő jelig.
Ez jelentősen jobb eredmény, mint az AVR saját számlálójának felfüggesztése miatti csúszás.
Azért kíváncsi lennék rá beállít-e interrupt flag-et ilyenkor, vagy sem. -
tvamos
nagyúr
válasz
Teasüti
#4055
üzenetére
Es a PIR szenzornak nem mindegy? Amit a riasztokhoz hasznalnak kabel teljesen megfelelo. Ha nagyon igenyes vagy, akkor legyen csavart erparas. Ha ket MCU kozott kell kommunikalni, az azert megbonyolitja a rendszert, minde elkeszites, mind debugolas szempontjabol, szoval azt csak a kihivas miatt, ebben az esetben.
-
gyapo11
őstag
válasz
Teasüti
#4047
üzenetére
Hogy méretezzek vezetéket analóg jel továbbításra?
Egy fotoellenállást szeretnék kihelyezni 5 méterre az MCU-tól.Erre való az áram, pl. 4-20 mA. Ennél nem számít a vezeték ellenállása (hacsak nem extrém nagy), mert az adóoldalon addig emeled a feszültséget, amíg a vevő bemeneti ellenállásán+a vezeték ellenállásán kialakul a kívánt áram.
-
#4045
krisztianAMG
senior tag
Teasüti
#4044
krisztianAMG
senior tag
válasz
Teasüti
#4044
üzenetére
Távtartókkal. Kifúrod a helyét, alulról beleteszel egy csavart, rá a panel, majd rögzíted egy anyával.
Amúgy meg deszkapanel.
-
zsolti_20
senior tag
válasz
Teasüti
#3759
üzenetére
Arrol lenne szo konkretan hogy egymasnak tudnank uzenni par meter tavolsagrol. Mind ket oldalt lenne egy-egy kijelzo amin latnank hogy milyen uzenetet hagyott a masik. Pl megkapom azt hogy "xy cikkszamu dolog kell" visszakuldom hogy "rendben 15 perc" A kommunikacio leroviditese lenne a cel.
-
-
Janos250
őstag
válasz
Teasüti
#3555
üzenetére
Rendben, megkezdett projektet nem könnyű variálni, de azt azért ne sajnáld, hogy az újabb led sort vetted! Jó az!
A linkelt 700 Ft-os ARM laphoz csak annyit, hogy:
"All USART interfaces can be served by the DMA controller."
Ez azért ugye már egy más kategória. Bár én még ezt nem használtam ki.
Ha DUE-ban gondolkodsz, azon az áron már egész jó lapot is lehet venni, ami ugyanúgy teljesen passzol az Arduinohoz. -
Janos250
őstag
válasz
Teasüti
#3553
üzenetére
"A FAB LED library kikapcsolja a megszakításokat a led szalag frissítése előtt"
A megszakítást a led frissítésénél nem kell végig kikapcsolni, csak amíg a magas szint van, ez kevesebb, mint 1 microsec.
Az alacsony szint hosszában elég nagy a tolerancia, 8-9 microsecig elmehet alacsony szinten.
"kell egy második MCU"
Nem feltétlenül! Egyszerűbb, ha választasz egy korszerűbb CPU-t!
Például:
[link]
Ez ARM Cortex-M3 CPU, 72 Mhz-en jár, 64K flash memory, 20K SRAM, 720 Ft-ért.
Én persze ha csak lehet, azaz ha nem kell túl sok láb, az ESP8266-ot használom, de hát ez az én mániám.
Pl.:
[link]
1000 Ft-ért
[link] 800 Ft.
vagy a WeMos D1 R2-t, ami már 2-3 eFt Ft.
[link]
Ezzel a WeMosszal az a baj, hogy nem tudni, hogy a kicsi kínai valóban az R2-t küldi és nem az R1-et.
"Biztosítékot nem a tápra kell méretezni? Vagyis ha 15A-es tápom van, akkor zárlat esetén 15A fog áthúzni."
Nem! Egy mai jólnevelt táp, ha rövidrezárod, leáll, tehát ez a védelem már eleve benne van a tápban. Próbáld ki egy PC táppal. Ha rövidrezárod, leáll.
Ha biztosítékot akarsz betenni, akkor azt a maximális fogyasztásnál egy kicsit nagyobbra kell méretezni.
Egyébként ugyebár ilyesmire általában PC tápot (mert gyakorlatilag ingyen van a kiszuperált PC-kből), vagy laptop tápot szoktak használni. Vagyis akkora a valószínűsége, hogy a rendszered kigyullad, mint amekkora a valószínűsége, hogy egy PC, vagy egy laptop kigyullad. Nem nulla, de elég kicsi. Ilyen alapon a laptopoktól is nagyon kellene félni.
"Akkor még egy kérdés: létezik olyan túláram védelem, ami a táp kapacitása felett korlátozza felvehető áramot?"
Igen, maga a táp :-) ha az öreganyámnál egy kissé fiatalabb. -
Teasüti
nagyúr
válasz
Teasüti
#3435
üzenetére
Megvan a hiba forrása.
A FAB LED library kikapcsolja a megszakításokat a led szalag frissítése előtt. Hogy ez nem jutott előbb eszembe!
Konklúzió: kell egy második MCU, ami fogadja a parancsokat és az első MCU - ami a ledekkel foglalkozik - csak kérésre tud adatot fogadni.
Egyszerűen nem egyeztethető össze két, megszakítással működő library.
Vagy, szüneteltetni kéne a led frissítését, amikor bejön az első külső megszakítás.
Hmm...
Na ehhez library-t kéne írni szerintem.(#3552) Janos250
Biztosítékot nem a tápra kell méretezni? Vagyis ha 15A-es tápom van, akkor zárlat esetén 15A fog áthúzni. Gondolom én naivan.
Illetve ez így annyira nem szupi, mert simán le tudom terhelni 15A-rel üzem közben.
Akkor még egy kérdés: létezik olyan túláram védelem, ami a táp kapacitása felett korlátozza felvehető áramot?
Teszem azt 300 db led 18A-t tudna felvenni, de csak 15A áll rendelkezésre. Egy brown-out jelenség kedvezőbb volna a világításban, mint egy elfüstölt táp.
(Mondjuk szoftveresen tudom szabályozni a teljesítményfelvételt - mérni is tudom MCU-val az áramfelvételt -, de nem ártana vmi hardveres korlát is.) -
Janos250
őstag
-
tibi-d
tag
válasz
Teasüti
#3549
üzenetére
Az a kérdés, hogy az 5V-ot miként állítod elő. Ha 230VAC / 5VDC tápról hajtod meg a teljesítményfokozatot, akkor érdemes lehet egy külön 1-2W-os 230VAC/5VDC adapterről meghajtani, és csak a negatív potenciált összekötni. Ha az arduinonál lépne fel gond, a kisteljesítményű táp lekapcsol, "megvédve az arduinot". Ha másképp, akkor bonyolódik a helyzet.
-
tibi-d
tag
válasz
Teasüti
#3547
üzenetére
Mert a nagy áram kapcsolgatásakor óhatatlanul lecsökkenhet a feszültség 4,5V alá is, amit te nem veszel észre, de az arduino akár resetelődhet is. A testen keresztül zavarjelek indulhatnak el a processzor felé ( földhurok), ami szintén megzavarhatja a működését. Ha viszont elválasztod a nagy áramú részektől, az arduino minden zavartól mentesen végezheti a dolgát, nem érhet meglepetés. Ezt saját tapasztalatból mondom, mert heteket szenvedtem azzal, hogy néha nem azt csinálta amit kellett volna neki. És nem volt logikus magyarázat a dologra. Ekkor homályosítottak fel, hogy gondoltam-e a fentebb vázolt problémára. Igaz, hogy teljesen át kellett tervezni az áramkört, de azóta nem jelentkeztek "anomáliák". Azóta, ha 1-2A-nál nagyobb áramokat kell kapcsolgatnom viszonylag nagy sebességgel, akkor mindig ezt a módszert alkalmazom. Ha a sebesség nem fontos, maradok a relénél, a megfelelő védelmi megoldásokkal (védődiódák, stb.).
-
tibi-d
tag
válasz
Teasüti
#3540
üzenetére
Az optikai leválasztásnak az a lényege, hogy a vezérlő-, és vezérelt áramkör semmilyen galvanikus kapcsolatban nincs egymással. Az iparban ez egy rutin eljárás. Több 1000A áramokat vezérelnek processzoros áramkörökkel. Az optocsatoló bemeneti közös pontja csatlakozik az arduino testjére, az optocsatoló kimeneti közös pontja pedig a vezérelt teljesítményfokozat testjére. Az arduino az optokapu LED-jét vezérli, az megvilágít egy fototranzisztort, ami kapcsolja a teljesítmény fokozatot. A két oldal között csak a fény biztosítja a kapcsolatot. Így lehet akár 2-5kV feszültségkülömbségű áramköröket összekapcsolni. A másik módszer az impulzustranszformátor, ez a bonyolultabb módszer.
-
válasz
Teasüti
#3536
üzenetére
Talán a legegyszerűbb, és legolcsóbb megoldás egy PC boltokban is kapható túlfeszültségvédő. De igazából nem túl drága egy ilyen arduino, sem, így ha meghal sem drága cserélni, esetleg cseredarabot tartani otthon (én is így csinálom)
-
gyapo11
őstag
-
Janos250
őstag
válasz
Teasüti
#3506
üzenetére
Nem emlékszem már biztosan, de valahonnan úgy rémlik, hogy:
13-as LED bootloader állapottal kapcsolatos, lehet, hogy a gépre dugás egyből boot állapotba viszi?
D3: talán a watchdoggal kapcsolatos
Talán D7,D8,D9 valami hiba információ, de soha nem használtam, nem tudom.
Ajánlják az interneten, hogy félig halott panelnél :kikapcs
reset bonyom, nyomva tart
USB bedug
upload
mikor ténylegesen elindul a feltöltés (pontok) akkor kiengedhető a resetHa egyszerűen elvágod a fesz. stab. IC lábát és stab. feszt adsz rá?
-
tvamos
nagyúr
válasz
Teasüti
#3502
üzenetére
Azt nem mondtad, hogy minden alkatreszt le akarsz szedni. En holegfuvoval szoktam.
(#3499) Ribi válasza tvamos (#3498) üzenetére
Szaz szonak is egy a vege, normalis kornyezet kell a biztonsagos munkavegzeshez --> jo tap kell, aminem az asztalon hanyodik. Lehalabb egy lemez darabra, vagy plexire ra kell csavarozni. En a breadbordomat is raragasztottam alu lemezre, es gumitalpat is raktam ra, ne csuszkaljon ossze-vissza az asztalon.Nem is hianyzik mar mas, minthogy mondjuk egy boost konverter, vagy motor driver kiprobalasanal szetcsapjam a szkopom, vagy a pc-m.(#3504) Teasüti
Lehet, hogy az USB-serial interface mihalylott meg. -
Janos250
őstag
válasz
Teasüti
#3497
üzenetére
Én is javasolom tvamos első kettő linkjén szereplőket, én is használom mindkettőt, igen elégedett vagyok vele. Akkut is ilyennel töltök.
A harmadikat nem ismerem, de tetszetős, egyből rendeltem is egyet :-)[ Ezeken kívül én még használom a filléres tápokat is, persze mielőtt valakinek a kezébe adom, magam állítom be a feszültséget :-)
[link] 210 Ft
[link] 240 Ft
Ezen meg áramkorlát is állítható 430 Ft-ért:
[link] -
-
Janos250
őstag
válasz
Teasüti
#3454
üzenetére
"Mit értesz vektor alatt?"
Amit Te puffernak nevezel.
"ugyanúgy el kell tárolnom a ram-ban a vezérlőbájtokat minden szalagra vonatkozóan"
Így van.
"akkor ezt sehogy nem lehet leredukálni egy változóra"
Azt tényleg nem.
"Vagyis ha jól értem az egyetlen előny az volna, hogy átláthatóbb és rendezettebb lenne a program a mostani katyvasz helyett."
Jól érted. -
Janos250
őstag
válasz
Teasüti
#3451
üzenetére
Igen, jól érted.
Nem biztos, hogy jó a javallatom, mert nincs energiám részleteiben átbogarászni a programod.
Talán: egy képkocka generálás egy class, paraméter a kocka adatait tároló vektor.
Egy képkocka adatait mindenképpen egy vektorban kell tárolnod, és egyszerre küldeni ki a szalagra, mert - ha jól emlékszem - talán
8-9 microsec lehet max a szalag következő ledjének az adatainak küldése között, mert ha hosszabb, akkor "elölről kezdi",
azaz ami pl. 10 microsec múlva érkezik, azt már újra az első led kapja el, mint "sajátját".
Tehát akkor:
Egy képkocka első szalagra, bele a vektorba.
A vektor kiküldése az első szalagra.
Egy képkocka második szalagra, UGYANABBA a vektorba (memória takarékosság)
A vektor kiküldése a második szalagra.Változók/memória:
Amit a classban "felül" deklarálsz, azok a példány élete során végig megmaradnak. Amit az egyik tagfüggvényben, az csak a tagfüggvény működése közben.
A class a paramétereket (többnyire) érték szerint veszi át, de pl. a vektort nem, hanem "hivatkozás szerint", azaz a címét veszi át, és a "kintit" használja, így nem foglal
külön memóriát. Ha kell, lehet olyat is, hogy valamely változóból ne jöjjön létre példányonként egy-egy, hanem összesen egy, és minden példány azt az egyet használja ("static"). -
-
tvamos
nagyúr
válasz
Teasüti
#3442
üzenetére
En inkabb megprobalnam elhagyni a switch-case-t, ha lehet, ha ilyet csinalok.
A serialll kapcsolatban: [link]
En nem hasznaltam meg az Arduino frameworkot ilyen bonyolultsagu projekthez, megirtam C-ben. (Vagy regebben Asm.) Igy nem kellett megszakitasokkal sem bajlodnom, kiveve a pin change interruptot, azt hasznalta azert.
Most a te Unodban melyik AVR van? 328?
-
Janos250
őstag
válasz
Teasüti
#3442
üzenetére
Sajnos nincs kéznél, és a napokban nem is érek rá csinálni , neten meg nem tudok egyszerűt.
"Az effektezésnél tudatosan vannak kihagyva, így paramétertől függően végigmehet mindegyiken."
Én azért próba-szerencse alapon kipróbálnám enélkül, azaz ideiglenesen kikommentelve.
Vagy másként szervezném a switchet, hogy szabályos legyen, bár lehet, hogy így is az.Erőforrás:
Ja, igen, én ESP-t és ARM-ot használok többnyire :-) -
Janos250
őstag
válasz
Teasüti
#3437
üzenetére
Még egy megjegyzés egy amatőrtől:
Majd amikor már teljesen készen lesz a program, javasolom a globális változók használata helyett a class/objektum-ra átírást. Ugyanis ha csak egy szalagod van, akkor nem okoz gondot a globális változók használata, de ha több szalagot vezérelsz, akkor egymásnak bekavarnak. Objektum esetén viszont minden példánynak sajátjai vannak, tehát nem bántják egymáséit. -
Janos250
őstag
válasz
Teasüti
#3437
üzenetére
Okosat nem tudok mondani, de az egyik case-ből hiányoznak a break-ek.
Tapasztalatom szerint ez teljesen meg tudja bolondítani a programot, teljesen váratlan módon képes futni, nem csupán azt teszi, hogy ráfut a többire is.Ezt másnak is hangsúlyozom: Hiányzó break-ekre vigyázni!
-
Janos250
őstag
válasz
Teasüti
#3421
üzenetére
Esetleg egy próba:
Már nem pontosan emlékszem a problémára, és nem találom az eredeti bejegyzést, de soros átvitel során elvesznek adatok.
Nekem a Serial.print okozott hasonló problémákat ott is, ahol nem lett volna szabad. Igaz, én ESP-t használtam. Ha kihagytam az ellenőrző Serial.print-eket, hiba nélkül ment. Ha a Serial.print-ek elé, után delayt raktam, általában az is megjavította. Ha gondolod, próbáld ki.
Nincs más a programban, ami a megszakításaival bekavar? -
tvamos
nagyúr
válasz
Teasüti
#3421
üzenetére
En elso blikkre azt javasolnam, hogy menj le, amennyuire lehet. 600 baud, ha az a minimum.
Masodikra meg azt, foglald itt ossze, mirol van szo, mert en mar nem emlekszem pontosan.
- Hardware elemek: Windows PC / laptop --- Arduino Uno R3 USB kabellel osszekotve, vagy ket kinai nano 1km riaszto kabellel, ilyesmi. Esetleg egy kep.
- Ird le, mit szeretnel, mert mar arra sem emlekszem. Idojaras adatokat kuldeni, vagy Tolsztoj Háború és békejet akarod atkuldeni soronkent.
- A programodat esetleg rakd fel valahova, hogy be tudd nekunk linkelni. (Mondjuk a pastebinre.) En most kiprobalni nem fogom tudni, de azert beleolvasok... (Ami nem sokat segit, mert en nem futtatok fejben programot, meg amugy is hw tervezo vagyok, de hatha megis jon valami otlet.)Ha osszefoglalod, mit akarsz, lehet, hogy neked is lesz otleted, nekem mar tobbszor segitett, hogy valakivel beszeltem a problemarol, es osszefoglaltam, mi a gond, mit is kell megoldani.
-
gyapo11
őstag
válasz
Teasüti
#3395
üzenetére
A hardware-es kevésbé, egyszerűbb programból megoldani, de akadhat eset, amikor jobb a hw-ban.
Pont az a baj, hogy csak egy nyamvadt gomb, olyan érintkező felületekkel és mechanikával, amikből következik a prell. Nem is tudom, hogy egyáltalán el lehet-e tüntetni a prellt tisztán a kapcsoló mechanikai kialakításával, arany vagy bármi más érintkező felületekkel. Elektronikával sokkal egyszerűbb. A programmal szűrés időzítést kíván, és az néha gond lehet. -
tvamos
nagyúr
válasz
Teasüti
#3395
üzenetére
A MCU-k világában már inkább software-es a prellmentesítés. (En speciel ritkán nem teszek fel legalább egy kis kerámia kondit.) Régen, amikor még kevés volt a program memória, (pl. fél kByte-nál is kevesebb,) meg amikor kapukból építettük a logikát, akkor az volt, amit a kolléga írt.
-
Zahze
csendes tag
válasz
Teasüti
#3385
üzenetére
"mint az őrült azt a ledet" - Hogy kéne írnom ?
Amúgy ez csak egy egyszerű példa lenne rá, hogy valami nem kóser a megszakításkezeléssel egy ekkora programba se. (Lehetőség szerint, kizárni a programozási hibát...)
Amúgy ez egy riasztórendszerhez kéne, szebb lett volna így megoldani, ha már van benne ilyen lehetőség hogy megszakításokat használjak. Eddig amúgy a loop-ba volt simán if(digitalRead(2)) - el megoldva, az működött...
Kapcsolási hibát... hát, ennél egyszerűbben nem tudnék semmit összekapcsolni
Szóval szerintem nem ott a hiba.A kapcsolást is és a képet is az Elektromanoid-ról szedtem. Annyi változtatás van az én kapcsolásomban hogy egy NC-s nyitásérzékelővel működik.
Ennyire macerás/instabil ez a jelszint váltás elkapása az arduino számára ?
-
zka67
őstag
válasz
Teasüti
#3390
üzenetére
Jaja, rossz a megközelítés. Én 100ms-es timer megszakítással szoktam lekérdezni a nyomógombokat, így simán ki lehet szűrni a prelleket, és a megszakítás alatt még azt is lehet ellenőrizni, hogy a gomb most lett lenyomva, vagy már le volt nyomva stb, stb... és egy inkey() rutinnak átadni a paramétert. Én úgy szoktam, hogy ha az inkey() 0 értékkel tér vissza, akkor nem volt gombnyomás, különben a gomb értékét adom vissza.
-
gyapo11
őstag
válasz
Teasüti
#3387
üzenetére
A te megoldásod se jó, ha van prell. A prell ugyanis pont olyan, mint a nyomógomb rendes működése, csak gyorsan történik. Tehát ha nincs a beolvasásban időzítés, hanem rábízzuk a sebességet a processzorra, akkor az olyan gyors, hogy simán feldolgozza a ms nagyságrendű prellt is, és lekezeli mint gyors gombnyomkodást.
Kis késleltetés (10 ms körüli) megoldja, persze nem elegáns delay-jel, hanem millis-sel, hogy közben azért a program futhasson. Az interruptos megoldásnál meg az kell, hogy amikor beérkezik az első állapotváltás, akkor egy időzítést indítani, és ezt figyelni az interrupt függvényben, ha az időzítés még nem járt le, akkor figyelmen kívül kell hagyni az állapotváltásokat, mert azok a prell miatt vannak. Ha lejárt az időzítő, akkor megint ki lehet szolgálni a következő 1 db állapotváltást. Az interrupt függvényben ugyan nem működik a millis, de a meghíváskori állapota is megfelelő.
És lehet azt is csinálni, hogy két állapotváltás közötti időt mérni, és ha az kisebb egy adott értéknél, akkor figyelmen kívül hagyni. Pl. 20 ms-en belül ember nem tudja megnyomni kétszer, a prell meg ez idő alatt lecseng. -
gyapo11
őstag
válasz
Teasüti
#3385
üzenetére
Nem az lehet a gond, hogy a gombnak prellje van, és egy nyomás vagy fölengedés valójában n db change, és ezeket a gyors interrupt kiszolgálás mind meg is csinálja? Ha páratlan számú, akkor jól működik, ha páros, akkor viszont látszólag nem történik semmi, valójában annyiszor váltott, csak ezt nem lehet látni.
-
tvamos
nagyúr
válasz
Teasüti
#3377
üzenetére
Szerintem nem megoldhatatlan ez a probléma. Ha nem sikerül kiküszöbölni 1-1 byte elvesztését, akkor azt kell megoldani, hogy a vevő tudja, hogy ott elveszett valami, és a küldő újra küldje a csomagot.
(#3375) Janos250 válasza gyapo11 (#3373) üzenetére
Persze... ez az professzionális alkalmazás lesz... -
Janos250
őstag
válasz
Teasüti
#3361
üzenetére
Az okát jól leírta gyapo11.
Amatőr megoldás a problémára:
1. Az öregecske 328-as proci helyett egy korszerűbb. Nem drágább pl. egy ARM, ami sokkal gyorsabb, nagyobb a memóriája, korszerűbb. A megírt arduino program úgyanúgy (általában) fut rajta.
2. Multiprocesszor amatőr megoldása, hogy ha ragaszkodsz a 328-as procihoz, hogy egy picike külön 328-as Arduino panel (5-600 Ft), ami semmi mást nem csinál, csak a soros portot kezeli, ha lehet/szükséges előfeldolgozást végez, és akkor küldi át a ténylegesen dolgos procinak, amikor az kéri. -
gyapo11
őstag
válasz
Teasüti
#3361
üzenetére
A program feltöltése közben a mikrovezérlőn nem fut a kód, resettel kezdődik a feltöltés. Tehát minden figyelmét a soros porton érkező byte-okra fordítja.
Amikor viszont fut a kód, akkor ugrálnia kell a kód és a soros port etetése között, és itt bejöhet időzítési probléma, akadozás, ami adatvesztést eredményez. Sokszor elég egy kis delay, de a pontos megoldás mélyebb ismereteket igényel mind a mikrovezérlő működése mind a librarykban található kódot illetően.
Amíg nem tudjuk pontosan, hogy bármely pillanatban mit csinál a processzor, addig nem tudhatjuk az okot se a hibajelenségre. Ezért nem annyira alkalmas az arduino rendszer profi feladatmegoldásra, nincs megfelelő szintű debug, léptetés, regiszterek kiíratása, amivel meg lehetne találni a hibát. -
gyapo11
őstag
válasz
Teasüti
#3351
üzenetére
Valójában a villogás nem a megfelelő szó, jobb az akadozás. Simán el tudom képzelni, hogy valaki megírja az animációt, valaki más a távirányító kezelését, és a kettőt összeeresztve akadozni kezd, mert pont akkor nyomok rá a távirányítóra, amikor léptetni kellene az animációt, és a processzor egyszerre csak egy dologgal tud foglalkozni, a szem meg érzékeny az akadozásra. Ilyenkor jön az, hogy meg kellene találni az okát, de ezt idegen kódban és nem profi programozási tudással elég nehéz. Ha meg profi a tudás, akkor nem kell netről vadászni a kódot, hanem meg kell írni az első byte-tól úgy, hogy az infrát is le tudja kezelni a legkisebb akadás nélkül.
A megszakítás jó dolog, de nem tud csodát. Vagy az eredeti kód fut, vagy a megszakítást szolgálja ki, de addig az eredeti kód áll. Ahhoz több processzormag, közös memóriakezelés stb. kellene, hogy egy beérkező megszakítás ne állítsa meg az egyik magon futó kódot, és a másik magon azonnal futhasson a megszakítás.
Egy távirányítóról érkező parancs kiszolgálása persze elég rövid idő, de ha nem jól van megírva a kód vagy a library, akkor akár látható nagyságú idő is elmehet, és gond van.
Nem beszélünk konkrét számokról, mert ahhoz kellene a kód, és még akkor sem könnyű összeszámolni a szükséges órajel ciklusokat. Ehelyett ha írunk egy kis ciklust, az kb. 100 ezer/s, ha csinál is valamit, akkor legyen 10 ezer/s, ez 100 μs, ha pl. hangfrekis hullámformát generálunk, és egy megszakítás elvesz ennyi időt, akkor az már hallható lesz.
Sokszor láttuk már itt a fórumon is, meg más forráskódokban is a delay(1)-et vagy hasonlót, mert különben elvesznek byte-ok a soros vagy egyéb csatornán. Pedig a processzor 16 MHz-en pörög, és az ehhez képest rettentő lassú soros porton is el tud veszni adat, ha nem állítjuk meg egy ms-ig a futást.
Már egy ilyen kis processzorocska is annyi mindent csinál, hogy nem elemezzük órajel szinten. Ráadásul mi c++ forráskódódot látunk, de a processzorba egy ebből generált bináris kód megy, nem tudjuk, hogy melyik arduino utasításból milyen bináris kódot generál, így nem tudjuk az időigényeket se. Ráadásul ott vannak a libek, amiknek még a forráskódját se nézzük, hanem csak include-oljuk és reménykedünk benne, hogy működik és nem ütközik semmivel.
Ezért mondom, hogy ez hobbyra van kitalálva, mert pillanatok alatt tud bárki működő programot futtatni. Amint bonyolódik a program, mindenféle korlátokba ütközünk, az időzítést is nehéz kézbentartani, a libek minősége ismeretlen, a szigorú tesztelése időigényes. Mindezek elkerülése meg oda vezet, hogy elhagyjuk az arduino hw-t és sw-t is, és magát a mikrovezérlőt programozzuk profi eszközzel, debuggal, teszteléssel.
Vannak komoly házvezérlések, és egyéb bonyolultabb projectek, tehát sikerülhet a dolog, de erre nem lehet építeni, nem lehet megélhetést alapozni rá. -
printpro
csendes tag
válasz
Teasüti
#3321
üzenetére
Jogos, végülis, van egy full windowsos tablet (desktop win 10 fut rajta) De ahhoz kell egy külön software ami kezeli. Nem tudom, van-e erre kész megoldás? Vagy külön appot kell írni rá? Nem dobná az meg a fejlesztési időt / költségeket?
Első ránézésre erre gondoltam mint lehetséges távirányító kiosztást:[link]
Igazából nem ragaszkodom infrához. .Ha jobb / egyszerűbb valami okos eszközről vezérelni legyen. Csak az tart vissza hogy mennyire bonyolítja ez meg a projectet.
-
#3257
FireKeeper
nagyúr
Teasüti
#3256
FireKeeper
nagyúr
válasz
Teasüti
#3256
üzenetére
szerintem olcsóbban és egyszerűbben kijössz vele ha valami vízálló dobozkán vágsz rést egy sima karakteres LCD-nek és beragasztod (vagy ha nem is közvetlen az LCD-t ragasztod, akkor valami üveget/átlátszó műanyagot, és mögé a kijelzőt, vagy keresel valami ablakos dobozt). továbbá erre olyan gombokat tudsz rakni amilyeneket szeretnéd. el kell vele szüttyögni, de meg lehet szépen igényesen csinálni, még ha olyan nem is lesz amivel kiállításokra mész
-
kmisi99
addikt
válasz
Teasüti
#3254
üzenetére
Majd a következő lépcső lehet az lesz. Igazából én pont az összerakás és technikai oldalával vagyok jobban kapcsolatban. 5 éven át próbáltak belém programozást erőszakolni, mindenki elbukott. Egyszerűen az gondolkodásmódom nem való erre, mintha egy pap kapna bordélyházba állásajánlatot.
De persze érdekel, meg tökre örülök, hogy most a szervót is sikerült bele rakni a programba. -
kmisi99
addikt
válasz
Teasüti
#3252
üzenetére
Programozási analfabéta vagyok, de tényleg sikerült! Bár szerintem eléggé "csöves" módszerrel oldottam meg. Ugye megnyomom a balra gombot akkor balra megy de ott is marad, ezért beállítottam, hogy az előre gomb megnyomásával középállásba rakja a szervót. Köszönöm a segítséget, már annyira túl akartam bonyolítani ezzel egész jól meg lett oldva. Mert maga a program kicsit korlátolt, egyszerre csak egy gombot lehet lenyomni benne.
-
kmisi99
addikt
válasz
Teasüti
#3250
üzenetére
Hoppá! Valóban, a hozzá lévő androidos program már úgy működik ahogy kell! Köszönöm!
Már csak egy dolgot nem tudok, és ez a legnagyobb problémám. Az a helyzet, hogy az eredeti projektben amit találtam az autó kanyarodásáért motor felelős így a programban is ez van. . Viszont nálam ez szervó lesz. De fogalmam sincs hogyan tudnám ezt beleírni. Nekem annyi is elég lenne, hogy a turn right nál elfordítja jobbra 60 fokkal a leftnél balra 60 fokkal.
-
kmisi99
addikt
válasz
Teasüti
#3248
üzenetére
Köszönöm a segítséget így valóban úgy funkcionál ahogy kell, viszont a delay-t egészen 20ms ig kellett emelnem, hogy egyáltalán bírjon gurulni normálisan, de így is nagyon darabos. A PWM értékeknél meg nem látok delay-t amit emelhetnék, van a végén egy ilyen delay(time_ms); meg egy ilyen, delay(delay_ms);
De ezekkel nem tudom mit kezdhetnék. -
zka67
őstag
válasz
Teasüti
#3223
üzenetére
Szia, az adás és a vétel is ugyan azzal a sebességgel megy, ugye? Nos, amikor jön egy CR vagy egy LF karaktered, akkor te kiíratsz 3 karaktert. Amíg a programod azzal van elfoglalva, hogy megvárja amíg elküldi a 3 karaktert, ezalatt neked jöhet még 3 karaktered, amit nem tudsz kiolvasni, mert a programod épp mást csinál, és ezek a karakterek mennek a levesbe.
Többféle megoldást is tudok neked mondani, az első az, hogy amíg nem értél a vétel végére, addig ne írj semmit a soros portra. A második, használj megszakítást, írj saját rutinokat a küldés-fogadásra, címezd közvetlenül a regisztereket, azaz ne az előre megírt rutinokat használd.
Szerk: most látom, hogy println-t használsz, az még további két karakter jelent.
-
zka67
őstag
válasz
Teasüti
#3218
üzenetére
Szia, persze, én sem szoktam végigolvasni a több ezer oldalas doksikat, de amire szükségem van éppen, arra veszem a fáradtságot és átnyálazom alaposan, hogy melyik bit mit is csinál pontosan. Neked is csak rá kellett volna kattintanod az AVR CPU CORE -: STACK POINTER könyvjelzőre a doksiban, elolvasni, hogy hogyan működik és megnézni a hivatkozást az SRAM-ra, és máris tudtad volna, hogy miért nagyobb az SP értéke, mint a RAM mérete. Ezt nem bántásból írom, hanem a jövőre nézve adok tanácsot, sokkal gyorsabban megtalálod a doksikban amit keresel, mint ahogy itt válaszolnak neked. Utána úgyis megnézed a doksiban is azt, amit megnézhetnél kérdés nélkül is. De tényleg csak jószándékból írom ezeket.
De azt a "8 bites tömböt" nem értem, amit írsz.
uint8_t tomb[2048]; // Ez egy 8 bites tomb
uint8_t *pTomb; // Ez pedig egy 8 bites tombre mutato pointerIgen, a 8 bites tömb azt jelenti, hogy minden eleme egy bájtból áll.
Az utolsó elemének a címét pontosabban, nem
Mivel pointerként van deklarálva, ezért természetesen igen. Az elemet a * operátorral tudod elérni.
Üdv.
Zoli -
zka67
őstag
válasz
Teasüti
#3216
üzenetére
Szia, az uint8_t * nem 8 bites változót deklarál, hanem egy 8 bites tömböt, aminek a címe egy 16 bites érték.
Az Atmel AVR8 procikban a ram nem a 0-ás címtől kezdődik, hanem 256-tól, és a stack pointert a memória végére címzi, szóval stimmel a 2297-es érték. A memóriád utolsó bájtjának a címe = 256+2047.
Egyébként nem árt megismerkedni a procikkal, amikkel dolgoztok, azaz el lehet olvasni az adatlapjukat, minden fent van az atmel.com oldalán.
uint8_t *report = SP+1;Ez visszaadja a stack utolsó elemét.
-
Janos250
őstag
válasz
Teasüti
#3209
üzenetére
https://www.arduino.cc/en/Hacking/LibraryTutorial (a library készítést írja, de a végén az is le van írva, hova tedd, stb.)
[link]https://www.arduino.cc/en/Guide/Libraries
[link]aztán ha megnézel egy libraryt, látsz még benne ezt-azt.
library.properties néhány jellemző
keywords.txt itt adhatod meg, hogy miket milyen színnel jelöljön meg a keretprogram. "helyesírásellenőrzésre" jó
src könyvtárba kerülnek a .h és .cpp forrásfájlokbiztos még sokféleképpen jó, de így is működik.
-
Janos250
őstag
válasz
Teasüti
#3202
üzenetére
A /267 meg a B7h karakter, ami egy vesszős nagy E, vagy hasonló.
Tippjeim:
1. kicsomagolási, másolási hiba a fájlban.
2. valami olyan szövegszerkesztővel szerkesztetted, ami az ASC karakterek mellé még valami berak.Tehát a hiba azt jelzi, hogy nem ASC karakterek találhatók a fájlban.
Én nem látok az aplicationmonitor.h fájlban oda nem illő karaktereket.
Nálad valahogy nem jó ez a fájl. -
tvamos
nagyúr
válasz
Teasüti
#3169
üzenetére
Simán átmásolod a programot RAM-ba, onnan futtatod, és írod a flash-t. Újabban már ez sem kell, lapokra van osztva a flash, egyikben fut a kód, másikat írod.
De tuti Arduinon is lehet akkor, mert van bootloader. Akkor rosszul tudtam, az újabb avr-eknél biztosan lehet.
Aha, ja. Ha eltolod, felülírod a kódot.
-
fpeter84
senior tag
válasz
Teasüti
#3066
üzenetére
Az ilyen új dolgokat (timer, egyéb IRQ) egyébként ne egy meglévő programon belül próbálgasd, hanem nyiss egy új hello world projektet, amivel mondjuk egy ledet villogtatsz, vagy ha van oszcilloszkópod akkor azzal nézheted a lábat - kizárandó az egyéb hibákból, összakadásokból adódó helyzeteket
-
Teasüti
nagyúr
válasz
Teasüti
#3064
üzenetére
Sehogy se akar működni az I2C busz a megszakítással. A végrehajtási ideje 560 uS, szóval technikailag mennie kéne, de még 250 hz-re csökkentve se éled fel a program. Egyszerűen el se indul, még a setup() se fut le.
(#3065) fpeter84
GY-512-es modulom van, tud küldeni megszakítást.
Viszont jelenleg csak egyetlen tengely adatai kellenek nekem és csak a nyers adatok kiolvasása példáját használom. Az INT-hez meg már kéne a FIFO puffer, amivel meg társul a DMP is ha jól emlékszem (de nekem nem kell a DMP ehhez a projekthez, csak a nyers gyorsulás egy tengelyen).Illetve kicsi frekvencián nincs zajszűrés (átlagolva a mintákat), ami nekem nem jó.
-
fpeter84
senior tag
válasz
Teasüti
#3064
üzenetére
Van IRQ/INT lába a modulnak? Lehet programozni kell, lehet alapból is így viselkedik, de azzal tud szólni hogy van kész kiolvasható adata. A kis UNO-nak szerintem túlzás az 1KHz+matekozás, vedd vissza alacsonyabbra és timer IRQ helyett menjél rá a pin change IRQ témára!
-
Teasüti
nagyúr
válasz
Teasüti
#3063
üzenetére
Hmmm úgy néz ki működik a dolog, ha az interrupt függvény tartalmát kikommentelem és bent hagyok egyetlen számlálót.
Ebből arra következtetek, hogy túl lassú az interrupt végrehajtása?
Talán a következő megszakítás újraindítja a kódot mielőtt az lefutna?
Lehetséges ez egyáltalán, hogy a következő megszakítja az előzőt?Hogy szokás fix frekvencián kiolvasni egy I2C buszon lévő eszköz regisztereit, ha nem timer interrupt-tal?
-
fpeter84
senior tag
válasz
Teasüti
#3057
üzenetére
Egyébként valóban, sokszor egy 40-50$-os tablet lehet a legjobb megoldás a GUI megjelenítésre
A kékfog viselkedése meg majd kiderül a gyakorlatban, keress rá blogokat, tutorialokat - lehet minden írás után le kell húzni a resetet? Akkor az úgy elég macerás, annyi erővel már a kézi resetgomb megnyomás se problémásabb...
Új hozzászólás Aktív témák
Hirdetés
ekkold
- Gamer Laptop, Gamer Monitor és Konzol Felvásárlás Magas Áron, Gyorsan és Egyszerűen!
- BESZÁMÍTÁS! ASUS ROG STRIX X570-E Gaming alaplap garanciával hibátlan működéssel
- AKCIÓ! Gigabyte H610M i5 12400F 32GB DDR4 512GB SSD Intel ARC A770 16GB Rampage SHIVA 650W
- Telefon felvásárlás!! Samsung Galaxy A12/Samsung Galaxy A22/Samsung Galaxy A32/Samsung Galaxy A52
- 35" ASUS ROG Swift PG35VQ curved GAMER monitor
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged