Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Idézet: „Van belső oszcillátora.” Nincs! Mielőtt válaszolt, nézd meg, mi az a belső oszcillátor! Idézet: „Ez hasonlít a tömbkezeléshez, de asm-ban nincsenek tömbök, mint a C-ben...” Komolyabb nyelveken programozók szerint a C-ben sincs olyan, hogy tömb, csak egy összefüggő memóriaterület, amihez tartozik a terület elejére mutató pointer. Ezenkívül a fordító a típusdeklaráció alapján tudja, hogy mekkora egy elem mérete, s az a{i} hivatkozásból a fordító képezni tudja az &a[0]+sizeof(típus)*i címet. Assemblerben sem sokkal nehezebb. U.i.: a szögletes zárójel nem jelent meg, ezért írtam át kapcsosra!
Igaz hogy mikrovezérlős környezetben ritkán van szükség többdimenziós tömbökre, de azt azért már lényegesen egyszerűbb C-ben megcsinálni mint ASM-ben.
Rá lehet fogni, de én nem tekintem tömbnek(vektornak), mert csak lefoglalt memóriaterület, amit indirekt címzéssel érek el. Ez csak nézőpont kérdése.
Mindenesetre az assemler nyelvben ne keressük a tömb deklarálást. Az hogy megoldjuk, az más kérdés. Idézet: „„Van belső oszcillátora.” Nincs! Mielőtt válaszolt, nézd meg, mi az a belső oszcillátor!” Vegulis ha szigoruan vesszuk van belso oszcillatora, csak kell hozza egy kulso kvartz  Hagyjuk ra Idézet: „Komolyabb nyelveken programozók szerint a C-ben sincs olyan, hogy tömb, csak egy összefüggő memóriaterület, amihez tartozik a terület elejére mutató pointer.” En, mint programozo ezt azert cafolnam. Max az uj generacio akik C++ -on nevelkezdtek allitanak ilyesmit ossze keverven a futas ideju index validalast az indexelt cimzessel. Idézet: „Ezenkívül a fordító a típusdeklaráció alapján tudja, hogy mekkora egy elem mérete, s az a{i} hivatkozásból a fordító képezni tudja az &a[0]+sizeof(típus)*i címet.” Pontosan ettol tomb a tomb, de nevezhetjuk akar fix record hosszusagu adathalmaznak is akar. Idézet: „Assemblerben sem sokkal nehezebb.” Persze, hogy nem nehezebb. Csak PIC midrange-nel erosen bejatszik meg a bank kezeles ami kicsit megbonyolitja a helyzetet -- egy ilyen rutint csak egyszer kell megirni es mar kesz is, utana mar csak be kell inklucalni a rutin gyujtemenyeinket a forrasba es hasznalni vagy ha felepitunk egy libet akkor linkerrel ossze kell szerkeszteni -- a vegeredmenyt tekintve mindegy, ugyanolyan gyorsan tudunk epitkezni egy jol megirt asm rutn gyujtemennyel. (bocsanat, nem vitatkozni akarok, csak epp most ertem haza a pub-bol es a Guinness mennyiseg beszel belolem )
Az indexhatár-túllépés ellenőrzése azért jóval régebb keletű dolog, s az Igazi Programozó természetesen nem C vagy C++ nyelven programoz (bár ezeken a nyelveken is képes FORTRAN programokat írni!
 ). Nyilván nem PIC téma, de ha már szóbajöttek a tömbök és a programnyelvek: A valódi tömbkezeléskez szerintem az is hozzátartozik, hogy az index ne legyen 0...n-1-re korlátozva, hanem mehessen pl. -10-től +20-ig. Ennél még fontosabb, hogy legyenek tömbökre értelmezett műveletek, hogy a bugyuta
helyett elég legyen annyit írni, hogy:
Vagy:
S akkor a tömbökkel kezelt indexlistákról még nem is szóltam. A FORTAN95 elég jól van "eleresztve" ilyen szempontból, s azóta már újabb kunsztokat is kitaláltak. Idézet: „Csak PIC midrange-nel erosen bejatszik meg a bank kezeles ami kicsit megbonyolitja a helyzetet” Ez eleve kivül esett a látókörön, mert a témaindító dsPIC30F-hez keresett megoldást. Idézet: „epp most ertem haza a pub-bol” Remélem, nem volt indexhatár túlcsordulás!  Idézet: „Az indexhatár-túllépés ellenőrzése azért jóval régebb keletű dolog, s az Igazi Programozó természetesen nem C vagy C++ nyelven programoz (bár ezeken a nyelveken is képes FORTRAN programokat írni! ).” Milyen igaz Amugy jomagam a Pascal-t sokkal jobb nyelvnek tartottam mindig is. A C talan egyetlen elonye a bitmuveletesdi volt.Idézet: „helyett elég legyen annyit írni, hogy:”
Ah, de jo is lenne! En mar a Perl fele foreach-el is boven beernem Idézet: „Remélem, nem volt indexhatár túlcsordulás!” Csak egy kis buffer overflow de az exception handler meg idoben elkapta a hibat
Érdekes dolgot találtam, miközben a PIC -es modellvasút dekóderek lelkivilágát próbálom megérteni. A MERG féle dekóder 16MHz -en fut, és azt mondják róla hogy 16kHz / 8bit -es pwm van benne megvalósítva. Szoftveresen. Akárhogy filózom, ezt nemtudom hogy csinálták.
Én így tudom elképzelni a pwm jel genárálást: beállítunk egy timert megszakításra megszakításban növelgetünk egy számlálót ami ha elér egy adott értéket akkor nullázzuk a számlálót, és bekapcsoljuk a kimenetet. Ezen számolási intervallumon belül pedig egy másik érték (pwm kitöltés) eléreskor kikakpcsoljuk a kimenetet. Csakhogy így én 16MHz-el még csak kb kiloherzes pwm frekit tudok elképzelni, azt is csak kb 5 bites felbontásban. Van valami más módszer szoftveres pwm jel előállítására ?
Most nincs kedvem szamolgatni meg adatlapokat nezegetni, de ahogy en csinalnam szoftveresen:
1. Kiszamolnam hogy mekkora elooszto ill szamlalo ertek kellene, hogy 16KHz-t kapjak. 2. Ebbol a konstansbol szamolnam ki, hogy adott % duty cycle-hoz mekkora ertekkel kell a timert felprogramozni, hogy megszakitast adjon. 3. Kimenetet magasba kapcsolom es csinalok valami mast... 4. Egy statusz gep segitsegevel az elso megszkitas alkalmaval a duty cycle veget jelezi, a masodiknal pedig a culkus ido veget. 5. Elso esetben lekapcsolom a kimenetet (duty vege) majd a timert feltoltom a ki=onstans - a maradek % ertek kiszamitasaval 6. Ciklus vege, kezdek mindent elolrol... Nem tudom ertheto volt-e amit akartam irni, mindenesetre szerintem eleg kol meg lehetne kozeliteni a 16Khz-et, nyilvan lehet nehany 10 ppm elteres.
Tegnap este szórakoztam egy 16F882-vel, szeretnék belőle egy frekimérőt építeni. A mérés alapvetően a timer1 külső impulzusokkal történő számoltatása aszinkron módban, túlcsordulás esetén egy interruptban a "TMR1U" regiszter növelése, ilyenformán a kapuzási idő alatt megszámolt impulzusok számát 24 bitesen ábrázolom.
A PIC 20MHz-es kvarcról jár, a kvarcoszci kimeneti lábára tettem egy emitterkövető buffert, így frekimérős multiméterrel is tudtam ellenőrizni az órajelet, valamint a tesztek során a bemenetre is tudtam vezetni. Azt az érdekességet tapasztaltam, hogy ha túl alacsony a timer1 előosztója (pl. 1), akkor a TMR1H:TMR1L ugyan számol rendesen, de a timer1 interrupt nem következik be, így a TMR1U nem lép túlcsorduláskor. Lehet, hogy az interrupt feltételének ellenőrzése valahol le van írva az adatlapban, a tapasztaltak alapján úgy tűnik, hogy órajel-szinkronizált műveletekkel állítja be, és emiatt nem tudja túl gyors számlálás esetén "elkapni" a túlcsordulás pillanatát. Igazából csak érdekességképpen írtam, mert több helyen látni a neten, hogy akár 50MHz-ig is képes impulzusokat számolni a timer1 aszinkron módban (bár lehet, hogy ez az érték egyébként adatlapot sért). Azt mindenképp jó tudni, hogy ha a számlálás során a túlcsordulási állapot Fosc/4-nél rövidebb ideig áll fenn, akkor nem biztos, hogy a túlcsordulást észreveszi a PIC.
Hát ez is egy érdekes módszer. Viszont így a timerük "össze vissza" szakít meg. Persze nem írtam hogy konstans megszakítás kell. Közben nézem a dekóder kapcsolási rajzát, és úgy tűnik mégiscsak hardveres lesz az a pwm. Csak olyan rossz ez a rajz, nincsenek pontok az összekötéseknél, alig lehet kibogarászni. De elvileg a 16F872 13-as lába lehet a pwm kimenet.
Idézet: „Igazából csak érdekességképpen írtam, mert több helyen látni a neten, hogy akár 50MHz-ig is képes impulzusokat számolni a timer1 aszinkron módban” 1. A Timer0-át kell használni, mert annak a számlálási periódusa levihető 20 nanoszekundumra, ami tényleg 50 MHz. Timer1-nél 60 ns alá nem vihető, tehát az háromszor lassabb. 2. Timer0 előosztását (N) úgy kell megválasztani, hogy (Tcy+40)/N < 20 teljesüljön (nanoszekundumban mérve). 3. Az AN592 Application Note írja le, hogy az előosztó maradékát hogy lehet kiolvasni.
Hello!
Kezdő vagyok és lenne egy kérdésem. Szeretnék kipróbálni egy 18F4550-esen egy 16F-re írt programot (konkrétan Topi egyik cikkéből van, az alapok közzül). Megcsináltam a kis átírást amire szükség volt hogy működjön a saját pic-en az assembly progi, de ha le akarom fordítani és a Project ablakban a fájlra jobb klikk, majd Assemble parancsot választok akkor hibaüzenetet kapok és sikertelen fordítást, viszont ha a Make gombot nyomom meg, akkor pedig figyelmeztetést de akkor legalább elkészül a hex fájl. (pedig a forrásfájl ugyanaz). Mellékeltem a fordítandó fájlt és a hibajelentést. Itt csak két sor van a hibajelentésben, de olyan is volt hogy minden utasítást felsorolt, hogy gondja van vele. Szeretném ha el tudnátok mondani mi lehet a gond? Ja és MPLAB-bal fordítom. Remélem sikerült érthetően kifejezni magam. Előre is köszi! Üdv!
Megnéztem az AN592-t, elég érdekesen csinálja. Mondjuk ez az 50MHz szerintem nem is szükséges, illetve nekem úgyis kevés, emiatt lesz egy 128-as előosztó, ami elvileg 1GHz-ig működik. Az előosztó nélküli "natív" mérésnél bőven elég a 10MHz is.
A 24 bites számlálással viszont elég jó felbontásban lehet mérni a frekvenciát, már ha egyáltalán tényleg van erre szükség. Azon meditálok még, hogy hogyan lehetne H és L időket mérni, impulzushosszat, kitöltési tényezőt számolni. Akárhogy nézem, ha nem használok fel külső alkatrészeket, akkor még 20MHz-ről járatva is csak 200ns felbontással lehet dolgozni, ami 1%-os pontosságnál 50kHz-es határfreki.
Gondolom a csatolt ELSO.ERR file a make kivalasztasakor torteno figyelmezteto uzeneteket tartalmazza.
Annyit ir csak, hogy a LIST direktivanak nem lenne szabad a sorban a legelso karakter helyen lennie. Ott ugyanis csak a cimkek lehetnek. A #include #define stb is lehet ott, de az csak azert, mert azt a preprocessor kigyomlalja meg mielott a fordito azt lathatna... Ugyanigy az END direktivanak sem lenne szabad ott a sor elejen lennie. Tedd ezeket ugyanabba az oszlopba ahova azutasitasokat tetted...
Az oszlopot úgy érted, hogy számít az hogy van e tabulátor az adott sor elején vagy nem? Úgy értem nem csak a program küllemét alakítja a tabulátor?, hanem funkcionális jelentősége is van? Bocsi ha hülyeséget kérdezek.
Jat ez tenyleg egy erdekes modszer... Vegulis 16 bites timernek hasznalja a 8 bites timert...
kipróbáltam és működik, nincs több hibaüzenet, se warn.
Nagyon szépen KÖSZÖNÖM! Üdv!
Van több érdekes frekvenciamérő projekt, pl. ez a 2.5 GHz-es frekvenciamérő.
A H/L időket (kitöltési tényező) nagyobb frekvencián esetleg analóg módon érdemes mérni (mintha egy PWM kimenet volna).
Sziasztok!
Nagyon új vagyok az oldalon és a PIC-es témában,de a programozás is nagyon alap szintnen megy! Szeretném kikérni a véleményeteket milyen programnyelven programozzak,mert a Basic-et ajánlották de nem találok hozzá semmi dokumentációt az interneten! A fórumot olvasva nagyon senki se ajánlja a Basic-et.Ha esetleg tudtok valami segédletet a Basic-hez azt is megköszönném ,de ha másik programnyelvet ajánlotok akkor ahhoz is kéne ha lehet minél több infó. A projektemről annyit hogy egy három tengelyes cnc marót szeretnék építeni,ezt csak azért írtam meg ha valaki készített már ehhez hasonlót akkor tudja mire vállalkoztam és tudja melyik program erre a legalkalmasabb esetleg ha valaki szeretne ilyesmit készíteni akkor tudna velem is konzultálni ,mert több szem többet lát .Előre is köszönöm a kimerítő válaszokat. Üdv. Barty
CNC vezérléshez azt a legérdemesebb használni, amihez pl. a CNC vezérlő elektronika fórumban segítséget tudnak adni.
Általában pedig a fősodor az, amit a gyártó támogat, tehát: - Microchip Assembler, vagy ha C kell, akkor - mid-range-hez (PIC12, PIC16) Hitech C, - PIC18-hoz Microchip C18 - dsPIC30/PIC24/dsPIC33-hoz Microchip C30 Vannak aztán külön utak (BASIC, FORTH, PASCAL, PARSIC, FLOWCODE, YAL és egyebek), amelyek kívül esnek a fősodron, ezért ezekkel kevesebben foglalkoznak, kisebb tehát a valószínűsége, hogy segítséget kapsz hozzá.
Hali!
Nagyon szépen köszönöm a gyors választ! Akkor a PIC16F877-hez a Hitech C a nyerő ,és a továbbiakban a kérdéseimet a CNC vezérlő elektronika fórumon teszem fel  .Köszi mégegyszer. Idézet: „Akkor a PIC16F877-hez a Hitech C a nyerő” Egy jotanacsot ha elfogadsz: Soha se az eszkoz dontse el milyen uton haladsz, hanem a cel elerese erdekeben valaszd ki a neked megfelelo eszkozt! Szerintem icserny is ezert ajanlotta neked hogy elobb kerdezoskodj ill olvasgasd azt a CNC-s topicot hogy lasd ok miben dolgoztak es azzal milyen eredmenyt ertek el. Igy akkor kozelebb jutsz, hogy milyen PIC-kel vagy mas microvezerlovel erdemes neki allni es ahhoz milyen fejleszto eszkozt erdemes hasznalni -- ami pl forditja a mar meglevo peldakat is...
Üdv mindenkinek!
Szeretnék kérni egy kis felvilágosítást pár utasítás értelmezésébe. set_tris_b(0b00000000); portB kimenet output_b(0b11111111); portB minden lába magas szinten port_b_pullups(0b00000001); portB 0 felhúzva Ezek így helyesen vannak? Ha pl a B port felét ki felét bemenetnek akarom akkor azt hogy tehetem meg? mi a különbség a ki és a bemenet megadása közt? Előre is köszönöm.
Eh eh, megint en leszek az ugyeletes mumus, de meg mindig nem olvastad el az adatlapot
 Egyreszt a felhuzo ellenallas csak bemenetnek van, tehat felesleges foglalkozni vele, ha kimenetnek akarod... Masreszt ugye a TRIS-nel az adatlapban vilagosan le van irva, hogy a 0 az az output, az 1 az input (legkonnyebb megjegyezni, hogy a 0 hasonlit az O-ra, azaz Out, az 1 hasonlot az I-re azaz In... Nyilvan amelyik helyen 1 van az input, ahol pedig 0 van az output... Egyszeru eddig... A bonyodalmat az okozza, hogy gyakran a portok osztoznak a labakon. Azaz -- bar nem tudom milyen pic-ed van -- szinte bizonyos, hogy a PORTB-den van analog lehetoseg is, amit altalaban bekapcsolva szokott lenni a PIC power on resetjekor. Tehat ezt nyilvan ki kellene kapcoslni. Ha nincs ADC rajta akkor lehet compatrator van rajta, azt kellene kikapcsolni. Mas modulok altalaban nem szoktak kapasbol bekapcsolva lenni de erdemes ennek ellenere az adatlapot tuzetesen atolvasni, a Port-okrol szolo fejezetet. Altalaban meg egy rovid inicializalast is meg szoktak adni digitalis es/vagy analog modra. Igaz assembly, de ne zavarjon, a lenyeg, hogy kiolvasod melyik regiszterbe miket tolt es elolvasod a magyarazatot miert... Es nezd meg azt is, hogy fel van sorolva az, hogy adott PORT-hoz milyen regiszterek tartoznak -- azokra keresgelj ra a dokumentacioban, hogy melyik mire valo, abbol is ki szokott egy csomo minden derulni -- pl akarsz egy PWM-et meg egy ADC-t meg egy RS232-t es akkor mi hogyan utkozik a port labaiddal, mire kell figyelni mikor egyik-masik modult feleleszted hogy ne kavarjon be a tobbi port labba stb stb stb...
Az a baj, hogy nem vagy tisztában az alapokkal, ennek ellenére a CCS-t erölteted! A CCS témában már volt róla néhányszor szó, hogy alapból az output_x() függvény kimenetté billenti a komplett portot, tehát birizgálja a TRISx biteket is. Erre van egy valamilyen beállítás, amit a forráskód elején meg kell adni, és akkor az output_x() függvény nem fogja a TRISx-et birizgálni, csak a PORTx-et. Hogy mi ez a beállítás, fejből nemtudom, utánanézni pedig nem vagyok hajlandó. Az efféle hülyeségek miatt útálom a CCS-t annyira...
Idézet: „Erre van egy valamilyen beállítás, amit a forráskód elején meg kell adni, és akkor az output_x() függvény nem fogja a TRISx-et birizgálni, csak a PORTx-et. Hogy mi ez a beállítás, fejből nemtudom, utánanézni pedig nem vagyok hajlandó. Az efféle hülyeségek miatt útálom a CCS-t annyira...” Igen, az a fastio vagy mi a fene, de amugy tenyleg borzalmas ha az ember nem allitja ezt be.
Üdv!
Nem szeretnék komolyabb progit csinálni egyelőre, csak a portot ki, be kapcsolni, de egyszerre több lábat. A C nél ezt csak asm utasítással tudom megtenni. A többit C be megoldom (valahogy). Lényeg, hogy egyszerre tudjam a B port (16F628 nál) felét kimenetként kapcsolgatni. A bemenetet C be kezelném.
A végén lévő 4 db nulla nem zavar be ha a bemeneteket C be kezelem? A fastio nak utánanézek.
Nekem csak egy roppant egyszerű kérdésem lenne, mégpedig, hogy ha egy kimeneti biten logikai 0 van, akkor az 0V - VSS ugye, ha pedig logikai 1, akkor +5V - VCC van ugye?
Ha nem, akkor hogy is van ez? |
Bejelentkezés
Hirdetés |
