Egy kicsit belegabajodtam az SPI buszba.
Nem viágos az SDI és az SDO sinek adatforgalma. A leírások alapján úgy működik, hogy (PIC esetén) betöltöm a kiküldendő byte-ot a SSPBUF regiszterbe, majd várok SSPSTAT,BF el, hogy az adat küldés a SDO sinen rendben megtötént -e. Lényegében 8 órajelciklust várok ki.
Ez pl itt is le van írva
Erre a nyolc órajelre visszalép a Slave felől az adat, a PIC SSBUF regiszterében azonnal megjelenik.
lásd gyára SPI ajánlás_36. lap
Eddig világos is lehetne, DE hogyan tudja a Slave, hogy mit is akarok tőle kérdezni? Például egy memória címet küldök ki, és arra várok adatot. Szegény memoria honan tudja már az első byte nál, hogy majd melyik cím adatát kell küldenie???
Mellesleg nekem is működik a gyakorlatban de fogalmam sincs miként. Néha láttam Dummy byte kiküldését is adatlapokon. Ezzel érteném a dolgot, mert akkor van ideje a cím kiküldése után azt értelmezni a Slavenek, majd a a dummy órajelével válaszolni. De ezt a megoldást általában nem használják.
Valaki megtudná világosítani a kérdést?

Képzeld úgy, mintha a Slave eszközben is lenne egy SSPBUF regiszter, ami akkor töltődik fel adattal, ha megérkezett 1 byte a Master felől. Ekkor a kapott érték alapján a saját kis "programja" eldönti, hogy kell-e még több adat, ha igen, vár; eközben a Master kiolvassa az SSPBUF regisztert a BF flag törléséhez, beleírja a következő byte-ot, majd amikor minden byte hasonló szekvenciával "átment", az SS (Slave Select) vonalat inaktívvá téve jelzi a Slave részére, hogy az átvitel befejeződött.
Azt, hogy mikor, milyen funkcióhoz hány byte-ot és milyen összeállításban kell elküldeni, mindig a Slave adatlapja határozza meg.
Az általad linkelt pdf doksi talán jobban elmagyarázza mindezt, mint én.

Rendben, hogy a Slaveben is van SSPBUF. Sajna még egy kicsi segítséget kérek.
A gondom továbbra is az, ha kiküldök a memoriának egy cím byte ot, hogyan tudja a slave azt az első bit "előtt", hogy az első címbit órajelére melyik címen lévő adat első bit jét léptessen vissza a mester SSPBUF regiszterébe. Ha mindez már ok, akkor "a kicsi programocska már" edöntheti akar -e több adatot: az is a fenti byte szintű főkérdés magyarázata szerint működhetne.
Köszi a választ, de nekem még mindig kínai a dolog.

Körkörös adatforgalom van: amikor a Master "betol" egy bitet, tulajdonképpen egy balra forgatás történik a Slave-ben (ha az MSB megy ki először), az ő SSPBUF-jának a felső bitje kerül ki az adatvonalra. Memóriát pl. úgy olvashatnak, hogy:
- Slave Select-et Master aktívra húzza, jelzi a küldést
- Master kilépteti az olvasás parancsát, 8 bit után Slave "megérti", hogy olvasás lesz, vár a címre
- ezzel együtt Slave kiléptetett 8 akármilyen bitet, Master beolvassa a BF törléséhez, de figyelmen kívül hagyja
- Master kilépteti a cím kódját, Slave értelmezi, kikeresi a területen lévő adatot, saját SSPBUF-jába teszi
- ezzel együtt Slave megint kiléptetett 8 akármilyen bitet, Master beolvassa a BF törléséhez, de figyelmen kívül hagyja
- Master küld 8 akármilyen bitet (tetszőleges SSPBUF == dummy byte), a lényeg, hogy a Slave-nek 8 órajel kell ahhoz, hogy kitolhassa a kiolvasott memória értékét
- ezután már a Master SSPBUF-ban ott van a fogadott adat, inaktívvá teszi az SS vonalat, kész.

Master által 3 byte küldés, Slave felől három byte fogadása, de ebből csak a harmadik tartalma a lényeges (élőben meg, ahogy az adatlap meghatározza).

És még hogy kicsit zavarossabbá tegyen önmagamat.
itt van egy SPI memoria adatlapja, amelynek 7. oldalán (fig. 2-1) read sequence idődiagramja cáfolja amit eddig irtam a párhuzamos adatcseréről. Látható, hogy SI instruction és address alatt semmi nem jön vissza SO-n. Tehát az SSPBUF mégsem a fentiek alapján működik? Mert így van idő a cím és az adat közti rövid időben eldönteni mit is kell visszaküldeni. DE mindez egyáltalán nem hasonlít szerintem a fent tárgyalt "kiléptet és egyben be is léptet" elméletre.
Most akkor hohhan is kell nézni mindezt?
szerk:
most látom a fenti választ, köszi tanulmányozom.

Igen, ez egy lehetséges megoldás, bennem is felmerült.
1. Akkor viszont miként magyarázod, hogy egyetlen SPI buszos adatlapon sincs dummy byte kiléptetés megemlítve, amire az adat visszajönne? (Volt hogy láttam dummy -t, keresem)
2. a korábban említett pdf sem az általad említett algoritmust programozza le! Ott sem látok az adatolvasásra ujabb byte küldést, csak azért, hogy ismét meglegyen a 8 órajelperiódus.

Az SPI olyan amilyen.
A PIC leírása szerint megcsinálja a dolgát. Ezután, hogy mire, és milyen módon használod, az teljesen tőled függ. Ha pl. egy SPI memória olvasására/írására használod, akkor a PIC SPI-jét összhangba kell hoznod a memória IC SPI buszának vezérlésével. A PIC ezzel az SPI-vel csak megkönnyíti a dolgodat, hogy ne neked keljen a bitenkénti léptetgetést elvégezni. Azon ne csodálkozz, hogy van olyan, hogy csak kimenő adat (v. éppen cím) van, és nem jön vissza semmi. A fordítottja is elképzelhető, attól függően, hogy miként használjuk az SPI-t.

Van olyan fajta alkalmazása is - amely nincs összhangban az SPI memóriákkal -, hogy az SPI-re egy shift regiszter láncot kötünk, s ezzel kibővítjük az I/O portjainkat. Ilyenkor az input portok olyan shift regiszterek, amelyekbe betölthető (latch-elhető) a bemenő jelek logikai szintje, míg az output portoknál a beleshiftelt adat átírható a port kimeneti tárolójába (vannak ilyen 74LS TTL IC-k). Ezekből tetszőleges összeállításban tetszőleges számút felfűzve, első lépésben az input biteket "be-latch-eljük" egy külön jellel, majd az SPI-t indítjuk egy - tetszőleges értékű - teszt bájttal a kimeneten. Majd sorban küldözgetjük ki az output bájtokat, illetve ha az input port bájtja következne, akkor pl. 0 bájtot. Közben olvasgatjuk is be az SPI-n bejövő bájtokat, de csak azokat tároljuk el amelyek input porthoz kötődnek, a többit eldobjuk. Ha sikerült a tesztbájt után annyi bájtot kinyomnunk, amilyen hosszú a lánc, akkor utoljára a tesztbájt jön inputként vissza. Ezt megvizsgálhatjuk, hogy sértetlen-e, és ha igen, akkor sikeres volt a lánc feltöltése/kiolvasása. A végén nem felejtjük el egy külön jellel az output portok kimenetére "ki-Latch-elni" a beléjük tolt biteket.

Látható, hogy ez utóbbi egy másfajta kezelési logika, mint az SPI memóriáké.

Az ember - ötletességénél, furfangosságánál fogva - még ezeken túl is sokfajta felhasználására képes a PIC-be épített SPI vezérlőnek.

Szerintem teljesen mindegy, hogy jön adat, vagy nem jön, ha úgyis eldobjuk. A master az órajelek ütemében bekapuzza a bejövő adatvonal állapotát, és vagy 1-et vagy 0-át olvas. Ehhez nem muszáj a slave-nek adatot küldenie.

Csak az a fontos, hogy amikor már az érdemi adatátvitel folyik, akkor megfelelő ütemben kerüljön az érvényes adat a vonalra.

Nekem csak az a fura, hogy egyetlen SPI dokumentációban sem látok határozott utalást arra, hogy a mester az adat beléptetéshez a slavenek értelmetlen byteot kell hogy kiküldjön.
Igaz, arra kell vigyázni, hogy tényleg értelmetlen legyen, mert különben komolyan veszi és feldolgozza. (hacsak valami mikroprogram nem örködik a rendszerben efelett. Ezek után aki SW. es megoldást csinál figyelnie kell erre is)

Ha olyan a slave, akkor van benne "mikroprogram", ami őrködik. Persze ez nem olyan program, mint a firmware a kontrollerben, hanem logikai hálózat és számlálók. Az egész átvitel folyamatát a slave-ben a mastertől jövő chip-select, chip-enable, slave-select, stb. jel reseteli. Tehát megjön a chip-select jel, akkor az egész slave alaphelyzebe áll. Ezután vár 8-16-32 bitet, ami tartalmazza, hogy mit kell majd csinálnia. Egy példa: a slave 16 bites parancsot vár és memóriáról van szó. Ekkor a nulladik bit mondja meg, hogy írás vagy olvasás lesz, a következő 15 bit pedig megadja a memóriacímet, amire írni akarunk, vagy olvasni akarjuk. Ha bejött az első 16 bit, akkor ezután ha olvasásról van szó, akkor a memória beteszi a kimenő regiszterébe a fogadott címről az adatot, és utána bármit küld a master, azt nem veszi figyelembe, csak az órajelre reagál, és lépteti ki sorban a biteket. Pl. olyan is lehet, hogy megjött neki a 16 bites parancs, és ha utána kap mondjuk 32 órajelet, akkor a címzett memóriacella utána a címzett+1, címzett+2 és címzett+3 című cellák tartalmát is kilépteti. Tehát nem lényeges, hogy értelmetlen legyen az első 16 bit után a beléptetett adat, mert a slave úgyse nézi az első 16 után, hogy mi jön be. Azt meg, hogy melyik az első 16, azt abból tudja, hogy a chip-select láb reseteli a számlálóját. Ha a nulladik biten az jött be, hogy írás lesz, akkor az első 16 bit után további adatokra várakozik a slave, és egy átmeneti tárolójába lementegeti a bejövő biteket (pl. 32 bájtot bevár, és utána elkezdi az eeprom cellák írását a bejött címtől kezdődően felfelé haladva). Nézd át alaposan a slave-ek adatlapját, ahol nem emlegeti, hogy értelmetlen adat menjen, ott általában teljesen mindegy, hogy mi megy, mert úgyse veszi már figyelembe.

Érthető, köszi mindenkinek. Igy volt logikus nekem is, de azért jó volt hallani egy kis megerősítést.

Nekem is lenne egy kérdésem: nem teljesen tiszta a Sleve Select használat.
Adatlapból (18F25K20):


de:


Szóval a kérdés: master eszközön használhatom az SS pin-t normál I/O-ként, vagy inkább hagyjam szabadon? :kerdes:

Hello
megvitathatnék veled egy problámámat mert nem jövök rá mit csesztem el.
alapjaiban nem a ds18b20 van gondom mert simán olvasom, hanem ezt rfm12b tranciveren keresztül szeretném használni
a progim használ megszakításokat, tmr1 és sorosportét is, simán müködik is, 32786 külsö kvarc a t1osi és t1oso lábakon, 32768-tól számol 65535-ig, megszakit, lép 1 sec-t, olvas ds18b20-at, aztán kiir nokia kijelzőre.
eddig semmi gáz, tök jó.
a gondom ott kezdődik amikor elkezdtem volna az rfm12b inicializálni. rc4, rc5, rc3 lábakon rá kötve, spi kommunikáció kell hozzá.
amint sspen = 1 beirom a progi, soha többet nem hajt végre megszakítást.
tehát nem ir ki, nem számol, nem mér hőt.
16f877 használok most épp, ez volt kéznél.
kérdésem csak az hogy volt-e már dolgod spi komm és megszakitásos progikkal, ha jól vettem észre már nem kezdő vagy.
picbasicben nyomom, ha kell elküldöm a kódót.

ha van vmi építő ötleted előre is köszi.

Csatold a kódot

Rájöttem!
A picbasic szívatott meg, mert a kód végén voltak a megszakítás kezelő rutinok és ez így nem tetszett neki.
a kód elejére kell rakni és egy GoTo OverInterrupts át kell ugorni. Elég gagyinak tünik, de a gyári sampléban is így van megoldva, csak én nem ragaszkodtam hozzá.....
Most már az RFM12 init nem megy, átmentem ennek a forumjára.
Bővebben: Link

Sziasztok!
Abban kérnék segítséget, hogy hogyan lehet 8 bites mikrovezérlővel (PIC16F690) 9 bites adatot továbbítani SPI-n? Vannak elképzeléseim,de szeretnék egy konkrét működőképes útvonalon elindulni, mert eddigi próbálkozásaim nem sikerültek. Amúgy egy Nokia 6100 LCD-t szeretnék vezérelni és ezért kell a 9 bit.
Esetleg szívesen fogadom az ezen a téren szerzett tapasztalatokat is. Előre is köszönöm!

Hello, ha a PIC hardverbeállításával nem lehet elérni a 9 bites módot, akkor marad a szoftverből történő megvalósítás...pár sor az egész...

Hali
Mi van ha ket byte-ot kuldesz? Nem ismerem az emlitett kijelzot, de 9 bitet csak soros vonalon hasznalnak. Ha elfogadja a 2 Byte-ot akkor nyert ugyed van. Ha nem akkor SW bitbillegtetes.
Udv Vili

Hali!
A következő pár sorra gondolál?


Jól csináltam? Elvileg az először kiküldött bit a 9. határozza meg, hogy adatot vagy utasítást küldök. Szóval először küldöm a 9. bitet majd sorjában a többit. Valami ötlet? Vagy esetleg egy másik megoldás?

Közben sikerült, csak egy vezeték nem jól érintkezett. Szóval jó a kódom...

Igen, igy gondoltam, és jó!
Itt egy ugyanolyan, csak pepitában:
SPIIO
BTFSS BUSY ;ic dolgozik?
GOTO SPIIO ;ha L var
movlw 16 ;16 bit lesz
movwf CLOCKS
bcf SEL ;kivalaszt
loopspiio
bcf STATUS,C ;Vettunk egy nullat?
btfsc SDI ; Ugrik, ha vett egy nullat
bsf STATUS,C ; Vettunk egy egyest
rlf SPIDATAL,F ; berotalja a Low digitet
rlf SPIDATAH,F ; berotalja high digitet
bcf SDO ; Ad nullat
btfsc STATUS,C ; ugrik, ha 0-t kell kuldeni
bsf SDO ; ad egy 1-t
bsf SCLK ; Clock
nop ; NOP nelkul is megy
nop
bcf SCLK
decfsz CLOCKS,F ; Letelt?
goto loopspiio
bsf SEL ; De-select
return

Hello.
A következő lenne a kérdésem: Hogyan lehet megállapítani, hogy mikor írhatom a következő bájtot az SSPBUF regiszterbe? A BF bit figyelésével annyi bajom van, hogy ha amint az 1-esre vált rögtön kiolvasom SSPBUF regiszter tartalmát és már küldöm is a következő bájtot, akkor azt figyelmen kívül hagyja és beállítja WCOL bitet. Ez szerintem azért lehet, mert a bemenetet a bitek közepénél vizsgálja, és BF már akkor 1-esbe billen, amikor az utolsó bit közepénél jár, mert akkor már bejött az adat. Az lehet a hiba oka, hogy még az utolsó bit küldése folyamatban van amikor én SSPBUF-ba írnám a következő bájtot. (PIC18F2550-ről van szó, az SPI órajele Timer2 output/2, ami jelen esetben 24000 Hz)
Ha igaz az elméletem, akkor a kérdés az, hogy
van-e jobb megoldás mint WCOL bitet figyelni, hogy 1-re billent-e és amíg mindig átbillen, újra próbálkozni az írással?

SSPIF bit nem jó?

SSPIF-vizsgálatával ugyan így viselkedik, valószínűleg mind a kettőt egyszerre állítja 1-be, a bemenet utolsó vizsgálatánál.
(elfelejtettem bekapcsolni az értesítőt és azt hittem, hogy még nem jött válasz)

Nézz bele az Erratakba, mert rémlik valami probléma az SPI körül egyes chipeknél.

Hogy tudom kiolvasni Device ID-t?
(olvastam egy két érdekeset az errata-ban)
Lehet, hogy software-es SPI lesz a végén.
Konkrétan ezt találtam és ezt tapasztaltam: SPI master, write collision for FOSC/64 and
Timer2/2

ICD2, Pickit2 égetők ki tudják olvasni. De írsz bele egy kis programot, ami a saját programmemóriájából a 3FFFFE címről kiolvassa az alsó öt bitet, és akár kiteszi ledekre, majd végtelen ciklusba megy, az is jó. Ezután megnézed a táblázatokból, hogy ezek alapján a tiéd melyik revízió.

A megoldás az errata-ból:
Add a software delay of one SCK period after
detecting the completed transfer and prior to
updating the SSPBUF contents.

Köszönöm a segítséget!

Sziasztok!

SPI működésével kapcsolatosan szeretnék kérdezni. Az MPlab-ban Pickit3-mal debugolok. Megfigyelt regiszterekhez hozzáadtam a C portot (ezen van az SPI modul). Az órajelet kell-e látnom a WATCH ablakban? Elvileg ugye az rc3 az órajel, de ennek változását jelen pillanatban nem látom. Ez így normális?

Sziasztok!

Tudna valaki segíteni abba, hogy SPI busznál a master és a sleve között mekkora távolság lehet?

Köszönöm.