Amit küldél linket abban az encodernek 5 pin-je van. Leírás nincs róla?

Az 5 pin-es rotary-kban mindig van egy nyomógomb. Maga a tekerő egy mikrokapcsoló lenyomható gombja. A három sorban lévő láb a rotary, a másik oldalon a két láb a mikrokapcsoló, az egy-egy szélső láb a fémház. Alps EC11, a kereső hozza az adatlapot.

Igen, így van. A másik két pin a nyomógombé, azt már le is próbáltam külön működik szépen. Igazából ez az egy oka, hogy ezzel szórakozom és nem potmétert veszek, mert szükségem van rá, hogy a tengelyt lenyomva legyen egy nyomógomb!

Agent_Z működő mintaprogramjában a 3, 4 lábakra a kötve az enkóder, a te általad beírt verzióban meg a 2, 3 lábakra. Biztos a bekötésnek megfelelő a programod?

Többször felmerült bennem, hogy egyszerűen nem azt a bitszekvenciát adja vissza a rotary, mint amit vár a program. Vagy nem olyan bitekkel kezdődik mint amit vár és akkor félremegy. Több olyan rotary-m is van ami másféle sorrendben adja vissza ezeket a jeleket és a programot módosítani kell. Néha elég egy egyszerű "polaritáscsere" az AB lábakon, de néha át kell írni még a library-ban is a bittérképeket.

Az egyetlen ami nem derül ki első ránézésre, hogy te milyen library-t használsz a rotary-hoz. Aztán megnéztem a MIDI lib-et és ott saját rotary kezelés van. Tehát írhattok tesztprogramot amilyet akartok, azon úgyis jó lesz de nem biztos, hogy ugyanúgy kezeli a jelek sorrendjét a MIDI-s csomag is. Megnéztem a rotary adatlapjában a jelsorrendet, ami ugyanolyannak néz ki, mint az Instructables-en lévő cikkben. Benne van még a pakliban az Agent_Z féle dolog, hogy a negatív számokat a program egyedien kezeli le és ott is elcsúszhat a dolog a rotary esetleges eltérő bitszekvenciájával.

Sajnos kezd ez kicsit sok lenni nekem, de olyanra is kell(het) gondolni, hogy a midi refresht()-t egy interruptos függvényből kellene meghívni.

Nem úgy kell ezt bekötni, hogy a 'gomb' lábait egy interruptra használható lábra kötni, a maradék kettőt pedig nem?

Mit értesz maradék kettő alatt? Két független áramkör van a rotary-kban. 3 gomb a rotary A-GND-B és egy sima mezei nyomógomb. A kettő egymással nincs összekötve.

Van 3 különböző rotary-m, különböző forrásokból. Mind a 3 működik a tesztprogrammal ami csak a magas-alacsony szinteket figyeli. Viszont az olyan programokban már nem, ami "bittérkép" módban működik, az egyik semmit se csinál, a másik minden tizedik forgatásra működik, a harmadik meg jó. Nem minden rotary-t úgy gyártanak le, mint az elvi rajzokon.

A bitszekvencia alatt meg ezt értsd, ezek a legegyszerűbb és elméleti példák (CW: clockwise: óramutatóval egyező irány, CCW:counter clockwise: óramutatóval ellenkező irány):

Egyik library által figyelt sorrend:
CW : 0101
CCW: 1010

Másik library által figyelt sorrend:
CW : 1010
CCW: 0101

Remélem érzed, hogy hol csúszik el a dolog. De vannak library-k amik még bonyolultabb szekvenciákat figyelnek, még több bittel, fél-lépés, egész-lépés, start, begin, next, final, ezeknél végképp nem mindegy milyen a sorrend.

Épp ehhez hasonlót akartam most írni:

Még az jutott eszembe, hátha lehet ezt az encodert jumperolni, hogy Big Edian, vagy Little edian adatsort lökjön ki.

Ezt még elképzelhetőnek tartom, hogy minden hardware-hez könnyebb legyen illeszteni, de attól tartok ez nem az lesz.

Viszont akkor azt nem értem, hogy a monitorozáskor miért jók az adatok? Int változó, rendesen kiíródik. Vagy tényleg ez a midi Lib nem ehhez van illesztve.

Arra gondoltam, hogy a nyomógombot kell az interrupt lábra kötni, az a és b-t pedig egy digitális lábra, de nem interruptot támogatóra.

De már több ötletem nincs.

Azért jó monitorozáskor, mert ott simán magas-alacsony változást figyelsz az elvi bekötés alapján. Te döntöd el, mi a balra és a jobbra, nincsenek bitsorozatok. Ugyanez volt a bajom a 3D nyomtatóval, bontottam egy autórádióból rotary-t, bekötöm, nem jó. Szívtam vele sokáig, bontottam egy másikat, az se jó csak máshogy. Szereztem egy harmadikat, az meg jó volt elsőre. A tesztprogrammal meg jó volt az összes. Én gyanakodnék még az általad említett negatív számot egyedien kezelő dologra is ami a MIDI lib-ben van, ott is írják több oldalon keresztül.

A CRC-s kérdésemre nincs ötleted? Jó lenne valami egyszerű számítás is. Mondjuk összeadom, kivonom, xor-olom, mittudomén, csak biztosan egyedi legyen az ellenőrző összeg és a másik eszközön megismételhető legyen.

Esetleg ebből meríthetsz ötletet:
Fast CRC library for ARDUINO

Köszi, megnézem. Te milyen módszert alkalmazol ha használsz ilyet? Részletek itt. Azért keresek egyszerűt, hogy bármelyik platformon tudjam alkalmazni. Vagy ahogy az előzményben írtam, lehetséges-e különböző library-kat más platformok között "összeszinkronizálni"?

Kicsit el van szúrva a RotaryEncoder.h -ban a refresh függvény. Egyik irányban tekerve 0-t, másik irányban tekerve 127-et küldött a SendMidi függvénynek. Módosítsd az alábbiak szerint, és 0..127 közötti értékeket fog küldeni (ha a debug.h -ban kiveszed a kommentet, akkor a soros monitoron tesztelheted a működést).

Nem szoktam túlbonyolítani:

Értem, köszi. Valami ilyesmire gondoltam.

Átírtam a RotaryEncoder.h-t és kiszedtem a kommentet a debug.h-ból és ezeket a szépségeket mutatja, bármerre tekerem akkor egy "tekerésre" (amíg nem mutat értéket) ír egy "négyzetet", majd ha még egyet tekerek akkor egy négyzetet és egy "ţ"-t és így tovább... illetve továbbra is csak növeli az értéket!

Hol volt pontosan a hiba?

Másik kérdésem, hogy melyik oldalról leszedett encoder lib ez?

Nekem is kell egy kijavított verzió, ne szívjak már ennyit vele! Ha feltennéd mindannyiunknak a módosított Lib-et, hálásak lennénk!



Ennyi kellett volna a kódba, hogy ha a korábbi pos értéket átalakítottuk volna a célnak megfelelően? Akkor nem is kellene az encoder lib?

Csak mert kérdeztem korábban, hogy ezt a pos értéket (újabb kódunkban, ahol már ment) hol, milyen módon adjuk át bárminek is. Erre itt ez a refresh().

Ezt a lib-et használom!

Csak a fentebb közzétett módosítást csináltam, a forrás pedig a wifi196 által belinkelt oldalon levő MIDI_controller.zip.
wifi196: ezek a kockák olyanok, mint ha a soros port sebessége nem lenne megfelelő. Nekem nincs Atmega8u2-t tartalmazó modulom, csak dedikált USB-soros átalakító chipes, így az abban levő USB-MIDI átalakítót nem tudom kipróbálni. Gyanús, hogy neked az USB-s atmega8u2 dupla programja nem tudja a 9600bit/sec-et. Ha van CH340-es átalakítót tartalmazó modulod, azon próbáld ki inkább DEBUG módban.

Vagy próbálgassa végig a saját soros porti ablakának a sebességeit.

Sziasztok Srácok!
Az 1.5.7-esel rendben lefordult a program minden oké.
Köszönöm Gabónak és persze mindenkinek aki segíteni akart.
További szép napot nektek.
Üdv:Józsi

Hello.
Mindenhol kerestem arduinohoz az SPI.h konyvtárat/fájlt de sehol sem találtam.
Valaki be tudná linkelni nekem ami használható is?
Üdv.

Szia!
Ezt az arduino könyvtáraim között találtam:

Vagy ITT letölthető.

Köszi.
De ebben is tudnál segiteni?
Vagy valaki?

A progin belül adtad hozzá a .ZIP fájlt a könyvtárakhoz?

Én raknék hozzá egy fél marék hidegítő kondenzátort, esetleg szénné szűrném a tápot.

Ez érdekes jelenség én megnézném szkóppal a kimenő jelet meg a tápot. (bár nekem is volt olyan hibám, hogy amint a szkópot ráraktam, azonnal megszűnt a hiba, így nem tudtam mérni sem). Az arduino tápja rendben van? (belül mérj a modulon, legutóbb olyan hibát találtam egy kapcsolásban, hogy nem kapott rendesen tápot és a RESET felhúzóellenálláson keresztül bejövő +VCC működtette, persze instabilan).

A táp egy 2A -es telefon töltő, mini usb csatis. Mindig ezt használtam hozzá, az elején is,mikor még csak vezetékkel volt összekötve.

Szia!
Szerintem a SPI.h alapból benne van az arduinoban. Nem kell külön a libraryba is berakni.