Ja hogy tegyem őket vissza inputra, ne csak magasra? Nekem így egész jól ment. Egy régi vacakoló duén teszteltem, amiért már nem kár. Ok megoldom persze, viszont normál diódás mátrixnál már szerintem nem kell, mert közben rákötöttem egy rossz yamaha dx21 billentyűzetét. Már kiíja a lefogott billentyűket, illetve a polifónia is stimmel. Egyedül 1 billentyűnél szólal meg az összes hang. Ott hardverhibára gyanakodtam, végig is mértem minden diódát, de nem találtam meg a hibát, úgyhogy azt egy kicsit félretettem...

Ne mondj semmit tökre belekavarodtam ebbe a közvetlen portírásba egész nap ezzel szenvedtem. Egyszerűen csak a 45-től 52-ig tudom olvasni a bemeneteket. Alatta semmi reakció ezzel a módszerrel...
Pedig nekem kellene még a: 43, 41, 39, 37- is olvasásra, és kimenetre állítani 28-tól 50-ig a páros számúakat, címezve ezeket a megfelelő bittel, hogy a Yamaha billentyűzet csatlakozóját simán csak rácsatlakoztassam az alaplapra és az közvetlenül kezelje a keyboard-mátrixot...

(Egyébként 12 vezeték a címzés. Ez általában a címnek megfelelő hang: C vagy Disz, vagy D stb. Azt meg, hogy melyik oktáv szól éppen, akár egyszerre is, az a 6 bemeneten érkezik vissza. Így 12 lépésben leszkennelhető az összes lenyomott hang. DigitalRead()-al és Write-al remekül működik is.)

Elég hosszúra nyúlt a hozzászólások sorozata, nem találtam meg miről van szó.
A Arduino DUE igy már értem.

Köszönöm! Javítva az if-es rész is és mindkét LED-nél még kellett egy delay. Most már működik!

Lehetőleg mellőzzük az ilyen időtartamú delay()-t. Itt van egy lehetséges megoldás:

Igen a Due portjait akarnám elérni.
Közben már csak a 43-as láb nincs meg csak. Alatta felette ok.

Ha vannak diódák, akkor nem tudnak összeakadni a sorok, nem kötelező bemenetnek kapcsolni a nem aktív sor kimeneteket.
Amúgy nem egyszerűbb egy működő billentyűzetről midi-n működtetni? Vagy be akarod építeni a rossz szinti dobozába a saját cuccodat? A dx21 nem billentésérzékeny, így nagyon könnyen lekérdezhető a teljes billentyűzet, nem kell az egy billentyű két érintkezője között eltelt idővel foglalkozni mint a billentésérzékenyeknél.

Köszönöm!
Áttettem a LED-eket az analógra és az A2-n lévő nem villog. Az A0-ra HIGH kell, hogy váltson? Azért kellenek a D pin-ek mert több LED-et kell működtetni és nem akarom sem sorosan sem párhuzamosan kötni.
A jelet egy reed relé modulról veszem és az LOW jelet ad.
Ez egy vasúti dioráma fénysorompó vezérlése lesz. Balró és jobbról van egy-egy reed relé modul és azok váltják át a jelzéseket.

Ezért szoktam a változó vizsgálatánál előre tenni a konstanst.
Ha bekerül egy if (LOW=state), akkor egyből felsír a fordító, hogy mit is akarok.

Azokat írd át magadnak, hogy nálad hova vannak kötve.
A gomb a 2-esen, a 2 led meg a 8,9. Feltételeztem, hogy ezt magad is meg tudod csinálni
Erre módosítsd.

A gombot pedig a GND-re és a megadott kivezetésre (nálad épp most a 2-es) kösd.

Igen köszi, elvileg működik. Most építem bele a saját fm motyóm, kb ugyanazzal a menürendszerrel, kibővített képességekkel. A szinti sajnos EEPROM hibás, és sem írni sem szerezni nem sikerült, pedig Két éve áll nálam. Szép hangszer, megérdemel egy új életet, ráadásul igazi DX "designed", nagy álmom volt egy saját fm hangszer, csak horror árban vannak, most nekem is lesz egy saját "Reface" Yamahám

Köszönöm az ötletet! Átírtam a villogtatást úgy, hogy most már nincs benne a delay. Úgy tűnik, hogy jól működik így is.

Egy érdekes dolog történt a minap. Egy Arduinoval vezérelt fütés valamitöl megakadt.
Szeptembertöl ment gond nélkül, majd hirtelen a 4x16 LCD displayen csak az elsö meg a 3. sorban világitottak a fehér kockák a betük helyett. A másik 2 sorban meg semmi.
Egy RST az Arduinon nem segitett.
Kivettem a gépből a z Arduinot, ujratöltöttem a kodot ami rendbe tette a vezérlöt.
Elöször fordult velem elö olyasmi, hogy a proci kodja megakad.
Hogyan lehetne ezt megelözni?
A kod nem egyszerü.
Az LCD I2C - keresztül kommunikál.
A két termosztat egy másik porton, de szintén szeria kodon keresztül kommunikál
A beállithato értékeket változás esetén az Eepromba menti.

Át kell nézni a kódot sorról sorra, és ahol az van, hogy pl. várunk, amíg az IC clk-ja magas lesz, oda be kell rakni egy hibakezelést, ami kilép a várkozásból, mert néha, a környezeti zavarok miatt jöhetnek nem várt jelek is. A tömbtúlírásokat el kell kerülni. Esetleg fix újraindítás naponta/havonta, de a watchdog használata is segített volna a problémádon.

Gyakorlatilag naponta többször is ujraindul, mert a kazán idövezérlöje kapcsolja ki-be.
A watchdogra én is gondoltam, de az sem igen tud többet mint egy ujrainditás, ezen meg ez nem segitett.

Azt megteheted, hogy egy pin-t billegtetsz folyamatosan, ezzel pedig a saját tápját engedélyezed. Ha leáll a program, megszűnik a változó jel, nem kap tápot az Arduino, aztán, hogy hogyan indul el, az már a következő kérdés. Egy kis analóg áramkör kell.

Áramot kapott a rendszer de a kontroller nem indult el. Ilyenbe belefutottam már, ott egy masszívabb táphiba valahogyan olyan állapotot idézett elő, hogy a kontroller felülírta itt-ott magát, a kiolvasott kód nem egyezett a korábban beletöltöttel.

Minőségi tápegységet kell használni és úgy megírni a kódot, átalakítani a kapcsolást, hogy ne a kontroller tápegységét kapcsolgasd hanem egy bemenetét.

Irtam, hogy ez nem segitett, hiszen többször kikapcsoltam, ujra inditottam, reseteltem semmi. Kivettem a tokbol meg visszaraktam, az sem. A display lekapcsoltam arra sem reagált. Amikor észrevettem a hibát akkor a 13 porton levö beépitett LED villogott. Ez a port meg LED sem fordul elő a kodban. Az a villogás a RST-re megszünt.

A táp egy minöségi 5 V-t ado kapcsitáp. Mar vagy egy tucatot épitettem be, soha semmi baj nem volt vele.

Hogyan áll a fuse bit, ami az alsó lekapcsolási feszültséget állítja be? Eeprom íráshoz magasabbra kell beállítani, mert az érzékenyebb, és az írás relatíve lassú. Ezek szerint felülírta magát valahogy. Vannak a proci táplábainál nagyobb kondik? Én be szoktam rakni min. 100µF-ot. Nem foglal sok helyet.

A fusebitekkel nem igen foglalkoztam. Jelenleg az egész dobozt mindenestül a kazán idözitöje inditja párhuzamosan egy keringetö szivattyuval, azaz onnan kap 230V-t ( más kimenetem nincs a kazánból). Azaz akkor indul és a beállitott hömérsékletek szerint indit egy másik keringetö szivattyut. Amikor a kazán idözitöje lejár akkor megáll a doboz. Van a bemeneten egy nagy kondi 470 uF, de extra nem figyelem a táp kimenetét. Lehet, hogy azt kellene. Az eepromot csak akkor irja át, ha valaki manuálisan változtat valamit küszöbértékeken. Ami mostanában nem történt meg.
Más értéket nem igen ir, a hömérsékletet csak beolvassa, kiirja az LCD-re és összehasonlitja a beállitott küszöbbel, és aszerint kapcsolja a pumpát.
Azt talán meg tudom csinálni, hogy egy extra port figyeli a tápot ( amig a proci a 470 u kondirol megy), és leállitja magát, ha megszünik az 5 Volt a táp kimenetén. Igy elvben nyernék 20-30 sec a leállás elött, annyi csak elég, hogy mindent elvégezzen.

Ez nem az, amiről korábban beszéltél. Ez csak egy felváltva villogtató program, amiben a while() funkcióját tekintve a programodban egyenértékű a delay() használatával. Úgy tűnik, meg kellett volna indokolnom, hogy miért ajánlatos a hosszabb idejű delay() kerülése. Azért, mert megakasztja a loop-ot. Addig az ideig nem tud semmi mással foglalkozni. Mert ha már van egy bonyolult áramkörünk egy mikrokontroller formájában, ami rengeteg utasítást képes elvégezni nagyon rövid idő alatt, akkor ne kárhoztassuk arra, hogy semmi másra nem használjuk, csak kizárólag arra, hogy egy 2 tranzisztoros astabil multivibrátort szimulálunk vele
De természetesen arra használod, amire akarod, csak erre a feladatra kicsit túlzásnak tartom.

Én hardveres problémára tippelek. Valamilyen tranziens okozhat ilyesmit, a programkód nem igazán tudja magát felülírni. Ugyanis normál esetben a program memóriából mindig csak olvasás történik, annak a tartalomnak a megváltoztatása nem egyszerű feladat. Ha a tárterület túlírásra kerül, maga a programkód attól nem változhat, mivel fizikailag másik területen van. Egy reset-re ilyenkor visszaáll (ezt teszi ugye a watch dog).

Sajnos nekem sincs semmi ötletem. Tranziensek nem igen lehetnek, hiszen nincs a berendezésben semmi ami ilyesmit okozhat. A bemeneten intelligens kommunikacioval kapcsolodo höérzékelök (DS1820). A két nyomogomb rendesen kezelve van (1-1 kondival) és csak akkor kérdezi le, ha változást észlel. A kimenet a displayre I2C a relé egy optoval van leválasztva.
Amiota ujra irtam a chipbe a kodot hibátlanul megy ( ahogy ezt tette tavaly szeptember ota).

Érdekes, hasonló problémával én is találkoztam. Csak az segített, ha újra feltöltöttem a kódot a mikrovezérlőre.
De azzal a vezérlővel, amivel ez egyszer előfordult, azzal többször is, így kicseréltem másikra. A másikkal nem történt ilyesmi.

Erre kíváncsi lennék, ha kicsit mélyebben ki lehetne fejteni (vagy utána keresek). Az biztos, hogy a memóriában simán felül lehet írni másik változót, ami programhibát fog dobni, ez a RAM. De hogy a program memóriába lehet-e írni futásidőben, ez jó kérdés... A PROGMEM onnan olvas közvetlenül, viszont ez már a fordításkor eldöntődik.
Átgondolva: Miért ne lehetne? Ugyanezt teszi a bootloader is!

Természetesen írni lehet a programmemóriát(máskülönben programozni sem lehetne ugye), viszont ez a művelet egyéb védelmi körülményekhez van kötve, tehát csak úgy, brahiból nem tud összejönni, ehhez azért pontosan kell a szükséges feltételeket összehozni, s csak utána fog menni!

Nagyon röviden a lényeg, hogy a Neumann architektúrában egyetlen címmezőn található minden, ROM, RAM, EEPROM ha van. Míg a Harvard-nál ezek fizikailag külön vannak választva, még a cím hossza sem stimmel. Így egy pointer, változó hibás értékénél lehetetlen, hogy a program memória felülíródjon. A csillagok különös együttállása kell ahhoz, hogy a bootloaderben pont arra a címre kerüljön a vezérlés, ami írja a program memóriát, mégpedig úgy, hogy az írás feltételei is pont meglegyenek (vannak ugyanis engedélyező bitek is). Ennek a valószínűsége tart a végtelenhez . A másik ok, hogy a program memória írása nem annyira egyszerű, mint a RAM-é. Kizárólag laponként lehet írni, ennek gyártástechnológiai okai vannak. Tehát először törölni kell, ami itt minden bit 1-be állítását jelenti, majd az íráskor történik a nullák beállítása. Ezért tart sokkal tovább az írás (pl. a PIC kontrollereknél is külön eljárással lehet csak írni az EEPROM-ot).

A törlés itt a legkevésbé kritérium, mivel anélkül is lehet módosítani egy meglévő adatot, amennyiben az nem csupa 0-ás bit!

Én is tranziensre tippelek. Nekem kb. 1 hónapja volt hasonló problémám. Egy lapcsiszoló gépben kellett csak az irányváltásokat figyelni és kijelezni. Az 1-es képen lévő tápot használtam, majd egy 2-3 nap múlva az MCU megállt. Program újraírás segített, de már figyeltem hogy mikor történik meg újra. Pár nap múlva ismét, cseréltem az Arduino lapot (gondoltam valami selejtest fogtam ki, azért történik mindez), itt már teljesen elszállt a lap, semmi életjelet nem adott többé. Árnyékolt kábelokat használtam(mivel zajos környezetben müködik) ügyelve hogy földhurok ne alakulhasson ki az árnyékolásokon keresztül, optocsatolós leválasztás a bemenetre, bemeneti jel független tapról, GND-ről ment. Majd a megoldást a 2-es képen lévő tápcsere adta. Common noise, érdekesség.
Elfelejtettem írni, hogy mindig a bekapcsolás pillanatában történt a hiba, tehát ha elindult akkor menet közben minden rendben volt.