Fórum témák
» Több friss téma |
Talán így:
Idézet: Ez így nem az ! „Egyszer kell amúgy lefutnia a program elején.” Idézet: Így talán nem annyira rossz. „De hiába a while parancs ugyanúgy rossz”
Sziasztok!
Egy kis segítségre lenne szükségem. Szeretnék egy többcsatornás mérőpanelt készíteni PIC+ds18b20-as eszközökkel. LCD kijelzés+soros portos adatátvitel... Az lenne a gondom, hogy 24 érzékelőt kellene mérjek, de az előző fórumozások alapján arra a végeredményre jutottunk/ jutottam, hogy 3 különböző lábon lenne 8-8 eszköz. Na most, hogy a kód ne legyen túl nagy, szeretném átírni a ds-hez tartozó függvényeimet úgy, hogy kapna még egy argumentumot, és az alapján lenne eldöntve, hogy melyik lábon kell mérni. Csakhogy nekem van egy 1wire.h fájlom, amiben define paranccsal adom meg az OW láb "helyzetét" és ezt hogyan tudom feltételes fordítássá tenni? Mármint hogy bármikor módosulhasson a meghívott argumentum függvényében?
Először valami ilyesmire gondoltam:
És a meghíváskor:
Csak így nem jó. Idézet: „Csakhogy nekem van egy 1wire.h fájlom” Koncepcionális hiba van az elképzelésedben. A .h fájlhoz tartozik valahol egy .c fájl, amiben a .h-ban felsorolt függvények beltartalma van megadva (a .h csak a függvények meghívását mutatja, de a konkrét implementáció máshol van). Nem elég a .h fájlt módosítani, a függvények implementációjához is hozzá kell nyúlni.
Az tiszta sor. Csak azt szerettem volna tudni, hogy van-e rá valamilyen eljárás, hogy ezt a két sort
megtudjam változtatni valahol máshol. Mivel ezt nem tudom, így kénytelen vagyok megírni a :
és így tovább..... És persze ezeket is:
A hozzászólás módosítva: Szept 28, 2013
Idézet: „hogy ezt a két sort megtudjam változtatni valahol máshol.” Nem azt a két sort kell megváltoztatni, hanem azokat a sorokat, ahol ezeket a makrókat felhasználod. Persze megoldás lehet az is, hogy legyen 3 verzió mindegyik függvényből. Annak fényében, hogy 8-bites PIC-ről beszélünk, érdemes megnézni azt is, hogy a függvények kibővítése egy plusz paraméterrel mennyivel bonyolultabb kódot fog eredményezni assemblyben. Ha nagyon, akkor simán lehet, hogy nem éri meg az, hogy ne legyen 3 verzió mindegyik függvényből. A hozzászólás módosítva: Szept 28, 2013
Idézet: „simán lehet, hogy nem éri meg” Igen, ezt szerettem volna elkerülni azzal, hogy megváltoztatom a lábat, így csak arról kell gondoskodjak, hogy akkor tudjam, hogy csatornaváltás történt. Szóval Idézet: : „Nem azt a két sort kell megváltoztatni, hanem azokat a sorokat, ahol ezeket a makrókat felhasználod.” pl. van egy ilyen függvényem:
Akkor itt mit kellene átírnom?
helyett pl.
nyilván az OW.. makrókból kell csinálni három készletet.
Egy ilyen megoldás is működik:
Nekem a legtöbb infót ez a megoldás adja:
Egy kapcsolási razhoz beállítani így a legkönnyebb szerintem. Minden más megoldás, számomra csak áttekinthetetlenné teszi a kiosztást. Kinek a pap.... A hozzászólás módosítva: Szept 28, 2013
Nem inicializálásról, hanem egy kiterjedt 1-Wire (a számosság miatt több vezetékre kötött) érzékelő rendszer kezeléséről volt szó. Ahhoz kerestem ötletet, hogy ne kelljen annyiszor elkészíteni, leírni a 1-Wire kezelő függvényeket.,,
Sziasztok!
Feladtam a jó kis langyos CCS-t és elkezdtem C18-al foglalkozni, de az őrületbe kerget a warningjaival. Hogyan lehetne ezektől megszabadulni? (Természetesen nem a warningok kikapcsolására gondoltam)
erre Warning [2066] type qualifier mismatch in assignment
erre pedig Warning [2054] suspicious pointer conversion az uotdata egy egyszerű char[64] és az strncmpram2pgm hívásra mindenhol ugyan ezt adja, akár mit teszek vele.... Segítsen valaki!
C18-nál a ROM és a RAM memóriához különböző típusú mutatókat használunk. Nem tudom, hogy az MPLAB-ban a memória címzésmód változtatásával lehet-e ezen segíteni.
Szerintem hadilábon állsz a tömbök/pointerek használatával, és erre próbál finoman rávezetni a fordító. Azt kell megjegyezni, hogy a tömb neve magában leírva egy pointer, ami pont az első elemre mutat. Ennek a pointernek nincs címe (úgy nevezett jobb-érték), ezért a "&cmd" kifejezést a fordító csak nagy duzzogva eszi meg, és értékeli ki ugyanarra a kifejezésre, amit "cmd" magában is jelent. Ugyanezért a "&strVersion" helyett is "strVersion" kéne magában.
Továbbá ha az outdata egy char tömb, akkor a "(char*)&outdata[5]" pont ugyanazt csinálja, mint az "&outdata[5]", csak nem sumákolja el egy casttal, hogy most akkor stimmel-e a típus (ha később megváltoztatod az outdata típusát, akkor cast nélkül a fordító ordítani fog, míg a casttal ezt felülbírálod, hogy "jól van, tudom mit csinálok, ne küldjél warningot" ). Ezen felül az "&outdata[5]" helyett lehet írni, hogy "outdata + 5", ami jobban tükrözi a pointeres szemléletet. A hozzászólás módosítva: Okt 5, 2013
Igazad van, vannak bizonytalanságok/hiányosságok a tudásomban.
Sajnos amit leírtál az nem vitt előrébb, sőt..... megsokasodtak a warningok Lehet hogy valami apróság, még sportolok rajta, de ahogy kiveszem a típuskényszerítéseket egyre jobban hisztizik a fordító. Azért próbálkozom. Köszi az oktatást, ez a jobb-érték dolog valóban az újdonság erejével hatott.
Üdv. Sikerült találnom egy hibátlan fordulasztámmérő programot. Mindössze a timer2 leosztását nem tudom átállítani hogy azt az értéket jelezze ki amit kellene mert gyorsabban jár ez a processzor mint amire írták eredetileg a programot. Előtte egy 16f887-en 8mhz-en ketyegett a program most 18f4550-ön menne 48Mhz-es pll-el és kristállyal. Bemásolom azt a kódrészletet ami nem stimmel :
Most 50Hz-nél aminek 3000-es fordulatot kéne jelentenie 480RPM-et jelez ki.
Egy kicsit több részlet kellene a programból... 48 MHz = 6 * 8 MHz, tehát nem 125 megszakítás érkezik, hanem 6 * 125 = 750. Milyen típusú az int_sec_count?
Bemásolom az egészet. Hirtelen nem tudom mire gondolsz az utolsó kérdésed alatt.
Az spi-s dolgokkal nem kell foglalkozni és a komparátor és analóg bemenetekhez tartozó paranccsal azt már átírtam a 18f nyelvére.
Szia!
helyett
és minden előfordulásánál az
helyett
Szia, köszönöm szépen módosítom ez szerint.
Hát ha szét szakadok is warningol.....
erre még mindíg Warning [2066] type qualifier mismatch in assignment
Erre pedig Warning [2066] type qualifier mismatch in assignment Mit nem csinálok jól? (MPLAB C18 v3.45)
Nem ismerem a C18-at, de szerintem csak annyi a baja, hogy konstans memóriaterületre állítasz egy pointert, és szól, hogy veszélyes vizekre eveztél.
Ha erre a memóriaterületre a változó nevével közvetlenül hivatkozol, akkor nem fogod tudni felülírni a "const" miatt. De ha ugyanide pointerrel hivatkozol, akkor már felülírható. A szintaktika szempontjából pedig mindegy, hogy az egy ROM terület, és egyébként sem lehet "csak úgy" írkálni oda. Másrészt az is lehet a baj, hogy egy konstans "változót" egy nem konstans változóba másolsz, ami innentől szabadon megváltoztatható, azaz afféle típus konverzió történik.
Akkor kapod ezt a warning-ot, ha az strcpypgm2ram()-nak nem jo tipusu erteket adsz at.
Amit kap az (char *, const rom char *) Hogy mit var az strcpypgm2ram() azt meg kellene nezni abban a header-ben, ahol deklaraljak, ami valoszinuleg a string.h lesz. Mondjuk logikusan ezt kellene varnia. Na, utanaolvastam a neten: A C18 leirasa irja (csak nem tudok a pdf-bol masolni), hogy elofordul, hogy ezt a warningot kapod, ha a masodik parameter 'near' mikozben a fuggveny 'far'-t var. Valoszinuleg a megoldas a problemadra: strcpypgm2ram(outdata + 5, (const rom far char *)strVersion); Erdemes a C18 pdf-jet elolvasni, ott irnak meg par dolgot ezzel kapcsolatban. Udv, Andor
Nem akarok "csak úgy írkálni", hanem a ROM területre akarom tenni a string konstansokat hogy ne a RAM-ot zabálják.
killbill: Köszi! Ez lett a megoldás egyszerűen csak egy far kellett neki.
Üdv, valaki elmondhatná, ha van mondjuk egy nand nor stb kapu, hogyan tudok kialakítani c-ben picre?
Azért lenne érdekes, mert plc-t kéne alkalmazni az alkalmazáshoz, de nem akarok rá 10-en ezreket költeni, amúgy is csak egy uC- van ugyanúgy egy plc-ben is. Valaki tudna-e példákat mutatni? |
Bejelentkezés
Hirdetés |