Fórum témák
» Több friss téma |
Kellett számolgatni: 5*60 = 300, 9966 = int(10000 * 300/301).
Ha valamelyik megszakításkérés aktív, amikor a sleep utasítást végrehajtja a kontroller, azonnal fel is ébred... Ahhoz, hogy 2 percenkét ébredjen fel az kellene, hogy a Timer1 2 percenként járjon le, azaz Fclk/4/8/65536 legen kb. 1/120 Ez kb 17.478 kHz órajel lenne - elfogadhatatlanul alacsony. Inkább ébredjen fel, számolja a felébredéseket, ha eltelt két perc, végezze el a feladatát, ha még nem telt el a két perc, mehet vissza aludni. Idézet: „Ahhoz, hogy 2 percenkét ébredjen fel az kellene, hogy a Timer1 2 percenként járjon le” Nos igen, azt hiszem, akkor elérkezett a pillanat, hogy azt is leírjam, mi lesz a program célja ha kész lesz.  Tehát egy lézeres köridőmérő stoppert szeretnék készíteni. Cél, elsősorban, egy másfél perces pályán versenyzünk haverral biciklivel, hogy ki tud rövidebb idő alatt 1 kört menni a pályán. Ezt szeretnénk ugye tizedmásodperc pontossággal mérni. Mivel akkumulátorról menne az egész, és szeretném, ha fél napot vígan kibírna töltés nélkül, így úgy gondoltam, hogy mivel tudom, kb mekkora 1 köridő, akkor azt be lehetne állítani az eszközön, aztán -20mp és az így kapott idő lenne az, ameddig az eszköz alvó módba lép és úgy számol tovább. És így csak akkor fogyasztana sokat amikor tényleg van rá szükség, de amikor csak számol és nem kell figyelni semmi mást, akkor aludna szépen csendben. Meg ugye e-melett szeretnék egy olyan funkciót is, hogy ne csak 1 beállított idő után ébredjen fel, hanem gombnyomásra is fel lehessen ébreszteni. És ami fontos, hogy alvás közben számoljon tovább.
Mivel mindezidáig nem kaptam semmi tippet, vagy útbaigazítást, tovább vizsgálódtam a többmodulos project tekintetében. Átvittem az egész cuccot MPLAB 8-ba, és láss csodát; ott működik.
Tehát két lehetőség van: 1.) X alatt máshogy megy a dolog. 2.) Az X hibás. (Ezt valószínűbbnek tartom.) Ezekután bizonyára most valamelyik microchipes fejlesztő anyukája csuklik rendesen. Idézet: Ezt pl INT0, RB portmegszakitassal el lehet erni.„Meg ugye e-melett szeretnék egy olyan funkciót is, hogy ne csak 1 beállított idő után ébredjen fel, hanem gombnyomásra is fel lehessen ébreszteni.” Idézet: Ez csak aszinkron uzemmodban lehetseges, mert Sleep eseten leall az oszcillator. Lehet hasznalni egy kulso 32768 Hz orakvarcot a TMR1 oszcillatoran. Akkor alvas alatt is szamol tovabb a TMR1. „És ami fontos, hogy alvás közben számoljon tovább.” Ajanlanam a PIC adatlap gondos tanulmanyozasat. Kulonosen a TMR1, az IT, es a Sleep funkciok leirasat. Onnan sokminden kiderul. Pl a Sleep utasitas utan illik berakni egy NOP(); utasitast, mert ebredeskor mindig a Sleep utani utasitast fogja vegrehajtani. Idézet: „Ezt pl INT0, RB portmegszakitassal el lehet erni.” Ez meg is volna, csak sajnos onnan folytatja, ahol elment sleepbe, tehát nem számolt alvás közben. Idézet: „Ez csak aszinkron uzemmodban lehetseges, mert Sleep eseten leall az oszcillator.” CCS C nyelv esetén hogy váltok aszinkor üzemmódba? Idézet: „Lehet hasznalni egy kulso 32768 Hz orakvarcot a TMR1 oszcillatoran.” Feltétlen 32768 Hz-s kvarc kell? Más fajtával nem oldható meg? Idézet: „a Sleep utasitas utan illik berakni egy NOP(); utasitast,” A CCS C compiler "Undefined identifier" nek jelöli. Azaz ismeretlen parancs.
Hmm, a NOP()-ot nem fogadja el annak ellenére, hogy az elején definiálva van így:
De ha a mainen belül már nem a NOP()-ot hanem csak szimplán ezt használom:
Akkor viszont jó. Valamiért a definiálást nem fogadja el. Viszont különbséget a gyakorlatban nem tapasztaltam így NOP használat esetén. (Bár biztos vannak esetek, mikor elengedhetetlen a sleep után). A többire továbbra is váron a válaszokat. Köszi.
Pesze hogy nem szamol Sleep alatt mert a PIC oszcija is alszik. A regisztereket es azok bitjeit lehet birizgalni a programbol. Pl ebben az esetben
A NOP lehet igy is
Ja es meg mindig ervenyes, hogy tanulmanyozd a PIC adatlapjat, mert abbol pl kiderul a TMR1 hasznalati modja is. Ingyenesen letoltheto a MCHP honlapjarol.
Idézet: A PIC mukodesebol adodoan illik betenni, mert a Sleep utan mindig a kovetkezo parancsot hajtja vegre, es csak azutan lesi pl az IT-t. „Viszont különbséget a gyakorlatban nem tapasztaltam így NOP használat esetén.”
Ha amit írtál berakom a programomba, akkor iszonyúan lelassul a számolás.
Idézet: „Ja es meg mindig ervenyes, hogy tanulmanyozd a PIC adatlapjat, mert abbol pl kiderul a TMR1 hasznalati modja is. Ingyenesen letoltheto a MCHP honlapjarol.” Persze, tisztában vagyok vele, le is van töltve PDF-be, csak sajnos, iszonyú sok minden van benne, meg sajna nincsenek benne C nyelvű parancsok, és így nem igen értem mik vannak beleírva, főleg, hogy angol. Szóval inkább csak a lábkiosztás miatt szoktam nézegetni, hogy melyik láb mire jó. Persze, most jöhet, hogy akkor el kéne kezdenem assemblyben programozni, hogy megértsem, de egyszer próbáltam, kb 50 sor programkód után meguntam, mert rájöttem, hogy az C-ben alig pár sorból megvan.
Az igaz hogy C-ben pár sorból megvan, de látod mennyi kínlódással jár ha nem értesz a belsejéhez és ilyen projektre adod a fejed
 . Én is voltam hasonló cipőben mint te de mióta rájöttem hogy az úgy nem jó áttértem az assemblyre és lehet hogy eleinte nagyon sok gonosz dolgot fogsz benne találni amivel nehezen gyürkőzöl meg de hidd el megéri az assemblytől tanulni. Szép fokozatosan.
Mi az ami lelassitja?
A kolleganak teljesen igaza van. Latod itt kinlodsz egy par napja egy egyszeru kis dologgal mert 1: Nem ismered a PIC belso felepiteset 2: Nem tudsz programozni Igenis ugy lehet jol megismerni a PIC lelkivilagat, es a programozasat, ha elkezded olvasni a doksit es parhuzamosan irsz 1-1 eszeru ASM programocskat. Leirtam mar sokszor. Es kezdoknek ez a nehezebbde eredmenyesebb eljaras.Demo panelek Demo programok, doksik Itt talalsz ASM es C mintapeldakat, valamint PIC doksikat. Melle meg demo panel terveket. A CCS C telepito konyvtarat is erdemes vegignezni mert talalsz benne sok peldat, drivert klf HW elemekhez.
Egyre jobban kezd idegesíteni az MPLAB X. Miután már elég nagyra dagadt a program amit épp írok, folyamatosan kiakad a fordító és bedobja azt az aranyos hibaablakot. Próbáltam már leszedni és újratelepíteni, emellett új projectet létrehozva tiszta lappal indulni, de az sem segít. Nem tudom hogy mi a baja, mert pl. ha törlök egy üres sort, akkor utána nem akad ki fordításkor, aztán ha változtatok a szövegen, akkor megint kaki van. Középeurópai karakterkészletet használok - amit esetleg nem szerethet -, de ékezeteket csak a megjegyzésben használok. Egyébként látható a szerkesztőben hogy sokszor a betűk színe nem a típusra jellemző, hanem fekete. Szóval... szerintem van még mit javítaniuk a fejlesztőknek.
Mivel azonban a szerkesztője sokkal jobb mint a fapados MPLAB 8-é, inkább ezt használnám. Viszont fordítás, szimuláció és programozás terén az MPLAB 8 sokkal gyorsabb és megbízhatóbb. Nektek milyen tapasztalataitok vannak az X-ről?
Az MPLAB X-et nem ajánlom senkinek. Teljesen alap szinten mozog még és miért mi kínlódjunk vele ha vannak erre tesztemberek. Ajánlom hogy addig amíg a jól megszokott régi MPLAB fejlesztés alatt áll használd azt mivel megkíméled magad ezektől a gondoktól valamint egy rahedli eszközt támogat amit az MPLAB X még nem!
Az MPLAB 8 teljesen jól ellátja a feladatát - ez kétségtelen -, de szerkesztő része az messze el van maradva a kor szintjétől. Vessd csak össze a Microsoft Visual studio fejlesztőrendszerrel, ami már 10 évvel ezelőtt volt olyan, (vagy jobb) mint az MPLAB X.
Szóval... én annak örülnék ha olyan felületet, szolgáltatásokat és megbízhatóságot kapnék, mint a fentebb említett fejlesztőrendszernél. Sajnos ez még messze van onnét.
Nem próbáltál külső szerkesztőt? Én Notepad++szt használok és teljesen bevált. Persze ez egyén függő
Mondjuk egyel többször kell megnyomni az alt+tab-ot.
A szerkesztő az tényleg nem a legjobb, de első az hogy a lehető legjobb fordítást és megbízhatóságot kapjuk. Hiába lesz csilli villi a felület ha a kód meg tele lesz hányva minden hülyeséggel és rosszul fogja fordítani mindamellett hogy jóformán nem támogat csak pár eszközt.
A külső szerkesztő nem helyettesíti a fejlesztőrendszer sajátját. Az IDE szerkesztője pl. felismeri az assembly mozaikszavakat, a direktívákat, a szám és szöveges változókat, és ezeket azonnal különböző színekkel jeleníti meg. Így rögtön lehet látni, ha valamit elgépelt az ember. Emellett egyből le is lehet fordítani a kódot, ahol szintén rögtön kijönnek a durvább hibák, vagy látható a memóriafelhasználás, stb.
Nem a csilli-villi, ami hiányzik, hanem a szolgáltatások. Az hogy a durva hibák ne futtatáskor jöjjenek elő, hanem már az íráskor. Hogy a szerkesztő segítse és megkönnyítse a programozó munkáját. Aki írt már hosszú, bonyolult programot, az tudja mit jelent ez.
A fordítás milyenségéért meg egyébként sem a szerkesztő a felelős, hanem a fordító és a linker. Az MPLAB X eszköztámogatásával pedig nekem - személy szerint - nincs semmi gondom.
Mondjuk nekem van mert a PICkit2-est még mindig nem támogassa megfelelően. Mondjuk a szerkesztője nagyon átlátható az igaz de még mindig volna mit csiszolni. Viszont tökéletes sohasem lesz és nem is fogja utolérni a mai fejlesztőrendszerek szintjét szerintem. De ez saját vélemény. Én mondjuk egy kezdőnek biztosan nem az X-et javasolnám. És kisebb programokra untig elég a 8-as szerkesztője. És legalább az újonc megtanulja szépen felkommentezni és rendezni a programját úgy hogy szép és átlátható legyen ne pedig összevisszaság.
Ezeket csinálja ám az is amit írtam, és még jópár (ultraedit, programmer's notepad...). Sőt, be lehet állítani külső futtatást, így ha van kedve az embernek, akár abból is meg lehet hívni a fordítót, parancssorosan. Tud kódkiegészítést is. Amit nem tud, az a szimuláció, a könyvtári függvények paraméterezésének a súgását. Bár azt nem tudom az mplab tudja e. Az alt+tab pedig azért kell mert azzal átváltok az mplabra, és ott fordítok. Szerkeszteni viszont (szerintem) jobb a n++, fejlett könyvjelző, kereső, ha kijelölök egy változót, kiszínezi mással a többi előfordulását, lényegesen kontrasztosabb, részletesebb a színezése.
Balsorsom egy 25K80-as PIC programozasara kenyszerit es a regi mpasmwin-em nem ismeri ezt a tipust.
Nem hasznaltam eddig az mpasm fejlesztokornyezetet, csak a forditot. Az ujabb csomagokban mi fordit? Mert nem talaltam az 4-esnel ujabbat (ez nem a csomag, hanem az mpasmwin verzioja!)
Az MPLAB-bal települ az MPASWIN (MPASM Suite mappában). Nálam most v5.42-nek mondja magát, s ezt tavaly augusztus végén töltöttem le (MPLAB 8.76). Ebben szerepel a PIC18F25K80 típus.
Pontosan hogyan lehet külső szerkesztőt használni az MPLAB 8-hoz? Mennyire működik vele együtt? Szintaktikai ellenőrzéssel mi van?
Amit én pl. még az MPLAB-ból hiányolok, az az azonnali paraméter- és címzésmódellenőrzés, tehát hogyha elhagyom az aktuális sort, akkor azonnal kiértékelje azt, és figyelmeztessen ha hibás címzésmódot, vagy paramétert használok, és esetleg ajálja fel a lehetőségeket. (Visual Studionál ez is megvan.)
MpLab 8.85: MPASMWIN.exe v5.45, mplink.exe v4.43, mplib.exe v4.43
Fordítani tudsz rá, de a szimulátor még beta és PICKit3 kell a programozásához. A PICKit2 V2.61 sem tudja programozni (csak a 18F26K80 -at).
Configure=>Settings=>External editor. A címeket nem fogja ellenőrizni, a paramétereket stb. nem ellenőrzi, bár kiegészíteni tud valamilyen szinten, igaz én nem használom, így nem tudok sokat mondani róla.
Indítani sem az mplaból szoktam, lusta vagyok, így csinálok mindig egy parancsfájlt, ami az adott feladathoz szükséges fájlokat megnyitja, elindítja a programokat (pl: mplab, forrás, header, adatlap, pickit...).
Hp41C, Icserny
Koszonom, en sajat programozot hasznalok, csak a hex filet elo kellene allitanom valamivel. Ha lehetne, nem telepitenem azt a par szaz megat, ezert kertem, ha valaki fel tudna tenni az oldalra a legujabb mpasmwin-t...
Szia!
Az MpAsmWin nem biztos, hogy elég: Idézet: „Due to the various limitations of COD format, versions 5.3 and above of MPASM do not generate COD format as the output of an absolute assembly file.” Idézet: „MPASM Assembler v5.00 and later will have backward compatibility to earlier versions at the source level only.”
Eddig azt gondoltam, a prell jelenség csak akkor lép fel, mikor a kapcsoló/nyomógomb/stb. érintkezői egymáshoz csapódnak, azaz bekapcsoláskor. Pénteken viszont beleolvastam egy PDF-be, amiben az szerepelt, hogy az érintkezők szétválásakor is van ilyen jelenség. Ha ez igaz, akkor módosítanom kell a programomat, mert a jelenlegi formájában nem fog helyesen működni. Szerintetek?
|
Bejelentkezés
Hirdetés |
