Fórum témák
» Több friss téma |
Forditsd le mindket valtozatot, utana vessuk ossze, mit latsz a .lst fileban, mire is forditott.
Az spi_adat cimet tudjuk? Az is kiderul a .lst filebol... De varjunk csak egy pillanatra: nem lehet, hogy maga a masolas mukodik, csak utana valamilyen vizsgalatot vegzel es mivel nem kerult be a W regbe egyaltalan egy movff soran, ezert a korabbi, random W erteket vizsgalod tulajdonkeppen? A hozzászólás módosítva: Júl 2, 2015
Az spi_adat címe 00000011
A forditas alapjan minden tokeletes, a bitek is rendben vannak, a cimek is. Az adatmasolas jo kell, hogy legyen. Szerintem mas gond lehet ott.
Esetleg masik PIC is ezt csinalja? Ha teszel NOP-okat elotte-mogotte, akkor is csinalja? Ha mondjuk egy masik memcimrol toltod be ( movf spi_adat,w movwf masikmem movff masikmem,SSPIBUF1 vagy fix erteket hasznalsz movlw fixertek movwf spi_adat movff spi_adat,SSPBUF1 Ilyenkor mit csinal?
Cseréld le azt a $-1-et címkére. A 18F-es PIC-ek memóriaszervezése is 8 bites az utasítások mindig csak páros címen lehetnek.
Vártam már, hogy mikor szúrja ki valaki.
 Az érdekes az, hogy attól még működik, szimulációban is és élőben is.
Az tényleg érdekes mert én is belefutottam párszor ebbe a hibába nekem le se fordította a fordító.
Pedig nekem dob egy warning-ot a fordító, de szimulátorban is megy.
Ajánlom figyelmedbe az errata 14. pontját, és az adatlap 210. oldalát.
Szerk: tesztelhetnéd az ütközés detektáló bitet mielőtt módosítasz a kódon, valószínű 1 lenne. "Bátor" dolog kommunikációt hibakezelés nélkül megírni. Nagyon tudnod kell mikor milyen adat milyen irányba folyhat és hogy zajlanak a bufferek cseréi. Nem kritika én is azt hittem anno minden úgy megy ahogy én gondolom, de hát a saját hibájából tanul az ember, ritkán máséból  A hozzászólás módosítva: Júl 3, 2015
Ez nagyon hasznos volt, köszönöm! De nem oldotta meg a problémát. Átírtam a kódot így:
Így sem működik. Az ütközést detektálást még tanulmányozom, de szerintem itt más a gond.
Sziasztok.
Pic18f2550 el usb-n keresztül akarok küldeni adatokat ( HID kapcsolattal ). Örülök mert tudok ledeket ki be kapcsolgatni, meg nyomógombok állapotát lekérdezni, viszont az usb_descriptors.c ben lévő USB_DESCRIPTOR_STRING stringeket sehogy se tudom lekérdezni. A kliens programot c# ban van írva. Remélem tud nekem segíteni valaki abban hogy hogyan tudom ezeket lekérdezni. Előre is köszönöm.
Bár nem értek hozzá (mármint az USB-hez) és lehet hülyeséget fogok írni, de lehet, hogy az USB-s kapcsolat is egy fajta COM portos UART kapcsolatot létesít.
Így talán egy UART-os RX/TX -s lekérdezést készítesz a win programodba és megnézed milyen adatok jönnek. Lehet teljesen rossza amit írtam, de hátha ad ötletet a továbbiakra...
Ha olvasni fogadni nem akarok adatot az SPI vonalon, akkor az SDI lábat lehet I/O-ként használni vagy nem ajánlatos?
Most akkor olvasni és írni sem akarsz SPI-n?
Akkor nem kell beállítani az SPI regisztert és már is használhatod ki és bemenetnek, legalább is, ha az adott PIC (adatlapja szerint) adott lába is engedi az oda vissza irányt. De egyébként, akkor is használhatod I/O portként az SPI lábakat, -persze ha a fenti mondat vége is igaz- ha használod az SPI-t csak mindig arra kell figyelned, hogy az adott port adott lábára a megfelelő beállításokat megadd (TRISx regiszter) és, hogy az SPI CS lába magas szinten (vagyis SPI-t nem használod) legyen, majd a művelet végén visszaállítod a portokat (TRISx regiszter). A hozzászólás módosítva: Júl 4, 2015
PIC-el SPI potikat vezérelek, de ahhoz a PIC-nek csak írnia kell az adat vonalat, olvasni nem, tehát az SDI lábat az SPI nem használja. Ezért kérdeztem, hogy felhasználható-e pl a CS vezérlésére.
Ha a láb nem egy periféria kimenete, vagy nem analóg módban működik, akkor minden további nélkül felhasználható rendes kimeneti/bemeneti célokra. A lábra ugyanis egyszerre több digitális periféria, port kapcsolódhat. Egyetlen kikötés hogy csak egyikük lehet kimenet, az összes többi csak bemenet.
A hozzászólás módosítva: Júl 4, 2015
Sziasztok!
Próbáltam az SPI digi poti projektet 16F877A-ra átültetni, de valami gond van az SPI-vel. Az a helyzet, hogy az SSPSTAT,BF nem akar 1-be billenni soha. Próbáltam már mindent, de semmi eredmény. Maga sz SPI működik, mert ha késleltetést rakok a bitfigyelés helyére akkor nagyon kínlódva de megy az átvitel. Az errata nem ír semmit. Találkozott már valaki hasonlóval?
Az előző hozzászólásomat javítanám, ugyanis ez az SPI lábaknál nem igaz. Az SDI láb felett ugyanis az SPI teljesen átveszi a hatalmat, vagyis sem a PORT sem a TRIS regiszter nem jut érvényre. Elnézést a félrevezetésért!
Ez minden PIC-nél így van a BF bit csak I2C-nél lehet küldésre és fogadásra figyelni viszont SPI-nél csak a bejövő adatra szolgál, így tudsz adatot küldeni SPI-n:
A hozzászólás módosítva: Júl 5, 2015
Köszönöm, de sajnos így sem megy. Nem tudom mennyire lehet hinni a PICKIT2 debug-nak, de pl.
után üres marad a buffer, tehát nem tölti bele a w tartalmát és ezért nem megy az egész. Az mindenesetre érdekes, hogy ha a bitfigyelés helyett késleltetést teszek be, hogy egy helyben pörögjön a program, akkor néha átmegy az adat.
Hát nem tudom nekem Pk3-nál volt, hogy újabb típusú PIC-nek az SSPBUF-ját üresnek írta de mégis elküldte az adatot. Én amit ilyenkor próbálni szoktam egy multiméterrel, 2,7 - 3,3V környékéig kell mérni feszültséget az SDO-n és SCK lábon:
Ha így "mérés" szinten sincs semmi akkor nem tudom, hogy mi lehet a baj. A hozzászólás módosítva: Júl 5, 2015
A GND-hez képest mindkét lábon 4,5 V-t mutat.
Helyesbítek ez a feszültség a sebességtől is függ, de szerintem működik a modul is meg a szoftver is mert ha 4.5V-ot mérsz az elég "nagy" különbség nullához képest.
Igen. Most azt mutatja, debug módban, hogy az SDO lábon 0V-van amíg arra az utasításra nem ér, hogy a bufferbe töltse az adatot. Ha elérte ezt az utasítást felmegy a feszültség 4,5 V-ra és ott is marad. Ha kész az adatküldés, nem kéne visszaesnie 0 V-ra?
Nézd meg az SCK ha az nulla akkor mindegy mi van az SDO-n, ha az SCK egy vagy felfutó élen van akkor számít az SDO állapota(már nem emlékszem, hogy szint vagy él vezérelt).
Azt már néztem. Ott egyből meg van a 4,5 V ahogy az SSPCON regiszter feltöltődik a megfelelő adattal.
És mikor a polling enged tovább nem lesz nulla az SCK ?
Basszus! Találtam egy jó kis doksit és rájöttem, hogy mekkora láma voltam, már megint!
Szóval eszerint nincs igazad abban, hogy az SSPSTAT,BF csak I2C-re jó. Viszont rávilágított, hogy az SSPBUF BANK0-ban, az SSPSTAT pedig BANK1-ben van. Én meg nem váltottam bankot a polling előtt, így aztán hiába vártam, hogy bebillenjen a bit. Tehát a helyes megoldás:
|
Bejelentkezés
Hirdetés |
