Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Ez eleg tipikus eset, de azt nem ertem, hogy ha a strukturatomb helyett egy sima char tomb van, akkor miert mas az eredmeny.
Sziasztok!
Egy olyan kérdésem lenne, hogy mivel valósítható meg az, hogy hardveres pwm jel minden (vagy valamennyi) lefutása egy megszakítást generáljon (kb. 16 kHz-en)? Pic12f683-at programozok ccsc-ben. Vagy ez csak szoftveresen érhető el? Nem tudom külső megszakítással vagy capature üzemmóddal megvalósítható-e? Előre is köszönöm!
A timer2 minden ciklusban megszakítást kérhet. A PWM jelet a TMR2 és a CCP midul segítsgével lehet előállítani.
Ezt egy kicsit nem értem. A timer2 hogyan kérhet minden lefutó élnél megszakítást?
(Bocsi de még nem keltem fel. ![]() A hozzászólás módosítva: Szept 12, 2016
És hogyan érhetem el azt, hogy a timer2 megszakítása ne felfutó, hanem lefutó élre essen?
Vagy mind a kettőnél megszakít?
Esetleg ha az adatlapon megnézed a timer2 lehetőségeit, nagyon hamar bármilyen részletesen megkapod a választ a kérdésedre.
A hozzászólás módosítva: Szept 12, 2016
Ahogy pajti2 is írta, ha elolvasod az adatlap ide vonatkozó részeit(timer2 modul, ccp modul) magad is kitalálod. De hogy egy kicsit aktívan is segítsek, a timer2 akkor ad megszakítást, ha a TMR2 regiszter = a PR2 periód regiszterrel, azaz minden periódus végén, vagy mondhajuk, hogy az elején, attól függ honnan nézzük. Ennél a típusnál a kitöltés kezdete nem variálható sajnos mindig a ciklus elejéről indul, de a PWM jel aktív magas, vagy aktív alacsony választható opció és ezt ki lehet használni, hogy felfutó vagy lefutó élnél akarod-e a megszakítást. Remélem érthető volt. Sok sikert.
A hozzászólás módosítva: Szept 12, 2016
Annyira felidegesítettem magamat az említett debug hibával hogy elhatároztam hogy újraépítem az egész projektet a nulláról. Amúgy is rengeteg dolog nem tetszett benne mert mikor azt a projektet elkezdtem még nem nagyon tudtam C-ben programozni szépen. (Pontosabban akkor még rondábban programoztam.) Rengeteg globális változó van benne, paraméter-átadások alig stb...
Na és a TFT-vezérlő függvényekkel kezdtem a dolgot. Szeretném azt hogy külön-külön c fájlok legyenek minden egyes kijelzővezérlőhöz (pl. ILI9341.c, SSD1963.c, R61581.c stb). Ezek a c fájlok pontosan ugyan olyan nevű és paraméterű függvényeket tartalmaznak csak maga a függvény tartalma más az egyes c fájlokban. Nem szeretnék melléjük külön header fájlokat, csak egyetlen egyet ami a TFT.h lenne, a függvények prototípusai is ebben vannak leírva. Ebben a TFT.h-ban van egy ilyen sor:
A c fájlokban a függvényeket belefoglaltam egy-egy ilyenbe:
Nyilván a másik fájlban az R61581 helyett pl ILI9341 van írva. A probléma az, hogy nem fordul le a kód, a c fájlokban lévő függvényekre "multiple definition of..." hibaüzeneteket ad a fordító. Miért, mit rontottam el? Itt vannak a fájlok: A hozzászólás módosítva: Szept 12, 2016
Nem nyitottam meg a fájlokat, de nyilván ez a hibaüzenet, ha minden c fájlban-ban ugyanazon néven vannak a függvények, és mindet behívod egyszerre. Vagy feltételes behívást kellene alkalmazni értem it az #if defined mert a sima ifnél mindent efordít em meg csak a definiált paraméterre vonatkozót , vagy más egyéb módon megoldani. Nem példálózom, mert épp hogy éren vagyok, alig tudok már gondolkodni,de a fönt leírtak alapján gondolkodj.
De pont ez az hogy elvileg nem hívom be mindet egyszerre, ezért vannak a c fájlban e közé foglalva a függvények:
Próbáld meg így:
Pontosabban lefordul és nem ír már rá errort, de warningot igen: "warning: character constant too long for its type". Ez probléma?
Hol írja, a feltételes fordítási direktíváknál, vagy valahol máshol a kódban?
Idézet: „TFT/Driver/R61581.c:5:5: warning: character constant too long for its type TFT/Driver/R61581.c:5:24: warning: character constant too long for its type TFT/Driver/ILI9341.c:5:5: warning: character constant too long for its type TFT/Driver/ILI9341.c:5:24: warning: character constant too long for its type” A két feltételes fordítási direktívához írja, ehhez:
És ehhez:
Nem gond. Nálam rendesen ment a váltás,a 2 init között.
Amúgy ilyen próbáknál ,amikor nem vagy bizti benne, akkor tegyél bele 1 return-öt mind2 init-be. Próbáld ki,hogy kiszeded a define-t,és ha egyből kiakad a fordító,hogy nincs Init függvény,akkor működik.
Biztos hogy működik mert amikor aposztrófok közé írtam azonnal kiszürkítette az ILI9341.c-ben a függvényeket az MPLABX (mert az R61581 van definiálva). Ha átírom a DISP_CONTROLLER-t 'ILI9341'-re akkor az ILI9341.c lesz aktív és az R61581 függvényei szürkülnek ki. Ha beírok valami hülyeséget akkor mindkettő szürke és a fordító kiabál hogy eltűntek a függvényei. Tök jó ez MPLABX...
Jópofa a Microchip!
![]() Idézet: „character constant too long Character constants must not be too long.” Ha túl hosszú a karakter-konstansod akkor a megoldás az hogy ne legyen túl hosszú. Kössz!
Próbáld dupla macskaköröm közé rakni. Elvileg ez egy multi-karakter konstans. Azt dupla macskakörömmel szereti. Akkor lehet,hogy nem dob warningot, de biztos nem vagyok benne, ki kell próbálni.
Nem minden warningot kell figyelembe venni,ki is lehet kapcsolni. Pl. nekem a sprintf miatt sír folyamatosan,mert nem chart,hanem unsignedet erőltetek rá.Ugyan úgy működik,de mivel ő char-t vár,ezért figyelmeztet.
Én ameddig lehet kerülöm az X-et... Megnéztem kb.30 kariig,és ott is működik,csak warningol ![]()
Igen az lenne a legjobb,de az #if bele fog kötni....
A szimpla idézőjelek karakteres konstanst jelentenek, az 1 karakter hosszú lehet. Próbáld meg dupla idézőjelek közé tenni!
Egyébként a másik megoldás, hogy nem értéket adsz a makrónak, hanem különböző makrók meglétét ellenőrzöd ifdef-fel. Tehát pl. az egyik forrásban #ifdef _DISP_CTR_R61581 lesz a sor, a másikban #ifdef _DISP_CTR_ILI9341 és így tovább. A főprogram elején meg értéket adsz valamelyiknek, pl. egy #define _DISP_CTR_ILI9341 sorral. Azt is szokták csinálni, hogy az összes létező értéket felsorolják egymás után #define-okkal, és a nem kellőket kikommentezik. Én úgy tapasztaltam, feltételes fordításhoz inkább ezt az utat, azaz egy makró meglétét vagy nem meglétét szokták használni, minthogy a makrónak értéket adjanak. De lehet, hogy csak kevés C forrást nézegettem még eddig ![]()
Azért én amondó vagyok, hogy illik a warningokat is értelmezni, és lehetőleg eltüntetni a fordításból. Nagyon kellemetlen lehet, amikor valami pointer nem megfelelő castingja vagy a casting hiánya miatt dob egy warningot a fordító, és ezt nem veszed figyelembe, holott a valóságban éppenhogy "hülyeséget" fog csinálni a program emiatt. ARM-es, memóriába ágyazott perifériaregiszter-struktúrákban párszor belefutottam, és elég sokat kellett a fordított assembly-t valamint a lépésenkénti debugot vizslatnom, hogy rájöjjek, mit rontottam el (és persze, hogy én voltam a hülye, nem a fordító).
A hozzászólás módosítva: Szept 12, 2016
Már én is akartam ajánlani a felsorolásosat,abba nem kötne bele a fordító.
Igazad van ,de az #if miatt nem működik a dupla idézőjel.Itt inkább string összehasonlító függvény lenne a legalkalmasabb,bár még nem próbáltam ennél a felállásnál. A sima idézőjelekkel úgy néz ki,hogy végigmegy a stringen,csak beleköt,hogy sok a karakter.
Header file problémához:
Zárd a fenti keretbe az összes headert, és nem lesz dupla header állomány, akárhányszor hívod is be őket #include-al. Értéket adni neki pedig nem kell. Az egy direktíva, nem egy változó. Az maga az érték, hogy már létezik, vagy még nem létezik. A hozzászólás módosítva: Szept 12, 2016
Ha idézőjelek közé írom, akkor nem fordul le:
Idézet: „error: token ""R61581"" is not valid in preprocessor expressions” A felsorolásos megoldás nem tetszik mert nem olyan elegáns a ki-bekommentezgetés szerintem. A warningokra pedig figyelni kell! Néha tényleg fontos dolgokról szólnak. Nálam általában nincs egyetlen warning sem, kivéve ha nagyon sietek. Szerk.: Na jó meggyőztetek, így lesz:
A hozzászólás módosítva: Szept 12, 2016
Akkor a stringeket lecserélheted szimbólumokra (makrókra):
A TFT.h-ba beteszed ezeket:
Utána ahol ki akarod választani az aktuális drivert:
Végül a driver forrásokban a feltételek:
Így kikerülöd a stringek használatát, és elég beszédesek lesznek a feltételeid is. Egyébként én személy szerint az összes lehetőség felsorolását és a nem kellők kikommentezését azért szoktam szeretni, mert később bármikor elővéve a forrást, elég beszédesen látszik, hogy mik a lehetőségek, és nem kell más forrásfileokban kotorászni ehhez. De persze ez ízlés kérdése, nem kötelező használni. A hozzászólás módosítva: Szept 12, 2016
Ööö az a #define úgy nem lesz jó
![]()
Sziasztok!
Lenne kettő kérdésem: Valakinek nincs valami nagyon egyszerű FAT32-es SD (SPI) library-je, nem szeretnék a dologhoz most a fájl rendszerekben elmélyedni, egyenlőre a lényeg az lenne, hogy működjön? A PIC32-eseknél, ha SPI/UART-ról beszélünk PPS-el a TRIS-t nem kell piszkálni beállítja magától, de ha analóg lábon van az SDI/RX akkor ahhoz tartozó ANSEL-t törölni kell? |
Bejelentkezés
Hirdetés |