Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
A logikai 1, az logikai 1(Vdd*0.x), de értem mit akartál mondani! A belső felhúzók is szerintem nem véletlenül nem lehúzók, úgy hogy ez is jó meglátás.
Igen, biztosan ebből ered, és lehet, hogy megszokás, viszont jól működik, ezért nem érdemes megváltoztatni, csak ha jó indok van rá.
Ugy emlexem, hogy az egyik elony, hogy igy a periferia bekapcsolt allapota tesztelheto, mivel a gomb mukodese jellegzetesen pillanatszeru, igy ha tartosan van alacsony szint a bemeneten, akkor vagy nincs a periferia jol csatlakoztatva vagy zarlatos a gomb. Ilyenkor hibauzenetet lehet adni
Sziasztok!
Mitől van az hogy megáll a PIC és nem is indul el csak ha hozzá nem érek valamelyik alkatrészhez? Próbapanelen van összerakva, belső oszcillátorról megy. Tud valaki segíteni? A kifejezés egyik fontos eleme a helyesírás. Sajátítsd el! dgs.
Szia!
Egy nyomógomb esetén ennek nincs jelentősége CMOS rendszerben. (A TTL áramköröknél az 1.6mA (normál), 2mA (S) és 400uA (LS) alacsony szintű bemeneti áram miatt a felhúzűs egyszerűbb volt és a zajtartalék is nagyobb volt, hiszen a komparálás 1.1 - 1.4V körül volt.) Sokkal inkább előjön a probléma, ha nem nyomógombot, hanem egy másik rendszer kimenő jelét kell illeszteni. Föleg azoknál, aminek megengedett a táp kikapcsolása is. Ekkor a két rendszert nyitott kollektoros / nyelőelektródás kimenettel és a fogadó rendszer tápjára felhúzott bemenettel kötik össze. Ekkor, ha a jelet átadó rendszernek nincs tápja, a bemenetet nem tudja alacsony szintre húzni, ha a fogadó egységnek nincs meg a tápja, akkor a felhúzó ellenállás nem terheli meg az adót. Ellenben: Ha a bemenet aktív magas szintű és a földre menne az ellenállás, akkor ha a vevőnek nincs tápja, és az adó magas szintet szeretne, a jel vezetékre rákapcsolódik a vevő tápvonala a beépített védődiódákon keresztül. Ez egyrészt túlterhelheti az adót, másrészt meg nem engedett üzemmódot eredményezhet a vevőnél. (Pl. a táp stabilizátor kimenetén feszültség jelenik meg, amikor a bemenetén nincs meg a feszültség.) Azt az elemet, aminek a védődiódáján átfolyik az áram, tönkre is teheti. Hasonló okokból terjedt el az aktív alacsony reset megoldás is, hiszen a nyitott kollektoros kimenet már 0.7 - 1V táp esetén fenn tudja tartani az alacsony szintet a reset vonalon...
Szia!
A hidegítő kondenzátor hiányától, a MCLR láb lebegéssétől, a szűretlen tápfeszültségtől ....
a tápot a pickit-ről kapja az elvileg nem lehet gond, az mclr láb lebegésén mit értesz? illetve hidegtő kondit hova kellene raknom?
Szia!
- Egy 100nF kerámia kondenzátort közvetlenül a pic táp és föld lába(i) közé kell tenni, amilyen rövid kivezetésekkel csak lehet. 40 lábú tok esetén mind a két oldalra 1 - 1 darabot. Ha több táp és föld lába van, akkor azokat mind be kell kötni. - MCLR lábat a tápra kell húzni 10k ellenállással vagy a konfigurációs szóban le kell tiltani. - Ha az alacsony feszültségű programozás (LVP) engedélyezett, akkor a PGM lábat alacsony szintre kell húzni ellenállással. Hogyan lehet néhány fontos, sokszor előkerülő tippet a topik fejében megjeleníteni, mint ahogy az "AVR - Miértek, hogyanok..." topiknál van? Idézet: „- MCLR lábat a tápra kell húzni 10k ellenállással vagy a konfigurációs szóban le kell tiltani.” Csak kiegészítésképp, ha kikapcsoljuk a konfigurációs szóban, akkor is határozott potenciálra KELL húzni, mert egyrészt felesleges fogyasztást okoz, ha egy bemenet lebeg, másrészt ha a potenciálja felmegy 7-8V fölé, akkor belép programozási üzemmódba és ettől is resetelésszerű jelenségeket produkál. Ha a lábra nincs egyébként szükség, akkor inkább érdemes MCLR módban hagyni (némelyik chipen ekkor van belső felhúzó is, tehát kívülről akár lebegve is hagyható - pl. 12F683 ilyen). Ha meg szükség van a lábra, akkor meg a külső áramkör fogja határozott potenciálon tartani a lábat.
Szerintem minden normális picben ha ki van kapcsolva az mclr akkor aktivizálódik a pullup. Legalábbis én még nem találkoztam másfélével.
Ha az MCLR-t kikapcsolod, akkor most így hirtelen nem találtam adatlapot, ami szerint bekapcsolna bármilyen belső felhúzás csak attól, hogy az MCLR-t tiltottad a konfigurációs bitekkel. Olyan van, amiben van bekapcsolható felhúzás az MCLR lábon, ehhez viszont a kontrollernek el kell indulnia, ami nem teljesen biztos egy lebegő MCLR lábbal (ugye a saját farkába harapó kígyó esete).
A bekapcsolt MCLR felhúzása úgy tűnik, hogy az újabb kontrollerek mindegyikében van. Ezzel szemben sok kedvelt tipusból (pl. 16F628A, 16F877A, 12F675, 18F4550, 18F97J60, 18F1320) hiányzik, így mindenképpen az adatlaphoz kell fordulni a pontos információért. Viszont az univerzális megoldás továbbra is egy 10k felhúzó az MCLR lábon, és akkor akármilyen kontroller, akárhová állított MCLR lábbal el fog indulni.
Mond! Ha már egyszer figyelmeztetnek is rá, Te akkor is direkt, széllel szembe?
Nem, csak sajna később vettem észre hogy rám szóltak.
Rendben.
Sziasztok!
Egy nagyon furcsa hibával találkoztam. A Release-módban hibátlanul futó program Debug módban néha egyszerűen megáll. (Azért nem váratlanul. Mindig olyankor áll le, amikor egy, a gépre soros porton csatlakoztatott eszközt lekapcsolok. De az eszköz leállítása nem lövi le mindig a Debug-módot. Remélem, értitek, mire gondolok. Bocs a kacifántokért.) Arra gondoltam, hogy a sorosporti eszköz kikapcsolása valahogy (vagy a hálózaton, ami nagyon valószínűtlen, vagy a soros porton, aztán onnan az USB-n, ami szintén nagyon valószínűtlen, de valamelyiknek a kettő közül kell a hibásnak lennie) egy kis feszültségingadozást okoz a rendszerben, ami reseteli a PIC-et. Ez a Release-módban nem okoz gondot, de a Debug-módot esetleg megállíthatja. Ebben szeretném a segítségeteket kérni: Lehetséges, hogy a Reset a Debug-ot lefagyasztja? Az a baj, hogy nem tudok napi szinten hozzáférni a rendszerhez, ezért jó lenne, ha abban a rövid időben, amíg dolgozni tudok vele, nem vakvágányom keresném a hibát. Sajnos a Debug-módban nincs tapasztalatom, nem tudom, hogy az MPLab in-circuit debuggere mit reagál egy reset-re, de hálás lennék, ha valaki megmondaná...
Helló! Mplab8.20a-val dolgozom, és a következővel szembesültem. 30f2010-et szerettem volna debug módban mplab-sim-el tesztelni mikor szembesültem, hogy a Simulator Logic Analyzer ablak nem aktív. Ez miért lehet estleg frissítsem az Mplab-ot? Vagy ez a mód valamiért dsPIc-nél nem aktív? Válaszotokat köszönöm.
1. Szimulációhoz nem kell Debug mód.
2. Debugger/Settings menüpontban az Osc/Trace fülön a Trace all mellett van pipa?
Köszönöm, szépen gyors válaszodat nem volt pipa. További szép napot neked.
Szia!
A soros vevő a lecsatlakozásnál hibás karaktert vesz, a hiba olyan, hogy a vevő kikapcsolásával lehet csak törölni (RCSTA,SPEN törléséve és újra beállításával). Ekkor sajnos a megszakítási ok (PIR1,RCIF) nem törlődik. Az okot az RCREG kiolvasásával, külön lépésben kell törölni. (Ha ez nem történik meg, a megszakítási rutinból kilépve a kérést újra elfogadja a kontroller, minduntalan a megszakítási rutin fut le.)
Félreértesz. A mikrokontroller nem fogad semmit a soros portról. A gépbe van bekötve a soros eszköz. A közös kapocs a két eszköz között egyedül a számítógép. (Meg a hálózat, de a tápok elvileg szűrnek.)
Tápellátás vagy és földhurok a csatlakoztatott eszközök között, valamint nem megfelelő szűrések a tápfeszen, lehetnek az okok, ha a PC-t kizárjuk a lehetőségek közül.
Sikerült lefordítani az első p24 es programomat. Valóban kellett hozzá az elérési utak beállítása mellett a file elérési útjaiban az ékezetmentes karkaterek használata, meg a limitált hossz. Eddig ez nem okozott gondot, mert a p16 - p18 fordításkor legalább reklamált az MPLAB, ha túllépett a max. hosszon és az ékezetes betűk használatáról azthittem csak a régebbi verziók nem tolerálják. De dinokal válaszával már világosan értem milyért működik másként a két processzorra írt program fordítása. Hálás köszönet érte!
Idézet: „mert az egész modulokból áll, és az egyik elfogadja az ékezetes útvonalat, a másik nem.” Mivel a p24 hez használt modul láthatóan más filozófiát használ, ezért kicsit újszerű az Otput ablakban megjelenő információ. Itt pl. nem keletkezik .lst file. Ez arra volt jó volt, hogy adott helyen megjelent egy error kód, aminek szükség esetére megvolt a leírása is. Most az Output ablakban látok egy figyelmeztetést: Warning: end of file not at end of a line: newline inserted. Mi lenne ez? Másik dolog ami csak a projekt .map filéjében van benne, hogy: optional library libp24HJ128GP502.a not found. Itt mit nem talál? Megint valami elérérési út beállítási gondja van?
Én is csak ilyenekre tudok gondolni. Köszi a megerősítést.
Idézet: „Warning: end of file not at end of a line: newline inserted” A C nyelveknél szükséges, hogy a fájlok utolsó karaktere újsor karakter legyen, erre figyelmeztet ez. Tehát egyszerűen menj a jelenlegi utolsó sor végére és nyomj egy Entert.
jogos. Nekem a warningból ez közvetlenül nem jött le.
A 16F62xA szériában a konfigurációs bittel ha digitális bementre állítod a MCLR lábat (MCRLE=0), a MCRL funkció belső felhúzással automatikusan elintéződik, de nem jelenik meg a lábon logikai 1.
A 16F877A már nem képes ilyesmire, ott mindenképpen külső felhúzás kell. 18F1xK50 esetén konfigurációs bittel is beállítható a MCLR funkció belső felhúzásra, de az így képződő bemenetet WPUA regiszter ide vonatkozó bitjével kell/lehet felhúzni (miután az INTCON2 regsizterben ezt engedélyeztük), hogy a felhúzás a lábon is megjelenjen. 18F4x20-nál megint csak annyi van, mint a 16F62x sorozatnál. Konfig bittel állítható, de nincs pull-up a lábra. Idézet: Keletkezne, ha engedélyeznéd az MPASM30 opciói között.„Itt pl. nem keletkezik .lst file.” Idézet: Szerintem erre majd csak a C programoknál lesz szükséged (a C30/lib/PIC24H könyvtárban található egyébként, két változatban: COFF és ELF)„optional library libp24HJ128GP502.a not found” Idézet: Igen. „Megint valami elérérési út beállítási gondja van?” Idézet: „de nem jelenik meg a lábon logikai 1.” Igen, erről beszéltem, hogy a láb lebegő állapotban marad, amit nem szabad megengedni. Mindenképpen kell rá a 10k felhúzó (vagy akár lehúzó, ha az MCLRE=0) Idézet: „de az így képződő bemenetet WPUA regiszter ide vonatkozó bitjével kell/lehet felhúzni” Fel, de ehhez a kontrollernek először kell indulnia. Az addig lebegő MCLR lábbal ez viszont nem garantált. Én itt most nem arról beszélek, hogy ha az MCLR lábat tiltjuk, akkor belülről a chipben a belső reset jel fel van húzva tápra vagy nem, mert az egyértelmű, hogy fel van. A lábról viszont a programozási üzemmódba léptetést sehogyan sem lehet letiltani, ezért a lábat mindenképpen valahová oda kell húzni, ha a kontrollert üzembiztosan akarjuk használni. Ha az MCLR tiltva van, akkor akár gnd-re is húzható, a lényeg, hogy vagy tápra vagy gnd-re oda legyen húzva.
Helló. Segítséget szeretnék kérni, ha valaki tudna-e kapcsolást készíteni a programomhoz. A program része megvan, viszont a kivitelezés nem tiszta. Mondjuk van egy bemenet, amin egy HALL szenzorral fogom érzékelni a jelet. De nem köthetem csak úgy rá, kell hozzá felhúzó ellenállás, meg talán egy ellenállás elé, ha a kimenetből bemenet lenne (vagy fordítva) Ezekkel a dolgokkal nem vagyok tisztába. Ezt az előzőt is csak egy fórumban olvastam, hogy kell elé ellenállás. Akkor lenne egy olyan, hogy lenne egy bemenet, de a bemeneten nem 5V lenne a LOG1 érték, hanem 12V, ahhoz szükséges egy feszültségosztó. Annak is az illesztése a PIC-re nem tiszta. Ki vállalkozna ennek a segítségében?
|
Bejelentkezés
Hirdetés |