Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Rendben köszi szépen! Remélem sikerül vhogy hozzákezdenem.
Itt a Hobbielektronikán is van jónéhány cikk azokat is olvasd el.
Erdemes ezt a forumot az elejetol a vegeig vegig olvasni meg akkor is ha hosszu es faradalmas. Rengetegszer elhangzott mar ehhez hasonlo keres es sok link is van, sok megvalaszolt kerdes is. Azonkivul a cikkek kozott a "Nullatol a robotokig" c. cikket elolvasod az is segitseg lehet.
Igen elolvastam végig mindent de nekem vhogy sehogy sem tiszta a regiszterek meg minden. Az a baj hogy ezzel kapcsolatban semmi tudásom nincsen mert láttam egyesek nullák parancsszavak stb de az hogy hogy függ össze meg stb ez nekem nagyon ködös. ehéz este vok tudom de ezt mindenféleképpen meg akarom tanulni, és ezért szeretnék lehetőleg személyes segítséget. Lehet hogy elég fura elképzelés de ha elmagyarázza valaki úgy jobban megértem, és vmilyen programozási nyelvismeret sem lenne hátrányos. szal én nem 0 ról hanem -10 röl kezdeném
 
[OFF]
Ilyen ertelemben viszont lehet erdemes lenne az alapoktol elindulni - pl matematika, kulombozo szamrendszerek, logikai muveletek stb. Aztan pl a Szamalknak volt egy viszonylag jo alap konyve, ha jol emlekszem Bevezetes a szamitastechnikaba a cime, azt hiszem Szelezsan Janos irta. Biztosan meg lehet kapni ezt a kornyekeden egy konyves boltban.
Olvasnod kell akkor sokat. Itt is van egy leírás, annakidején azt hiszem én is ezzel kezdtem: Bővebben: Link
Ezt mindenképpen: http://fairco.freeweb.hu/. Én innen tanultam.
Erre még senki? Assembly-ben mi az a kód, amivel véletlenszerűen tudok kiválasztani egy változót gomb nyomásra?
Egy megoldási lehetőség: a gombnyomás pillanatában kiolvasod a TMR0 értékét, ebből maszkolással előállítod a kívánt véletlenszámot ( pl. TMR0 &00001111B --> 16 különböző véletlen számot ad!), majd ezt a számot indirekt címzésnél felhasználva kiveszed a változód értékét a memóriából!
Steve
Ha hajlandó vagy október első hétvégéjét rászánni akkor tudok neked segíteni, feltéve hogy eljössz Debrecenbe. Akkor egy hétvége alatt képbe kerülsz. A szeptember nekem nem jó mert éppen albérletet cserélek.
Addig pedig szépen csinálj egy klón ICD2-t vagy PICkit2-t aztán adott esetben nálam felprogramozzuk.
Zajgenerátor jelének AD konverziója....
Köszi a lehetőséget zsimon! Komolyan megfontolom, csak kérdéses hogy hogy lesz mert idén érettségizek szalagavató stb de egy 7végére megpróbálok elmenni. Méegyszer köszi!
Nem pont világos, pl a maszkolással hogyan lehet véletlen számot létrehozni, és a többi..
Egy hétvége nem a világ. Ahhoz elég hogy nagyon jól el tudj indulni. mindentől függetlenül arra van időd amire akarod. Én ICD2-t használok, bár van gyári PICkit2-m is, szóval van választék...
 A többit magánban, MSN.
Ha készítesz leírást, szívesen elolvasom
Megnézné valaki,h ez a kapcsolás jó-e PIC és léptetőmotor összekapcsolására?
A véletlenszámot a TMR0 kiolvasásával hozod létre ( ez egy nagy sebességgel pörgő számláló 0-255-ig, így a lenyomás pillanatában előre nem tudhatod, milyen számnál jár --> a kiolvasott szám "kvázi" véletlen!).
A maszkolás azért kell, mert valószínűleg nem 256 különböző változó közül akarsz válogatni, így a maszkolással állítod be a változók lehetséges darabszámát ( a változók számának ezzel az "egyszerű" megoldással 2 egészszámú hatványainak kell lenniük, de megoldható másképp is)! Steve
Akár jó is lehet, de hogy ezzel mire mész nem tudom. Sokféle léptetőmotor van, és sokféle kommunikációs protokoll is elképzelhető a vezérlő program felől. Így ez a kapcsolás csak egy darab "vas". Ha meg tudod tölteni lélekkel, akkor működhet, mert az illesztések jók.
Felejtsd el a maszkolast egyenlore. Gondolj bele, van egy idozito aramkor a PIC-ben, ez porog ezerrel, es minig mikor eleri a maximalisan abrazolhato szamot, akkor elolrol kezdi.
Valaki megnyomja X idopillanatban a gonbot, es ebben a pillanatban kiolvasod mi van a szamlaloban eppen aktualisan. Mivel a gomb megnyomasanak idopillanata a felhasznalotol fugg ezert a kiolvasott szam veletlenszeru lesz... Maszkolassal cupan annyit ersz el, hogy az igy kinyert szam ertektartomanyat lecsokkented - ezt azert szoktak, mert ha a szamlalo nem porog "eleg gyorsan" akkor a szam felso bitjei nem lesznek veletlen szeruek - azaz egymas utani gombnyomasokkor a kiolvasott szam minden esetben nagyobb lesz az elozoleg kiolvasott szamtol, legfeljebb a kulonbseguk lesz veletlenszeru. Ezeket lehet orvosolni mindenfele matematikai mutatvanyokkal is de a maszkolas a legegyszerubb, tehat pl ha az also 4 bitet nezed ilyenkor csak, akkor azok mar meglehetosen gyorsan fognak cserelodni hogy a szam teljes mertekben veletlennek tunjon - viszont igy 0-15 -ig lesz a tartomany...
USB az eddigi legkisebb, legkevesebb lábú tokban.
Van de csak ASM. Másfelől videó memóriás jellegű, és időzített megszakítás frissíti másodpercenként 30x... Megfelel?
Érdekesen hangzik ez a memóriás frissítős dolog. Frissítéskor az egész kijelző újra felülíródik, vagy csak az előző frissítés óta megváltozott karakterek ? Nem foglal ez le egy picit sokat a PIC szerény ramjából ?
Én is csináltam ilyet, igaz, csak 1x16-os kijelzőhöz, ott azért nem akkora "pazarlásról" volt szó.
Az az előnye viszont megvolt, hogy a főprogram folyamán semmivel nem kellett foglalkozni, csak beírni a 16 byte megfelelő pozíciójába a karakterképet és már lehetett is továbblépni, nem volt várakozás, ilyesmi. További előny, hogy nem kell FIFO-kezelést sem megírni, tulajdonképpen a legkézenfekvőbb és leggyorsabb megoldás. A rendszeres timer interruptban meg mindig egy műveletet végzek csak el, majd beállítom a művelettől függően, hogy hány interruptot kell kihagyni, hogy az adatlap szerinti leghosszabb feldolgozási idő is biztosan elteljen. Pl. úgy emlékszem, a "cursor home" parancs elküldése után többet kell kihagyni, mint egy egyszerű karakterkép kiküldése után. A megoldás hátránya, hogy nem tudod kihasználni az LCD modul adta lehetőségeket, pl. autoscroll, kurzorvillogtatás, ilyesmi (mert ugye folyamatosan az történik, hogy "home", aztán a 16 karakter kiírása, majd ez kezdődik elölről).
A Program PIC24. De szerintem ez nem probléma mert olyan "mezei" utasításokat írtam hogy bőven érthető mondjuk PIC18-on. Igazából az ötlet a lényeg.
Kurzorvillogtatás meg ilyenek szerintem tök fölösleges dolgok benne. Egy kijelző kijelezni van. Mivel a PIC-nek van POR-ja ezért az inicializálásnál az első utasítás előtti extra hosszú szünettel nem foglalkoztam. 40MHz-re írtam, de PIC24-nél egy utasítás két cikluss, szóval eleve dupla a sebessége. Másfelől van benne egy HD44780 nevű makró ami azt csinája hogy: HD44780 [Char/Command], [R/W], [Data] A videómemóriáról meg annyit, hogy mivel 4x20 kataktereshez terveztem, 80-at foglal le. De mivel a PIC24 word szervezésű ezért 80 word. A kommenteket angolul írtam mert ha valami gondom volt untam hogy a kommeneteket át kell írni angolra a microchipnek...
Elfelejtettem írni: a teljes kijelző frissül.
Hirtelen nem ismerek olyan PIC-et aminek 80byte gond lenne a GPR-ből... Egyébként PIC24HJ256GP610-et használok az nem éppen a szerénységéről híres... Idézet: „Kurzorvillogtatás meg ilyenek szerintem tök fölösleges dolgok benne. Egy kijelző kijelezni van.” Igy van, igy arra is valo, hogy kijelezze hol kell a usernek beadnia az inputot... Ha nincs input akkor nyilvan nem kell kurzor. A szoveg eltolas (scroll) meg ott nagyon hasznos, amikor a megjelenitendo uzenet hosszabb vagy tobb sorbol all, mint amit a kijelzo egyszerre meg tud jeleniteni. Az elmelet az, hogy a firmware egy nagyobb kepernyonyi teruletet tolt fel mindig ugyanarra a memoria cimre ir stb, es kozben a nyilakkal pl a user tudja eltolni az eppen lathato "ablakot". Pl tobbsoros menunel is lehet alkalmazni ilyen technikat, egyszer kell csak a kepernyot feltolteni es utana mar elegendo csak scrollozgatni fel-le. Vagy van ket fix kepernyod, es a valtast scrollozassal oldod meg ahelyett, hogy az egesz kepernyo tartalmat ujra es ujra atmasold a PIC memoriajabol a kijelzore. Szoval az intelligens vezerlo erre is jo, hogy teher mentesitse az eszkozunket - bar lehet, hogy egy kamionban mint amivel Te is dolgozol mar engem sem erdekelne ha 3 fotellel tobbet kell hurcolasznom
Most hogy utánna gondolkoztam a videó frissítésnek nem kellene kimerülni csak a látható adatokban. Semmi akadálya pl annak hogy a frissítés végén még utasításként megadjuk hogy hová pakolja le a kurzort és hogy villogva hagyja ott.
Ezt a kamiont meg fotelt nem értem... Idézet: „Most hogy utánna gondolkoztam a videó frissítésnek nem kellene kimerülni csak a látható adatokban.” Ebben igazad van, de ha jol ertettem a technikat - es a Szilva fele megoldast mar lattam arrol tudom, hogy errol van szo - szoval ez a technika azon alapszik, hogy van egy timer megszakitas ahol is a "video memoria" kimasolodik az LCD-re. Azaz folyamatosan megtortenik a masolas ha kell ha nem kell szemben azzal, hogy a masolas 1x megtortenik, majd legkozelebb akkor ha valoban valtozik a kepernyo tartalma. Pl. kint van a menu az LCD-n, a user amugy is gondolkodik, hogy mit kell csinalnia, ezelatt az ido alatt a frissitgetos modszer akar tobb ezerszer is ujra toltheti az LCD-be a teljes kepernyot. Scrollozassal meg az is elerheto, hogy a legelejen az egesz kepernyot letoltjuk az LCD-re, majd utana csak kiadunk 1-1 parancsot, hogy "le" vagy "fel" es tobb mindennel nem is kell foglalkoznunk. De azt alairom, hogy sokszor a controllernek ugyis van annyi felesleges ideje, hogy ezek a kepernyo frissitgetesek ne okozzanak problemat. Idézet: „Ezt a kamiont meg fotelt nem értem..” Rossz hasonlat arra, hogy egy bohom nagy 24H-val dolgozol Igazandibol csak irigykedem |
Bejelentkezés
Hirdetés |
