Fórum témák
» Több friss téma |
HP41C:
Idézet: „A 80. sorban miért szerepel a programból való megszakítás kérése?” Csak a megszakítás működésének tesztelését szolgálta. Időközben feltettem az MPLABX v3.61-et, azzal végre működik a kontrollerben az időzítés, a megszakítás is, a szimulátorban megáll a megszakításban elhelyezett töréspontnál, viszont a TMR0H-TMR0L nem számol. Az időzítések messze nem a dokumentumoknak megfelelően alakulnak, de a lényeg az, hogy működik zenetom: Az csak a teszteléshez kellett. Köszönöm az észrevételeket és a segítséget! A hozzászólás módosítva: Máj 14, 2017
Nálam is a v3.61 van fent, de nem működik. Azzal a kóddal, amit fent írtál, belép a megszakításba, úgy is, hogy kitörlöd a főprogramban a TMR0IF állítást?
Sajnos mégsem sikerült megoldanom az i2c.h problémát.
A lib könyvtárból bemásoltam a saját project könyvtárába az i2c.h fájlt, az MPLAB projectben a heder fájlokhoz hozzáadtam, és azóta a #include "i2c.h" -ra már nem jön "no such a file" üzenet, de sajnos amint bármilyen ...i2c() függvényt szeretnék használni, undefined symbol üzenetet kapok. Ahogyan a csatolt képen látszik. Mi lehet a megoldás?
TNR0IF=1- el lehet ki lehet kényszeríteni, de a TMR0 túlcsordulásnál nem áll meg.
Úgy tűnik ezzel nincs mit tenni, nagyon új még az eszköz. Az időzítés sem a szimulátorban sem a kontrollerben nem működik korrektül. Egyéb IDE-ről nincs tudomásom, ami ezt a kontrollert támogatja.
Hát ha kézzel állítod a TMR0IF-et, annak nem sok értelme van.
Pont az lenne a lényeg, hogy a Timer0-ra bízod az időzítést, vagyis hogy lépteti a Fosc/4 a TMR regisztereket. Ha ez nem működik, akkor nincs értelme. Ha lesz rá időm, megpróbálom ASM-ben, de szerintem ott se fog menni. De amúgy ez elég nagy gáz, ha tényleg nem megy.
A 3.50- 3.60-al a TMR0IF-el sem állt meg a szimulátor töréspontjánál és nem futott a kontrollerben sem. Most fut, de nem azt csinálja, amit kellene. (Szerintem )
Jó lenne egy stabil verzió, amivel legalább játszani lehet. Kicsit szokatlan még az MPLABX, új a kontroller és nem kizárt, hogy elnézek valamit. Ezért próbálkoztam ezen a helyen végére járni a dolognak. Kíváncsi vagyok az ASM eredményére, mert ott azért feketén- fehéren látszanak a dolgok.
Ha van másik (régebbi) PIC-ed, próbáld meg azzal is.
Az persze csont nélkül, hibátlanul megy. (PIC18F2321-el)
T0CKI default pin: RA4: AN4
Idézet: „15.0 I/O PORTS .... Ports that support analog inputs have an associated ANSELx register. When an ANSELx bit is set, the digital input buffer associated with that bit is disabled.” Idézet: „17.1 PPS Inputs Each peripheral has a PPS register with which the inputs to the peripheral are selected. Inputs include the device pins. Multiple peripherals can operate the same source simultaneously. Port reads always return the pin level regardless of peripheral PPS ion. If a pin also has analog functions associated, the ANSEL bit for that pin must be cleared to enable the digital input buffer.”
A hozzászólás módosítva: Máj 14, 2017
A CONFIG1L-ben a HFINTOSC_64MHZ-et használom 8 MHz-en, így nem baj, ha a külső oszci dolgait nem állítom be.
Amúgy gyors kiszámolva (amit lehet elnéztem.. ) elvileg a T0 Int az ~0.015Hz-es! Tehát kb. 67 másodpercenként lépne csak be.. Kivártad a valóságban azt az időt? Bár ha a másik PIC-en működött..
A hozzászólás módosítva: Máj 14, 2017
A kérdés életszerű
De ezekkel a paraméterekkel 5 perc alatt másodszor már nem áll meg. (Úgy tűnik, hogy a szimulátorban elfelejtették léptetni a TMR0L - TMR0H-t, így persze nem lesz túlcsordulás, sem megszakítás)
Próbálom az MpLab X 3.61 -el a 18F46K40 programot szimulálni. Beállítanám a konfigurációs regisztereket. Jó sok Gooogle segítséggel megtalálom hol is lehet. Be kell állítani egyesével lisboxokban majd generál egy beállító kódot. De nem tudja lefordítani amit generált. ( )
Amelyiket hibásnak vélt, komment jelet kapott... 7 a 35 -ből. Egész jó arány, csak 20% hibás. A hozzászólás módosítva: Máj 15, 2017
Akkor gondolom Nálad se nőtt az MPLABX iránti elkötelezettség...
Lehet, hogy az MPLAB X-et direkt assemblyhez fejlesztették? Az egyéb programnyelveket pedig csak szőrmentén kezeli?
Ugyanis én még csak ezt a fordítót használtam, és csak assemblyben, de a fórumon eddig felhozott számtalan hiba egyikébe sem szaladtam még bele. Főleg abba nem, hogy a saját maga álltal generált konfigurációs kódot nem fordította le.
Mit csinálhattam rosszul?
A konfigurációs részt a 3. képen látható "Generate Source Code to Output" gombot megnyomva, az output ablakból a forrásba másolva csináltam. Az include <xc.h> sor lehet a config sorok előtt vagy után, a hibák maradnak...
Milyen verzió számú XC8-ad van? Nálam v1.4-el fordul.
Lehet, ha a legújabb van az problémás nálam XC32-ből az 1.43-as nálam nem megy rendesen csak az 1.42-ig.
Szerintem egyszerűen csak trehányul csinálják a C fordítót (mondjuk a C18-al is voltak gondok..), illetve az MPLABX-re való áttéréssel rengeteg hibát vittek be.
Ez egy rossz döntés volt a Microchip részéről, amit sajnos el kell fogadni, mert tuti nem változtatnak ezen a vonalon. A baj csak az, hogy egyre csak gyűlnek- gyűlnek a bugok, és nem tudni meddig mennek el vele.
Az a baj, hogy mivel neked C-re fordít, így az nekem tótul van.
Ugyanígy csinálom én is asm. alatt, de ott teljesen másképp néz ki a fordítás.
Én el kezdtem foglalkozni ARM-os MCU-kal is hát azok az IDE-k se kispályások... egyetlen szerencse ott, hogy ARM-ra van VisualGDB amivel a Visual Studio keresztül teljes native support van az MCU-ra programozás és debug szinten is.
Az a baj mindenki a Java felé megy és megpróbálják lenyomni az ember torkán az interpreteres f*st.
Már nem tudtam módosítani az 1.41-re gondoltam
De leszedtem az 1.42-őt is és azzal is hibátlan. Néztem MPLAB X v3.55 és v3.61 alatt mindkettővel egyikben se volt hiba nekem lefordult. Ha esetleg nem probléma küld át a project fájlt megnézem.
Ennél sokkal egyszerűbb a helyzet.
... A hozzászólás módosítva: Máj 15, 2017
Sziasztok,
Van valaki aki tudna segíteni abban, hogy miért nem fordul le az alábbi program? :0: error: (499) undefined symbol: _OpenI2C(dist/default/production\i2c_teszt.X.production.obj) hibaüzenetet kapok. A i2c.h fájlt a project könyvtárába másoltam, és hozzá adtam a projekthez. MPLAB X IDE v3.61 környezetben XC8 (v1.42) -vel.
A hozzászólás módosítva: Máj 15, 2017
Idézet: „Elkezdtem nézegetni: - Ahogy írták már mások is kitörlődött / megszökött egy sor. A pa deklarációja után kimaradt az értékadás. pa = & l[i][0]; - Milyen típusa is van a pa mutatónak? Olyannak kellene lennie, mint az l[][] tömb elemeinek. Azonban a int *pa; a deklarációja, az tömb pedig char l[6][26]; A char *pa; a jó megoldás. /// Az int ebben a fordítóban 16 bites (2 byte - os), a char pedig 8 bites (1 byte - os). Az int típusra mutatóként deklarált változó a ++ műveletre 2 byte -tal megy arrébb a memóriában. A Watch ablakba vedd fel a ps és a l változót és figyeld az értéküket. A ledkockanagy_2 képen az is látszik, hogy a pa változó szépen ellépkedett az l[1][25] címére. Így nem használható az oszlopok() hívásában paraméternek. Az is látszik a ledkockanagy_3 képen, hogy az indexelés milyen műveleteket hajt végre ... CALL _Mul_16x16_U, 0 Nini egy szorzó rutin...” Char volt tényleg a gond de a fényerö probléma ugyan úgy meg maratt.... Ötlet??
Sziasztok!
PIC el szeretnék jelgenerátort csinálni! Azzal nincs is gond ha mondjuk 2-4-5 stb MHz jelet akarok létrehozni! Mert azzal a frekivel behivok egy makrot! és a makroba megpenditem mindig a kimenetet! De.... van mondjuk egy 4Mhz-PIC em ( vagy kristályom) de én szeretnék mondjuk 160-170 MHz-es jelet generálni?!?! Erre mi a megoldás? Olyan kristály kell hozzá? vagy tudok valami szorzót használni?
(emlékeim szerint már az XC8-ban alapból nincs benne a plib)
próbáld meg a Properties ->XC8 Linker Link in Peripherial Libary-vel régen úgy emlékszem le lehetett még tölteni, de most nem találtam meg.
Olyan frekvenciával egy pic egyáltalán nem boldogul el. Valahol 10 környékén az elméleti lehetőségekből is kifutsz a jel összetettségének függvényében (pic32mz család 252 MHz-et tud asm szinten utasítás végrehajtási sebességnek, de abban talán még sram-ból futtatva is wait state-ek vannak, és az ugró utasítás 4 órajelet visz el per darab). 160-170-nél egy cpld / fpga kell neked. Mennyire lenne bonyolult szerkezetű a jel?
A hozzászólás módosítva: Máj 16, 2017
Szia Tanszka!
Bocsi a késői válaszért! Azért választottam ezt a procit, mert a 16 Demo Board-ban ez van benne. Tanulásnak szerintem jó, ha tönkre megy, kidobom és veszek másikat. Külső oszcillátort szeretnék használni, a Board-on 32kHz-es van gyárilag. A LED-ek is a gyári lábakon vannak RA0-RA7 között.
Igen erre gondoltam énis... hogy nem ez lessz az én megoldásom!
Amugy egy sima rf jel lenne! Foglalkoztat egy ideje az antennaanalizátor építése! Ahhoz gondoltam! De lehet hogy abszolute nem jo irányba keresgélek! Még sokat kell olvassak utánna!
Közben megtaláltam a saját topikját ugyhogy ezzel a kérdéssel költözök is oda!
|
Bejelentkezés
Hirdetés |