Fórum témák
» Több friss téma |
Idézet: „Most terveztem a PicKit2-höz egy 74HC125-tel működő illesztő fokozatot ilyen mérésekhez...” Jó megoldás. 
Még mindig rendetlenkedik az SPI.
Az nSS-re gyanakodtam én is, de multiméter szerint rendben van. Gyanakodtam oszcillátor configra, de ha a kvarc szinkront sutba is dobom, órajel attól még van, egy villogó led legalábbis ezt igazolja. Gyanakodtam a peripheral pin selectre, de ha az SPI1 kimenetet be tudom állítani, a többinek is stimmelnie kellene. Gyanakodtam SPI beconfigolásra, de az analizátor remekül megmutatta, hogy master SCK / SDO rendesen kimentek. A slave ugyan arra a CKE / CKP / SMP-re van állítva, mint a master. Soros ellenállásokon keresztül kapja a jelet (3k3 hü**eség védelemnek). Master SDO -> Slave SDI, Master nCS -> Slave nSS, Master SCK -> Slave SCK, Master SDI üresben, Slave SDO configban kikapcsolva. És a slave nem kapja meg az adatot:
Találkozott már vki ilyesmivel?
Továbbra is az a kérdés, hogy amikor a Slave felé az adatokat lépteted, akkor annak a SS lábán megvan a megfelelő jelszint?
Igen, tuti megvan. SPI adat kiírás előtt egy külön utasítással húzom le az nSS lábat, és jelenleg az egész pic 230 KHz-es utasítás órajelen ketyeg, ergo a nanosecundumos sebesség meg ilyesmik most tuti nem játszanak. Megállítottam egy "while(1);"-el a programot, az nSS lehúzás és az SPI1BUF töltés között, és rámértem multiméterrel.
Már azon is filozom, okozhat-e bármi problémát, hogy mindkettő SPI busz ugyan ahhoz a pichez tartozik, és hogy valami üzemzavart eredményezne az egymásba átkötésük, de nem találtam erről egy kukkot se az adatlapokban. Jobb tippem nincs, gyártok egy négyvonalas összekötést, és rámérek analizátorral a master bemenetein az SI / SO lábakra. Bár előre gyanítom, a túloldalról semmi nem tud visszajönni. Menet közben nem tudom nem észrevenni, hogy ezeknek a perifériáknak a bemeneti lábaival van a gond, mert a kimenetiek a jelek szerint működnek. De perpill nem tudok mit kezdeni ezzel az információval. Összerakom valami könnyen lemérhető formában a kapcsolást, és feldobom ide a full programot is, nem egy hosszú valami. Hátha valami olyan marhaságot követtem csak el, ami egyébként magától értetődő lenne, és csak én szaladtam rajta keresztül. Idézet: „Már azon is filozom, okozhat-e bármi problémát, hogy mindkettő SPI busz ugyan ahhoz a pichez tartozik” Ezt kifejtenéd? Legjobb lenne ha lerajzolnád a jelenlegi SPI kört az összes alkatrésszel, ami rákapcsolódik a vezérlő és adatvonalak bekötésével együtt feltüntetve a bekötött lábak nevét!
Hello !
A haverom épített egy kijelzővezérlőt mely bemutatná a kijelzők multiplexelését. Erre kéne megírni a programot mivel se én se ő nem ért hozzá, és úgy kellene, hogy a gomb egyszeri megnyomására a kijelzőn kirajzolódjon egy szegmens, kétszeri megnyomásra átugorjon a második kijelzőre és így tovább. A segítséget előre is köszönöm. 
Szívesen kifejtem. Adva van egyetlen darab PIC, van neki kettő darab SPI interface-e. Vezérlő programot akarok írni, ami az egyik kimenetét átküldi a másik bemenetére, és ezt programból szeretném visszaigazolva látni. Ez a probléma egy sokkal nagyobb problémából lett kinyisszantva, aminek a kulcsa kutakodások szerint valahol ebben gyökeredzik. Egyszerűen csak nem tudok egy ilyen programot működésre bírni. Nem is vitás, simán megérdemlem ezért a szemmel verés esetét, csak légyszi adjatok legalább tippet, merre keressem a hibát.
A teljes "project" egyetlen darab main.c, ezt fordítom le C30-al, és egészben küldöm le. A teljes pic memóriát írom, az itt nem érintett config bitek az erase utáni "1" értéket fogják kapni. Rajzolni akartam kapcsrajzot is, de éppen rájöttem, hogy most a világon semmi programom nincsen, amivel ilyet tudnék tenni. A kapcsolás egyébként totál egyszerű. Az elrendezésben a pic táplábainál szűrőkondik, pár átkötés a pic saját lábai között, és a PK2 rádugva. Semmi más releváns dolog nincs a PIC-en. Néhány ellenállás, ami vagy földre húz egy lábat, vagy tápra. Hatástalan dolgok, amik az eredeti környezet részei, és nem akarok mindent hulladékra lebontani. Mint a programból alant kiderül, egyébként sem tudnának vizet zavarni. Néhány pic láb pedig "lifegve" marad üresen bemenetként, de 230 KHz-es utasítás órajelnél aligha okoz nagy galibát. A program:
A két SPI eszköz SDO-ja került éppen a PK2 programozó lábaira, hogy kényelmes legyen azonnal analizátorral megnézni is (maradt az ICSP eredeti bekötése, ergo SPI1.SDO->CH1, SPI2.SDO->CH2). Analizátor kimenete fotón beillesztve. Ha valamit zagyván írtam volna le, szóljatok rám, átalakítom kérés szerint.
Szia!
A led-re van egy ötletem: a 49. LATAbits.LATA4=1 és az 50. sorban TRISAbits.TRISA4=0. A led a +3.3V-ra van kötve, tehát nem világít. A 64. sorban az állapot nem változik. TRISAbits.TRISA4=0 helyett LATAbits.LATA4=0 kellene??? Szia
Abszolút igaz, elkapkodtam, javítva:
Továbbra sem világít.
Azt hittem több alkatrész van. Nem kérdezem mi ennek az értelme.
Holnap, ha lesz időm, belemélyedek jobban, mert szerintem az adatlapban lesz a megoldás. Lehet, hogy valamit nem állítottál be jól...
Hálás köszönetem minden segítségért.
Jól elszoktam már az Eagle-től, de ezt azért még legyártottam (kapcsrajz mellékelve). Értelme pedig annyi van, hogy egy sokkal kiterjedtebb kapcsolás simán csak nem működik a lehalt SPI miatt. Pont ugyanúgy nem boldogulok vele, ahogy ezzel a kinyisszantott aprósággal sem. Azért ilyen apró, hogy mégse az egész hóbelebancot hajítsam itt rá valakire, mert az felesleges. Sejtem, hogy a katalógus lapokban lesz valahol a megoldás, de nem tudtam rájönni, hogy hol. Pedig egy párszor már átolvastam őket.
Még egy lehetőséget kimerítettem, nevezetesen hogy talán a portok SDI lábával mégiscsak lenne valami bibi. Felprogramoztam csak az SPI1-et, és visszakötöttem az SDO lábát az SDI-re. Az alkalmazott üzemmód phasing mentes: ugyanakkor olvassa be a jelet, amikor a kimeneti clock érvényesíti a kimenetet. Vizsgáltam ciklusban, hogy a kiment, és a visszajött jel egyezett-e. Ha nem, akkor lefagyott volna a ciklus, egyébként meg villog a led. Villogott.
Elvileg SDO és SDI rendben vannak a jelenlegi felprogramozás alapján is (bármi is hiányzik belőle a teljességhez), analizátor mérés szerint az SCK kimenet is rendben van, az nCS vezérlést pedig multiméterrel mértem ki. Kerestetik annak az oka, hogyan képes az SCK mint bemenet érzéketlenné válni. Idézet: „Kerestetik annak az oka, hogyan képes az SCK mint bemenet érzéketlenné válni.” Esetleg a konfigurációs biteknél kellene szélesebbkörű beállítás? Elsősorban a FICD bitjeire gondolok: JTAGEN_OFF kellhet. Nem tudom, hogy mi az alapértelmezett beállítása. ICS_PGD1 való a mostani konfigurációhoz (csak Debug esetén van jelentősége) Van aztán a BKBUG és COE, amelyek talán nem is szerepelnek minden dokumentációban. Ezeknek 1-ben kell állnia. A fordított logika miatt hülyén néz ki, hogy BKBUG_ON kell, ez kapcsolja KI,hogy a reset Debug módba kapcsoljon! Tehát BKBUG_ON és COE_OFF kell. Ha új fordítód van, akkor nem kell meglepődni, ha reklamál. Jártam már úgy, hogy az újabb verzióban mikrovezérlő header állományában nem volt definiálva a BKBUG bit.
Szia! ? Megvárom icserny javaslatainak végeredményét, utána ha kell még, tovább gondoljuk.(Bár icserny ebben most nagyon otthon van, rám nem is nagyon van szükség!
)
Lenne egy kérdésem, bután fog hangozni: Honnan tudod melyik láb az SCKx,SSx,SDOx,SDIx?
Mert én az adatlapban és a csatolt SPI doksiban sem találom sehol.  Miért raktál ekkora ellenállásokat sorba? Én nem tennék, legfeljebb 100...270ohm-ot.
Nem gondoltál arra, hogy ez nem egy multitaszkos processzor?
Mindent egymás után képes csak csinálni. Szerintem a saját adását képtelen fogadni, mert amíg ad, nem vesz és fordítva. Bár nem tudom, a kimenetek állapotát meddig tartja, de szerintem kiküld egy adatsort, mire beolvasná, az elszállt.
Szia!
Ha jól olvasom az adatlapot, a perifériák jeleniek a kivezetésekhez való rendelését az un. Peripheral Pin Select regiszterekben be kell állítani (lehetőleg egy kivezetésre egy funkciót). Kérdésem az lenne, hogy az SPI1 és SPI2 3-3 jelére jól vannak-e beállítva a regiszterek? Szia
Tévedsz, az SPI hardveres, nem kell processzor teljesítmény hozzá.
Most nincs időm adatlapot böngészni(közben programozom), ha te látod írd már meg, hol látható a fentebb kérdezett lábak melyik kimeneten vannak? köszi!
Szia!
- Nem találom a direkt kivezetéseknél, csak a "port remap" segítségével lehet kihozni. A kapcsoláson is a RP13, RP12, RP10, RP9 és RP0, RP1, RP3 kivezetésekhez kapcsolódnak az ellenállások. - A pickit2 a Ch1 és Ch2-n 4k7 lehúzó ellenállás tartalmaz... A becsatolt leírás 32 üres oldal... Szia
Áh, ezt elfelejtettem, hogy lehet variálni melyik láb mi legyen!
 Köszi, már képben vagyok!A pdf nekem megnyílik innen letöltve is. Próbáld ki a Foxit Readert!
Köszönöm mindenkinek a rászánt idejét, sorban írom a válaszokat.
icserny: Köszönöm a JTAG tippet, az SPI2 kivezetései amiatt "nem éltek". Az SPI2 most már élet jelenségeket mutat. A BKBUG és COE annyira nincsen nálam ledokumentálva, hogy az MC oldalról leszedett C30 pic header állományában sincsen benne. Hiába is adnék ilyet a fordítónak, nem sok esélyem van működtetni. A config regisztereket a header állomány makroival kezelem, így biztos, hogy a nem érintett bitek a törlési 1-ben maradnak. Ha a BKBUG_ON és a COE_OFF is az 1-es bit eredménye, akkor azokkal már nem lesz baj. Ha nem, kellene nekem valami olvasni való, hol láttad ezeket? Melyik bitet billentsem nullába? Ofc ki tudom egészíteni a pic header állományát, de ahhoz info kellene, melyik bit milyen állapotban mit csinál. Újra átnéztem a config biteket, elvileg már nem siklottam át ottani "taposóaknákon". watt: A belinkelt pdf hibás. Ellenállásból éppen ez volt kéznél. Lelassítottam az SPI buszt 450 Hz-re (!), így a parazita kapacitások / induktivitások plussz soros ellenállás most nem fogják kiszedni a jelalakot az előírt határokból. Természetesen nem így fog üzemelni végleges állapotában, ez csak tesztelési célokat szolgált. A dsPIC-eken van egy "peripheral pin select" nevű feature. Ha a cél pic doksiját nézed (70292C.pdf MC site-on megtalálható / letölthető), lapozz a 11.4 fejezethez (159/386. oldal). Gyorsban a lényeg annyi, hogy az említett kivezetések alapból sehova sincsenek kivezetve, de van egy konfigurálható jel multiplexer ráillesztve a pic kivezetéseire, és az eldönti a beállítások alapján, hogy hova legyen "bekötve" az adott pic láb. A küldött forráskódban az RP regiszterek programozása állítja be a konfigot:
Ahogy menet közben az újabb felírásokat nézem, már nyomon vagy magad is. erbe: A szitu az, hogy "multitaszkos" a processzor. Több külön logikai áramkör van összeillesztve a belső buszra, és órajel szinkront kap mindegyi. Kvázi egy számítógép perifériákkal egy tokba integrálva. Gondot az jelenthetett volna, ha a működéshez olyan shadow regisztereket is felhasznál a két SPI busz, amik nincsenek duplázva. Akkor biza torkosborzolok miatta. De nem volt erre utaló információm. Hp41C: Tegnap éppen emiatt volt külön is hosszú éjszakám, mert lefekvéskor eszembe jutott, mi van, ha hibás az 70292C.pdf MC doksi? Leteszteltem külön az SPI1 működését, és külön az SPI2 működését _is_. Megvannak az életjelenségek. Nincsen tévedés azokban a program sorokban. Külön-külön átmegy az az adat, amit kiküldök, és tényleg az megy át. Jelenleg még szenvedek kicsit a programon, mert bár az SPI2 már működik, olybá tűnik, nem az az adat megy át a kettő SPI busz között, aminek kellene. Még nem tudok teljes sikerről beszámolni. Külön-külön önmagába visszacsatolt SPI-vel viszont működik. Rászabadulok analizátorral, és ha nem találom meg a hiba okát, feldobom majd ide a jelenlegi programot, meg a teszt eredményeket.
Az a soros 3k3 akkor is sok oda. Cseréld ki 270...330ohm ra legalább.
Sziasztok!
Egy érdekesség: A dsPIC33FJ128MC802 a DS70291C és a DC70291D ír, a DS70292 a dsPIC33FJ128GP802-ről... Szia
Hp41C:
Én a 70292-t használom, és GP a pic. Mindössze érdekességként, mi az alapvető különbség a GP és az MC között? watt: Kicsit parásnak tűnik nekem az az értéktartomány. MHz-nél használnám, nem mélyhang frekinél. Miért csípi annyira a szemedet ?  Amúgy a teszt eredmények szerint bit elcsúszás van, nem jelalak hiba, noha oszcilloszkóppal nem tudtam bevizsgálni. SPI1->SPI2 programozva 0x34, olvasva 0x1A (lefele csúszott 1 bitet). SPI2->SPI1 programozva 0x2C, olvasva 0x58 (felfele csúszott 1 bitet). Itt valami config móka lesz. Még keresem. Idézet: „Kicsit parásnak tűnik nekem az az értéktartomány. MHz-nél használnám, nem mélyhang frekinél. Miért csípi annyira a szemedet ?” Ebből egy szót se értek, kérlek fejtsd ki mire gondolsz! Idézet: „mi az alapvető különbség a GP és az MC között?” A konkrét tulajdonságok az adatlapokból derülnek csak ki. MAPS szerint itt az MC mindössze enyiben tér el a GP-től: 8-MtrCtrl. PWM, 2 QEI, valamint a maximális hőmérséklet 125 helyett 140 fok. Ha ők hazudnak,úgy én is... Alapvetően két külön családról van szó: MC = Motor Control, feltételezhetően ezek erőssége a PWM kezelés. GP = General Purpose, azaz általános felhasználásra szánt típus.
watt:
Idézet: „Ebből egy szót se értek, kérlek fejtsd ki mire gondolsz!” Oké, ezt külön kifejtem. A pic Schmitt triggerei 1uA-t terhelnek, amit a vonalon ragadt parazita töltés is be tud adni neki egy ideig. Nagyobb sebességnél ha a vonali meghajtás nem szipkázza le a vonalról azt a töltést, akkor szétcsúszik a kiadott órajel, és a túloldalról érzékelhető vett adat az időzítési keretben. Tipikusan az SPI busz egyik átka. De itt most semmi sem megy MHz-eken. 450 Hz-en ketyeg az SPI busz. A pic is 230 KHz-en megy. És egyébként sincs most kéznél 4 egyforma ellenállásom vágatlan hosszú lábakkal másmilyen érték. Azért 3.3k, mert a 1.5k elfogyott. Ez volt kéznél 1k-tól 10k-ig. Éppen hétvégére esett ez a teszt eset, és már el se megyek bolt felé, mielőtt ennek az egésznek a végére járnék. A végleges kapcsolásban egyébként semmiféle soros ellenállás nem lesz. Egy nem működő kapcsolásnál a bánat tudja mi a rossz, hát nem kockáztatok. 1mA-ből nem tud baj lenni statikus terhelésnél sem, de 10mA-el már nem kínoznék meg egy 1500 huf-os pic-et, amit a katalógus lap szerint nem kellene 2mA fölött terhelni. icsernyi: Thx, érdekességként jó ilyet tudni.
Régebbi C30-hoz dsPIC33FJ128GP802.h-ben ez is van:
Mivel neked BKBUG=1 és COE=1 kell, ne izgasd magad vele!
Oké, akkor az valami régebbi config beállítás lehetett, amit valószínűleg valami chip revision túlhaladott, de megtartották a felülről kompatibilitás miatt "Reserved"-nek azt a két bitet.
Valami másmiatt viszont aggódom. Megtaláltam az okát, miért csusszan el egy bitet az átvitt adat a két SPI busz között. És nem tetszik a dolog. Kapcsrajz gyakorlatilag azonos az előzőleg közölttel, kiegészítés benne csak az nSS vezérlésre ráültetett szonda (a PK2 AUX 3.6V-ra van beállítva, ezért csináltam 5V-hoz egy szintillesztő invertert egy BC182-ből). Forráskód egészben vágatlanul:
Alant fotó beillesztve a logikai analizátor kimenetéről. Nem tudom másnak is feltűnik-e, de az nSS vezérlésnek nem szabadna visszaváltania addig, amíg a Master ki nem adta az utolsó clock falling edge-et is. Mindezt azért nem, mert a Slave az nSS megszűnés hatására inaktívba kapcsol, és legközelebb ha megkapja az nSS-t, és az órajelet magasban találja, azt egy órajel impulzusnak érzékeli, és beolvassa a bitet, amit az adatvonalon éppen talál. Kezdő órajelnek érzékeli a Master utolsó töredék órajelét! Ha elegendő késleltetés van a főciklusban, hogy lecsenghessen az az órajel, akkor ilyen baj nem történik, de ha nincs, akkor lehal a ciklus (hamis adatot érzékel). Kimértem a szükséges késleltetést is a FOR ciklushoz, forráskódban kommentezve ott van. Szóval a kérdés. Lehet arról bárhogy gondoskodni, hogy a
ne térjen vissza addig, amíg a falling edge a ciklus végéről még esedékes? És amúgy ja, ez a kis "semmiség" engem most nagyon megszivatott. |
Bejelentkezés
Hirdetés |
