Ott valamit elkötöttél !
Próbáld meg újra !
Ezek szerint nem "csöngetted ki a rotary kivezeteseket.Nem azonositottad jol be....
Nem kell nyomni ahhoz hogy valtozzon a tekeresmor.
A nyomogomb az lenne az "enter" , nyugta, kivalaszto, funkcio valaszto nevezzuk aminek akarjuk.
Ha pedig tenyleg jol van kotve , akkor softvert kellene megnezni , lehet igy keszult tenylegesen.
Veletlen eltekeres stb miatt ... a hasznalati leirasaban ilyen van , hogy nyomd es tekered egyszerre ?!

Az nem jo. Vagy a nyomogomb ad forditott jelet ( Low helyett High szintet), vagy a programban van forditva értelmezve. (Egy ! elötte segit).
Az Ardunioban van egy kisebb logikai bukfenc, amikor a magas (High) szintet értelmezi aktivnak, holott sokkal gyakoribb a forditott logika, amikor pl egy nyomogomb stb, aktiv állapotban a GND-re kapcsol, azaz alacsony (Low) az aktiv szint. Ebböl gyakran keletkeznek olyan bukfencek, mint ami veled is történt, hogy nyomni kelljen a gombot a müködéshez.
A gomb az enkoderben többnyire arra szolgál, hogy bevidd a rendszerbe a beállitott adatot, azaz a proci beolvassa a tekerést ( gombnyomás nélkül), de csak akkor használja fel, ha utánna megnyomod a gombot.

Sziasztok. Egy (Columbo-s)kérdésem lenne . Sikerült e már valakinek stack overflow -ot (verem túlcsordulás?) előidézni? Mire kell vigyázni, gondolom hogy milyen "mélyre" megyünk a szubrutin hívásokkal , na de milyen mélyre mehetünk? Mitől függ? Az SRAM foglaltságtól? Bocs a láma kérdésért de pár napja már aludni is alig tudok emiatt

Adott egy arduino NANO.

Több Nano-n is fut egy program, az jól müködik.

Az egyik nano panel érdekesen viselkedik...
Egy ideig jól müködik, majd csak a pwr led világít, és nem működik. Ha rádugom a gépre látja hogy fel van csatlakozva, de nem tudok rá tölteni semmit sem. Majd késöbb megy a feltöltés, és működés. Ha nem töltöm rá a programot, akkor is egy idő után jó. Ez lehet bootloader? Vagy inkább valami alaktrész nincs leforrasztva? Gondolom az uP.

Szerintem hardver hiba, nem bootloader, lehet nincs jól beforrasztva valamelyik IC láb. Lehet ha fut a program az Arduinon, akkor jobban melegszenek az alkatrészek, így nem jól érintkezik valami valamivel. Ha egyáltalán nem tudtál feltölteni semmit,szerintem akkor lenne a bootloader hibás.

Ezért ne legyenek álmatlan éjszakáid! Olyan mélyre lehet menni, amíg el nem fogy a stack területe. Ez nem olyan sok, lévén hogy az atmega328 összesen 2k ramot tartalmaz. Ha csinálsz egy függvényhívást, akkor a paraméterek számával tudod befolyásolni a hívás költségét. A változók is kérik a ramot. Ha rekurzívan dolgozol, például rendezel, akkor érdemes nagyobb procit választani, és akkor nem fogsz kifutni belőle. Természetesen programhiba még mindig okozhat ilyen hibát, de kisebb eséllyel. Esetleg figyelheted magadnak a foglaltságot, de ez prociidőt fog elvinni. Nem tudom natívan van-e erre lehetőség.
A véleményemet erre alapoztam.

Szerk: Bocs, nem volt kijelentve hogy 328-as, valamiért feltételeztem. A többit viszont tartom.

De Massawa és JZoli hozzászólására is.

Bár most nincs itt a próbapanel, de most lehet, hogy jól bekavartam.... Visszaidézve én összekötöttem az enkoder két GND kivezetését, aztán az a közös ment az A2 pinre, a maradék switch meg a GND-re. Tehát pont fel van cselérve... Bocs !
Majd szombaton tudom csak folytatni a "butaságom törtétetét". Addig is köszi nektek !

Hibájából tanul az ember, legközelebb sikerül.

Az nem jo, ha az encoderröl, csak egy vezeték megy a prociba. Annak ugyanis az a lényege, hogy 2 kimenet "fáziseltolásban" van. Ebböl tudja a proci, hogy merre tekered ( jobbra vagy balra felfelé vagy lefelé számol). A nyomogomb most extra ( még galvanikus kapcsolat sincs a forgorészhez).
Azaz azon az oldalon, ahol 3 láb van a középsö rendszerint a GND, a két szélsö megy mondjuk az A1 meg az A2 lábra. A nyomogomb egyik lába megy a GND-re a másik meg pl az A0-ra.
Kera_will kolléga már pontosan be is irta, hogyan kell, csak más lábakat használt.

Ok, a forgatást mostmár értem. De mi történik ha megnyomom az enkoder gombot ? Csak az LCD háttérvilágítást kapcsolgatja ? Kezdő vagyok ebben, nem látom át még a programot...

A program ugy szokott müködni, hogy az enkoder állását beolvassa és elteszi egy átmeneti változoba. Pl LEPES. Itt van egy szám ( ki lehet pl irni a displayre). Amikor beállitod a számot akkor jön a gombnyomás és a LEPES változo tartalmát átmásolod, ahova kell.
Pl igy lehet egy erösitöben ( autorádio) egy "tekerövel" beállitani a balancet, a hangszint meg a hangeröt. Az elsö kettöt általában elmentik a megfelelö eepromba, hogy ne kelljen mindig ujra állitani a hangerönél ilyesmire nincs szükség, azaz arra azonnal reagál az erösitö. pl a gombbal kiválasztod mit akarsz beállitani - balance, hangszin, majd a gomb megnyomásával elmented az ez értékeket az eepromba. Erre a szerkezet kilép a menüböl, és a tekerö átváltozik real-time hangeröszabályová.
Nem emlékszem a te szerkezeted mire szolgál, lehet, hogy valoban csak arra, hogy kapcsolja be a display világitását, hogy feleslegesen ne fogyassza pl az áramot az elemböl.
Közben utánnanéztem, te a t12 elektronikájával küzdesz. Ha jol emlékszem ott, ha megnyomod a gombot 9 paramétert lehet beállitani. Valahol le van irva. Ilyenek:
1. A páka beállitott alap hömérséklete 340 fok
2. A standby hömérséklet 160 fok
3. Az idö hány másodperc után kapcsol standby-be: 45 sec
4. A páka höjellemzöje. Stb

Csak igy fejböl irtam, már nem emlékszem, egyszer végigcsináltam az egészet. Eléggé áttekinthetetlen. Ugy müködik, hogy megnyomod a gombot, kiir a diaplayre egy számot.(1-9).
A cetlin le van irva melyik szám mit jelent, azaz kiválasztod a számot a tekerövel beaállitod a kivánt értéket majd ujra megnyomod a gombot. Ezzel elmented, igy kikapcsolás után is ezzel a paraméterrel indul a páka. Amugy nagyon ötletes, sajnos a display kis mérete teszi áttekinthetetlenné.

As instructables honlapon minden meg van irva. 3 almenüje, azaz a gombbal 3 különbözö menübe lehet belépni. A controller menuben pl:ezt lehet beálliani:

The controller menu
To get to the controller setup menu, long press the encoder in standby mode. In the setup mode the configuration parameters can be adjusted. There are 6 menu entries in this mode:

automatic power-off timeout (in minutes)
temperature units (Celsius or Fahrenheit)
the iron calibration ('calib.')
initial setup procedure ('tune')
save the changes
cancel the changes
Rotate the handle to select the menu item. To change the selected item, press lightly on the encoder handle. After adjusting the parameter, press the handle again to return to the setup menu. Long press of the encoder handle can be used to return back to standby mode and save the parameters in the EEPROM.

Bocs, még mielőtt jobban bele nem mélyednél. Ezek szerint nem olvastad a EZT a kérdésemet. Ugyanis én ezzel a kapcsolással - és programmal - birkózom. A kérdés is konkrétan erre a kódra vonatkozik. Még egyszer bocs ha félrevezettelek !

Én nem irtam a kodot, de ugy látom, csak igy gyorsan átfutva, hogy ebben is van legalább egy állapot, amit ki lehet választani ( MANUAL CONTROL). És itt lesz pontosan a gombnak a funkcioja. A kapcsolás a másikban is hasonlo, csak a kod lesz egy kicsit másabb.
A te kododban is van egy vagy két szubrutine ahol a változok definicioját végzik el, azaz az lesz az az üzemmod, amikor ezeket be lehet állitani arra az alaphelyzetre.
(A pontosabb elemzésre ismerni kellene azt az 5-6 *.h programot amit az elején betöltesz ( include....)

Itt megtalálhatsz mindent, a leirást a kodot a kapcsolást.

T12

Köszönöm, elnézést a pontatlanságért, igen atmega328 - ra értem a kérdést. Egyenlőre nem volt szükségem rekurzív függvényhívásra, egyszer próbáltam kíváncsiságból (persze végtelent) hogy mennyire egyszerü elöidézni összeomlást az MCU -n, meglehetősen egyszerü volt és gyors. Következő függvényt használom hogy lássam mennyi a maradék szabad SRAM méret:

Arduino környezetben rendesebb debuggolási lehetőség híján ez mennyire megbízható eljárás? Vagy ugye ezt az infót egy Serial.print -el juttatom a tudtomra ami persze plussz fgv hívás a freeRam fgv. után ami már nincs beleszámítva a kapott eredménybe? Nagyon hasznos volt a link

Ez az egész mókolás lehet hogy okafogyott! Végülis mire kell neked ennyire pontosan a ram ismerete? Ha szükséges, akkor figyelheted, de ez plusz ram, és cpu időt jelent. Ha függvényt akarsz hívogatni, akkor megteheted hogy a hívás előtt kijelzed a szabad ramot, meghívod a függvényt, majd újra kiíratod, de most már a függvényen belülről. A kettő különbözete a függvényhívásod költsége. Ha a továbbiakban nem piszkálod a függvény kódját, akkor most már ezt az értéket használhatod konstans tényként, hogy megbecsüld/kiszámold a szükséges memóriahasználatodat (már ami a vermet illeti). Ki lehet dobálni az immár felesleges kódokat belőle, és visszakapod az erőforrásaidat. Most már csak arra kell figyelni, hogy ne legyen váratlan esemény ami újra megdobja. Ez az egész attól függ, hogy milyen kódot írsz, mert ha jól figyeltem erről még nem esett szó.


Ezt így nem tudom megmondani. Én általában "markereket" szoktam használni erre a célra, a kód bizonyos helyein kapcsoljon fel egy ledet pl. De jó a soros terminál is, csak figyelni kell hogy hasznos adatokat írass ki vele, mert eléggé erőforrás igényes.

Nem használnám programon belül, csupán kisérletezés végett, fejlesztés, hibakeresés közben információt kapni a szabad memória méretéröl.Pl. Itt gondolkodtam el,használtam a fgv -t hogy infót kapjak a memóra állapotáról mivel néhol mélyebbre megyek egy-egy fgv. hívásakor.

Üdv!

Nextion könyvtárat ki ismeri, használja?
Hajam égnek áll tőle. Olvasgatom az itead tutorialját ami az arduino könyvtárra épül, de nem lettem sokkal okosabb. Azt már sejtem m it kell megadni a nexListenList funkciónak, de a popcallback esemény mit kezel le? Valamint ez egyenként kezeli a gombokat? Nekem úgy van megírva a nextion-ra a szoftver, hogy a kijelző lekezeli a beviteli eseményeket és egy SAVE gomb lenyomására küldi el egyszerre. A nexLoop ki tudja olvasni egyszerre az össszes elküldött paramétert?

Szerintem kérdezd Bakman-t, ő már foglalkozott vele, cikk is készült: Bővebben: Link

Köszönöm azt ismerem, de az PIC-re készült. Azzal nekem sincs bajom. PIC-re már készítettem többet is. Ott tudom mi hogy megy, mert megírom a saját rutinjaimat. Az Arduinót nemrég használom és itt ugyebár kész könyvtárak vannak amiket bogarászhatok. Ráadásul C++-ban gyenge vagyok. Már nagyjából kifiléztem, hogy a kijelzővel nem küldhetek semmit csak touch eseményt, és az arduino (esetemben az ESP) kér adatot ha megkapja az eseményt és arra válaszol a kijelző.

Üdv!

Szeretnék egy arduino uno-val PS4-es kontroller jeleit feldolgozni. Utána olvastam a neten és azt találtam, hogy szükség van egy usb host shieldre. Rendeltem egy usb host shield minit(Bővebben: Link). Ezt a leírást szerettem volna követni:Bővebben: Link, de itt arduino pro mini-t használ. Igazából azt szeretném kérdezni, hogy Uno-hoz, hogy lehet ez a host shield mini-t csatlakoztatni illetve, hogy a jelszintek megegyeznek-e az UNO és a Usb host shield mini között.

Köszönöm a segítségeteket!

A kérdésedre válaszolva szerintem simán beteheted az uno-t a mini helyére, nem kellene hogy gondod legyen belőle. A linkelt oldalon írja is, hogy a shield mőködik 3/5V-ról is. A hogyant illetően, mutatja a rajz, hogy melyik pint hova kell drótozni.

Igen én is olvastam azt, de megnéztem a max3421e ic adatlapjat ami az usb hos shield minin van és azt írja, hogy a max VCC az 3.6V(11. oldal):Bővebben: Link

Miért nem használsz pőre UART parancsokat? Karakter, szöveg küldés. Gondolom Arduino alatt is meg lehet oldani a fogadást, akár megszakításból is.

serial print ("t0.txt=\"alma\"")

Vagy valami ilyesmi.

Hát lehet, hogy az lesz, ha nem sikerül dűlőre jutnom ezzel a könyvtárral.

Arduino dueval meg tudod csinálni gond nélkül, van a neten minta, még effektek is lehetnek benne, csak az elég dŕága eszköz, mióta az enyém tönkrement nem nagyon gondolkodom benne...
Egy torzítót meg tudsz venni 4000 Ft -ért használtan. Egyébként a nanot is meg lehe úgy hekkelni, hogy hangfrekis dolgokat lejátszon, a bemenet csak 10bites lesz, de lehet ehhez elég az is...
Egy másik megoldás a nano+vs1053, ez viszonylag olcsó...

Feltételezem, hogy ATMega328 alapú Arduino-ról van szó.

Ezen a processzoron 0-tól kezdve a RAM előtti címeken vannak a regiszterek és az IO-k. 0x0100-tól 0x08FF-ig van a RAM. Lásd: https://forum.arduino.cc/index.php?topic=570405.0

(A program memóriának külön független címtere van, mert ez nem Neumann, hanem Harvard architektúrájú processzor.)

A RAM-ot a legkisebb címektől kezdve a fordító fixen feltölti a "statikus" változókkal, amik a program teljes élettartama alatt ugyanott csücsülnek. Felülről pedig jön a stack, indukáskor tehát a stack pointer pár (SPH, SPL) a 0x08FF címre mutat, és minden push lefelé növeszti a stacket. Stack overflow akkor történik, ha a stack "beleér" a statikus változók területébe.

A statikus változók helyeit az úgynevezett MAP fájl ember által értelmezhető módon megmutatja. Ilyet a legtöbb fordító rendszer elő tud állítani, az Arduino alatt üzemelő avr-gcc is. Itt van leírás, hogy hogy kell csinálni, gondolom működik: https://forum.arduino.cc/index.php?topic=72948.0 A map fájlból látszik, hogy hány bájtot foglaltunk le statikusan, tehát tudjuk, hogy mennyi maradt a stacknek.

A MAP fájl nélkül is a __bss_end szimbólum tartalmazza az utolsó foglalt bájt címét, a fordító tölti ki értékkel mikor megtörtént a statikus változók elhelyezése a RAM-ban. Lásd: https://www.microchip.com/webdoc/AVRLibcReferenceManual/malloc_1mal...o.html (Itt van malloc-ról is szó, amit lehet csinálni, de tipikusan nem malloc-ozunk 2kB RAM-ban, az Arduino-ban alapból nincs malloc.)

Ja, és az Arduino alapból is kiírja a RAM statikus foglaltságát IMHO, tehát csak rá kell nézni és látjuk mennyi hely maradt stacknek.

Stack overflow-ra sok rendszerben van beépített figyelés, de tudtommal ezeken a processzorokon nincs, tehát sosem fogsz stack overflow hibát kapni, csak simán hülyén fog működni a program. Először néhány változót felülír a BSS szegmensben, aztán a DATA szegmensben is, végül az IO-t és a regisztereket sem kíméli a program. Ha átfordul a címzés és a 0xFFFF-re mutat a SP nem is tudom mi történik, de eddig úgysem szabad eljutni.

Az SPL és SPH regiszter értékét a programod bármikor le tudja kérdezni, és ki tudod pl a Serial-on keresztül printelni PC-re. Így meg tudod nézni, hogy a programod bizonyos pontjain mennyi a stack foglalás. Így ki tudod mérni, hogy melyik függvénynek mennyi a foglalása. (Vagy az ASM programkód elemzésével is meg lehet ezt tudni. Illetve egy idő után már tudod becsülni a C kód alapján is.) Illetve be tudsz építeni magadnak ellenőrzési pontokat a programodba, amik túl nagy stack foglalás hiba esetén vészleállítanak és jeleznek.

Tipikusan stack overflow jellegű hibák hibás végtelen rekurzióval tudnak előjönni: ha bárhol van rekurzió a programodban, akkor ott nagyon észnél kell lenni, hogy ne lehessen végtelen önújrahívás. (Természetesen több függvény is lehet kölcsönös rekurzióban, arra is figyelni kell.) Nagyobb programkódokra szokás statikus ellenőrzést futtatni, ami kizárja például a rekurziót. (A pointeren keresztüli függvényhívásoktól eltekintve a kódból gráfot lehet építeni, hogy mi mit hívhat meg, és ezen a gráfon látszik, hogy van-e lehetőség rekurzióra.) A MISRA szabvány pl tiltja a rekurziót: nagy megbízhatóságú rendszerek esetén szokás ilyet kikötni.

A másik módszer, ahogy stack overflow-t lehet csinálni, ha egy ISR (interrupt kezelő) valamiért egymásba ágyazva futhat le. Ilyen akkor történhet, ha az ISR-en belül engedélyezed az interruptokat (SEI) és valami okból ugyanaz az interrupt újra aktiválódik mielőtt visszatérne az előző handler. Ha nem írsz egyedi ISR-eket, vagy sosem adsz ki SEI-t interrupton belül, akkor erre azért nem kell számítanod, hogy az alap rendszerben ilyen hiba volna.

Természetesen rekurzió nélkül is előjöhet stack overflow, ha nagyon nagy tömböket allokálsz a stacken (a függvények nem statikus változói ide kerülnek), vagy rengeteg függvényed van. (Vagy ha nagyon nagy a heap-ed és ezért eleve kicsi a stacked.) Ezek ellen kell mérni (többnyire becsülni is elég) a tipikus lefutások stack igényét.

Elterjedt módszer még, hogy a bss_end és az SP közötti címteret teleírod egy fix mintával induláskor, és azt nézed, hogy meddig lett ez a minta "elrontva" a stack használat által. (Ez a vízjel, vagy stack watermarking) A vízjel leolvasását elég például a loop-ban egyszer megcsinálni, és ha sose gyanúsan sok a vízjel értéke, akkor nincs overflow a kódban.

Ja, és hogy válaszoljak az első kérdésre is: igen, csináltam már stack overflowt ATMega328-on meg máson is .

Köszönöm szépen ezt a részletes információt. Igen, pontatlan volt a kérdésem, 328 -as MCU volt a kérdés tárgya. Ez a "vízjeles" megoldás nagyon ötletes, tetszik, Rekurzióra egyenlöre nem volt szükségem de jó észben tartanom hogy oda figyeljek ha használnom kellene(rendezés). A "gráf" megoldás után fogok olvasni, egyenlöre nagyobb kódnál papíron próbáltam felvázolni hogy melyik függvény mely másik függvényt hívhatja meg és így kiküszöbölni az esetleges rekurziót(hobbi megoldás hobbi programozótól )

Igen, a gráfépítés a kód alapján statikus elemzővel egy profi megoldás. De ezek a toolok általában rendkívül drágák. Csak azért említettem, hogy nagy profi projektekhez léteznek ilyen eszközök, de amit csinálnak, azt kicsiben kézzel is meg lehet tenni.

Arduino ISP:
Ez használható?