Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Idézet: „Szkóppal már figyeltem a jeleket, határozott, jól látható váltások vannak az események függvényében.” Bár ebből nem derül ki, hogy mi a feladat, de erős a gyanúm, hogy ezt legegyszerűbben analóg technikával lehetne megoldani. De ez nem az a topik...  PIC helyett inkább dsPIC-re való a feladat, ha mégis digitálisan akarod kezelni a nem is tudom mit. Gondolom, valamilyen algoritmussal szoftveresen kell megvalósítani azt, amit analóg módon egyszerűbben is megcsinálhatnál. (sávszűrő, integrátor, komparátor, tudomisén...) Idézet: „Ezt úgy igértem, hogy január végére elkészül.” Melyik évben?  A mostani kicsit szűkreszabottnak tűnik, ha még ennyire kezdetleges állapotban van a tervezés is. Gondolom, a nap neked is csak 24 órából áll...
Hali!
Vázolom a helyzetet: Megépítettem a Topi-féle PIC programozót, 16F877-et szeretnék vele programozni. Naszóval, amikor feltelepítem az ICProg-ot, akkor a beállításnál a JDM programozóknál nem tudom egyik COM portot se kiválasztani. Olvasásnál befagy a gépem, reset után átállítom az Interface-t Windows API-ra. Na ekkor már be tudom olvastatni a PICet, csak nem 3FFF-eket ír ki, hanem 0000-kat. Égetésnél viszont ezt a hibaüzenetet dobja ki: Verify failed at address 0000h.  A programozást jelző LED meg folyamatosan világít az első olvasás után, meg akkor is, amikor nem csinálok semmit...(se olvasás, se írás) Topi utasítása szerint átnéztem a kapcsolást, nyákot (csináltam másikat), beültetést, COM csatlakozó bekötését, és minden OK...  Kezdő PIC-es vagyok, mire véljem a helyzetet?? Elöre is köszi: Noja
Kérlek olvasd el ezt: - Miért ne építsünk JDM-et? -
Szóval akkor azt mondod, hogy azt amit most építettem, azt jobb kézzel bal váll fölött dobjam el jó messzire, és építesm meg ezt??
De ezzel tudom programozni a 16F-es szériát??
Ha már JDM, akkor használj hozzá WinPic-et. Ez a program korrekten kezeli a JDM-et, 100%-osan éget és 10x gyorsabb az IC-prognál. Az IC-prog ilyen hibákkal száll el, 10-ből 5-ször nem éget és lassú. WinPic-cel nem lesznek ilyen gondjaid. De előtte korrekten be kell konfigurálni. Persze gondolom az a JDM külső tápos legalább...
Nem reklámozom a JDM-et, csak ha már az van neki és nem akar másikat, ez megoldás lehet a gondjára
Igen, igen... :yes:
Labortápról üzemeltetem...
Szia vizor!
Kélek Te is olvasd el amit linkeltem, mert lehet, hogy neked működik neki nem! De azért megpróbálhatja amit írtál, ha már úgy is megépítette, reméljük működik, és nem tesz tönkre vele néhány PIC-et, ha véletlenül nem. Idézet: „Szóval akkor azt mondod, hogy azt amit most építettem, azt jobb kézzel bal váll fölött dobjam el jó messzire” Én még akkor is azt mondom, ha netán még működik, de azt hiszem elég egyértelműen kiderül, mire tartom ezt az áramkört. Mire gondoltál, mikor azt írod, hogy: Idézet: „és építesm meg ezt??” ?
Azt az LPT-st, amit linkeltél...
Ha tudja pogramozni a 16-os szériát, és a JDM nem fog működni, akkor meg fogom építeni...
Nézz fel az - oldalamra - van néhány égető, válogathatsz. Ha van már tápod, akkor az oshont ajánlom!
- Itt - találsz egy pár ajánlást, amiket egybeszedtem, talán könnyebb választani. Ha már lesz egy működő égetőd, következő lépésnek ajánlom figyelmedbe a két klónt is(szilva és watt féle PICKit2).
Üdv !
Már olvastam régebben is, nem vitatom a dolgot és teljesen egyetértek. Ezért írtam, hogy "Ha ragaszkodik a JDM-hez, stb.". A kérdés speciálisan a JDM kapcsolásra irányult, amire a WinPic a megoldás. Ettől függetlenül valóban jobb ha épít egy jobbat, de ez már az ő dolga Jelenleg én is egy olyan égetőt szeretnék összehozni, ami a Te linkeden van, elég szimpatikus és nem is olyan bonyolult. Idézet: „A kérdés speciálisan a JDM kapcsolásra irányult, amire a WinPic a megoldás.” Nem akarok ezen rágódni, ne vedd szívedre, de ha a COM port nem tudja feldolgozni a 0V-ot, akkor a JDM-re még a WinPic sem megoldás.
Vizor, Watt, köszi szépen a segítséget...
 Nem jutottam sokkal előrébb, mint ahol délbe tartottam, dehát ilyen az ember szerencséje... Lehet h utánépítem a PICKIT2 Klónt, de lehet h megveszem, még nem döntöttem el igazán... Mégegyszer köszi, srácok! Még annyit fűznék ehhez a JDM-témához, hogyha egy kapcsolás nem biztos, hogy működik, akkor minek tette bele a szerző a cikkjébe?? Nem akarok litániát írni, de egy ilyen kudarc után csak azért nem adom föl a PICezést, mert rohadt nagy bennem az akarat és az elszántság, de mi lesz azokkal, akik ezek után megépítik, mert hisznek az 5 pontban, és ugyanúgy kudarcot fognak vallami a JDM-mel, mint én?? (csak azt akarom sugallni, h lehet módosítani kéne a cikken....  )Üdv: Noja Idézet: „csak azt akarom sugallni, h lehet módosítani kéne a cikken...” Nyugtasson meg a tudat, nem te voltál az első. Idézet: „Még annyit fűznék ehhez a JDM-témához, hogyha egy kapcsolás nem biztos, hogy működik, akkor minek tette bele a szerző a cikkjébe??” Néhányszor már mondtuk neki is, de mégse vette ki. Valamit sumákolt, hogy odaírta, hogy nem minden esetben működik, ahelyett hogy nagy piros betűkkel kiírná, hogy csak néha működik. Egyébként a közzétett kódban is volt régebben hiba a megszakításkori w és status regiszterek mentésekor, amit akkor és egyszer később is szóvá tettem neki. Igéret volt rá, hogy ki lesz javítva, de akkor nem lett. Azóta nem néztem, lehet, hogy még most sincs kijavítva.
Watt: dehogy veszem a szívemre
Ha lehet én is igyekszem a legjobb megoldás felé haladni, bár ez nem mindig sikerül maradéktalanul Potyo: a W és STATUS regiszterek mentésénél arra gondolsz, hogy a két nibble felcserélésével (SWAPF utasításokkal) kellene elmenteni ? A STATUS-t swap-olva elmenteni és swap-olva visszaállítani, a W-t meg simán elmenteni és kétszer swap-olva visszaállítani, az adatlap szerint. El tudnád magyarázni, hogy erre pontosan miért van szükség ? Idézet: „El tudnád magyarázni, hogy erre pontosan miért van szükség ?” A megoldás a műveletek hatására megváltozó STATUS bitekben rejlik(adatlap parancsok). Ha ugyanolyan STATUS állapottal akarsz kilépni a megszakításból, akkor nem ronthatod el pont a mentéssel!
Aha, a STATUST így értem, köszi !
De a megszakítás után a W kétszeri swap-olására miért van szükség ? Azt se elég csak úgy kiemelni a temp regiszterből ? Elmentve simán volt. Lehet, hogy nagyon amatőr kérdés, de én az is vagyok
Ez a kilépés:
Ha megnézed, először a STATUST állítja vissza, amit utána nem lenne jó egy MOVF f,W-el elrontani. A SWAPF nem állítja a STATUS biteket A MOVF állítja a Z-t.
Nagyon köszönöm !
Erre nem gondoltam volna Valóban, alighogy visszaállítanám a STATUST, már el rontanám Úgy látom, van még mit tanulnom. Főleg az utasítások hatását a STATUS bitjeire.
Még annyit ehhez, hogy a 18F-eknél ez is sokkal egyszerűbben megy, mert van MOVFF...
...és a megszakításnál maradva: WREG, STATUS és BSR regiszterek "automatikus" mentésének, ill visszatöltésének lehetősége...
 Idézet: „Még annyit ehhez, hogy a 18F-eknél ez is sokkal egyszerűbben megy, mert van MOVFF...” Sot, ott a WREG, STATUS es BSR automatan elmentodik, igy azokkal - ha csak egy szintu interruptot hasznalunk - nem kell torodni... Ja, es az enhanced-mid-range -nel pedig ha jol ertelmezem az adatlapot tobb szintu modon van ez a fast context savings megoldva, majd ha sikerul egy darabol a kezembe kapni kiprobalom
Ezügyben érdemes az adott chip errata-ját is megnézni, mert egyes revízióknál volt probléma a RETFIE FAST visszatérésnél, és emiatt nem lehetett használni a hardveres mentést.
Idézet: „Sot, ott a WREG, STATUS es BSR automatan elmentodik, igy azokkal - ha csak egy szintu interruptot hasznalunk - nem kell torodni...” Bevallom ez nekem új. Én mindig elmentem amit kell, ezért nem is néztem, hogy van ilyen. Potyo közben írja, hogy nem is mindegyikben műkszik jól, na akkor én maradok a régi vágányon. Idézet: „Ezügyben érdemes az adott chip errata-ját is megnézni, mert egyes revízióknál volt probléma a RETFIE FAST visszatérésnél, és emiatt nem lehetett használni a hardveres mentést.” Ja igen, a dupla szavas utasitasok koruli nyug, mikor is pl MOVFF-nel ha a cel regiszter WREG, STATUS, vagy BSR, akkor ezt a fast savings elronthatja a tartalmat. Elmeletileg lehet hasznalni ill van ra workaround mind C es ASM nyelvekben - kis atveressel az igazi ISR-t meg kell hivni CALL FAST-tal es utana leszedni a stackrol annak visszateresi erteket. Emiatt a context saving megtortenik helyesen es a visszateres is jo lesz mivel a CALL FAST cimet leszedjuk. Termeszetesen ha ugyelunk arra, hogy ne MOVFF-ezzunk WREG-be ill STATUS-ba akkor minden ok es nem kell a woraround. Idézet: „Bevallom ez nekem új. Én mindig elmentem amit kell, ezért nem is néztem, hogy van ilyen. Potyo közben írja, hogy nem is mindegyikben műkszik jól, na akkor én maradok a régi vágányon.” Amit nyerhetsz ezzel az az interrupt latency csokkentese, amugy teljesen mindegy velemenyem szerint.
Ez a hardveres mentés, hány programciklus alatt zajlódik le? Hová mentődik? Ja és mind a két prioritású megszakításnak van külön rekesz fenntartva? Vagy RAM-ba megy? (Ha már úgy is megnézted, ne kelljen kiböngésznem..
)
Van számára külön terület a hardverben, és úgy emlékszem, nem igényel plusz ciklust, lezajlik akkor, amikor a rutinra ugrik. De csak a magas szintű megszakításnál mentődik el, illetve csak akkor állítódik onnan vissza, ha a RETFIE FAST utasítást adod ki a visszatérésre a végén. Ha csak RETFIE-t adsz ki, akkor nem állítódik vissza. Az ezzel kapcsolatos problémának is az a megoldása, hogy a rutin elején elmenteni, és a végén kézzel visszaállítani, majd csak egy RETFIE parancsot adni ki, hogy ne próbálja visszaállítani az automatikus mentésből.
Aha, értem, köszi! Ez akkor amolyan félmegoldás(főleg, hogy még hibás is). Ennyi erővel akkor a low megszakításhoz is tehettek volna ilyen vermet, és megoldhatták volna a kétszavas utasítások problémáját is! A 16biteseknél már ilyen gond nincs, ott vektoros az INT. Nagyon kényelmes. Még ASM-ban is egyszerű a megszakítások lekezelése.
|
Bejelentkezés
Hirdetés |
