Írt, vagy talált a neten valaki 1-Wire kezelést PIC32-re?
PIC16-ra meg PIC18-ra találok csak megoldásokat.

Nem akar menni az SPI. dsPIC33EP512GM304-ről van szó. Így van beállítva:

Ugyan ezekkel a beállításokkal több más dsPIC-el használtam már az SPI-t, de itt most valamiért nem akar működni. Benne ragad a függvényem ciklusában:

Megnéztem logikai analizátorral, az SDO és az SCLK lábak alapból magas szinten vannak, az SPI2BUF-ba való bemásolás után mindkettő alacsony szintre vált és úgy is marad örökre.
Mi lehet a gond? Ugyan ezekkel a beállításokkal, ugyan ezzel a függvénnyel eddig több másik PIC-en is hibátlanul működött az SPI.

Van azon a picen jtag? Configból ki van kapcsolva?

Van, és elvileg kikapcsoltam:

Egy bájt (0xFF) kimegy, aztán semmi.
A mellékelt kép szerint a SPIRBF bit nem vált át 1-re és azért marad benne a while ciklusban.
Próbaképp oda PPS-eltem az SPI2 helyett az SPI3-at, lemostam a panelt, megnéztem az errata-t... más ötletem nincs.

Az az 1 szem clock pulse a legelején, az ott micsoda? Csak mert übergáz! Hogyan aktiválod az nSS jelet?

Nem tudom hogy az az egy órajel az micsoda. Ez a legeslegelső bájt ami kiküldésre kerül az SPI-on a periféria beállítása után, lehet hogy valami kósza impulzus... Kipróbáltam többször is és mindig ott van.

"nSS" jel? Az micsoda? A chip select-re gondolsz? Azt sehogy, a PIC és a periféria (SD-kártya) közvetlen össze vannak kötve és semmi más nincs ezen az SPI-on, ezért a kártya chip select lába fixen testen van. Más áramköreimben is így működik az SD-kártya.

Pár éve futottam bele ebbe a problémába én is. A végső megoldásom a DMA-n keresztüli adatküldés lett. De megnézve a Mikroe fordítói alapján generált kódot, Ők először nullázzák a SPIROV bitet, az SPI2BUF-ba pedig csak akkor írnak adatot, mikor az SPITBF bit 0. A beérkezett adatot meglétét csak az SPIRBF lekérdezésével ellenőrzik, amit ki is kell olvasni.

Ha a chipselect jel folyamatosan aktív, akkor az az első impulzus már az első bitet küldte ki a perifériának, és az utána következő 8 impulzus közül a 7. az, ami az utolsó bitet kiküldte. A 8. órajel pedig a második byte első bitjét küldte ki, és a periféria akár az idők végezetéig fog várakozni a további 7 bitre, ami jelen esetedben talán sosem érkezik meg - sosem megy ki. Az spi-d pontosan úgy működik, ahogyan annak kell. Épp csak fel kellene használni a chipselectet is. Fixen kikapcsolva kell tartanod, még egy felhúzó ellenállást is raknod kell rá, hogy biztosan kikapcsolva maradjon, és csak akkor kapcsolhatod be, amielőtt a byte-ot is elkezded kiküldeni. Nem lenne rá szükség, ha nem lennének kósza impulzusok az órajel vonaladon, de hát vannak.

Ha ez így lenne, akkor az azt jeleni hogy az első bájt kiküldése sikeres és a második bájt elején áll meg. Betettem egy töréspontot a while utáni sorra és nem fut rá, tehát már a legelső bájtnál elakad.

Kösd vissza annak az spi-nek a kimenetét a bemenetre, és while helyett küld ki ciklusban az SPIRBF bit állapotát egy ledre. Ha nem kapcsol magasba, valami nagyon kapcsrajz bakid van.

Checklist: jtag, analóg vonalak, pin remap. Jtagot kikapcsoltad, pipa. Analógokat is kikapcsoltad? A pin remapot sem szúrtad el?

Megcsináltam amit írtál, de a LED sajnos nem gyullad ki. A logikai analizátoron pedig a mellékelt ábra látható.

Így van beállítva a PIC:

Az áramkör kapcsolási rajzát mellékeltem.

Szerintem kimaradt: ANSELBbits.ANSB7=0; //RB7 digitális (SCLK)

Szerintem gondjaid lesznek az sd kártyával. Kell az a chip select az sd kártya vezérléshez + felhúzó ellenállás is. Azon túl spi mode 3-at beállítani, és ütemvégi mintavételezést használni.

Csak a bemeneteket kell átállítani digitálisra, a kimeneteket tapasztalataim szerint nem. De látszik is a szkópon hogy kimegy az órajel.

A fejlesztőpanelomon (annak itt a rajza: Bővebben: Link) is pont ugyan így van bekötve az SD-kártya és tökéletesen működik. De számos más áramkörömnél is. Konkrétan ez a mostani projekt a fejlesztőpanelomra íródott eredetileg és azon tökéletesen működik a program így ahogyan van. Csak aztán gyártattam egy saját kis panelt ennek az áramkörnek, és a projektből egy másolatot csináltam. Átállítottam a PIC típusát és a PIC inicializálását átírtam az új panelnek megfelelően.

A kimeneteket illetően lehet benne valami, de az sd kártyán rendesen csodálkozom. Az sd kártyák szerintem kötötten mode 3-ban kommunikálnak, és a frame startot a chip select triggereli.

Ha működött neked a fenti beállításokkal minden egy másik pic-el, akkor cseréld vissza a pic-et

Az a másik PIC 100 lábú, ez meg csak 44. Ez a legkisebb lábszábú 16 bites PIC amelyben 4db UART van és az itt kell.

Nem néztem át az SPI kezelésed, de talán az errata 36. pontja magyarázatot adhat rá.
Mármint a kósza jelre. Aztán hogy ez hogyan befolyásolja az adatfolyamot azt nem tudom.
De van pár SPI-re vonatkozó bekezdés az errataban. Elolvastad?

Megcsináltam amit az errata ír, vagyis az SPI3 beállítása és engedélyezése után kiküldök két bájtot és csak ezt követően PPS-elem oda a lábakra az SPI-t. Ennek eredményeképp a kóbor órajel eltűnt. Az SPI-os cserefüggvényemben viszont továbbra is benne ragad a while ciklusban.

Kínomban már azt is kipróbáltam, hogy az SDO és az SDI periféria-kivezetéseket ugyan arra a lábra PPS-eltem rá, azaz összekötöttem az SPI kimenetét a bemenetével. Bár a rövidzárral is ugyan ezt tettem tegnap. A SPIRBF bit azonban meg sem moccan, mindig 0.

Próbáld ki,hogy egyáltalán a bejövő pufferbe bekerülnek -e az adatok.Csak 1 tipp,még nem teszteltem,hogy csak a transmit(TBF)-et figyeld,utána1-2 Nop, addigra elvileg átmásolja a bejövőt a pufferbe,és nézd meg,hogy van -e adat .Ha a flag nem jó,talán így menni fog,max. majd a Nop-ok számával kell kihozni belőle az optimális elérést.

Ezt nem teljesen értem. Milyen bitet figyeljek?

Közben egyébként megépítettem az áramkört még egyszer, egy másik nyákra, egy másik PIC-el (ugyan az a típus csak másik példány), de ugyan azt csinálja. Próbaképp átkonfiguráltam az SPI3-at teljesen más lábakra, de akkor is.

Most a TBF + RBF-et figyeled a while- ben,de csak a TBF-et figyeld.Az RBF,ha jól emlékszem,csak akkor billen,ha a bejövő adatot betette a pufferbe.Így írtam a tippet,hogy a TBF billenése után 1-2 Nop,és megpróbálni,hogy van -e adat a pufferben.

Az SPI3BUF-ban 0x00 van, bármit is csinálok. Amikor beleteszek valamit, akkor is 0x00-at mutat a Watch ablakban.

Mint írtam nálam (csak) ez működött:



Még ami fontos, hogy, ha az SPIBUF nem kerül kiolvasásra, lefagy. Nem tudom neked megtörténik-e a kiolvasás, előfordul, hogy a C "kioptimalizálja"

Elvileg átírtam C-re:

Az eredmény ugyan az, a SPIRBF figyelése sorban megáll.

Ezt láttad? Bővebben: Link

A legfurább az, hogy elvileg bármilyen szinten lehet a bemenet, ha kimegy a 8 órajel, akkor a RBF-nek be kéne állnia. Fura egy hiba! (Gondolom) le ellenőrizted, hogy a regiszterekben azok az értékek állnak-e, amiket bele szeretnél rakni?... Végigszaadtam a beállításaidon, de elvileg jó értékeket töltesz be...

Az általad belinkelt fórumtopiknak ez a releváns része:

Vagyis az SCLK kivezetéshez nemcsak az SPI órajel kimenetet, hanem az SPI órajel bemenetet is hozzá kel rendelni! Ellenkező esetben a vételi alegység nem kapja meg az órajelet...

Na erre soha nem jöttem volna rá! Odakapcsoltam az SPI3 órajel bemenetét is arra a lábra amelyiken az órajel-kimenet is van. Láss csodát, végre átjutott a while cikluson!
Az öröm viszont nem teljes. Mint azt fentebb említettem, a hiba okának kiderítése során az SPI periféria ki/be vezetéseit totál más lábakra átraktam, hátha valamivel előrébb jutok. Most azonban hogy végre meg lett a megoldás, vissza PPS-eltem azokra a lábakra az SPI-t amelyekre ténylegesen kellene hogy ott legyen, mivel oda van bekötve az SD-kártya.
Na és így nem megy a dolog, ugyan úgy megáll a ciklusban.
Így működik:

Így viszont nem:

Ha az utóbbi két sort írom bele a programba akkor benne ragad a while ciklusban, ha az előbbi kettőt akkor meg tovább megy. Semmi mást nem írok át a programban, csak ezt a két sort cserélem ki.

Szerk.:
Az RB7 (RP39) analóg volt. Digitálisra állítva működik.

Ezt úgy is lehet értelmezni(gyengébb angollal), hogy vigyázz, mert két beállítás is lehetséges, ne keverd össze! Érdekes egy megoldás, ez is bug szagú...