Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Sokvolt a kérdés így egyszerre
 Sub interrupt If Testbit(PIR1, TMR1IF)=1 then cnt=cnt+1 PORTC=cnt 'ez a szimulátorban szépen növekszik is, főprogramnál kiiráskor 0-zom PIR1.TMR1IF=0 else If testbit(INTCON,RBIF)=1 cnt2=cnt2+1 'tesztnek írtam ide PORTC=255 'ez a intcon bitjének átbillentésével jó is lett INTCON.RBIF=0 end if end if End sub Mindkét cnt byte INT0-sem ment. Hiába nyomogattam a szimulátoron a gombot, nem ugrott rá a megszakításra. Aztán átnyomtam a INTCON megfelelé bitjét, és megcsinálta, amit kellett, majd nullázta. Tehát ha eljut na odáig, már menne. A timer1-es rész lehet nem pont így nézett ki. De az biztos, hogy ha RBIE 1, akkor a PORTC-n szépen ugráltatja a ledeket, csak LCD nem megy.
Alapban INT0-al akartam csinálni, de úgy sem megy, mert hiába nyomogatom RB0-t, nem csinál semmit.
Na ezt most nem veszem, lehet faradt vagyok.
1. Szoval TMR1IE = 1 ez be van allitva, ennek fuggetlennek kellene lennie a gomb nyomogatastol es attol, hogy RBIE 1 vagy 0. Ez a resze ha jol ertem mukodik? 2. RBIF vizsgalatat nem kell else agba rakni... Vegulis tesz szempontjabol most mindegy 3. Ahogy watt kerdezte, az RB labak amik imputok, azok lebegnek? Mindegyik fel van huzva? 4. Tegyel ledeket arra a PORTC-re, es az =255 helyett a PORTB-t rakd ki oda... tegyel az int RBIF vegere egy idohuzast tudom nem szep de teszt miatt kellene... igy a ledeken latni fogod mi tortenik, hogy interruptod lekezelodik-e, hogy a megfelelo portokat minek latja a PIC-ed stb... 5. LCD kiiras mitol fugg amugy? Tobb kerdesem egyenlore nincs
A lebegnek dolgot nem értem.
 Szimulátorban tudom állítgatni. Az meg eléggé digitális. De nem fut rá, hiába állítom. Alapban PORTB 0. Nyomogattam először a PORTB.0-t. De nem ment. Aztán jött RBIF, és RB4-7 nyomogatása, de semmi. Mindazontúl LCD-sem megy Csak ha átnyomom az INTCON.RBIF-et 1-re. Szimulátorban az összes memóriacím látszik, nem kell kiiratni. 1. ok 2. ha jó lesz, kijavítom 3. amit nem értek 4. írtam 5. Van egy loop, és ha cnt=5, akkor LCD_Out van. Kiírja a cnt, cnt2-t. A loop előtt kiír egy másik szöveget is, de az sem jön be ilyenkor. Ja, és a sorrend a kódban: TRISD=0 LCD_Init(PORTD) kurzorállítgatás LCD_Out(2,1,"Hello'") INTCON.RBIE=1 Nem tudom az eredetit belinkelni, mert az otthon van.
Lebeges: input lab nincs aktivan a foldhoz vagy a + -hoz kotve... (fel ill lehuzas). Tipikus hiba, ilyenkor az inputon megjeleno szint veletlen szerunek tekintheto - szimulatorban termeszetszeruleg ez a jelenseg nem latszik...
Amugy nem tudom milyen szimulatorod van, mikor azt mondod "megnyomod" mit nyomsz meg szimulatoron? Van valami gomb virtualis eszkozod? A port atmegy 0-bol 1-be, vagy aktiv 1-bol lehuzodik 0-ra? Es kozben RBIF nem valtozik?
Ha megnézed az RBIF feltételét a doksiban, akkor kiderül, hogy ha egyszer beesett egy ilyen interrupt, akkor törölni kellene a "nemegyezés" feltételét. Ez egy PORTB olvasással tudod megtenni, majd ezután kell az RBIF flaget törölni!
Így nem fog törlődni az interrupt flag, mert mindig azt hiszi, fennáll a nemegyezőség, és állandóan visszapattan az interruptba, szinte teljesen felzabálja a procit. A másik, amit trudnai is említett, hogy az interrupt rutinban ne else-be rakj ágakat. Azaz legyen egy "if timerinterrupt történe then ... endif", majd ezután egy "if RBIF történt then ... endif", és minden interrupt eseményre külön egy ilyen lezárt if-ág.
PIC18-as
Oshonsoft És van benne egy jelgenerátor, azzal akartam adni a jelet, tesztként, hogy mennyire pontos. Mivel azzal nem ment, maradt a nyomogatás. Akármelyik nitet át lehet állítani vele a memóriában egy egérkattintással. A végén már így csináltam. Ha RBIF-et állítottam, egyből törölte, és megcsinálta az interrupt alatt lévő részt.
De egyszersem fut rá.
Vagy ahogy beállítom INTCON.RBIE-t, egyből ki kell olvasnom?
Még előtte kellene kiolvasnod, hogy rendben legyenek az összehasonlító latch-ei. Meg az RBIE 1-be állítása előtt talán érdemes az RBIF-et is törölni, de ezt most csak fejből mondom, nem bújtam bele a doksiba.
A lényeg, hogy amikor bebillented az RBIE-t, akkor, abban a pillanatban nem kellene semminek történnie, majd amikor tényleg változik a bemenet, akkor kell, hogy a megszakításra ugorjon. A megszakításban meg a leírt módon kell ismételten eljárni, azaz törölni az egyezőtlenség feltételét (PORTB olvasás), utána törölni az RBIF-et (hacsak az nem magától áll ilyenkor vissza - a doksit el kellene olvasni). Egy változáshoz egyszer kellene beesnie interruptnak.
RBIF törölve van.
A doksi sajna angol Úgy ahogy kihámoztam. A kiolvas alatt mit értetek? a=PORTB.7 b=PORTB.6 ...? INT0-nál mit csinálhattam rosszul? Ott is ki kell olvasni PORTB.0-t? Ok, doksi. Nézem, de majd otthon.
Hát, valamennyire meg kellene barátkozni az angollal, mert anélkül nagy kínlódás. A doksit amúgy meg lehet nézni angol tudás nélkül is, néha az ábrák is sokat segítenek.
A kiolvasás azt jelenti, hogy kiolvasod a regiszter értékét, mondjuk egy semmire nem használt változóba (dummy = PORTB). Ez csak azért kell, hogy a változást figyelő belső tárolók beálljanak a bemenetek aktuális állapotának megfelelően, majd ezután ehhez képest fog változást érzékelni. INT0-t most nem látom, hogy ott mit is csináltál.
PIC18-as... melyik?
Meg Oshonsoft... nem veletlen egy ICD2 debuggert hasznalsz? Az most mindegy, hogy klon vagy eredeti, de DEBUGGER, nem szimulator... Szimulator az pl ami az MPLAB-ban levo MPSIM... Debuggert meg szoktak emlegetni emulatorkent is, mert nem teljesen igazi a kornyezet, csak ahhoz nagyon hasonlo, de semmikepp sem szimulator!Na mindegy, szoval akkor igazi gombokat nyomogatsz... es akkor megint kerdes a gombok hogy vannak az aramkorre kapcsolva stb. Es hogy akkor az osszes inputra kapcsolt portlab meg van-e aktivan hajtva? Ha lebeg nem eleg, hogy tobbet fogyaszt a pic-ed, de meg uzemzavarokat is okozhat. Valoszinuleg amugy Szilva kapta el a lenyeget, ugyhpgy az o segitseget kovesd...
Szerintem az oshon PIC szimulátor programját használja. Most azt próbáljátok kideríteni, hogy ez a szimulátor megfelelően működik-e!
Lehetséges, hogy nem? 
Van PICKIT2-m is. Majd arra rátöltöm.
Csak abban 677-es van, majd megnézem, az miben tér el. De előbb ezt a kiolvasásos részt próbálom.
És valsz tényleg szilvának lesz igaza.
Ugyanis a PORTC.4=1 parancs sem hajtódik végre. Tehát végig interruptol, mert nem olvasom ki. Az elsőt meg nincs időm megnézni, mert a timer egyből felülírja. De ezért DEBUGGER Majd kidebugolom.Elég akkor az a parancs, hogy a=PORTB.0, ha csak INT0-t használok?
Sziasztok!
Egy PIC égetővel kapcsolatban lenne egy-két kérdésem: 1 Működhet az alábbi kapcsolás? 2 Milyen progival tudok égetni? 3 Esetleg valami más, baromi egyszerű kapcsolás, ami bevált? Kösszs: Uli
Nem tudom, de az Oshonsoft-os BASIC-ben így kell az interuptokak kezelni, van rá példa is. Nekem eddig mindíg működött.
DIM X AS BYTE X = 255 TRISA = 0 PORTA = X INTCON.INT0IE = 1 ENABLE HIGH END ON HIGH INTERRUPT X = X - 1 PORTA = X INTCON.INT0IF = 0 RESUME DIM T AS WORD T = 0 TRISA = 0xFF ADCON1 = 0 TRISB = 0 T0CON.T0CS = 0 INTCON.TMR0IE = 1 ENABLE HIGH loop: ADCIN 0, PORTB GOTO loop END ON HIGH INTERRUPT SAVE SYSTEM T = T + 1 INTCON.TMR0IF = 0 RESUME Ezzel szemben a tiéd így néz ki. Sub interrupt If Testbit(PIR1, TMR1IF)=1 then cnt=cnt+1 PORTC=cnt 'ez a szimulátorban szépen növekszik is, főprogramnál kiiráskor 0-zom PIR1.TMR1IF=0 else If testbit(INTCON,RBIF)=1 cnt2=cnt2+1 'tesztnek írtam ide PORTC=255 'ez a intcon bitjének átbillentésével jó is lett INTCON.RBIF=0 end if end if End sub Ha nem BASIC-et használsz akkor még érthető, de ha azt, akkor valamit nagyon nem jól csinálsz.
Na jo en meg sem szolalok tobbet mara
Mar en is bele zavarodtam, hogy most miben is probalgatja a programjat elektrolama De ezek szerint akkor nem debuggerben, hanem tenyleg szimulatorban Eletrolama, a debugger nem attol debugger, mert lehet benne debuggolni de asszem jobb ha mar tobb hulyeseget nem mondok mara    
Sziasztok!
Nem tudja véletlenül valaki, hogy MPLAB C18-nál hogyan lehet dinamikusan egy karaktertömbnek (string) helyet foglalni? Nem létezik véletlenül egy malloc() függvény, mint standard ansi C-ben? :miaz:
Ezt a förmedvényt felejtsd el.
Nézd meg az oshon és klónjait(oldalamon is találsz infókat))
Nem igazán értem, hogy mi az oshon és klónjai...
Megfogalmazom másképpen a problémámat: van egy
Így helyes:
Csienke:
watt nem a te kérdésedre válaszolt. Az majd látszani fog a címsorodban. De egy tipp: Amúgy a proginak nincs véletlenül utasításgyűjteménye?? Én 1hónapig használtam mikro C -t annak volt sőt le ís volt írva milyen jellegű dolgokat lehet vele csinálni, de én nem olvastam a dinamikus változókól, ha jól emléxem.... (Amúgy visszatértem az ASM -re mert a C nagyon messze áll a PIC-től, nagyon erőltetett, bár gyorsabb a prgramozás sokkal.)
Igaz. Bocsáss meg watt. Elnéztem.
Van egy C18 Library pdf fájl, de abban nem találtam példa programot, csak a stringkezelő és más utasításokat. 
Igen, egyetertek, technologiailag az osszes magasszintu nyelv messze all a PIC-ektol es mas mikroktol. En mar regita nyuzok egy 10F202-est, tegnap esti mosoditasom ota mar csak 9 program szo helyem maradt, szoval; cipokanal es presgep, de ugy tunik mukodik
Olyan ket csatornas digit szurot csinaltam belole, amilyenbol minden konkurencia csak egy csatisat birt epiteni es joval nagyobb PIC-eket valasztva - na ja, csak ok C-ben meg ki tudja mikben fejlesztenek...Persze lehet magas szintu nyelvekkel jopofa dolgokat muvelni, nem igazan kell erteni a hardver minden reszletet belulrol, az sem okoz tul nagy fejfajast ha at kell hurcolkodni masik MCU-ra stb. Nezzetek meg elektrolamat, kezdo de megis, beirja, hogy lcdout es mukodik neki, van sikerelmenye. Es ha nem olyan bugyuta mint en, hogy a legkisebbe akarja beletenni azt amit elmeletileg nem lehet, akkor miert nehezitene meg a sajat kis projectjet?
Azért annak a hardvereldugásnak elég nagy ára van - jól meg is isszuk a levét az asztali PC-ken, olyan erőműveken nézzük a homokórát, amikből akár egy is kiadta volna korábban egész Magyarország számítási kapacitását.
A mikrovezérlők eleve szűkös erőforrásaival szerintem luxus annyira pazarlóan bánni, hogy mondjuk egy C féle függvényhívással lassítsuk a program futását. Jó az az assembly
A dolog kulcsa a nyelv ismerete. Aki ismeri a sajat maga altal kedvelt nyelv minden csinjat-binjat az BARMIT meg tud oldani. En pl. szinten az assemblyre eskuszom (es a PC-t is abban progizom), de mostanaban eppen azzal szivok sokat, hogy mar minden csak c-ben van es nehez ugy visszafejteni valamit, hogy a masik nyelvet nem is ismerem.
Ha jol hasznalod az assemblyt, akkor tulajdonkeppen mar a sajat, egyeni nyelveden programozol, hiszen jol bejaratott, sajat makroid es a szubrutinjaid elore koszonnek
Nem ketseges, es azt hiszem nem a nyelvi korlatok itt azok amiket mar-mar feszegetunk, hanem a fordito hatekonysaga + emberi agy hatekonysaga. Assemblynel ugye az emberi agy optimalizal, az sem mindig tokeletes, foleg ha sokat kell piszkalni a kodot, meg ha tul bonyolitott az algoritmus. Sok forditonak kielegito az optimalizacios resze, ambar jomagam mindg jobban bizom az emberi agy mukodeseben - kiveve ha majd Altzheimer bacsi es tarsai elojonnek az oregedes elorehaladtaval
. Szoval jomagam is Assembly parti vagyok, es ahogy emlitettem a kis mutyuromet, hat azt C-ben lehetetlenseg lett volna megcsinalni - marmint ekkora meretben, ezzel a feldolgozasi sebesseggel, ilyen szukos eroforrasok mellett. 24 byte RAM, 512 szo programtar, no interrupt, 1 db 8 bites timer aminek nincs tulcsordulas erzekeloje stb stb stb.Apropo, Nemreg emlitettem a 9 szo szabad programtarat...nos mostanra ez osszebb ment 2 azaz kettore  Meg le tudom szedni a copyright szoveget az elejerol meg 2-3 dolgon lehetne trukkozni nagy erofeszitesek aran, de hat egyenlore ugy nez ki ez igy lesz bepreselve. Sikerult megcsinalnom egy stimulus file-t is amin gyonyoruen lehet modellezni a problemakat es jelentem kivaloan mukodik a dolog, ugyhogy ha a tobbi teszten is atmegy akkor az a ket szonyi hely megmarad a firmware szamara jatszoternek Na ezt Basicben vagy C-ben elerni... es kozben meg jobban is mukodik mint a konkurenciak amiket eddig be tudtam szerezni - meg ugyan van egy keszulek amivel nem sikerult osszehasonlito tesztet csinalni, de asszem igy is elegedett vagyok. Ja, es bocs hogy ilyen hosszan irok errol, csak most nagyon happy lettem, hogy becuppant ez az utolso modositas is
Én csak annyiban szeretnék ellentmondani, hogy ha valaki megszokta az assemblyt akkor C-ben is úgy fog programozni. Ekkor a C-is összezsugorodik és némileg irányított lesz. Ilyenkor nem használsz egy csomó headert, hanem magad oldod meg a problémák lekezelését. A perifériák beállítását is bitbillegtetéses módszerrel(pl. INTCONbits.GIE=1) oldod meg, így nem fedődik el a lényeg. Én legalább is így szenvedek a C-ben, ha muszáj! Az a jó a C-ben, hogy könnyű számolni benne. Igaz ennek ára lehet, ha nem használod ki a belinkelt rutint teljesen. Ilyenkor lehet sajátot írni... Ennek ellenére én is sajnálom, hogy rá lett erőltetve a C a PIC-re.
Jó reggelt Mindenkinek.
A következő kérdésem van: Az új MPLAB 8-ban amikor beállítom a PIC tipusát, akkor az eddigi zöld és piros pöttyök mellett megjelent a sárga is. Az mit jelent? Köszönettel.
Csak sejtéseim vannak, hogy részben támogatottat jelent.
|
Bejelentkezés
Hirdetés |
