Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Előzze meg a kommunikációs I2C, ISP, Soros cikket?
Üdv.
Megépítettem watt égetőjét, de nem sikerült égetnem vele: -Az konfiguráció látszólag megfelelően működik, a port beállításnál, billeg a Vpp, mclr, data, clock. (az ack-t még nem ellenőriztem, de majd megteszem). -A mclr 12,9V, a Vpp 4,94V a feszültségek stabilak, a cucc 15VDC-s adapterről megy, az 5V-ot mc33063 al állítottam elő, a 13-at pedig zenerrel. -Az LPT kábel hossza 50cm, de a szalagkábel minden vezetéke közé tettem egy GND-t, ahogy a honlapodon írtad. -egy 18f4550-et próbáltam égetni potyo ICD2 hex-ével, de nem sikerült. A pgm lábat (38) 1k-ával a földre húztam. -a pic tápfeszét nem a vpp-re kötöttem, hanem a +5V-ra. A pic azonosítás menüpontban sem sikerült azonosítani.
Van! Mondjuk egy korrekt stopper alkalmazás ami 1/1000-es
 Mert még mindig nem megy nekem  (így nem tudok pontos sebességet számolni )De mondjuk egy LCD-s/grafLCD megjelenítés, vagy egy menürendszer felépítés (3 gomb fukciováltással) bemutatása sem lenne rossz, vagy esetleg némi táblás számítás (pl itt is a HE-n volt egy hőmérős NTC-s nem lineális). vagy külső memóriák eeprom, sd ... stb használata...
Milyen hosszú a kábel az égető és a pic között? Az se legyen hosszú.
Sziasztok, a következőkben kérnék segítséget. Van egy régebben készült pic programom (valamilyen dos-os fordítóval) .OBJ formátumú. Ezt szeretném a PICSTART Plus-sal beégetni, a mit MPLAB sw kezel. Valahogyan nem sikerült a formátumot elfogadtatni vele, sem átkonvertálni .HEX formátumra.
Ha valakinek van ötlete, megköszönöm.
Én is találtam 1-2 dolgot, ami javításra szorúl (igazán nem kötekedni akarok, tetszik amit csinálsz), az első az nagyon fontos:
Idézet: „A 4. és a 8. lépés nagyon fontos. Gondoljunk bele, hogy épp XOR-oltunk két számot, hogy megnézzük egyenlőek-e. XOR-olás végetért, és a STATUS regiszter Zero bitje 1-et, jelezve nekünk hogy tényleg egyenlőek. Igenám, de mielőtt a főprogramban megnézhetnénk, hogy Zero-e, még előtte esik be pont az interrupt és a másodperc növelgetéssel máris felülírtuk a STATUS regisztert, és mikor végre visszatértünk a programhoz és vizsgálnánk a STATUS-t, már rég nem az van benne...” Itt ugye szépen leírod, hogy mekkora hibát követnénk el, ha nem mentenénk ezeket a regisztereket, de az assambler példákban használt módszerrel tulajdonképpen ugyanezt teszed. Idézet: „; Elmentjük a Work és Status regisztereket MOVWF W_SAVE ;Először a Work regisztert MOVFW STATUS ;STATUS-t bele a már lementett Workbe MOVWF STATUS_SAVE ;Status_save-be beletölti a Worköt ; Visszatöltjük a Work és Status regisztereket MOVFW STATUS_SAVE MOVWF STATUS MOVFW W_SAVE ” ez azért van, mert a MOVFW utasítás megváltoztatja a STATUS regiszter Z jelzőbitjét. Elmenteni elmenti az eredeti értéket, azonban visszaállításkor a MOVFW W_SAVE utasítás már felül fogja írni azt. Erre a megoldás a SWAPF utasítás, ami semmiféle flaget nem változtat: MOVWF W_SAVE SWAPF STATUS,W MOVWF STATUS_SAVE SWAPF STATUS_SAVE,W MOVWF STATUS SWAPF W_SAVE,F SWAPF W_SAVE,W Idézet: „Azt figyelembe kell vennünk, hogyha a Timereket kerek egész órajelről (pl. 4 MHz, 10MHz, 20MHz) hajtjuk, akkor soha nem tudunk nagyon pontos másodpercenkénti osztást csinálni, a kerekítések miatt.” de igen (egyes kerek órajelek esetén), ekkor is tudunk nagyon pontos másodpercet előállítani (előosztó megfelelő kiválasztásával és szoftveres korrekcióval), csak valamivel nehezebben.
hát én eddig ugy tudtam, a mov-val kezdődő utasítások nem bántják a status regisztert, és hogy a swapf az pedig az alsó és a felső nibble-t cseréli meg. Most akkor hogy van?
szerk: utánanéztem egy kicsit, és valóban igazad van. A swapf-nek meg egy kis idő kellett, hogy leessen Az időzítésben én sem értek teljesen egyet topi-val, mert lehetséges. Én is megoldottam valahogy, ha jól emlékszem, kiszámoltam, mennyi timer megszakítás után kell korrigálni, és ennek függvényében írtam meg a megszakítást
A másik módszer, hogy minden megszakításban hozzáadunk az adott timer értékéhez egy olyan konstansot, hogy a további osztáskor már ne kelljen korrigálni. Pl. 4MHz-es kvarc 1:1 prescaler és 8bites timer esetén hozzáadunk 6-ot a timer regiszteréhez, és azután csak osztjuk pl. 40-el majd 100-al, hogy megkapjuk az 1 másodpercet.
Én is csináltam már hasonlót. A lényeg, hogy nem osztok, hanem kivonok. És így a különbségek/hibák összeadódnak. De ez hiába működik profin, minden parancs idő...
 Az én pontos timer kódomat használja Deguss a CCS-es cikkében.
Hello!
Nem régiben csináltam egy fejlesztőt 16F84 kontrollerhez. És azt a jelenséget tapasztaltam, hogy megmértem a 4 Mhz-s kvarc frekvenciáját. 3,5 Mhz-t mértem. Ez hogy lehet? Rossz volna a kvarc?
Vagy rossz a kvarc, vagy rossz a mérőd. Tegyél rá egy másik kvarcot, és nézd meg azzal is.
Mondjuk fejlesztőt építeni 18F84-hez szerintem nem volt egy nagy ötlet. Inkább 16F627A-val fejlessz, olcsóbb és többet tud, mint a 16F84.
Nincs is kábel az égető és a PIC között, egy 5cm hosszú tüskesorral csatlakozik a dugdosós panelba az égető nyákja.
Szerintem nem a kábel hosszával lesz a gond, mert ha az lenne, akkor működés közben lennének zavarok. Különben is próbáltam állítgatni a ?kommunikációs sebesség? csúszkát, de még nem sikerült működésre bírni 
Láthatnánk a nyáktervet? (gondolom mivel más alkatrészekkel állítod elő a Vpp-t stb., más nyákot készítettél)
Jó lenne néhány fénykép is, hogy legyen valami fogalmunk a kivetelről. Egy biztos, hogy a hiba az Ön készülékében van! 
Raszteres próbapanelre építettem meg, úgyhogy képzelheted milyen gányolt lett
 . Ha megtalálom a fényképezőt teszek fel róla képet.Most próbálok egy 15cm -es lpt kábelt készíteni hozzá, mert már gőzöm sincs mi a baja, ha kész lesz, beszámolok. A port check-ben pipálgatva billeg mindegyik adat vonal, a data-t billegtetve változik ack értéke is, tehát elvileg jó. Esetleg a PIC-el is gond lehetne, de nem hiszem. Még teljesen szűz, az akció előtt csomagoltam ki. Eddig csak 16-osakkal foglalkoztam, de gondolom a 18f4550-nél is ugyanúgy kell: PGM-et földre húzni egy ellenállással, a többit értelemszerűen bekötve, külső oszci, vagy bármilyen extra nélkül. De végül is miért ennyire érzékeny a kábelhosszra és a vezetékezésre? Gyorsabban kommunikál? Már építettem ProPic2-őt, Tait-ot, és 2m-es kábelekről is simán égettek.
A kábel hossz PC függő. Potyonak megy 1,5m-es UTP kábellel, nekem csak 50cm-es szalagról(igaz, hogy most már az újabb fejlesztésű égetőt használom, ahol a 15m-sem okoz gondot!).
Az a lógó összeszerelés nem biztos, hogy kedvez, bár elvileg működnie kéne. Láttam már rossz 7406-ot is, pedig check-re jó volt! A PGC, PGD alapból milyen szintű? Jól vannak beállítva a fázisok? (bár elvileg nem kell változtatni ha 7406-ot használsz!)
A clock: 125mV, 4,94V
data: 136mV, 4,93V A rövid kábellel is ugyanaz Ha találok másik 7406-ot, akkor még kipróbálom azzal.
Mennie kell, ez ténykérdés! Biztosan minden jól van bekötve?
Sziasztok!
Már hosszabb ideje készítgetek egy programot p18F4520-ra MPLAB segítségével (C-ben). Ahogy bonyolódik a progi, egyre több változóra van szükségem. Most azonban furcsa dolgot tapasztaltam. Az egyik változóm (char State[4]) első karaktere kinullázódik, ha egy másik teljesen független változó értéket kap! Miért lehet ez? Fedik egymást a memória címek? Mert egyébként semmi hibát nem találok benne? Előre is köszi! Üdv.: Zoli
Ha jól gondolom a C fordító a bankokat lekezeli, viszont a megszakítások mentését nem(de lehet, hogy tévedek, és azt is lekezeli..) Egyébb okot nem látok, hogy ilyesmi történjen. Ha asm-ban írnál biztosan Bankolási probléma lenne, de C-ben a fene tudja...
CCS-C kezeli a mentést, C18-ról nem tudom. Én 18F-re is CCS-C fordítót használok.
Lehet, hogy a megszakítás tol ki velem! Ezt alaposabban meg fogom nézni!
Köszi a tippet! 
Na végre működött
 Igaz nem az általad fejlesztett égetővel, hanem a tait féle régi jól beváltal. Ez kedvező, mert nem kell új hardvert építeni, és cserélgetni, hanem elég egy is. Nekem úgyis csak az usb-s ICD2 pic-ét kellene beégetni, és azután csak azt használnám. Amúgy az égető program nagyon jó, mert be lehet állítáni az LPT csat. kiosztását, és más égetőket is lehet használni vele. Az ic-prog 1.05e pedig egy rakás ... , mert égetéskor mindíg kiírta, hogy Verify falied adress 0100h. Csak a 0100 hexáig írta a flasht, utána nem égetett semmit. Idézet: „Igaz nem az általad fejlesztett égetővel,” Azért tisztázzuk, hogy amit összelógattál, az messze volt az "általam fejlesztett égetőtől"! Én tíz perc alatt megtaláltam volna mit toltál el! 
Sziasztok!
Most kezdtem el piccel foglalkozni. Megépítettem Topi 1 robotos cikkéből a második égetőt, és a BIgClock progiját szerettem volna beprogramozni egy PIC16F84A-ba. Az égető a picet felismeri de verifitying failed adress 001h-t ír ki. a progizóm jó, 3 hibát találtam benne, de mind javítva van. soros porton megy. a pic jó. Légyszi segítsetek: Müszi 
Amit már megnéztünk. Feszültségek rendben, kábelhossz is rendben. Látszólag ír is a picbe, illetve írás után ott van benne az adat. Első bájt még jó is, de mint a hibaüzenet is mutatja már a második bájtnál száll el.
Törlés után szépen minden 3FFF.
tehát még mit kell javítani?
a kábel kb 10centi lehet. bocs, de még nemnagyon vágom a témát...
Lehet h hülyének nézel, de mivel még nem foglalkoztam az eletronika ezen részével nem foglalkoztam, ezért félek tőle.
Én persze látva az áramkört arra gyanakodtam. Igaz hogy rövid kábellel oldottad meg, de az egész égető légszerelésű. Levegőben összeforrasztgatott áramkörben hibát keresni, és annak stabilitását és zavarszűrtségét vizsgálni, majdnem egyenlő a fejlövéssel...
Mivel éget, csak hülyeséget ezért tuti hogy valami fizikai jelzaj van rajta. Amit egy rosszul beforrasztott felhúzó ellenállás is produkálhat.
Akkor holnap kap egy új nyákot, akkor jó lesz?
nem légszereléses, hanem rednes nyákra építeném... |
Bejelentkezés
Hirdetés |
