Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Keressetek, és találni fogtok!
Bővebben: Link
Hát nem tudom, nem győztél meg. Egy negyed órát sasoltam ezt az 1 sort, mire kezdem kapisgálni, hogy ki-kivel van és miért...
Akkor szép egy kód, ha ránézek és értem, hogy mi akar lenni, nem kell gondolkozni. Lehet, hogy a hiba bennem van.
Ennek azért hosszabb a futásideje, mint annak, amit NickE és én beírtunk. Vagy tévedek?
Idézet: „Ennek azért hosszabb a futásideje, mint annak, amit NickE és én beírtunk. Vagy tévedek?” Igen, egy csomo fel es le konverzio van benne... Csak probaltam matematikai uton megkozeliteni  Idézet: „Akkor szép egy kód, ha ránézek és értem, hogy mi akar lenni, nem kell gondolkozni. Lehet, hogy a hiba bennem van.” Nem benned van a hiba, hanem bennunk, emberekben. Amugy a megertest nagyban segitette volna ha kikommentezem ill. leirom az algoritmus lenyeget. Azonkivul lehetne optimalizalni, seged valtozokat bevezetni hogy ne legyen felesleges konverzio benne, es kulon valasztani az elemeket hogy szepen nezzen ki. Pl:
Aztan az egeszbol csinalhatunk makrot is:
Köszönöm Potyo!
Sajnos még nem tudom, hogy is kell a Timer megszakítást használni, ennek hamarosan utánna fogok nézni! A Timer az valójában a Bitváltás közötti időt határozza meg? És pontosan miért kell 4X-ével figyelni a lábat? Valójában azért szeretném így megoldani, hogy ne kelljen a Manchester kódolás miatt 2db 8Bit-es átalakítást, és vissza alakítást csinálnom!! Egy IR távirányító lenne majd  Mégegyszer köszi!
A lényeg, hogy a bejövő jelszintet periódikusan meg kell nézned, hogy azután ki tudd elemezni. Nézzük azt az esetet, hogy a periódusidő azonos a bitidővel. Ezesetben ha épp elkaptuk, hogy közvetlenül a lefutó él után vettük a jelet, majd utána mindig a szintváltás után nézzük, akkor jók vagyunk, mert minden egyes vizsgálatnál egy bitet kaptunk el. Igenám, de mivan, ha a periódusidőnk egy kicsivel kisebb, mint a bitidő. Ezesetben ha épp a startbit lefutó éle után közvetlenül vizsgáltunk, akkor a következő vizsgálat szélsőséges esetben még mindig a startbit idejébe esik, vagyis nem az adatbitet vizsgáltuk ott, ahol már azt hisszük, hogy azt. Tehát ez így nem megfelelő. Nézzük a bitidő felét periódusnak. Ha épp a lefutó él után közvetlenül vizsgáltuk, akkor a következő periódusban még a start bitben vagyunk, valahol annak közepénél. Ha innen kezdve minden második periódusban nézzük a bejövő jelet, akkor jók vagyunk. Igenám, de most jön az a probléma, hogy mivan, ha a legelső vizsgálat épp a startbit közepe előtt volt, a periódusunk pedig egy kicsit hosszabb, mint a fél bitidő, akkor már a következő vizsgálat, amikor még a start bitben kellene lennünk, már beleesik a nulladik adatbitbe. Vagyis ez sem járható út. Ami már járható az az, ha a periódusidő a bitidő harmada. Ekkor ugye az észlelés a startbit első harmadába esik, vagyis a következő vizsgálat még mindig valahol a startbit középső harmadában, vagy annak határától csak kis távolságra található. Innen ha a peridósuidő nemis pontosan a bitidő harmada, akkor is minden harmadik vizsgálat kellően beleesik az adatbitbe, és így nem detektálunk hibásan semmit (persze bizonyos határok között). Tehát a háromszoros sebességű figyelés az már működik. Innen a négyszeres az úgy jön, hogy a négy az egy szép kerek szám
Ennek az az előnye, hogy a soros küldés is megy egyidőben a fogadással, mivel minden harmadik vagy negyedik megszakításban kiteszünk egy újabb bitet a kimenetre.Lehet olyasmivel játszani, hogy kétszeres sebességgel figyeled a lábat, majd a startbit észlelése után negyed bitidő múlva nézed újra, ekkor a startbit második vagy harmadik negyedében vagy, vagy annak a határához közel, és innen bitidőnyi időnként nézed a lábat. Ennek az előnye, hogy ha nincs adatátvitel, akkor feleakkora a kontroller "üresjárati" terhelése, cserébe viszont változó periódusidőd van, ami hátrányos lehet, ha valami ezzel van szikronizálva, illetve így nem lehet a soros küldést ugyanezzel a timerrel megoldani a fogadással egyidőben - nem egyidőben természetesen semmi gond, minden második megszakításban kirakunk egy bitet. Csak ugye ki tudja, mikor jön adat, és mivan, ha épp akkor esik be, miközben küldés van folyamatban. Tehát bizonyos feltételek között a módszer jól használható. Egyéb módszer még, hogy ne foglald a kontrollert, hogy külső megszakításlábra kötöd a bemenő jelet. Alaphelyzetben engedélyezed a megszakítást. Ha jött megszakítás, vagyis elkezdődött a start bit, akkor tiltod a külső megszakítást, timert elindítod, hogy másfél bitidő múlva okozzon megszakítást, ekkor beolvasod a nulladik bitet, timert átállítod, hogy egy bitidő múlva okozzon megszakítást, és így beolvasod a többi biteket. Stopbit érkezése után tiltod a timert, újra engedélyezed a külső megszakítást, és kezdődik minden előlről. Talán ez a legjobb módszer, ha csak fogadni kell, nem kell adatot küldeni.
Sziasztok!
Van nekem egy ilyenem:
Az LCD működik szépen, kiír mindent, de a motor nem forog. Ha kikommentelem az LCD részét, és simán megadom a végén, hogy s=50 (vagy akármi), akkor forog a motor. Tehát nem olvassa be az előzőleg "kiszámolt" s változót? Mi lehet a hiba?
Lehet, hogy figyelmetlen vagyok, de s kezdőértéke mennyi? (és mennyi lesz ha abból elveszel egyet?)
 Illetve látok egy üres #define sort is...
Nem vagy eleg turelmes, hogy a vegtelen ciklus lefusson, mi?
A while(1)-bol valahogy ki kellene jonni ha azt szeretned, hogy a motor vezerlesre ra csorogjon a program szal... Azonkivul ahogy most csinalod a motor vezerles ha elindul soha tobbet nem lehet majd a billentyuvel allitani a fordulatot (bar lehet epp ez volt a szandek, ezt nem tudom). Meg egy aprosag (vicsys megjegyzesen tul) hogy a goto helyett tegyel be szinten egy ciklust, mert ez se nem basic se nem asm, itt nem illik gotozgatni... (kernel fejlesztesnel megvan annak is a szerepe, de ne menjunk most ebbe bele)
Különösebben célom nincs vele, csak gyakorlás -gondolom látszik, hogy elég ködös nekem ez a programozás dolog
Próbáltam úgy is, hogy egy while-on belül van az lcd és a motor is, de akkor sem forgatta. Elvileg akkor eljutott a motorig a program, nem? Amúgy eleinte ott volt, hogy s=0; ,de mikor kivettem onnan, akkor is 0-ról kezdte. A hiányos #include pedig nem tudom, hogy itt miért lett hiányos, a programban benne van; lényegében az az lcd vezérlője. Csatolom a programot, hogy látszódjon rendesen...
Latom meg nem javitottad a vegtelen ciklusos dolgot, sem az inicializalatlan 's' valtozo ugyet. Az inicializalas (mikor kezdo erteket adsz neki) az nagyon fontos. Ellenkezo esetben a kezdo ertek nem garantalt. Lehet debug kornyezetben nulla lesz, elesben nem annyi, az is lehet hogy ha a Hold eppen C alaku es az Nagymedve epp lebukik a horizonton akkor nem nulla lesz hanem 63, de mikor a halak jobbra usznak a Dunan akkor 72.
A billentyu figyelest amugy nem is annyira egyszeru megoldani egy ilyen motor vezerles eseteben. Pl. a mostani programban egyaltalan nincs perges mentesites -- vagy van hardveres perges mentesito? Az elegans billentyu ill. motor vezerles interrupt vezerelt, de lehet nem kellene meg ennyire elore szaladnod. A lenyeg, hogy a kenyszer varakozasba kellene valahogy beillesztened a billentyu lekerdesetet, ill. az LCD-re torteno kiirast, csakhogy kozben a leptetesek kozotti idonek sem szabadna elcsusznia. Ez nem is annyira egyszeru feladat! Legtobbszor (mint minden mas mernoki teruleten) csak elfogadhato megoldasok vannak annak elonyeivel es hatranyaival.
Sziasztok. Először is köszönöm a válaszokat amiket kaptam pic beszerzés ügyben. Másodszor felmerült bennem egy új kérdés egy pic 16f84-el kapcsolatban. Szóval a kapcsolásban a picnek egy 10MHz-es kristály adja az órajelet. A kérdésem az lenne hogy kicserélhetem e ezt a picet 20MHz-s vagy 4Mhz változatra vagy a kapcsolás szempontjából nem mindegy? Ugyanis ezt a két típust viszonylag könnyen be tudnám szerezni de ez a 10MHz-s kicsit bonyi. Ha tud valaki akár használt 10Mhz-est megvenném. Előre is köszi a válaszokat.
Üdv
Mindenképpen ajánlatos a 20 MHz-eset beszerezned. A 4 MHz-esnek nincs a specifikációjában a túlhajtási lehetőség (10 MHz), ezért csak külön öröm, vagy sikerélmény, ha 10 MHz-et teljesíteni tud (persze páran sikerrel próbálták már a világon...). De az már nem tartozik bele a gyári működési tartományba.
Köszönöm a gyors választ
Szóval a pic-eknek ezek a megadott órajelei azt a maximumot jelentik amit bír? Tehát a 20Mhz-est én hajthatom 10 Mhz-en a kapcsolási rajt változtatása nélkül? Amúgy szerintetek ha a pic égetőmre az van írva, hogy 16f84A típust éget akkor ezzel a /P jellel elboldogul majd?
A P betű a tokozást jelenti. Ha viszont az égető 16F84A-t tud, és nincs ott a 16F84 a listában, akkor már nem biztos, hogy tudja égetni...
Sziasztok! Biztosra veszem, hogy már elhangzott jópárszor, de nem volt kedvem visszaolvasni 1151 oldalt pedig lehet csak pár oldallal ezelőtt hangzott el... Szóval a kérdésem a következő. Amikor MPLAB IDE ben csinálok egy programot, PIC18F877-nek akkor úgy kell kezdődnie a programnak, hogy:
Hol itt a kérdés?
Ez egy program rész a config sorral. A config leíréat nézd meg, megtudod mit csinál ez a config. De nem kell így kezdődni, ez csak egy eset a több száz variációs lehetőség közül. Idézet: „Szóval a kérdésem a következő. Amikor MPLAB IDE ben csinálok egy programot, PIC18F877-nek akkor úgy kell kezdődnie a programnak, hogy:” Eloszor is az, hogy MPLAB IDE az nem jelent semmit sem. Abban lehet Assemblerben is dolgozni vagy C-ben, es ezek kozul is lehet tobb fajta forditot talalni. Az Assemblerhez legtobbszor az MPASM-et szoktak hasznalni amit az MPLAB alap installalcioja mar tartalmaz. Masodszor: Az MPASM-ben a direktivak nem kezdodhetnek a programsor legelso karakter helyen. Minimum egy TAB vagy egy SPACE-nek kell lennie elotte. Cimkeknek es valtozo neveknek azonban csak es kizarolag az elso helyen szabad szerepelniuk. MPASM sajnos egyike azoknak a nyelveknek amelyik erzekeny az indentalasra. Harmadszor: Nyisd meg a "C:\Program Files\Microchip\MPASM Suite\Template\Code\16F877TEMP.ASM" -et, ill. a 16F877ATEMP.ASM-et ugyanonnan, majd mentsd el magadnak egy masik neven a sajat fejlesztesi konyvtaradba. Idézet: „majd mentsd el magadnak egy masik neven a sajat fejlesztesi konyvtaradba.” A legfontosabban nem említetted! El is kell olvasni! 
Ooooo, tul sokat feltetelezek emberekrol, mi?
Sziasztok!
Lenne egy gondom. Egy hőmérő szenzorról akarom leolvasni az értékeket SPI-n keresztül, de nem tudom megirni a szoftvert mert a close-ba beleköt, hogy valami bővítmény hiányzik. A forráskód az MCC18 doksikból való. Ha valaki tud akkor kérlek titeket segítsetek! Előre is köszönök mindent!
Az SPI kiiratást kihagytam, mert nekem az most nem kell blőle, csak az olvasás.
Pontosan melyik doksibol valo, es mi a hibauzenet?
Szia!
A C:\MCC18\doc\periph-lib könyvtár SPI dokumentuma. A végén található egy example és azt variáltam , de nem megy nekem sehogysem. A hiba: Idézet: „---------------------------------------------------------------------- Clean: Deleting intermediary and output files. Clean: Done. Executing: "C:\MCC18\bin\mcc18.exe" -p=18F45K20 /i"C:\MCC18\h" "SPI.c" -fo="SPI.o" -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa- D:\...\SPI\SPI.c:62:Error [1032] ')' expected in expansion of macro 'CloseSPI' Halting build on first failure as requested. ---------------------------------------------------------------------- Release build of project `D:\...\SPI\SPI.mcw.mcp' failed. Language tool versions: mpasmwin.exe v5.31, mplink.exe v4.31, mcc18.exe v3.31 Sun Sep 20 23:28:09 2009 ---------------------------------------------------------------------- BUILD FAILED”
Ja, latom mar. Nekem az spi.h -bol ugy tunik, hogy nem kellenek a programodba kulon funkcio deklaraciok. Probaldd meg kiszedni...
Szerintem is az a baj, hogy az spi.h headerben már deklarált CloseSPI rutin mégegyszer deklarálva lesz.
Na, akkor gomboljuk újra a mellényt! Ez az eredeti mintaprogram:
Most akkor azt kellene tisztázni, hogy mit és miért akarsz megváltoztatni benne? Az alábbi két sort és a függvény(újra)deklarációkat hagyd ki!
A függvények: getsSPI egy stringet olvas, ReadSPI egy karaktert olvas, DataRdySPI megvizsgálja, hogy van-e olvasható adat. A fenti hívássorozatnak így nem sok értelme látszik lenni... Szerintem előbb kellene a rendelkezésre állást vizsgálni (a visszatérési érték 1 vagy 0), utána olvasni. Vagy rosszul gondolom?
Sziasztok!
Köszönöm mindenkinak aki segített, főleg icserny-nek, mert mihejst kiszedtem a fölösleges deklarációkat, stb linkelési probléma volt már csak! De most szépen látom mit mér, vagyis abból 8 bitet. Mégegyszer köszönöm a gyors válaszokat! üdvözlettel: bubu |
Bejelentkezés
Hirdetés |
