Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Szia!
Idézet: „Tehát XPT2046 Touch IC van rajta. Kérlek erősíts meg abban, hogy ezt nem kell inicializálni” Nem, úgy emlékszem hogy az XPT2046-ot nem kell inicializálni. Idézet: „a PENIRQ láb akkor kerül alacsony szintre, ha a kijelzőt megérintik, ekkor az SPI buszon kiküldött 0xD0-ra visszaküldi a megérintett X koordinátát, majd a 0x90-re visszaküldi a megérintett Y koordinátát” Igen. Bár a hexa kódokban nem vagyok biztos így fejből, de igen, így működik. Idézet: „a visszaküldött érték pedig 16 bit” Én úgy emlékszem hogy lehet 8 bitesen meg talán 12 bitesen használni. Idézet: „A touch IC BUSY lába pedig akkor kerül magas szintre, amikor a CS aktív” Na ezt nem tudom, én a BUSY lábat nem használtam. Idézet: „A kijelző kapcsolási rajzát olvasva (csatolmány), látom, hogy van benne egy stab IC aminek se típusa se semmilye és sehol sem írják, hogy mekkora feszültséget kaphat minimum és maximum a Vcc és GND lábak között. Erről tudsz valamit?” Rövidre zárom a kérdést: Úgy fogod megkapni az Ebay-ről hogy a panelon az U1 nincs beültetve.  Idézet: „A JP2-es jumpert leforrasztva, a LED+t a Vcc-vel összekötve és a LED_PWM lábra PWM-el lehet szabályozni a háttérvilágítás erősségét, igaz?” Igen, én is így szabályozom a dsPIC-kel a fényerőt a kijelzőn. Idézet: „Grafikai dolgokat próbáltál már vele, például egy objektumot mozgatni a kijelzőn?” Nem, én csak szövegeket írtam ki rá és különböző alakzatokat (vonal, téglalap, kör) jelenítettem meg rajta. Illetve BMP-t rajzoltattam ki a memóriakártyáról. Ezen a videón látszik hogy nagyjából miket csináltam én eddig a kijelzővel. Mondjuk a videón pont egy másik típusú (sokkal rosszabb minőségű) kijelző van, de ugyan ezeket csináltam a nagyobbikkal is: Bővebben: Link
Rotációs enkódert szeretnék kezelni. Pontosabban azt szeretném hogy a PIC kezelje.
Agyaltam rajta hogy hogyan lehetne jól megcsinálni és arra jutottam hogy a legtutibb megoldás az állapotgép lehet. Írtam is egyet, de sajnos a gyakorlatban nem akar működni. Sokszor nem léptet és sokszor pedig többet lép mint kellene. Teljesen használhatatlan... Nem értem hogy miért nem működik. Az enkóderem alaphelyzetben az A és a B kivezetésein is H szintet ad, a forgás közben az iránytól függő sorrendben L szint lesz rajtuk. Az enkódernek 24 lépése van és ezeknél mechanikusan picit arretálja magát, ilyenkor van mindkét lábán H szint. A PIC az enkóder mindkét lábát megszakításból figyeli, az A lábat az INT1-el, a B lábat pedig az INT2-vel. Az állapotgép az enkóder helyzetének változását úgy követi, hogy a két megszakításnak folyamatosan változtatgatja az élét. Az állapotgép az enkóder hét különböző állapotát különbözteti meg, és azt hogy épp melyik állapotban van, azt az "EnkoderAllapot" nevű előjeles változóban tárolja. Alaphelyzetben 0 az értéke, és ez -3-ig és +3-ig tud elmenni, eme hét állapot közt oda-vissza lépkedve követi az állapotgép az enkóder helyzetét. Ha -3 alá, vagy +3 fölé lép, akkor ismét 0 lesz az állapot és ilyenkor történik a tényleges léptetése a léptetendő változónak amely most épp a "DACL" nevet viseli. Elvileg ennél hatékonyabb enkóder-kezelés nincs, mert itt magát a pergést is követi elméletileg az állapotgép így fals léptetés vagy léptetés kimaradás elméletileg nem történhet. A gyakorlatban viszont sajnos szinte csak ezek történnek. Mi lehet a gond? 
Ahogy látom nem túl átlátható a kód így a fórumban, talán így jobb:
Dehogy jobb, sajnos a fórummotor lekicsinyíti a képet. Itt van az eredeti:
Valamilyen prellmentesites van a bemeten?
Ja igen: természetesen mindkét láb digitális bemenet, mindkettőre be van kapcsolva belső felhúzóellenállás, az egyikre az INT1 van odakapcsolva, a másikra pedig az INT2, ezeknek a megszakításai engedélyezve vannak és ezen megszakítások prioritása a legmagasabb. Mondjuk az ördög nem alszik, inkább mutatom:
A pergésmentesítést maga az állapotgép végzi el. Illetve végezné, ha működne rendesen.
Ennél az állapotgépnél nem számít ha prelleg az enkóder, mert követi magát a prellegést is, viszont léptetni csak akkor léptet amikor ténylegesen megtörtént egy egységnyi forgatás (az enkóderem esetében 360°/24=15°).
Szia!
Köszi a választ a kijelzőhöz, adok én is egy kis segítséget! Én a következő képp csinálnám: Az encoder két lába és a test közé még kell 1-1 100nF-os kondi, ha most nem prelleg de ha kopik akor fog. Az interruptot jól csinálod, egyszerűen csak a másik lábon kell figyelni, és eldönteni hogy alacsony vagy maga szinten van és ennek függvényében balra vagy jobbra lett tekerve. Nekemfelfutó élre fut le az interrupt. A növelt változót pedig a main-ben kellene feldolgozni, tehást ott kellene kialakítani a state machine-t. Szükség lesz egy flag-re, amit az SM-ben 1-re állítasz és az SM-be csak úgy lép be ha a flag 0, az interruptban pedig a flag-et nullázni kell. Szerk: A kódodat látva elég egy interrupt afelfutó élre és ott egy if-el kell csak figyelni a másik lábat. Nekem a gyakorlatban szoftveres prellmentesítésre nem volt szükség, elég a 100n. A hozzászólás módosítva: Dec 14, 2015
Amikor átállítod a figyelendő él irányát, bejön/bejöhet a megszakítás. Le kellene tiltani, átállítani az él irányát, törölni a jelzőbitjét és újra engedélyezni.
Úgy érted hogy jön mondjuk egy INT1 megszakítás, belép a megszakításvektorra, ott rögtön törli az INT1 flagbitet majd míg utána ott molyol addig történik még egy INT1 megszakítás? És ahogy kilépne a megszakításból már rögtön ugrik is vissza?
Vagy úgy érted hogy benne van az INT1 megszakításban és közben jön egy INT2 megszakítás? Erre gondoltam, ezért van az "else if"-ek utolsó sorában mindig a másik megszakításforrás flagbitjének törlése. Viszont az előző eset az végülis megtörténhet. A két megszakítás egyébként (INT1 és INT2) egymást ugye nem tudják megszakítani mert ugyan olyan erősek.
Ha engedelyezve van az "interrupt nesting", akkor egymast megszakithatja a ket egyforma prioritasu megszakitas is. Az adatlapban valahol kell legyen emlites a termeszetes prioritasu sorrendrol.
Az első eset a prellegés esete. Ha az első utasításként törlöd a jelzőbitet, a feldolgozás alatt bebillenhet újra.
A második eset az, amire gondoltam. Most épen az INT1 kér megszakítást és az INT2 magas szinten van. Az INT1 kiszolgálója átállítja az INT2 él irányát. Ekkor bejöhet az INT2. Ha letiltja, átállítja az élet törli az INT2 jelzőbitjét és újra engedélyezi, az él állításakor keletkező kérés nem jut érvényre. A 16 biteseken megszakíthatják egymást.
Átírtam úgy ahogyan mondtad. Sajnos így is össze-vissza prelleg.
Én ebben az áramkörben nem tehetek kondikat az enkóderre és nem is szeretnék. Másrészt a te megoldásod jóval primitívebb, vegyünk egy példát:
Az enkóder nyugalomban van, az A és a B lábán is magas szint van. Elkezdenéd tekerni az egyik irányba és ennek hatására az A alacsony szintre vált és megszakítást generál. A megszakításban megnézem hogy a B milyen állapotú és ha magas akkor mondjuk növelem a kívánt változót, ha alacsony akkor pedig csökkentem. Ez után prellegés miatt újra magas szintű lesz az A (a B pedig mindig is az volt), majd ismét L szintű. Ez újra megszakítást fog okozni, megint beolvasom a B-t és ismét növelem a változót. Két léptetést is érzékelt így a PIC, pedig valójában a tekerések száma nulla volt. Ugyan ez az állapotgépnél úgy néz ki, hogy az enkóder állapota "0", és az "+1"-re, majd ismét "0"-ra, aztán megint "+1"-re és végül "0"-ra változik. A csökkenteni/növelni kívánt változó marad annyi amennyi volt.
Én ugyan nem merültem bele ilyen mélységig, de Interrupt On Change (B0 és B1-es portra) megszakítással (egy makróra dolgoztak) nekem jól mentek az enkóderek. A és B állapotát tárolni egy változóban, majd ha megszakítás jön, összehasonlítani az előző állapottal és így el lehet dönteni, merre fordult. Igaz, nálam csak akkor működött jól, legfőképpen a prellegés miatt, ha legalább 20 MHz-en járt a PIC.
A kondi hardveres prellmentesítést végez, ezért nem prelleg. Rosszul mondtam, bocsánat most meg is néztem és le illetve felfutó élre kell interrupt. Én még azzal is megspékeltem, hogy egy timerrel méri milyen időnként jönnek megszakítások és egy bizonyos iső felett nem 5-ösével, hanem 10-esével növeli a változóm. Továbbá kivédtem hogy ha jól emlékszem 100ms-on belül nem történhet irányváltás. Szoftveres prellmentesítést nem is raktam bele, nincs szükség rá.
Videót nem csináltam, ha szeretnéd megmutatom, semeddig nem tart.
Még egy apróság: szerintem külső, 1-5 kOhm felhúzóval zavarmentesebb lenne.
Most tudtam megnézni a videót.
Az milyen típusú kijelző? A touch jól működik? Szerintem a képminőség sem olyan rossz. Hol vetted? Ha ez is ebayes egy linket tudnál küldeni?
Azon a videón ez a kijelző látható: Bővebben: Link
Ennek a tochpadja teljesen jól működik, legalábbis annak a példánynak a touchpadja ami nekem van. A képminősége sokkal gyengébb. Rossz a betekintési szöge, kisebb a felbontása és látványosan nagyon nem homogén a háttérvilágítása.
Nekem is eszembe jutott hogy lehet esetleg túl lassú a PIC és gyorsabban történik változás a PIC lábán mint hogy a megszakításból kilépne. De a helyzet az, hogy 70MHz-en pörög és egy 16 bites dsPIC-ről van szó aminél ráadásul csupán két órajelciklus egy utasításciklus. Az XC16 fordító persze biztos szerencsétlenkedik na de annyira lassú kódot csak nem írhat erre a pár bitbillegtetésre (megszakítás-élek és flagbitek birizgálása) hogy az nagyon jelentős legyen.
Nincsen sajnos.
 dsPIC33FJ128GP804-ről van szó.
Köszönöm az infót!
Kipróbálom ezt is, majd megrendelem aztán jó lesz valamire. Annyira nem ismerem a Microchip típusválasztékát. Egy PIC32MX795F12L-el akartam a másik kijelzőt vezérelni, most nincs időm megnézni, de majd megnézem, hogy megegyezik-e a lábkiosztása, tápfesz, stb, lehet, hogy inkább dsPIC33-at használok hozzá, az olcsóbb is és van olyan, ami nem SMD, ha meg ugyan az a lábkiosztás akkor persze marad a 32 bites, de a dsPIC-nek nagyobb az órajele, amivel szórakozni szoktam az pl 125MHz-ről ketyeg. Viszont a PIC32-vel többet lehet tanulni, mert az ethernetet és az USB-t is ki akarom vezetni. Meg amúgy minden portot tüskesorra, mert már programoztam ilyet egy Ethernet Starter KIT-en és eléggé megtetszett, sok lehetőség van benne.
Itt: Bővebben: Link (Reply #3) van egy C kód pergésmentesítésre, talán működik...
Ha csak szimpla mechanikus kézzel tekert enkóder kezelőszervről van szó, és egyébként is használsz valami ms nagyságrendű időzítőt legegyszerűbb abba beszúrni. 1ms sűrűséggel mintavételezve a két bemenetet és úgy feldolgozva semmilyen pergésmentesítés nem szükséges. Olyan gyorsan meg úgy sem tudod tekerni, hogy ne tudja követni.
Peldaul igy. Igaz, ez nem PIC, hanem 100MHz ARM es 100us-onkent van meghivva a fuggveny, de a lenyegen nem valtoztat. Bourns PEC-11 (mechanikus) enkodert hasznalok. Az lpc_pio... sor az enkoder ket jelet olvassa be az also 2 bitre.
Szia!
Kipróbáltam a kódod, nagyon tetszik ez a megoldás! Lehet, hogy elírtad, de nálam ez a sor: "else if(shift == 0b110100) --encoder;" csak így működött: "else if(shift==0b001011) --encoder;". Egyébként ez a megoldás nagyon stabil. Nem ugrál össze-vissza, pedig nincs is semmi kondi a rotary-n. 1mS-ként fut le az interruptom. Köszi! A hozzászólás módosítva: Dec 21, 2015
A működését el tudnád magyarázni légyszíves?
Bővebben: Link
Ezt a képet nézd meg. |
Bejelentkezés
Hirdetés |
