Fórum témák
» Több friss téma |
Sziasztok!
Én egy LCD-t (HD44780) és pár nyomógombot akarok vezérelni I2C-n keresztül. Erre az egyik legjobb megoldás az MCP2317 I2C 16bites I/O bővítő. Már elkészült a NYÁK rajz és lassan neki állok a programnak is PIC-ben. Érdeklődni szeretnék, hogy van e tapasztalatok MCP2317-es I2C-s I/O bővítővel. Esetleg milyen alkalmazásokban használtátok. Üdv: MaGor
Az LCD-hez kell 7vezeték, a pár gombhoz meg pár láb. Ehhez miért kell egy bővítő IC, miért nem elég egy megfelelő lábszámú PIC? Még talán a 18 lábúak is elegendőek, de a 28-asok biztosan, ha tényleg csak pár gombról beszélünk!?
A bővítőknek sok hibája van, pl, lassú... Persze nem az LCD-hez, meg egy gombhoz, de ez nem változtatja a tényt, hogy sokkal lassabb és bonyolultabb kezelni, mint egy PIC portjait.
Nálam 6 láb, soha nem olvasom a kijelzőt, betartom az adatlapban látható maximális időzítéseket (ezt lehet interrupttal is vezényelni, akkor nem kell várakoznia a programnak).
Az adatvonalakat meg bemenetre lehet kapcsolni, amikor az ember nyomógombot olvasna, ehhez az kell csak, hogy a gomb ellenálláson keresztül csatlakozzon, valamint olyan portbitre kell kötni az adatvonalakat, amikhez rendelhető belső felhúzó ellenállás (ha ez nincs, akkor külső ellenállás kell). Idézet: „Nálam 6 láb, soha nem olvasom a kijelzőt, betartom az adatlapban látható maximális időzítéseket (ezt lehet interrupttal is vezényelni, akkor nem kell várakoznia a programnak” Érdekes, de pont azt írod, hogy betartod a maximális időzítéseket. Ha ellenőrzöd a lábat, akkor csak addig kell várni, amíg szükséges! De egy lábon nem fogunk összeveszni!
Ha olvasod a ready-t, akkor addig semmit nem csinál a programod, amíg el nem végzi a kijelző a dolgokat
Ehelyett én azt találtam ki, hogy van egy rendszeres megszakításom timerből, valamint a RAM-ban egy shadow terület, ami a kijelzőn megjelenítendő dolgokat tartalmazza. A rendszeres megszakítás pedig azt csinálja, hogy egy művelet elvégzése után beállít egy számlálót, hogy hány megszakításnyit kell várni a következő műveletig. Ilyenformán folyamatosan frissíti a kijelzőt, kiadogatja a home-ot, a karakterkiírásokat, a 8-9. karakter között szükséges újrapozícionálást (ha kell). És nincs benne sehol egyetlen várakozás sem. A felhasználói progi meg a shadow területet firkálja, oda bármikor, bármit írhat. Persze van egy egyszerűbb rutincsomagom, ami sima delay-ekkel kivárja az időket, sokszor ez is elég.
Visszatérve az eredeti felvetéshez: én azért nem tartom túl nagy butaságnak az I2C-s kijelzőt, billentyűzetet. Főleg akkor, ha esetleg más miatt amúgy is kell I2C-t kezelni (pl. RTC), lehet, hogy hasznos, ha van egy előre megépített modul, amit csak rá kell csatlakoztatni az épülő cuccra és máris van kijelzőnk, billentyűzetünk.
Én a 946-ossal épült 3.5 digites LCD panelemmel kapcsolatban gondolkodtam el azon, hogy kellene valamilyen soros kommunikációs elérhetőség neki. Akkor úgy lenne használható, mint egy modul, lehetne ilyen kijelzőmodulokat felhasználva építeni mondjuk PIC-vezérelt tápegységet. Vagy akár egy hosszabb 7 szegmenses kijelzősornál is lenne értelme az ilyen felépítésnek.
Pont ugyanezt találtam ki én is. Van inicializáló rutin induláskor, ami bekonfigurálja az indulás után, hogy 4 bites legyen, kurzor ne látszon, stb. A többi rutin meg csak a pic memóriájában végzi el a műveleteket, mint karakter kiírás, string kiírás, szám kiírás, stb. Illetve van egy rutin, amit meghívogatok időnként, ami meg kirakja a pufferből az lcd-re minden hívásakor a következő karaktert, elvégzi az újrapozícionálást, stb. Bármilyen, periódikusan ismétlődő eseményhez hozzá lehet rendelni, nem kritikus a sebességre, nekem bevált.
Igaz, hogy nem a 23017-est, hanem a 23016-ost használtuk, amikor 288 kimenetet kellett vezérelni PIC-kel. nagy előnye volt, hogy egy SDA-SCL párra nyolc eszközt lehetett belőle felfűzni, és csak két láb kellett a PIC-ből. Nekem nagyon jó tapasztalataim vannak az IC-vel kapcsolatban. Úgy működhet bementként, mint kimenetként. LATCH-el, ír, olvas "falra vetít képet".
Idézet: „Ha olvasod a ready-t, akkor addig semmit nem csinál a programod, amíg el nem végzi a kijelző a dolgokat” A fontos dolgok megszakításban vannak, ami meg nem, az meg ráér. Így is lehet hatékonyan szervezni. Ti a megszakítás idejét pazaroljátok a kijelzésre, én ezt tartom rossznak. Idézet: „amikor 288 kimenetet kellett vezérelni PIC-kel.” Igen, oda indokolt volt. Sokmindenre jó és tuti, hogy nincs vele semmi gond.
Én nem. Csak a megszakításjelző bitet figyelem a főprogramból, de nincs a megszakítás engedélyezve. Vagy ha a megszakítás engedélyezve is van, akkor sem onnan hívom meg a rutint, csak egy jelzőbitet billentek be. Persze a megszakításból kezelt CDC-nél tényleg a megszakításból hívogattam, de csak a tesztelés miatt.
Üdv Mindenkinek!
Hogy miért akarok ilyen I/O bővítőt? Egyszerű, elfogyott a PIC I/O lába. Így meg gyakolatilag 4 láb felhasználásval nyerek 16 I/O-t! Egyébként azért is van értelme, mert így akár 8x16 azaz 128 be illetve kimenetet is csinálhatok (ha szükséges). Egyébként szerintem ez az IC már nem lassú 1,7MHz ... Egyébként köszi mindenkinek a hozzászólást. Idézet: „Egyébként szerintem ez az IC már nem lassú 1,7MHz ...” Meg is kell ám hajtani, és amúgy is relatív. Nyílván nem lehet olyan gyors mint az a PIC amiről vezérled. Idézet: „Hogy miért akarok ilyen I/O bővítőt? Egyszerű, elfogyott a PIC I/O lába.” Nagyobbat kell választani! Idézet: „Egyébként azért is van értelme, mert így akár 8x16 azaz 128 be illetve kimenetet is csinálhatok (ha szükséges).” Előbb tervezni, aztán vásárolni! Egyébként biztosan jó lesz! Idézet: „Egyébként szerintem ez az IC már nem lassú 1,7MHz” Egy láb be- illetve kikapcsolása (pl. az LCD esetén az EN láb) pic-ről közvetlenül meghajtva két utasítás, tehát 8 órajelciklus. Egy ilyen portbővítőre kötve viszont nagyságrendekkel hosszabb ideig tart, mivel a komplett I2C protokollnak végig kell mennie a buszon... Persze én nem vagyok ellene, és sok feladathoz kiváló megoldás, csak az az 1,7MHz azért nem jelent valami túl sokat.
Helló!
Szerinted nem terveztem meg ? Szerinted nem fogyott el a PIC lába? Egyébként egy 5 tengelyes robotkar emésztette fel a PIC lábait Így is egy csomót trükközök, hogy "spóroljak" az I/O lábakkal. Interruptnál is egy csomó logikai kapu a PIC elé, címezhető motor driver, hogy még kevesebb legyen az I/O... de hát "Előbb tervezni.....
Igen, igazad van, hogy nem olyan "gyors". Igazándiból a kijelzőt nem akarom állandóan "járatni". A gomboknál, viszont használni fogom az interrupt lehetőséget.
Érdeklődnék ha jól veszem ki a soraidból, akkor már csináltál I2C-s portbővítést. Milyen nyelven írtad meg a proggit? Üdv!
Használni nem használtam még, csak annakidején egy egyetemi projektnél szóbakerült a lehetősége, és akkor nézegettem ezeket. Ott akkor adott volt a kontroller (AT89S52), ahhoz kellett a környezetet megoldani. De végül sikerült úgy megoldani, hogy épp elég lett az AT89S52 lábainak száma, így nem kellett a portbővítő.
Nemigazán értelek, de mindegy. Hagylak kibontakozni!
Nekünk sok küzdelem után sikerült megoldani a vezérlését. A legtöbb gondot az okozta, hogy nem olvastuk végig az adatlapot. IODIR-rel beállítod az irányt, majd írsz, olvasol. Van INT kimenete, ami a portok változásakor jelez. 33pf kondi+3,9k ellenállás a CLK lábra, 3,9k felhúzó ellenállás az SDA és SCL lábra, aztán működik. Én szeretem, mert nem olyan lassú mint amilyennek látszik.
Szia!
Akkor valúszínűleg az MCP2316-os I2C- bővítőt használtad. Milyen nehézségekbe ütköztetek? Különben szerintem is elég sebessége lesz ahoz, hogy az LCD-t vezéreljem. Üdv!
Szerintem ez jelen helyzetben majdnem teljesen lényegtelen
Az első gond az volt, hogy "csak" 8 eszközt lehet felfűzni egy SCL-SDA párosra. Arra gondolok, hogy az MCP három biten címezhető. A több eszközt plussz SCL lábakkal sikerült megoldani. Mi kb. 2 m vezetékkel kötöttük össze a PIC-et az mcp-kkel, és rájöttünk, hogy a vezetékeket érdemes kicsit távolabbra tenni a nagyfrekvenciás "dolgoktól". Ja igen! Kezdetben ez volt az első I2C-s eszköz, amit használni kezdtünk, és hát szokatlan volt, hogy a címzésnél a legfelső bit sokat számít! Ezektől a nehézségektől eltekintve összeszerelés után rögtön tette a dolgát, nem volt vele semmi gond. Visszatérve az eredeti problémádra, ha nem akarsz multiplex kijelzést használni, akkor direktbe be vezetékeled az MCP-t az LCD vezérlő lábaihoz,(lehetőleg az egyik GP-hez, a másik majd jó lesz a gomboknak) majd a PIC-et akár hardveres, akár szoftveres I2C-n összekötöd vele. A két vezetékre egy-egy 3,9k felhúzó ellenállás és kész. Innentől kezdve már csak program kérdése a dolog. Szerintem nem olyan bonyolult, mint egyesek hiszik.
Én kisebb felhúzó ellenállásokat tennék, inkább úgy 2k2-t...
A gyakorlat mondatta velem a 3,9k-t, de igazad lehet, mert kisebbel nem is próbáltuk olyan jól működött.
Remélem, hogy az ajánlás nem kötelezően alkalmazandó minden esetben. Lehet, hogy csak nekünk volt szerencsénk (vagy ez az IC ilyen jó, hogy bőven túlteljesíti a specifikációit), de kifogástalanul működik a rendszer.
|
Bejelentkezés
Hirdetés |