Fórum témák
» Több friss téma |
Fórum » CCS PIC Compiler
Egyébként most ez van benne:
Amolyan debug ként. Nem tudom ezen van e valamit debuggolni. Egyszerűen felviszi magas szintre a B3 as lábat és ott is hagyja.
Microchip-nek van egy fejlesztőkörnyzete (nem tudom hirtelen más támogatja e pickit-et)
MPLAB illetve MPLABX az ujnak a neve. Ha ebben fejlesztesz akkor pickit ki lehet választani debuggerként és a programot debug módban fordítottad lehet akár lépésenként végrehajta menet közben nézegetni a változókat . De jobban megnézve általad használt típus de bugolását közvetlenül nem támogatja ... ugyhogy lehet vedd semmisnek előző üzenetet 
Azon gondolkozom ,hogy nem e a kvarcommal van valami gond. A kvarc lábait egy-egy 22p -os kerámia kondenzátor köti össze a földel. Ennek így jónak kell lenni nem?
En csak most kezdtem bele PIC programozasba, -megeshet hogy hulyeseg de talan megfontolando-. Ugy emlekszem nem igazan celszeru bizonyos esetekben a delay-t hasznalni idozitesre, mert akkor semmi mas nem muxik. Esetleg a millis() nem lenne jo?
Is it make any sense?
A fordító nem ismer ilyen fv. -t. De az teljesen mind1, hogy meg áll e minden mert egyszerűen lefagy az egész.
Természetesen ez így nem jó.
A #use a preprocesszornak szól, hogy hogyan számítsa ki a delay utasításokat. A #Fuses pedig a PIC configurációs bitjein keresztül a vasat állítja be, hogy milyen erősítése legyen az oszcillátor áramkörnek, hogy be bírjon rezegni.
Sajnos megint nem jó PIC-et választottál.
Drága is, kicsit butácska is és sajna nem is lehet debugolni. Tudom, ez volt a fiókban. De tanulni és vért pisálni az öt soros programokkal nem ez a legjobb választás. Egyébként szinte biztos, hogy nem megy a külső órajeled. Erre utal az, hogy felhúzza magasra a portot (tehát fut a program) és utána látszólag megáll. Szerintem nem áll meg, csak nagyon lassan fut. A delaynak meg az van mondva, hogy 12MHz az órajel és nagyon sokat számlál, hogy leteljen neki az 1000msec. A PIC a környezeti brummot szedi össze nálad mint órajel és arról ketyereg. Uszkve 50Hz sebességgel. Vedd ki a delay_ms(1000) utasítást és helyette használj delay_cycles (10) utasítást, vagy #use delay(clock=50Hz) Ezek után tessék jelenteni, hogy mi történt.
Beraktam #use delay(clock=50Hz) -et.
Most folyamatosan 2.4V ot mutat a multiméter. Ez meg hogy lehet?
delay_cycles (10) -el pedig 2V van folyamatosan a kérdéses lábon.
Újra méricskéltem kicsit:
1. PIC kap áramot 2. A kristály bal illetve jobb lába be van kötve a megfelelő helyekre. (15-16 láb) 3. A kristály egy-egy lábán van egy-egy 22p kerámia kondi amiknek a másik lábuk a földre van kötve. Mindenhol van összeköttetés és megfelelő jelszint. Egyszerűen nem értem. Működnie kéne.
Már majdnem jó.
Akkor mégiscsak megy az órajel valahol, mert ha 2.4V-ot mérsz, az azt jelenti, hogy 50% kitöltési tényezővel villog nagyon gyorsan a LED. Most kellene megmérni, a kijövő frekit, amiből meg lehet tudni, hogy milyen frekin megy a kristály. Ha játszol a use delay és az delay_ms utasításokkal, akkor egyszercsak a látható tartományba esik a LED villogása és kiderülnek a kvarc paraméterei. Lehet, hogy 1.2MHz és lekopott a tizedespont róla? Vagy tegyél bele egy tuti biztos kvarcot.
ameddig ~2.5 V körül mérsz a pic-en addig azt jelenti hogy müködik.
 multiméter átlagol tehát a pic szorgosan váltogatja 5V és a 0 V ot
Az nem lehet, hogy 4MHz-es a PIC-ed és te 12MHz-es kaviccsal akarod hajtani?
A 16F628A és a 16F628-20 bírja 20MHz -ig, a 16F628-04 csak 4MHz -ig megy.
Probald meg belso oszcival. A 16F628A rendelkezik belso 4 MHz oszcival, es akkor ki tudod zarni a kvarc koruli hibakat.
Na, végre!
Vilmosd rátalált a tuti megoldásra. Már régen túl lennénk a problémán, ha nem bonyolítottuk volna ennyire el. Köszönjük...
Mondjuk nem tudjuk hogy a kedves ujhus kollega milyen HW-t kotott. Lattunk mar itt 1-2 hetes kinlodast is es a vegen kiderlt hogy rossz volt egy forrasztas. Talan Inkabb ilyen tanacsokkal kellene segiteni a kedves kezdo kollegakat, nem talalgatni, es szurkalodni a masik segitokesz fele. Vegulis nem fontos nekem hozzaszolni.
Belső órajelel működik, ezt írtam is. A külsővel nem működik csak, de nem értem miért.
Zárlatot és szakadást nem találok a külső kristály körül.
A hardverrel volt probléma. Kiszedtem a kondenzátorokat a kristálytól. Így működik. Nem tudom mi a gond vele. 22p kondik. Esetleg valakinek van ötlete mi lehetett a gond elárulhatná. Kíváncsi lennék. Aztán az is lehet ,hogy a boltos mellé nyúlt és nem jót adott, mert nincs rájuk írva semmi.
Köszönöm mindenkinek a segítséget!
Esetleg túl nagy kapacitásúak (pl. 22 pF helyett 22 nF).
Te engem itt, most félreértettél!
Igazándiból örülök, hogy a sok gyógyegér (köztük én is) egyre kacifántosabb megoldásokban gondolkoztunk, hogy mi is lehet a probléma, mikor te hoztad az igazán elegáns és senki által nem ajánlott ötletet, hogy miért nem a belső oscillátorral próbálkozik a superman. Ez volt eddig az egyetlen és tényleg frappáns megoldás. Sajnos nekem van egy ilyen nagyon sz@r stílusom, amit, ha megfeszülök sem tudok megváltoztatni, pedig én is utálom magam ezért. Alapvetően nem vagyok egy destruktív elem csak sajnos mindenki azt hiszi rólam. Mindenkitől bocsánatot kérek, aki úgy véli, hogy megbántottam. Pedig nem akartam.
Ja meg annyit kell tudni hogy en 8 ora faziskesessel vagyok a HE orajahoz. Nalam most 10:00 AM.
Üdv!
Két PIC között közötti I2C kommunikációval bajlódok pár napja. Az egyik egy PIC18f2550 (48MHz PLL) ez a master. AZ SPI használata miatt nem lehetséges a hardveres i2c így szoftveresen lett megoldva. A másik egy 16f690 (8MHz belső osc) ez a slave. Ez hardveres i2c-t használ. A problémám az, hogy a slave-ről való olvasás néha stabilan fennmarad egy darabig, néha fals értékeket ad vissza de egy idő után mindig leragad a master-ben a program az i2c_read() utasításnál. Az írás rendesen működik. A felhúzó ellenállások 1,8k-sak. Az ide vonatkozó kódrészleteket bemásolom: Master:
Slave:
Bármi használható ötlet jól jönne.
Közben kipróbáltam, hogy mi történik, ha folyamatosan olvasom ki ugyanazt az értéket, ezért csináltam egy hurkot, ami nem csinál mást, mint folyamatosan kiolvas egy fixen beállított értéket a slave-ből majd kiírja.
A helyes érték a 222. Érdekes módon a 0-k mindig ugyanabban a mintázatban jelennek meg. És továbbra is kifagy véletlenszerűen. Továbbra sincs ötletem mi okozhatja ezt.
Ugye le vannak tiltva a megszakítások a kommunikáció alatt?
Igen, nincs más megszakítás közben. Ami viszont feltűnt, hogy ha lejjebb viszem az átviteli frekvenciát, valamelyest javul a helyzet. 30KHz körül még stabil is marad amíg csak egy byte-ot viszek át. Ha jön egy második is, az már néha nulla lesz. De külső zavarok is blokkolásba vihetik a buszt: pl. asztali lámpa felkapcsolása, pákatrafó. A master és a slave-ek közti vezeték kb. 25 cm hosszú.
A fura tényleg az, hogy ezek a problémák csak slave-ről való olvasás közben jelentkeznek, az írás teljesen rendben van.
A blokkolás valószínűleg azért van, mert valamelyik hibaesetet nem kezeled le. Az érzékenység meg ott játszik be, hogy akkor lesz bithiba, amit kezelni kéne.
Szkóppal nézted már, hogy mi történik?
Szia!
A slave -nek meg kellene állítania a master állapotváltozását addig, amíg ténylegesen be nem tölti az adatot a SSPBUF regiszterbe. A szinkronizációt a SCL jel alacsony szinten tartásával lehet megoldani: Idézet: „bit 4 CKP: Clock Polarity Select bit In I2 C mode: SCK release control 1 = Enable clock 0 = Holds clock low (clock stretch). (Used to ensure data setup time.)” Amikor a SSI modul jelzi, hogy a vett adat kész, a CKP=0 -val alacsonyra kell húzni az SCL vezetéket. A master egy fél bitidő múlva magasra engedi az SCL jelet és várja, hogy az SCL magas szintje beálljon. Ez addig nem történik meg, míg a slave alacsony szinten tartja. A program beírja a küldendő adatot az SSPBUF regiszterbe aztán a CKP = 1 értékre állítással jelzi a masternek, hogy mehet a beolvasás... |
Bejelentkezés
Hirdetés |
