Fórum témák
» Több friss téma |
Szia!
Vegyél 16F887 I/P -et a ChipCadnál 510+áfa... és még többet is tud...
A Slave az pic 16f74 es
 abból van 3 darab és azok kifogástalanul működnek, de nem tudják a master módot csak szoftveresen, de holnap kapok egy ismerősömtől egy 877a-t tehát a fejlesztés nem áll meg Holnap már tudok jelentkezni az eredményekkel , hogy az eddigi fáradozásainkat siker gyümölcse kíséri-e.. Úgy érted másik két lábra írjak szoftveres slave programot? Szerintem egy kicsit bonyolult lenne az órajelre adatokat bevinni sorosan egy regiszterbe, bár lenne erre is pár ötletem, de ez túl nagy falat lenne számomra. 887- tudom, azzal dolgoztam sokáig, érdekes hogy többet tud és mégis olcsóbb.. csak előszöri úgy gondolkoztam , hogy amilyen eszközök a közelemben vannak, és a 877 az adott lenne. A 877-et is nyertem Pic - versenyen, sok egyéb dologgal együtt, szóval kénytelen voltam azt használni
Szia!
Mint említettem, már megírtam egy olyan típusra, amiben még SSP sincs. Ezt könnyen lehet adaptálni a 16F74-re is... Csak a portot és a bitet kell rajta változtatni...
Nos ma voltam bent ic-ért a chipcadnél. Felégettem, és kipróbáltam az eeprommal, és siker. Működik! Holnap publikálom a szkópos felvételeket
Aztán holnap jöhet a két ic közti i2c tesztelése.
Az ígért felvételek. Közben visszaraktam a progiba az ACK vizsgálatot, és működik. Az adás fénykép úgy gondolom egyértelmű , az a címzés + memóriacím + adat
. A vétel jó/rossz nál csak annyi a különbség hogy amikor a rosszat csináltam direkt lehúztam az i2c-t így láthatjátok hogy valóságosan tényleg nem jön vissza adat. Vételnél: Címzés írással, memóriacím beírása, i2c újrakezdés, majd újracímzés olvasással aztán a 4. periódusban már a slave küld.
Sziasztok,
Van egy .asm programom ami I2C-n ír-olvas 24C16-ot.A program 16F877-re készült. Vajon megoldható ennek átírása 16F690-re? Vagy tudna valaki ajánlani 16F690-hez olyan kód, ami 24C16-al, vagy más eszközzel (Timer stb.) I2C-n képes kommunikálni? Köszönöm L. A hozzászólás módosítva: Máj 1, 2014
Sziasztok!
Nemrégen kezdtem el foglalkozni az i2c busz programozásával. Szeretnék készíteni egy PCF8583 alapú órát, melyből az adatokat egy pic olvassa ki. Az i2c kommunikációs programot megírtam, hosszú vajjúdás után működik. Van egy kérdésem, amiben nektek hátha van több tapasztalatotok: -Abban az esetben, ha kiküldöm a slave egység címét a slave egységnek ACK-ot kellene kapnom a Slave-től. Az ACK érkezését az SSPCON2, ACKSTAT bit jelezné. Az SSPBUF-ba történő írás után az ACKSTAT bit folyamatosan 0 marad, nem billen 1 állásba. Lehetséges, hogy az ic nem küld ACK-ot és ezért nem billen 1be? Jelenleg az PIR1,SSPIF bitet figyelem, de attól tartok, hogy ez csak az írás végét figyeli most és azt, hogy van-e ACK, vagy nincs azt nem. Volt már ilyen tapasztalata valakinek? Előre is Köszi!
Idézet a 16F88x adatlapjából:
Idézet: „bit 6 ACKSTAT: Acknowledge Status bit (in I2C Master mode only) In Master Transmit mode: 1 = Acknowledge was not received from slave 0 = Acknowledge was received from slave”
Hi!
Ez rendben van. Pontosan ezzel van a gondom. Ha írok egy byte-ot az sspbuf regiszterbe várnék egy ACK-ot. Azaz várnám azt, hogy az SSPCON2 regiszter az ACKSTAT flag-je 1 be billenjen, majd az ack érkezése után "0"-ra váltson. Ezzel jelezve, hogy a slave nyugtázott. De folyamatosan "0" marad az érték. Ha az ACKSTAT bit a továbblépés feltétele a kommunikáció leáll az írást követően. Ezért jött a kérdés, h küld-e Ack-ot egyáltalán?
Régebben tettem fel A "modulrendszerű... topic"-ba , az elején valahol, egy univerzális rutint pont erre az I2C-s eszközre. Több darabban van de egy működő dolog. Ebből is tudsz meríteni. Ha jól emlékszem ez szoftweres és van benne ACK is...
Idézet a 16F88x adatlapjából:
Idézet: „a) The user generates a Start condition by setting the Start Enable (SEN) bit (SSPCON2 register). b) SSPIF is set. The MSSP module will wait the required start time before any other operation takes place. c) The user loads the SSPBUF with the address to transmit. d) Address is shifted out the SDA pin until all eight bits are transmitted. e) The MSSP module shifts in the ACK bit from the slave device and writes its value into the ACKSTAT bit (SSPCON2 register). f) The MSSP module generates an interrupt at the end of the ninth clock cycle by setting the SSPIF bit. g) The user loads the SSPBUF with eight bits of data. h) Data is shifted out the SDA pin until all eight bits are transmitted. [quote]i) The MSSP module shifts in the ACK bit from the slave device and writes its value into the ACKSTAT bit (SSPCON2 register).” j) The MSSP module generates an interrupt at the end of the ninth clock cycle by setting the SSPIF bit. k) The user generates a Stop condition by setting the Stop Enable bit PEN (SSPCON2 register). l) Interrupt is generated once the Stop condition is complete.[/quote] Itt nincs szó arról, hogy az átvitel elején a ACKSTAT bit 1 -re állna. Csak annyit ír, hogy a 9. órajelnél a SDA vonalon levő szinre állítja ezt a bitet. PIR1 SSPIF bitjével kellene megoldani a szinkronizációt.
Csabi! Azt érted szoftveres megoldáson, hogy nem használod a hardveres IIC áramkört a picben? Én szeretném ezt használni, az egyszerűség miatt.
Hp41C!
A belinkelt részt úgy értelmezem: e, pont: Az MSSP modul beshifteli az ACK bitet a slave eszköztől és beírja az értékét az ACKSTAT flagbitbe. Jelenleg betöltöm a slave címét az SSPBUF regiszterbe, megvárom míg az PIR1/SSPIF bit 1-re vált, azaz az írás befejeződött. De szeretném ellenőrízni, hogy a slave küld-e ACK-ot, ezért ellenőrzőm a SSPSTAT regiszter ACKSTAT bitjét, de nem érkezik válasz. Az adat jön utána szépen, de az ACK-ot még keresem valahol... de nem találom... Idézet: Ezután olvasd ki a SSPCON2 regiszter ACKSTAT bitjét. Ha 1, akkor nem jött ACK. Ha volt ACK, töröld az PIR1 regiszter SSPIF bitjét és írd be a következő adatot a SSPBUF regiszterbe. „Jelenleg betöltöm a slave címét az SSPBUF regiszterbe, megvárom míg az PIR1/SSPIF bit 1-re vált, azaz az írás befejeződött.”
Igen azt étrem szoftveres megoldáson. Ha kézzel fogható harweres megoldásom lenne, akkor azzal próbáltam volna segíteni. Tudod havonta általában 10-12 különböző PIC-es progit kell írnom. Ezek általában 20-40e sor ASM. Gondolom nem nehéz rájönni, hogy ennyit nem vagyok hajlandó gépelni. Általában a Parsic4 nevő programot használom. Ebben modulokból összerakható rutinok vannak, amit a progi automatikusan összeilleszt. Általában elsőre megy, és még sohasem fagyott le programom. (ha valamire mégsincs modul, azt megírom és hozzállesztem) Nem szokott idegesíteni, ha mondjuk 10 soros rutin helyett 17 sor van. Nem az adott processzor 100ft-os árkülönbözete, vagy ciklusidő 60, vagy 72ns különbsége motivál, hanem a végső megoldás. (18F87K22-t használok leginkább) Egyébként az említett program új verziója már a HW megoldást használja. Az alól is kimásolható a megoldás számodra. Pár hét múlva fogok egy olyan projektet csinálni, ami hőközpontokban is használatos "szolga". tőbb különböző hőmérséklet szenzor ADC, DAC, 0-10V, 2-10V stb kezelése és Modbus kommunikáció. ebben lesz I2C belső kommunikáció is. Ott már a HW-s megoldást fogom használni.
A hozzászólás módosítva: Jan 13, 2015
Hp41C!
Volt időm debug-olni picit, most jöttem erre rá én is Megjelenik a megszakítás és ha utána az ACKSTAT 0, akkor volt ACK, ha 1, akkor a szolga nem küldött ACK-ot. Fordítva értelmeztem az adatlapot és először vizsgáltam az ACKSTAT-ot, ami természetesen küldés után egyből 0 volt és utána csak a megszakításbitet. Ez zavart engem. De mostmár minden OK!
Értem. Nekem ez csak hobbi, azért merülnek fel ilyen kérdések
Ezután nekem is egy "lakásvezérlő" projekt lesz a következő, de az még odébb van Hp41C, Dcsabi köszi a segítségeteket! |
Bejelentkezés
Hirdetés |
