Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Egy RS232 Ethernet Lan átalakító . Bővebben: Link
A Microchip TCP/IP stack -ből ki lehet indulni ..... Majdnem reménytelen, de az alagút végén mindig van egy kis fény, ha a válság miatt még nem kapcsolták ki...
Kaptam valami programot lehetséges, hogy ez lenne az?
Nagyon köszönöm!
Pontosan ez volt!!! Márt kapcsolgatom a reléket. 
Itt egy példakód, pontosan ugyanúgy inicializáltam mindent, és pontosan ugyanazt csinálja, mint amit az este láttam. Link
Kicsit benéztem microchip fórumra is. Ott végülis találtam egy olyat, hogy figyeljem az SPI2STATbits.SPIBUSY bitet. Ez végülis nekem kerülő megoldásnak jó, mert SPI transzfer előtt amíg ez nem nulla, addig nem adok újabb bájtot a kimenetre, valamint a Chip Select elvétele előtt szintén meg tudom várni, hogy az utoljára beküldött bájt kiérjen. De értelemszerűen jobb lenne, ha ki tudnám használni a 8 bájtos puffert. Majd nyitok valamikor ott egy új témát ezzel kapcsolatban. Lehet jövő hét lesz belőle, de majd beszámolok itt is a fejleményekről.
Más: újabb "hibát" találtam az MPFS2.jar nevű segédprogramban. Meg lehet adni neki, hogy mik a dinamikus fájlok, hogy ezekben a fájlokban keresse a behelyettesítendő változókat. Viszont nem menti le sehová a módosított listát, így következő indításkor ismét alapértelmezett listával indul. Emiatt a bat fájl nemis használható a .c, .h, .bin generálásra. Hol is kell a supportnak írni? Idézet: Pontosabban 16 bájtos... „De értelemszerűen jobb lenne, ha ki tudnám használni a 8 bájtos puffert.” A kihasználásnak nincs akadálya. Hosszas kinlódás után (közben - teljesen fölöslegesen - áttértem a gyári könyvtárakra) rájöttem, hogy működnek ezek a bitek, csak a debugger tohonyasága miatt nem látunk belőle eleget! Végül azt találtam ki, hogy minden írási ciklusban elmentem az SPI2STAT regiszter értékét, s így nyomon követhető az Enhanced Buffer működése. Az első írás előtt '1'-ben áll az SPITBE, jelezvén, hogy üres a buffer. Az írások során ez '0'-ba megy, a TXBUFELM jelzi, hogy hány adat van a bufferben, s valamikor a 24. bájt küldése után bebillen SPITBF bit is. Azért csak ekkor, mert versenyfutás van, a FIFO buffer nemcsak telik, hanem ürül is. A mellékelt programban a periféria busz 40 MHz-re, az SPI órajel pedig 1 MHz-re van állítva. TMR5 állapotát is lementettem minden ciklusban, de nem elemeztem különösebben.
Érdekes gondolat, eszembe nem jutott volna. Pedig arra gondoltam, hátha az mplab a hibás, ezért felraktam a legújabb verziót is, de nem gondoltam volna, hogy a debugger nem olvassa ki ezeket a biteket megfelelően. Ezek után hogy bízhatunk meg bárhol a debuggerben?
  Kösz a segítséget  Idézet: Kiolvassa az, csak kissé fáziskésében van. Addigra az SPI már kiköpte az összes adatot, s a buffer kiürült. Szerintem egy ilyen két dróton rángatott (PGC/PGD) vezérléstől nem várható el több. „nem gondoltam volna, hogy a debugger nem olvassa ki ezeket a biteket megfelelően.” Idézet: Szívesen, pláne, hogy előbb-utóbb én is érintett lehetek ennek a mikrovezérlőnek az SPI kezelésében. :yes: „Kösz a segítséget”
Fura is volt nekem, hogy a TMRx milyen sokat lép, miközben a szimulátorban jóval kevesebbet. Ilyen párezernyit ment arrébb egyik C sortól a másikig. Az a gyanúm, hogy amíg megy a változók szinkronizálása, addig is fut a timer és azért lehetett ez is.
Mintha 16F-18F-nél a debuggolás teljesen leállította volna a kontroller minden belső cuccát, és a Timerek sem futottak az idő alatt. De lehet, hogy rosszul emlékszem.
Sziasztok !
Egy nagyon egyszerűnek tűnő c rutinban olyan programozási hibára akadtam, amiről sejtelmem sincs miért csinálja a PIC. A kódot egy 18F4550 típusú pic-re készítettem, ami egy forgási enkóder jelét dolgozza fel. Működik is szépen, csak mikor eléri a számláló a felső határt, jelen esetben 1000, akkor megbolondul az egész és 768-ra ugrik vissza. Utána ezt az értéket növeli vagy csökkenti öttel, holott a változónak mindig öttel oszthatónak kellene maradni a. Ha felső határt pl. 900-ra állítom be, akkor tökéletesen működik a szabályozó. A segítséget előre is nagyon köszönöm.
A hibát szerintem nem mellékelt programrészben kell keresni. Fordításkor vannak warningok? "stdio.h" benne van? Szerintem valamelyik könyvtári függvény hibásan van meghívva és ezért olyan memóriaterülethez is hozzányúl amihez nem kellene.
PIC18F26K80-ról van szó.
Debuggolom az áramkörömet és írogatom meg rá a programot, de most eljutottam oda hogy meg kellene mérnem hogy milyen időközönként lép be a megszakításba a CCP3 miatt. Elvileg én kiszámoltam hogy 10ms legyen pontosan, de most valami nem stimmel és ezért meg kellene mérnem. Átváltottam hát a debuggert szimulációra (MPLAB SIM), beraktam egy töréspontot a CCP3 megszakítás lekezelési részéhez, megnyitottam a Stopwatch-t és vártam hogy mikor áll meg a töréspontnál hogy leolvassam a stopperon az időt. És itt jött a probléma. Először is az EEPROM-ban lévő adatokat memóriába betöltését végző szubrutinomnál végtelen ciklusba kerül, mert az olvasáskor az EECON1 regiszter RD bitje soha nem esik nullába. Ez nagyon érdekes, mert ha a programomat így ahogy van beégetem a PIC-be és tápfeszt adok neki akkor tökéletesen működik a programom, beolvassa az EEPROM-ból a dolgokat és utána szépen tovább megy. Ha debuggolom a PICKit3-al, akkor is tök jó. Nem baj gondoltam, a lényeg hogy a valóságban működik a programom, a szimulációval pedig most úgyis csak a megszakításba lépések közti idő megmérése a célom. Ezért az EEPROM-ból az értékeket beolvasó szubrutinom meghívását kikommenteztem. Aztán elindítottam újra a szimulációt elölről. Most meg az időzítő szubrutinban akadt el, a "decfsz delay1 goto $-2"-ből nem akar kiugrani. Watch ablak elő, abban látom hogy a delay1 regiszter nem akar csökkenni egyáltalán. Betettem elé egy "banksel delay1" sort, így már nem ragadt benne az időzítésben. Ez szintén érdekes, hiszen a PIC-be égetve vagy debuggolva nincs ilyen probléma, lapváltás nélkül is szépen dekrementálja az időzítő regisztereket. Nem baj, a banksel-lel most megoldva a dolog, jöjjön végre az időmérés! Újra elindítottam a programot és továbbra is b***ik belépni a megszakításba. Watch ablakban megnéztem a GIE, PEIE, CCP3IE biteket, a CCP3 és a TMR1 modulok helyes működését beállító regisztereket de mind rendben van. Megnéztem hát a TMR1 számlálót és lám, nem számol! De miért? Ismét mondom, hogy a valóságban, a PIC-be égetve tökéletesen számol és be is lép a megszakításba, csak itt a szimulátorban nem számol. A beállítás természetesen ugyan az:
Ötlet? 
Szia!
Nem tudom, hogy nálad melyik verziójú MPLAB van telepítve, nálam a 8.63-as verzió van és a szimulátor bár ismeri a kontrollered típusát, nincs tesztelve a helyes működés. Gondolom ez lehet a probléma forrása. Ha esetleg nem a legfrissebb IDE van telepítve, akkor javaslom, hogy telepítsd fel és próbáld ki hátha abban jól működik.
Szia!
8.63 van nekem is. Utána nézek van-e újabb... Szerk.: Van 8.83 is, de a szimulátornál nála is sárga "Y" van. 
A PMP buszhoz 18F67J50 et 48 MHz en hajtom, ekkor az utasításciklusa 12 MIPS lesz. A perifériabusz (Parallell Port) órajele ekkor melyik érték lenne? Én is hajlok arra, amit icserny gondol erről, de a Timing diagramban csak az órajelciklusok vannak feltüntetve. A négy órajelciklus szépen látszik a képen, de mit ért a perifériabusz órajele alatt a példakód nem derül ki. Fura, hogy a PIC 24 PMP doksijában is 4 órajelciklus ad egy utasításciklust, pedig az elvileg két órajellel ez már nála megtörténik. Lásd: Figure 13-13 -tól. Igazsághoz hozzátartozik, hogy a PIC24 esetében "P" vel, míg PIC18 esetében Q val jelölik az órajelütemet.
A 18F67J50 -nél a Figure 2-1: PIC18F87J50 Family Clock Diagram alapján a CPU és a perifériák órajele azonos (nem idle állapotban) és ezt nevezi később Fosc -nak
Waring az nincs, de a fordító két üzenetet írt amit nem szokott egyébként. Íme:
Advisory[1233] Employing 18F4550 errata work-arounds: Advisory[1234] * Corrupted fast interrupt shadow registers Egyébkén szerintem semmi standard library-t nem használ egész számok összeadásánál, kizárólag a fordító" htc.h" állományát, bár én nem vagyok egy spiller a programozásban. Dolgoztam már 18F szériával ,de még a float számok osztásával , szorzásával sem volt semmi gond. Én processzor hibára gyanakszom.
Használsz megszakítást? Az errata -ra utaló ajánlásokat nézd át és az errata -t is. (Bizonyos példányok, bizonyos esetekben elronthatják a gyors mentési tárolók értékét). A fordítót rá kell venned, hogy a magas prioritású kiszolgáló rutinban is programból mentse a regisztereket...
A TMR0.nak valóban van alacsony priolitású kiszolgáló rutinja, de nem tudom mit lehetne tenni vele, hogy megfelelően működjön.
A PICKit2 firmware -ben mindkét megszakítást ugyan arra a rutinra futtatják:
Sajnos ez a pragma direktíva nem jó a HT PIC fordítóhoz, de ha letiltom a megszakítást akkor sem jó. Sőt kipróbáltam ha eggyel növelem a számláló értékét akkor is "elszáll " 1000-nél, vissza ugrik 768-ra. Valami regiszter körül lehet a probléma talán.
Akkor már csak az az ötletem maradt, hogy le kell tölteni az Hitech C - MpLab plugin -t, installálni, az MpLab -ba létrehozni egy projectet és a szimulátoráben megnézni mi is történik.
Nézd meg a Microchip TCPIP demo-ban levő main.c elejét. Ott van valami megoldás.
Ő, a probléma megoldódott, de most aztán végképp nem értem mi történik a pic-ben. Az sprintf számára fenntartott buffer méretét 10 karakterre csökkentettem:
char buffer1[10]; sprintf(&buffer1[0],"DT:%u",counter); Így helyesem működik a program, de mi van akkor ha mind a 20 karakterre szükség lenne. Talán valami hely foglalási probléma lehet a regiszterek körül.
Nos a buffer deklarációját átraktam az enkóder függvény törzsébe, tehát lokális változó lett belőle. Úgy néz ki így nem befolyásolja a változó mérete a program helyes működését. A miérteket nem ismerem, de a program legalább most helyesen fut. A tippeket köszönöm szépen mindenkinek.
Segítségeteket szeretném kérni! Az alábbi képeken egy vezérlést láttok amivel a szemüveg lencséit lehet "szabályozni". (A villogását) A cucc rendesen működik egy dolgot leszámítva. A paramétereket számjegyekben kell megadni "millisecondban". Ezt szeretném megváltoztatni hogy a gombok nyomvatartására változzanak a paraméterek!
Meghálálom aki segít ezt megoldani! Ha netán valaki egy új vezérlést össze tudna tobni azt is megbeszélhetjük...) |
Bejelentkezés
Hirdetés |
