Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Így logikus. Nem néztem mélyebben utána, de így használtam, amikor -ref feszt használtam. Eleve akkor szoktak -ref feszt használni, mikor GND-nél nagyobb. Ekkor elég nehéz lenne GND-hez képest mérni a feszt. Tehát nem biztos, de elég valószínű.
A FET-ek a 2 cellás LiPo-ról mennek közvetlenül tehát 6-8,4 V körül kapnak. A FET driver pedig arról a charge pump ról kapja a tápot ami az aksiról közvetlenül működik tehát valamivel kevesebb mint 12-17 voltal táplálja a FET-drivert. De mondjuk visszatérve a PIC-es témára, a PIC mindkét lába (RE3, RE4) alacsony szinten marad ezt elég egyszerű kimérni, és ez az amit nem értek hogy miért, de tényleg köszönöm a tippeket volt egy-kettő amire nem gondoltam.
Ja értem már, én azt hittem, hogy a nyers fesz magasabb! Így jó lehet! A fura az, hogy ha direktben kapcsolod a kimenetet, akkor jó! Nem hiszem, hogy a ECCP modul belül lenne rossz! HA igen, azt szerintem még a gyárban is kicserélik és kettőt adnak helyette!
 
Ez egy apróhiányosság, én is láttam, de tulajdonképp a gyárilag ajánlott híd is így néz ki a PIC adatlapban. Ilyenkor az történik, hogy a felső FET-ek source-követőként viselkednek, és a G-S között kialakul az a nyitófeszültség, ami a terhelőáram áteresztéséhez kell a FET-nek. Ez tipikusan pár V szokott lenni, ha megfelelően kis nyitófeszültségű FET-et választunk (pl. IRLZ), akkor elhanyagolható.
Persze az igazán korrekt vagy a FET-meghajtó lenne, vagy "felülre" P-FET-ek beépítése, természetesen ilyenkor az azokat vezérlő kimeneteknek invertáltaknak kell lenniük.
Én megpróbálnék még egy másik ECCP modult, mirlőtt PIC-et cserélek. Lehet, hogy tényleg silicon-bug lesz, és a cseredarab is ugyanezt fogja csinálni. Mert a kódból, az adatlapból meg az lst-ből kiindulva nagyon úgy tűnik, hogy azt kellene csinálnia, amit Te is elvárnál tőle.
Szerk.: még az jutott eszembe, hogy azokon a kimeneteken nincs-e véletlenül valami alternatív funkció, ami bezavarhat a működésbe? Bocs, de ennek nem néztem utána, csak bevillant, hogy láttunk már ilyet is. Idézet: „de tulajdonképp a gyárilag ajánlott híd is így néz ki a PIC adatlapban.” Az csak egy elnagyolt elvi rajz. Ha a FET nincs redesen kinyitva, túl fog melegedni. Persze apró motornál ez nem történik meg...
Jó hírem van a probléma megoldódott. Szerintem érdekes hogy hogyan ezért leírom részletesen. Ez a PIC18F66J55 ugyanabba a kontroller családba tartozik ahova a nagyobb testvére a 80 lábas PIC18F86J55. Elvileg a kettő ugyan az de az egyik 80 láb a másik 64. Azonban 80 lábas kontrolleren az ECCP3 (jelen helyzetben nem működő) két lába programozható hogy a H vagy az E portra kerüljön, ugye H portom nekem nincs én a 64 lábút használom. Ugyanakkor az is programozható, hogy egyes lábak külső memória buszt alkossanak-e vagy ne és ez is érinti a két kritikus lábat. Mindezen beállítások a Config bitek állítgatásával érhetőek el. Én nem foglalkoztam ezekkel a dolgokkal tekintve a kontrolleremben az adatlap szerint ezek a funkciók nincsenek benne. Azonban jött az ötlet és a projektet átkonfiguráltam úgy hogy azt higgye az MPLAB és a C fordító, hogy egy PIC18F86J66-ost szeretnék programozni. Ugye itt a kódban a megfelelő config biteket beállítottam (különös tekintettel azokra, amik a 80 lábú problémákkal függenek össze) és felprogramoztam a kontrollert mintha ő egy 80 lábú lenne. A PicKit-2 egy warning –on kívül hiba nélkül felprogramozta a kontrollert. És működött szépen csinálta amit kell. Sőt ezután a projektet visszakonfiguráltam az eredeti kontrollerre, és így ismét rátöltve a progit ismételten működött. Köszönöm még egyszer a beszélgetést watt-nak és szilva-nak kaptam néhány ötletet, ami végül ide vezetett.
Ugye mondtam, hogy nem rossz, a PIC!
Nem semmi történet! Gratulálok a megoldáshoz!  Ja igen! A szimulátor meg eláshatja magát, jelen esetben!
Gratulálok, hogy sikerült elcsípni a hibát!
Egy kérdésem lenne: a config biteket az MPLAB config editorával állítottad-e vagy a forráskódban vannak benne?
A PIC az A/D átalakítást szukcesszív approximációval oldja meg. Ennek során bitről bitre (a legmagasabb helyi értékűtől a legalacsonyabb felé haladva) előállít egy analóg jelet a belső D/A-jával (kapcsolt ellenálláslétra), és ezzel hasonlítja össze az analóg bemeneten lévő jelet. Az összehasonlítás eredményeképp eldől, hogy az adott ciklusban vizsgált bit magas vagy alacsony lesz-e. Mivel a külső Vref-ek használatával a belső D/A ellenálláslétrájának alsó és felső pontján lévő feszültséget állítod be, így ilyenkor nincs köze az összehasonlításnak a GND-hez.
Ugyan nem próbáltam még külső referenciát használni, de azt kell gondoljam, hogy ilyenkor sokkal kevésbé szabad zajosnak lennie a mérésnek, mint a Vss-Vdd referencia használatánál. Természetesen a Vref- és Vref+ értékekre meg kell nézni az adatlapot, hogy mik között mozoghatsz, sőt, a (Vref+)-(Vref-) érték is adatlapban meghatározott tartományba kell, hogy essen. Azt hiszem, sokan örülnénk, ha megosztanád itt, ha lesznek gyakorlati tapasztalataid etéren.
A kódban adtam meg. Ugyanakkor pontosítanám az előző hozzászólásomat. Nem állítottam vissza teljesen a projektet, a C kódban a 86j55-ös header fájlt hagytam benn. Tovább nézegettem, hogy mi lehet és kiderült, hogy a 66j55-ben az elvileg nem implementált config biteket a C fordító 0-nak veszi ha a 66j55 van beállítva a C fordító számára. Azonban ha a 86j55 akkor 1-nek veszi. Megnézve az egyes bitek jelentését 1-be kellene beállítani őket ahhoz hogy jól működjön a 80 lábú. Elvileg jól kéne működni akkor is ha 0-ba vannak állítva a 64 lábú PIC-en, mivel ott nincsenek implementálva ezek a funkciók de mégse működik jól...
Próbaképp csináld meg a projektet a 18F66J55 header fájljával, majd zárd be a projektet, válaszd ki a 18F86J55-öt a select device alatt, majd import-al olvasd be az előzőleg elkészült hex fájlt, és csak módosítsd az említett, 18F66J55-nél nem létező konfig biteket, és exportáld hex-be, majd írd be a kontrollerbe 18F66J55-ként. Lehet, hogy elvileg nem létezik az a config bit, viszont a hardverben meg mégis benne van?
Kedves urak!
Az alább látható mintaprogram a gyakorlásom része, hibátlanul működik szimulálva és élesben próbapanelen is. A kérésem csak az lenne, hogy "MEO-zzátok le"  , és ha láttok olyant amit szerintetek kerülendő, akkor nyilatkozzatok, bármilyen észrevételt szívesen fogadok.Tehát:
Köszi!
Szia!
Ami "megütötte" elsőre a szememet az az A2 feltöltése a GOTO DEL-el! Ha direkt csináltad, akkor OK, de egyébként enélkül is működik, mert 0 után a következő kivonáskor 255 (-1) lesz a tartalma! A másik: a BANK váltásnál célszerű a BANKSEL makrót használni! Steve
A config megadásánál érdemes az inc fileban megtalálható definíciók logikai és kapcsolatával (&) megadni a kívánt konfigurációt, az sokkal beszédesebb, mint egyetlen hexa érték. Másik PIC-re portoláskor is hasznos segítség, mert lehet, hogy hozzá sem kell nyúlni a confighoz, hiába vannak a másik típusnak máshol az adott beállításhoz tartozó config bitjei. Ha mégis hozzá kell nyúlni, akkor is a beszédes nevek alapján sokkal egyszerűbb dolgod lesz.
Az interruptban a context mentés és -visszaállítás nem megfelelő, nézd meg az adatlapot erre vonatkozóan! Szintén ehhez kapcsolódik, hogy a mentésre használt tárhelyeket érdemes bankfüggetlen területen kijelölni. Egyebekben jól olvasható, átlátható a kód.
Ja, elfelejtettem mondani, hogy a késleltető rutin koppintás, de igazad van, nem nagyon néztem át, működött, így használni kezdtem,
több gyakorló programomban benne van.Ezzel a bankváltással kapcsolatban normális dolog, ha a fordító pár warning kíséretéében közli velem, hogy "Register operand not in bank x"? Konkréten BANK0-ra érti.
Szia!
Pokoli nagy szerencséd van: A programodban alig használod a STATUS bitjeit, csak a C értékére van szükséged néha, a megszakítási rutin pedig nem állítja át. Ha bele kellene tenni egy kis módosítást, ami a Z bit értékét is felhasználná, már nem is működne jól.... Csak a továbbfejlesztés és a tiszteséges mentés miatt: A 13. sor utánra és a 10. sor helyett:
Ind.: A 0x70-7F címtartomány minden lapról ugyanazt a 16 regisztert éri el (common bank). A 20. és a 21. sorok közé:
Ind.: Már egy movf IRANY,w elrontja a Z bit értékét.... A 26. sor utánra:
A 27. sor helyett:
Ugyanis: Tegyük fel, hogy a továbbfejleszett programodban a következő rész van:
A megszakítás a xorwf PR2,f utasítás után jut érvényre: A kiválasztott bank az 1. bank, a megszakítási rutinod az 1. bank változóival végez műveletet, nem a 0. bankon definiáltakkal. A movf IRANY,w beállítja a Z bitet, aszerint, hogy az IRANY értéke 0 vagy sem. A visszatéréskor a movf WSAVE,w megint mást állít be a mentett W értéke szerint. A visszatérés után mi szerint döntson a feltételes elágazás. A megszakítási rutin mentési feladatainál azt kell szem előtt tartani, hogy a bárhol bekövetkező kiszolgálás (a szándékosan végzett adatállításokon kívül) biztosítsa, hogy a megszakítás elötti állapot álljon vissza. És még szerencse, hogy a 16F628-ban csak 2K programmemória van, a nagytestvérben 16F648A (már 4K) még a PCLATH regisztert is menteni - visszaállítani kell, ha a kód mérete > 2K. Szia
Igen, azzal csak figyelmeztet, hogy az adott regiszter nem a nullás bankban van, és neked kell külön gondoskodni a megfelelő bankról. A fordító nem ismeri fel a program folyását, hogy éppen az adott helyen jó bankot állítottál-e be, így inkább figyelmeztet. (Ezt a figyelmeztetést ki is lehet kapcsolni valahogy, de én lustaságból nem szoktam foglalkozni vele.)
Urak, valoszinuleg en nezek el valamit es nagyon keso is van , de mintha a CAN bus inicializalasa hibas lenne a PIC 18F2580 es 2680 adatlapokban is...
Azt irja, hogy akkor van config modban, ha B'100xxxxx' -t irunk a CANCON regiszterbe, majd a CANSTAT regiszterbol lehet ellenorizni, hogy tenyleg annyi-e. Az adatlap gyari peldakodja erre: WaitConfig: movf CANSTAT, W andlw '10000000' tstfsz WREG bra WaitConfig Szerintem meg ez a rutin a 7. bit 0 volta eseten fog kiugrani a varakozo ciklusbol, nem? Vagyis pont az ellenkezojet csinalja, de elgepeles nem lehet, mert tstfsnz utasitas nincs a PIC-ben.
Szia!
Elgépelés 1. sorral fentebb is lehet : xorlw '10000000'... Szia
A figyelmeztetéseket ki lehet kapcsolni, mert különben mindig írja és a tényleges hibát nagyobb programnál már keresgélni kell a sorok között!
A megszakítást nem néztem, tényleg hibás, ahogy a többiek írták, én az adatlapból szoktam "bekopizni" az idevonatkozó részt és kiegészítem! A szimulációt ha alaposan végzed, akkor ezek azért kiderülnek !Steve
Koszonom, de nem valoszinu, mert a tobbi bit 0 ertekeben nem bizhatunk. Esetleg akkor egy sor kimaradhatott - pont az, amit irtal.
Köszi! A DS1307-nél maradok akkor.
Más: Srácok lenne egy érdekes kérdésem, ami lehet hülyeség, de hátha van ilyen... Előfordulhat az hogy egy LPT-s égető hibádzik égetéskor, és egy funkció nem úgy működik ahogy kéne? Persze a verify lefut rendesen. Ezt azért kérdezem, mert tisztán emlékszem, hogy egy bizonyos óra projektnél volt egy olyan gondom, hogy 23:59-kor nem nullázott, hanem számolt tovább 24-el. (24:01-02-03......) Akkoriban LPT-n keresztül égettem. A forráskódban a "timekeeping"-be pontosítottam, és utána jó lett. És most jön az érdekesség! PICKIT2 clone-al programoztam a mai nap azt az eredeti forráskódot, ami ezt a hibát művelte. (tutira a hibás, eredeti) És láss csodát evvel égetve nem produlkálja azt a hibát. Létezhet ilyen???
Nem, ilyen nem lehet. Vagy össze kevered a hex file-okat vagy épp nem jött elő a hiba valami oknál fogva. Keresd tovább a hibát és ne pazaroldd az energiad felesleges dolgokra
Én is csodálkoztam volna, ha ez miatt...
Hmmm! Na az van hogy az eredeti tényleg hibázik, de csak akkor ha egy ideje megy az óra. Én tegnap úgy néztem meg hogy bekapcsoláskor 23:59-re állítottam, és akkor még jó volt. Viszont ha eltelik egy kis idő, akkor már nem. Magyarán ha beállítottam 23:30-ra és fél órát vártam, akkor már gond volt. Érdekes egy hiba. Az általam átírt le van egyszerűsítve, amivel működik is rendesen. Nyilván evvel nincs tovább foglalkozni!
Geri12!
Használd légyszíves a válasz gombot, hogy tudjuk kinek válaszolsz. Köszi!
Igazán köszönöm, hasznos levezetés! Amint újra leülök mellé, átrágom magam rajta.
A swapf utasítás eszembe se jutott, nem tudom miért, de majd odafigyelek, hogy igyekezzek a lehető leghatékonyabb módszert alkalmazni. Hátravan még a Flowcode alkalmazás megismerése, de ami késik, nem múlik.
Ez pl. lehet megszakítási rutinban hibás regisztermentéstől is.
Üdv!
Olyan problémával találkoztam, hogy a wörkbe teszek egy értéket, majd meghívom a táblát, viszont ott nem a megfelelő sorra ugrik, hanem teljesen máshova. Mplab szimulátorban néztem. A vicc az, hogy ugyan úgy használom a táblát, mint előtte a programban. CIMKE ADDWF PCL,F RETLW 0X01 STB.. ... ... ... cimke2 movlw 0x00 call cimke ... Az első táblát amikor elkészítettem, hasonló problémám volt, viszont nem tudom, hogy azt, hogyan oldottam meg, egyszer csak ment. 16F887 És ha van valakinek olyan ötlete, hogy hogyan kellene megvalósítani egy lefelé számláló órát, az adhatna egy kis tanácsot, mert nem akar menni  ty |
Bejelentkezés
Hirdetés |
