Fórum témák
» Több friss téma |
Sziasztok!
Küzdök a 16F877 és a 24FC515 EEPROM köti I2C kapcsolattal. Lenne a programban egy feltöltés a 0x0000 címre, majd egy visszaolvasás onnan (PortB -n lévő LED vizuálisan is mutatná az egyezőséget). Ránézésre akár működhetne is, de mégsem teszi. A Slave küldözgeti ugyan az ACK -kat, (amit szókopon is látok) szépen körbefut az I2C_MAIN rutin. Azonban a kiolvasott adat 0xFF, vagyis a Slave nem válaszol a PIC nek. megj: Az EEPROM A0- A1 lábát "0" ba A2 lábát "1" re kötöttem előírás szerint, a page select bit (b0) ami, A2 nek fele meg, a programban 0 ra állítottam. Szóval lenne ötlet hol baltáztam el?
Szia!
Kifejezetten az eeprommal nem megy a kommunikáció, vagy most használod először a 16F877 belső iic buszát?
Értem.
Akkor bocs, ha olyat írnék, ami egyértelmű. Fontos, hogy a busz data és clk lába is egy-egy 1,5K-s ellenállással H-ba legyen húzva. Ennyi a hardverhez. Szoftverhez azt tudnám tanácsolni, hogy esetleg próbáld meg a történetet ACK ellenőrzés nélkül is. Bevallom, én régebben állati sokat szenvedtem ezzel a kommunikációval, amíg mindenáron le akartam kezelni az ACK-t. Aztán legyintettem, és azóta is ACK nélkül használom az eszközeimben. Persze, később nem árt kikísérletezni, hogy miért is van ez, én is mostanában szeretnék ismét nekiállni. De próbáld meg ACK ellenőrzés nélkül, és ha majd úgy megy, akkor ráérsz ACK-zni. Én a techtools-féle makrókat használom pic-programozásra, ezt a microchip félét nem szeretem. Ha gondolod, fel tudom tenni az IIC rutinomat, néhány sor az egész.
A felhúzóellenállások megvannak, és rendben is vannak, mert látszólag gyors felfutáú nényszögeket látok (gondolom open collectoros a kimenet, ellenállás nélkül nem is menne). Az ACK ellenőrzés szerintem rendben van, mert időképben is látom, meg a fail ágra sem megy el a program, tehát beszélgetek a slave vel. Kipróbáltam másik addressel, akkor rögtön ACK erroros lett a progi.
Tehát elvileg minden jó, aztán mégsem akar összejönni. Köszi a felajánlott makrót, - kérlek küldd is el szívesen megnézem - de alapvetően szeretném ennek a programnak a hibáját megtalálni.
No ennyi az egész, nagyon egyszerű.
Hozzátenném, hogy én csak masternek használom mindig a pic-et, úgyhogy adatkiolvasást még sosem kezdeményeztem vele. De ez az egyszerű rutin, amit IICOUT-nak hívok bizonyosan működik.
köszi tanulányozom, igaz a techtools macrokat nem ismerem.
A MOV értelemszerűen mozgatás, de itt más, mint a microchipnél, itt az elől lévő változóba tölti a hátul lévőt.
CLR bájtot töröl, CLRB bitet. JB = Jump if Bit bit, cím (címre ugrik, ha bit H, különben tovább megy) JMP=GOTO SETB= bit H-ba JNB= Jump if Non Bit bit, cím (címre ugrik, ha bit L, különben tovább lép)
Annyi, hogy ezek a makrók elvégzik azt, amit microchipes nyelven 2-3 sorral csinálnál meg.
A MOV parancsnál pl nem kell külön akkumulátorba mozgatni, az benne foglaltatik a parancsban. Ugyanígy amit én leírtam egyetlen sorral, hogy tesztelje a bitet, és ugorjon ha H vagy L, azt microchipesen több sorban lehetséges megoldani. Az én agyamnak ezek a makrók testhezállóbbak, mint a microchip számomra körülményes szöszölése 
Nem lehet, hogy rossz Control Byte -ot küldesz el ? Csak mert, az adatlap szerint a 0. bitnek 1 -nek kell lennie olvasáskor, a programban viszont 0 van írva. Ettől függetlenül még más is lehet benne hiba.
szerk.: Mégsem, csak nem vettem észre lejjebb. Bocsánat.
Szia!
Az I2C_FOGADAS rutinban a második call I2C_STARTT hívásnak I2C_RESTART -nak kellene lennie. Az eepromnak kell egy kis idő (ld.adatlap) az írás és az olvasás között, az I2C_FOGADAS elé kellene várakozás.
Valószínűleg Hp41C -nek igaza lesz igaza. Vagy várakozás, vagy ahogy egy microchipes leírásban láttam, a byte küldözgetések után volt egy szubrutinhívás, amivel ellenőrizte az SSPIF állapotát. (Lehetséges, hogy a különböző feltétel (pl.: restart) bitek bebillentése után is volt egy ilyen, megpróbálom megkeresni a leírást.)
SSPIF = Set to '1' after 8-bit transmission plus acknowledgment receipt is complete. Ha 0, akkor visszaugorsz a bitteszteléshez (btfss), ha 1, akkor manuálisan törlöd a flaget majd return.
Szia!
Még két dolog: - Egy byte írása max. 5ms. Az írás végehajtását lehet "Ack polling" -gal várni (adatlap. 7.0). Egy írást kell kezdeményezni (Start , Írási cím), ha a prom foglalt nem küld ACK-t. A kezdeményezést mindaddig újból el kell küldeni, míg ACK-t nem ad vissza. Ekkor az írás már befelyeződőtt. A WP láb magas, akkor az eeprom az ACK-t küldi, de az írást nem végzi el. (Belső lehúzó ellenállása van.)
1. Igazad van,
Idézet: az I2C protokloll szerint szerintem is. Első körben én is azt hívtam, de kínomban - engedve a 25FC515 adatlap FIGURE 8-2 szerint vagy például emiatt átalakítottam START feltételre. A poén az volt, hogy ACK -t minden esetben a protokoll szerint (és ahol a program szerint is vártam) megkaptam a Slave -től.„Az I2C_FOGADAS rutinban a második call I2C_STARTT hívásnak I2C_RESTART -nak kellene lennie” 2. Jogos lehet, hogy nem vártam ki azt írási ciklust, át fogom alakítani pollingosra, vagy legalábbis dobok bele első körben egy várakozási ciklust 10 msec ra. 3. A PIR1.SSPIF flag törlésére is gondoltam, de elvetettem, mert nem használok megszakításokat, és elvileg törölni kellene szoftveresen már a START kiadása után is (16F877 adatlap FIGURE 9-14 I2C MASTER MODE TIMING), de úgylátom a mester adását az SSPIF=1 beállása nem zavarja. Igaz, valahol én is láttam olyan mintakódokat, ahol az SSPIF állapotát figyelték R/W helyett. Persze ettől még lehet törlnöm kell minden esetben az SSPIF et. Lehet nem is látok jól, de 16F877 adatlapján SSPSTAT.R_W Idézet: , míg FIGURE 9-14 en R_W akkor "1", amikor írási ciklus van a buszon.„R/W: Read/Write bit Information (I2C mode only) This bit holds the R/W bit information following the last address match. This bit is only valid from the address match to the next START bit, STOP bit or not ACK bit. In I2 C Slave mode: 1 = Read 0 = Write In I2 C Master mode: 1 = Transmit is in progress 0 = Transmit is not in progress Logical OR of this bit with SEN, RSEN, PEN, RCEN, or ACKEN will indicate if the MSSP is in IDLE mode.”
SSPIF es helyettesítések, amit eddig találtam:
I2C start1: bank0 bcf PIR1,sspif bank1 bsf SSPCON2,SEN bank0 btfsS PIR1,sspif goto $-1 return I2C Start2: BANKSEL SSPCON2 BSF SSPCON2,SEN BTFSC SSPCON2,SEN GOTO $-1 BANKSEL SSPCON RETURN I2C Stop1: bank0 bcf PIR1,sspif bank1 bsf SSPCON2,PEN bank0 btfsS PIR1,sspif goto $-1 return I2C Stop2: BANKSEL SSPCON2 BSF SSPCON2,PEN BTFSC SSPCON2,PEN GOTO $-1 BANKSEL SSPCON RETURN Check_ACK1: bank0 bcf PIR1,sspif btfsS PIR1,sspif goto $-1 return Check_ACK2: BANKSEL SSPCON2 BTFSC SSPCON2,ACKSTAT GOTO I2C_FAIL BANKSEL SSPCON RETURN
Szia!
Én nem 24LC515-öt eepromot, hanem PCF8583 RTC kezelek I2C-n, neki csak 1 byte cím kell. Feltöltöm a rutinokat - az RTC-vel működnek 16F876-on és 16F886- on is. A fölösleget kiegyeltem belőle, az idő beállítását kiolvasását benne hagytam, hogy látszódjék, hoigyan hívom a rutinokat. 16F628-hoz van SW I2C kezelő rutinom is (a propeller clock topikban megtalálod prop_628_2.2x).
Valóban ott rontottam el, hogy az írás után nem vártam semennyit az olvasásig. Igazat megvallva nem világos milyért van rá szükség, ez idő alatt a slave nem is kap órajelet, ráadásul ACK val visszaigazolt.
Mindenesetre higgyünk az EEprom katalógusadatának, amely 5 msec ben adja meg az írási ciklusidőt. Az I2C_FOGADAS subrutinban I2C_RESTART al váltok fogadásra. Érdekességként megemlítem, hogy a I2C_BUSYCONTROL subrutin nélkül is működik, mint ahogy azt korábban is éreztem már. Meglehet az is értelmes dolog, pl. ha 2 vagy töb mester van a buszon, de ezzel a témakörrel egyenlőre nem foglalkoztam. Köszönöm mindenkinek a segítséget.
Na, örülök, hogy sikerült, viszont Hp41C arra én is kiváncsi vagyok, hogy hol olvastad az adatlapban, hogy az írás olvasás között kell egy kis idő. Egyszerűen nem találok ilyet, vagy már este van nagyon.
Idézet: „"Az eepromnak kell egy kis idő (ld.adatlap) az írás és az olvasás között.."” Erre reagálva.
Be kell fejeződnie az előző írási ciklusnak, mielőtt olvasást kezdeményezhetsz, mert mivan, ha épp azt akarnád olvasni, amire előzőleg írási parancsot adtál ki, a cella írása pedig folyamatban van. Mintha léteznének olyan eepromok, amikben lehet olvasgatni is az írás után közvetlenül, de azokban biztos van valami megoldás, hogy az írás alatt álló cellák olvasása esetén az írási pufferből szedje az adatot, ne magából a cellából...
Az adatlap TABLE 1-2: AC CHARACTERISTICS 17. sorában találod az írási időzítést.
Érthető, és egyben logikus is, köszi.
cassis: Kösz!
Szia!
A második start/restart probláma tényleg csak akkor lényeges, ha több master van a buszon. A restartnak az a lényege, hogy a tranzakciónak nincs vége, a másik master nem veheti át a busz vezérlési jogát. Örülök, hogy megoldódott a problémád.
Most találtam egy hasznos kis leírást az I2C kezeléséről. Hátha valakinek még hasznára válik.
tanulva előzőekből az alábbi linken, vagyis itt találhattok még némi kiegészítést a témával kapcsolatosan.
Ha ezt valaki hozzáértő leforditaná magyarra, nagyon sok kezdő életét megkönnyítené!!!
Nekem a nagyobbik fiam szokott néha segíteni, de csak az irodalmi angolt ismeri, így nagyon nehézkes!
Köszi, hogy felraktad a forrásprogidat! Most először sikerült I2C-s kommunikáció a demo panelemmel. Egy kevés változtatással a hőmérséklet mérő IC-vel is összejött!
Szia!
Örülök, hogy segíthettem. Azóta a 24FC512 eeprommal is működő verzión is van... Szia |
Bejelentkezés
Hirdetés |
