Megvan a probléma, ugyanis kétszer veszi az adatot megint amiatt, hogy minden címre reagál....

Öööö... nem tudom, hogy CCS-ed kezeli-e a dolgot, de ha nem CCS-t használnál, akkor azt külön kezelned kellene, hogy a címbyte-ot nem dobja el az IC, hanem mint az összes adatbyte-ot, azt is "megkapja" a program.
Azaz a master küld egy címbyte-ot, majd után 0..n db adatbyte-ot (írás műveletről beszélünk). Ezeket sorban megkapja az a slave, akinek a címe van a címbyte-ban. De az első byte, amit megkap, nem az első adatbyte lesz, hanem maga a cím (ami rendes körülmények között annyi információt tartalmaz csak a slave számára, hogy read vagy write jön - nyilván read esetén a slave-nek kell a byte-okat küldenie). Lehet, hogy a CCS a nagy okossága közepette ezt is külön kezeli, megintcsak tessék (CCS) doksit olvasni.

Nem ismerem a PIC C-t de az biztos, hogy magától nem tudja eldönteni semmi, hogy a cím neki szól-e. A PIC egy jelzőt állít be, ha a cím stimmel, de nem tudom hogyan kezeli le a rutin ezt. Lehet, hogy visszaad egy értéket stb, nem tudom, meg kell nézzed a forrást!

Elolvastam mindent, és ha az adress-nél meg van adva a cím, akkor elvileg arra reagál. A küldés is rendben van, elvileg működnie kellene. Ha átírom a hamradik IC-nek érkező adat címét, akkor az nem is reagál rá, de a slave PIC mindenre. Nem tudok már vele mit kezdeni, azért kérdezem itt. Külön is meg lehet adni a programban, hogy mi legyen a slave cím, megadtam, de semmi sem változik.

vl

Eldobja, mert, ha beírom a programba, hogy csak azután vegye a lapot, akkor semmit sem csinál.

Ja és, ha nincs kétszer küldve az adat, akkor csak minden másodikra frissíti a kijelzőt, amit megintcsak nem értek...

Bele kell nézned a rutin működésébe, másképpen nem fog menni! Valamit nem jól értelmezel, vagy valami nem jól működik a gyári kódban...

Mit értesz gyári kód alatt? Inkább csatolom mindkettőt.

Eddig arról beszéltünk, hogy nem ismerjük a CCS-t, azaz, hogy van-e olyan gyári függvénye, amit használsz és elintézi a cím lekezelését. Én nem látom, hogy használnál ilyet a kódban, annak ellenére, hogy te erre utaltál(lehet akaratlanul). Ha ez így van, akkor nem kell csodálkozni, hogy minden címre, adatra benyel mindent.
Nem néztem hány bites címet használsz, ha 7 bitest, akkor elég egyszer feltölteni az SSPADD regisztert. Ha 10 bitest, akkor figyelni kell még az SSPSTAT.UA bitet, ami jelez, amikor be kell tölteni a cím további részét. Ha cím egyezés van, akkor az SSPIF megszakításjelző bit beáll. Ez alapján lehet lekezelni(megszakításban(ajánlott), vagy máshogy), hogy veszed a többit, vagy nem...

Alvileg ennyi és ez benne is van.

#use i2c(SLAVE, SDA=PIN_A0, SCL=PIN_A1, ADDRESS=0x10110000, force_hw, fast)

Nem láttam a logikát, mi alapján dolgozik a programod. Én más mikrokontrollert használok de az elv ugyanaz. Ha küldesz A-ból B-be adatot, akkor érdemes használni a jelzőbájtokat is, például a cím és adat megkülönböztetésére. Így ha cím érkezik, az biztos, hogy például 13(CR)-al indul és 3 nulla, ha adat, akkor az adatfolyamjelző 02(STX) ASCII jellel kezdődik a kódsorozat és három nulla. Így nem keveredhet össze a cím és az adat és könnyebb szelektálni mi szól a slave-nek és mi nem. Persze nem tudom milyen protokollt használsz és nem tudom mit tud a hardver. Nálam egyszerű a képlet mert mindent szoftveresen kell megírni - de így egyszerűbb átlátni is (parallax p8x32). Én DMX-et programoztam mostanság RS 485-ön, ott a lezárás hiánya miatt a reflexió is szépen meg tudta bolondítani a jelfolyamot.

Ez I2C és működik is leszámítva az agyhalált a slave részéről.



Na ez nekem kínai. Elvileg az I2C full hardveres és nem kell ilyesmikkel foglalkozni.

Ezt hogy értsem akkor?
SSPSTAT regiszter UA bit.

Nem én kérdeztem... és miután parallaxos vagy(és ezt minduntalan felemlíted, ami már fárasztó), nem értem miért válaszolgatsz hardverspecifikus témában, miután beismered, hogy nem is ismered!

Fogalmam sincs, ha tudnám nem kérdezném. Nem vagyok gyakorlott programozó, sőt egyáltalán nem vagyok az, de a kezdő topikba válasz sem érkezett, nem, hogy megoldás.

Nyilván a CCS topikban kellett volna kérdezni, nem a kezdőben. Ez ugyanis specifikusan CCS-re vonatkozó kérdés. Pusztán PIC ismeretek alapján nem lehet megválaszolni.

Nálam kb. 5 éve volt fenn utoljára a CCS, úgy emlékszem, hogy volt sok gyári mintapélda, amiből ki lehetett ókumlálni a használat módját.

Oké, de érted amit írnak? Azt írtad, szerinted az I2C teljesen hardveres, semmi teendő. Akkor hogyan lehet, az, hogy jelezni kell, mikor kell címet váltani, hogy a deteltálás megtörténhessen? Az SSPADD 8 bites regiszter, 10 bit nem fér bele, nyílván valamikor bele kell tölteni a második részét. A komparátor is csak 8 bites. Nem látok semmilyen hardver részt, amibe a 10 bites cím beleférne, és azt betöltené amikor kell(adatlap folyamatábra).
Tehát az I2C nem hardveres, ilyen szempontból. Neked kell eldöntened, jó e a cím, az adatlapban leírtakat követve. A cím egyezés detektálása nekem is kusza kicsit, mert nehéz megérteni, mikor jön megszakítás és ahhoz mit kell beállítani, de most nincs időm teljesen kibogozni.

Erre szoktam írni, hogy nem csak a kérdésnek kell ebben a topicban haladónak lenni, ezért ez a címe.

Talán azért mert sok kényelmes hardverhez szokott fejlesztőnek a legelemibb és legegyszerűbb alap megoldások sem jutnak eszébe. Ezt abszolút nem bántásnak szánom, csak tapasztalat. Ha nem járod végig a miértek végtelen sorát, sokszor ha kiüti a szemedet a megoldás - akkor sem találod meg. Néha annak, hogy az ember társalog a másikkal - nem mindig az az eredménye, hogy megtudod a megoldást. Lehet, hogy csak annyi, hogy mással is elkezdesz próbálkozni, amire nem gondoltál. Én általában nem lehurrogni szoktam azokat, akik segítenek, csak megköszönöm. Akár segített érdemben - akár nem. Ahogy azt sem mindenki jegyzi meg - ki is az a Kameleon2. A kommunikáció és a buszos adatcsere egyébiránt abszolút nem hardverspecifikus téma - úgy gondolom.

Egyetértek, de meg lehet írni a lekezelést, ha nincs gyári, vagy nem érti a működését.

Számomra elemi az, hogy slave-re van állítva és meg van adva a cím. A cím 8 bites, nem 10, szóval ezt nemigazán értem. Elemi viselkedés lenne szerintem az is, hogy ha rossz címet használok, akkor nem működik, nem hiszem, hogy normális dolog az, hogy akkor mindenre reagál.

Azt tudom, hogy nem kell figyelni a buszon, hogy mikor van megszakítás stb., mert azt a hardver végzi és fogadja is az adatot és működik is, csak nem úgy, ahogy kellene. A 16F877-ben van hardveres I2C vezérlő vagy mia búbánat, de a fordító szoftveresen is meg tudja oldani. Innentől kezdve nem hiszem, hogy azzal lenne a baj. A CCS topikba is feltettem a kérdést, szintén nincs válasz. Tudom, hogy az I2C hogy működik, mi a formátuma és így tovább és működik is. Mindent elolvastam amit csak tudtam, de nem jutottam tőle elölrébb. Ha a cím érvénytelen akkor a fordító hibát jelez és le sem fordítja. Érdekes, hogya míg bármi mással van kérdés minden toppikban pörögnek a válaszok, de ha I2C-ről van szó, akkor senki sem tud vele mit kezdeni és nem akarom elhinni, hogy rajtam kívül senki sem használja, vannak vele tapasztalatai.

Csak akkor használok PIC-et, ha nagyon muszály, nem is érdekel a programozás és nem is bízok ezekben a mikrokontrollerekben. Én a cél ic-k-ben hiszek, de erre ilyen nincs, ezért kell megírni a programot.



Ha beírom, a programba, hogy csak akkor lépjen tovább, ha a cím egyezik, akkor semmit sem csinál, ebből gondolom, hogy ezt magának kellene megoldani. Ráadásul, ha nem így van, akkor miért van olyan lehetőség, ahol meg kell adni a hardver címét. azt sem értem, hogy bogarászom a help-et világosan le van írva, hogy egy X parancs mire jó, mi a helyes szintaxis stb. Majd beírom és azt sem tudja, hogy az micsoda (undefined identifier stb.) Ilyenektől őszülök meg, ezek miatt gyűlölöm ezt az egészet, de nicns más megoldás.

Ami a kedvencem, hogy a doksiban és a ti válaszaitokban is mindehol 5-7 betűs tövídítéseket használnak(tok)...

A rövidítések az adatlapban olvasható regiszterek nevei... Az UA pl. akkor jelez, amikor be kell tölteni a 10 bites regiszter második felét, majd akkor, amikor vissza lehet tölteni az elsőt.
A cím 7, vagy 10 bites lehet, 8 nem. Csak a regiszterek 8 bitesek.
Az I2C nem egyszerű, több időt kell szánj rá, mert szerintem valamit nem jól értelmezel. Nem tiszta számomra, hogy az adatlapi blokkvázlat szerint az addr match jelzés hová fut be, főleg hogy a folyamatábrákon nincs feltüntetve, mint jelzés. A szövegből sem értem pontosan, hogy minden címnél megszakítást okoz, vagy csak annál, ami egyezik az SSPADD al. Szóval nekem is vannak kérdéseim! Ki kéne próbálni lépésenként és kiderülne...

Én 887-tel csináltam I2C slave kódot, abban teljesen jól működik az address matching 7-bites címekkel. Ami másnak szól, azokat a byte-oket egyáltalán nem veszi a PIC. Viszont a dokumentáció tényleg gyengus.

Köszi, akkor csak a 10bites címeknél kell kicsit szoftverezni, ha jól értem!?

Gondolom, ahhoz nem írtam kódot, mert nem érdekel

Nem véletlenül írtam amiket írtam. Sokan szent grálnak tekintik a fordítót is, pedig vannak esetek, amikor valami nem úgy fordul le ahogyan kellene és valamilyen trükköt kell alkalmazni. PIC-nél egyszerűbb az élet, mert van debugger. Én anélkül írtam meg a DMX-et, vért izzadva. Úgy kezdtem, hogy 1 ledet villogtattam. Azaz a kályhától. Ha nincs válasz a kérdéseidre, akkor csak magad maradsz. A legjobb ilyenkor a "favágás" . Egyszerre egyet kell lépni. 1 címre, egy adatot küldj át, de ha lehet többfélét. Sokszor és sok sebességgel. Én távírótechnikán nőttem fel. Néha az RY a megoldás. Azaz a váltott kódok. 10101010 01010101. Akkor kibukik a hiba. Néha bizony - véletlenül. Én örülnék, ha az i2C-t jobban ismerném. Én csak annyit tudok, hogy nálam a címzés i2C-n hardveres. Azaz ha külső eeprommal kommunikál a mikrovezérlőm, az eeprom lábain állítom be hardveresen az eeprom címét. Nem szoftveresen.

A hangerőszabályzó IC-n is hardveres a cím beállítása és azzal nincs is gond, az csak akkor veszi a lapot, ha kell és az meglepőmódon elsőre működött. Hogy a fordító nem százas és trükközni kell az biztos, ennek látszanak a nyomai a mellékelt programokon is. Ha valami furcsaság van, mint az adatküldések közötti 10us késleltetés stb. az mind amiatt van, hogy stabilabb legyen a dolog. Ha csinálok valamit azt mindíg úgy csinálom, hogy az tényleg használható, stabil ketyere legyen. A hangerőszabályzót is összevissza ki be kapcsolgattam stb. és akkor nyílvánítottam késznek amikor mindíg tete a dolgát és teszi is rendesen. Igazából a kijelzés is stabilan működik így, csak a némításnál lévő két csíkocska közé villan be a nulla az egyik karakternél, ha tovább tekerem az enkódert, de agyban már talán megvan a megoldás erre is. És emiatt nem fogom megtanunlni az I2C-t az biztos.

Amúgy azon, hogy olyan kóddal próbálkozzak amit nem olyan könnyen kever össze mással már túl vagyok, egy egész éjszakán keresztül szórakoztam vele, kétségbeesésemben jöttem ide.

Ez így nem stimmel, mert PIN_A1 és PIN_A0 lábakon nincs hardveres I2C, a force_hw pedig pont azt erőltetné!

Szia!
Nézem a szenvedést... Lehet utálni egy típust, de jobb elolvasni a dokumentációt, és az Application Note -t (mert az is van). Értem én, hogy bonyolult az I2C, még a Microchip is javítani kényszerült a hardware -t is és az Application Note -t is....

Idézet:
„Ami a kedvencem, hogy a doksiban és a ti válaszaitokban is mindehol 5-7 betűs tövídítéseket használnak(tok)...”

Az eddig a hozzászólásokban leírt "5-7 betűs tövídítések" megfejtése megtalálható a 16F887 adatlapjában, a "Haladóknak" topikban megtanultnak vesszük...

És google testvér is szorgos...

És a helyes megfejtő icserny. Valóban ez volt a gond, csak így megy a hardveres ííketőcéé. Most már csak akkor veszi az adatot, amikor kell, és ilyen bináris formában sem maradhat, de legalább már megvan a válasz! Nagy Respekt.

És ami a lényeg, hogy egyszerűen konyhanyelven el tudta magyarázni, hogy mi a gond!

Szia!


Nem akarom elvenni a dicsőséget, csak úgy megemlítem, hogy nem csinált mást Ő sem, mint amit Neked is ajánlottunk. Kinyitotta és megnézte, elolvasta a 16F887 adatlapját... Bővebben: Link
Rögtön a 6. oldalon a tokozási rajzon, aztán a 7. oldal táblázatában látható a lábkiosztás, a 13.4 fejezet elején olvasható a lábak beállítási követelménye: ...
Ehhez csak annyi megjegyzésem lenne még, hogy magadnak spóroltál volna meg napokat, órákat.

Ahogy a matemetika tanulásában, itt sincs királyi út...
Miért várod el tűlünk, hogy a Te dolgaidra keressünk rá?? Nehezen fog menni az élet... Könnyebb valamit megkérdezni, türelmetlenül várni, hogy más megoldja, amikor az adatlapban szemkiszúróan megtalálható minden információ.


Ott van az információ minden szóbajövő dologról, rövidítésről. Ahogy az első bekezdésben írtam, három helyen, szájbarágósan le van írva. Hogy valaki programozza a MSSI illesztőt, de nem hajlandő legalább elolvasni a róla szőló fejezetet...
Még azt is megemlítem, hogy az I2C slave módjára a PIC16F88x_errata is tartalmaz bejegyzést...

A google keresési listát azért linkeltem be (ugyan nekem már több pic-en megy a I2C), de nem használom a CCS -t, így nem tudhatom volt-e nekik valamilyen problémájuk, javítások, verzió gondjuk a slave móddal.

Pontosan!