Fórum témák
» Több friss téma |
Sziasztok!
Miért van az, hogy az XC8 v1.12 compiler-t használva, nem tudom átadni az egyik tömb elemeit a másiknak? pl.: (most, hogy a "\0" karakter hozzá van adva a tömbhöz, vagy nincs nem számít, mert növeltem a tömb elemet meg csökkentettem is, és semmi; kínomba már kísérleteztem mindennel)
Olyan, mintha a tömböket keverné össze-vissza. Volt már máskor is gondom a tömbökkel benne, amikor egymás alatt többet deklaráltam és használtam őket egymás után. Idézet: „Miért van az, hogy az XC8 v1.12 compiler-t használva, nem tudom átadni az egyik tömb elemeit a másiknak?” Mi akadályoz meg benne? Szerintem a leírt kóddal pontosan azt fogja csinálni a számítógép, mint amire megkérted. "A számítógép nem az óhajainkat vagy a kívánságainkat teljesíti, hanem a parancsainkat".
Szóval azt mondod a kód helyes? De akkor mégse írja ki amit kéne.
Talán mást gondolsz annak, hogy "mit kéne", mint amit a számítógép...
És megy.... Hihetetlen, és nem tudom, most miért jó, pedig már nem egyszer megírtam így is. Bár folyamatosan ment az MPLAB már vagy 8-9 órája, lehet azért kavart be. Hát már papíron is levezettem magamnak az "algoritmust", mondom, próbálkoztam mindennel. A fenti példából meg, mint mondtam eggyel kevesebb eleműek a tömbök, mint kéne lenniük, meg persze az a[11] fel van töltve 10 elemmel.
A hozzászólás módosítva: Dec 27, 2012
Nekem furcsának tűnik az i és j változók létrehozása vagy kezelése. Az az int szócska teljesen nem odaillő, bár lehet, hogy az xc8 megemészti, de az akkor sem való oda. A tömbök után kellene deklarálni az i és j változókat, a for() sorából pedig törölni az int szócskát.
Idézet: Az egyik "korlátozás" az, hogy csak PIC18-ig elérhető... Bővebben: Link„Tudom-e hasznalni a HiTech forditojat, akar korlatozasokkal?” PIC32-höz az új XC32 vagy XC++32 választható, esetleg a régi MPLAB C32. - Compilers - Legacy compilers
Idézet: Az úgynevezett "C99" szabvány (az ANSI 2000 májusában fogadta el) szerint a deklaráció immár lehet a for ciklusban is a C++-hoz hasonlóan). „Nekem furcsának tűnik az i és j változók létrehozása vagy kezelése.” A kérdés csak az, hogy az adott fordító támogatja-e, illetve milyen fordítási opciót kell megadni hozzá.
Igen, C++ -ban engedélyezett, és az XC8 is támogatja és az alap fordítási beállításokkal megy. Programozást tanulok, ezért furcsálltam, hogy egy ilyen tömb átadást nem tudok megalkotni... De miután újra indítottam az MPLAB-ot, fordult rendesen.
Érdemes figyenli a build ablakot, hogy mit is fordít újra, mikor a build gombra nyomsz, valószínű az MPLAB rosszul indította a compilert. Ezért szoktam kisebb projekteknél mindig először cleanelni, aztán az egészet újra.
Amúgy ha egy tippet elfogadsz, ezt a "(....){ " zárójel tördelést felejtsd el, nagyon profinak tűnik, de gyakorlatilag csak olvashatatlanná teszi a kódot. A hozzászólás módosítva: Dec 27, 2012
Szia, ZsoltyFM! Hozzá lehet jutni ehhez a videótanfolyamhoz? Másfél éve vettem egy Mikroe EasyPIC6-ost, akkoriban irtó lelkes voltam, de a kudarcok visszavetettek, még addig sem jutottam el, hogy az általános beállításokban meg tudjam szüntetni a hibát, nemhogy egy LED-et működtetni
 (bár ez inkább kezdő kérdésekhez tartozna). Véletlenül beleolvastam a fórumba és újra belelkesültem. Szeretném megtanulni a "C"-t PC-n, aztán tényleg jöhet a PIC. Szóval tudnál segíteni a videók beszerzésében, vagy bármilyen segedletben? Üdvözlettel: Yoe
Idézet: „vettem egy Mikroe EasyPIC6-ost, akkoriban irtó lelkes voltam, de a kudarcok visszavetettek” Ez a könyv sem segített?
Szia! Természetesen letöltöttem és át is néztem, de - mint írtam - a programozásig el sem jutottam. Mindent úgy írtam be, mint ahogy a példaprogramokban van, mégsem tudtam semmit sem csinálni.
A hozzászólás módosítva: Dec 28, 2012
Sziasztok!
Kezdek rájönni, hogy az XC8 semmire se való, vagy én nem tudok programozni.
Ez se működik.
És ez se működik...
Így viszont igen...
Ez lenne a függvény, amit meghív.
A probléma, hogy rossz számot ad át a változókból. Tudom, hogy csak "int" típusú a változó, de a tizedesnél levág, így az "asd"-ba maradna simán egy egész szám, amit át tud adni. Mi lehet a gond?
Próbáld meg így:
Idézet: „Tudom, hogy csak "int" típusú a változó,” Int típusú, tehát 16-bites. Mivel 200 * 1023 > 65535, ezért már az első szorzásnál túl fog csordulni, és onnantól kezdve semmi köze nem lesz az eredménynek a valósághoz. Jó dolog ez a "programozzunk 8-bites mikrokontrollereket C-ben", de alapvetően úgy működik a dolog, ha precízen végiggondoljuk, hogy milyen műveletet (és hány biten) szeretnénk végrehajtatni, majd utána olyan parancsokat írunk le, ami pont azt csináltatja meg. Jelen esetben lehet azt kérni, hogy 4-byte-os egész számként (unsigned long) számoljon a fordító (minRPM * 1023UL), vagy el lehet azon gondolkodni, hogy a műveleteket hogyan lehetne optimalizálni, hogy beleférjünk a 16 bitbe. Mondjuk ha pl. a maxRPM értéke fix, akkor lehet játszani olyat, hogy minRPM + ((minRPM + ((minRPM >> 1) - (minRPM / 25)) >> 2) >> 2), ez egy 8-bites mikrokontrolleren gyorsabb lesz, mint az unsigned long-os számolgatás.
Ha valamelyik RPM értéke fix, akkor azt célszerűbb inkább #define-vel megadni, és akkor a számítást nem a mikrovezérlő, hanem a fordító fogja elvégezni. Annak meg mindegy hogy 16, 32 vagy akár 64 biten csinálja. Ha ez az RPM valami fordulatszámot jelent, akkor inkább unsigned int legyen a típusa (a negatív fordulatszám amúgy is elég nehezen értelmezhető, legfeljebb ha ha forgásirány is számít), úgy később fog a túlcsordulások miatt fals eredmény keletkezni.
Sziasztok!
Olyan gondom van és nem találok rá megoldást, hogy LAT PORT és TRIS biteket szeretném változóként kezelni. Vagyis valami ilyesmi kéne, de sehogy nem működik
Tulajdonképpen futásidőben dől el, hoyg épp melyik I/O lábat kell piszkálni. Remélem érthető hogy mit is szeretnék.... CCS-ben ez gond nélkül ment, de a C30-al nem boldogulok. Tudtok erre valami megoldást?
Az RPM, igen fordulatszám lenne. Azt a hibát orvosoltam, "long" lett az "int"-ből. Sajnos az RPM értéke majd attól kell függjön, hogy menüből mekkora értéket adnak neki, amit az EEPROM-ban tárol majd. Itt a "dolgozó" program rész és hozzá a változók:
A függvények, amiket meghív útközbe, azok tuti jók, így nem is másoltam be. Ahol ellentmondás lenne a változó neve és az elvárt értéke (pl.: temp_perCent megadásnál) között, az a tizedes jegyek kiküszöbölése miatt van. Amit a program csinálna: 1. Beállított hőmérséklet - temp_dif alatt van a mért hőmérséklet, akkor max. RPM 2. Beállított hőmérséklet + temp_dif felett van a mért hőmérséklet, akkor min. RPM 3. Beállított hőmérséklet - temp_dif felett van a mért hőmérséklet, de a beállított alatt, akkor min. RPM 4. Beállított hőmérséklet + temp_dif alatt van a mért hőmérséklet, de a beállított felett, akkor min. RPM 5. Ha meg nyomom a gombokat, egyik csökkenti a hőmérsékletet, másik növeli, és beállítás közben az LCD-n mutatja a folyamatos változást villogás közben, majd 10 "kör" után visszaáll a hőmérséklet mutatására. Ha a kikommentezett részt berakom, teljesen más értékek jelennek meg, és még a set_temp is ugrált össze-vissza, amikor nem is adok neki értéket sehol, kivéve a gombnyomásokat. Az RPM-es rész előtt minden ment szépen, úgy csinálta, ahogy kell, a jelenlegi hőmérsékletet viszont, mindig normálisa jeleníti meg. Bocs a hosszú kommentért és a kódért, remélem valaki tud segíteni, hogy miért is nem megy rendesen, és hogy miért kapok más értéket ugyanarra a bemenetre a PWM kimeneten, ha a kommentes rész belekerül. A hozzászólás módosítva: Dec 30, 2012
Idézet: „Tulajdonképpen futásidőben dől el, hoyg épp melyik I/O lábat kell piszkálni.” Több megoldás létezik: - shiftelgetős: LATA |= (1 << n), LATA &= ~(1 << n) - elágazós: switch (n) { case ... - függvénypointeres: mindegyik művelethez kell írni n db függvényt, és egy függvénypointerbe berakni a kívánt bitet változtató függvény címét A shiftelgetős/elágazós esetben is külön függvénybe érdemes rakni, ha sokszor akarod meghívni, mert elég nagy lehet a generált kód mérete. Egyik lassabb lesz, mint a másik. A hozzászólás módosítva: Dec 30, 2012
Ez még mindig nem azt fogja csinálni, mint amit szeretnél. Mivel a minRPM, az 1023, és a maxRPM is unsigned int, ezért rajtuk unsigned int-ként végzi el a számítást a rendszer, majd az eredményt kiterjeszti unsigned long-ra.
Eh...elírtam. 3. és 4. pontnál nem minRPM, hanem arányosan csökkenő, azaz a max. RPM-ból a kívánt hőfokig 50%RPM, ha a kívántat túl lépi akkor ugyanúgy, arányosan csökken tovább a min. RPM-ig
A maxRPM-t és a minRPM-t is átírtam long-ra, úgy se volt jó. (mindent átírtam longra, mert hely van, de láttam, hogy nincs változás így visszaírtam) Mondjuk nem írtam az 1023 mögé hogy L, lehet ez a gond akkor, ahogy írod? De nem lehet, mert mint mondtam a hőmérsékletnél az 1000-es szorzó meg jó és ott sincs L mögötte.
A hozzászólás módosítva: Dec 30, 2012
Arra már nem kéne szükség legyen. Elég a minRPM-et longra átírni (bár én inkább az 1023-at írnám át).
A programban amúgy van egy halom átgondolatlanság: Ez pl.: "(high_dutyCycle - low_dutyCycle / 2)" nem azt csinálja, amit szeretnél. A /2 itt csak a második tagot fogja elosztani kettővel, pedig szerintem nem ez volt a gondolatod. Vagy ott van a "(1000 * (temp_minRef - readADC())) / temp_perCent" - mi fog történni, ha az ADC a min referenciaértéknél nagyobb számot ad vissza? Arról nem beszélve, hogy az 1000-rel történő szorzásnál ugyanez az int/long probléma fennállhat, hiszen a min és a max referenciaérték között ~180 a különbség, ezt 1000-rel felszorozva simán nem fér el 16-biten az eredmény.
(high_dutyCycle - low_dutyCycle / 2) igazad van, köszi. Ez már a próbálkozások közbe ment el. Ha a minRef értéknél nagyobbat kap, akkor majd error-ral ki áll (azt jelentené hogy 100fok felett van a víz, ami már nagyon nem jó).
Szorzok-osztok, kipróbálom amit mondtál, az int és long közti dolgot. Idézet: „akkor majd error-ral ki áll” Nade honnan fogja észrevenni? Mert a kivonás negatív eredményt ad, amit utána beraksz egy unsigned int változóba - na innentől kezdve már senki nem fogja tudni, hogy mi történt, lévén a negatív érték "átváltozik" valami pozitív számmá. Szerencsésebb lenne az olvasott értéket olvasás után validálni, és ha nem stimmel, akkor valami más ágra terelni a feldolgozást. Idézet: „(azt jelentené hogy 100fok felett van a víz, ami már nagyon nem jó)” Vagy hibás a referencia, amihez méred. Ez azért nem annyira lehetetlen esemény...
A referenciát én állítom be, ki lett mérve 100fokon és 0fokon is. Majd ha végre működik az rpm-es dolog, meg amit még csinálni szeretnék, azután az ADC() egy változóba olvasom és levizsgálom, hogy az értékek közt van-e, ha igen akkor megy a mostani helyére a változóba az érték.
A hőmérő szenzorom 5db 1N4148-as összeforrasztva, másik topicba írták, hogy nem jó, meg nem pontos, és vegyek helyette ilyet meg olyat. De nagyon jól működik, és 5db dióda meg egy ellenállás kellett csak hozzá, amikből van egy rakás otthon. Én max. 0.5 fok eltérést tapasztaltam, ami bőven tökéletes
A probléma még mindig ugyanaz. Ha ezt a két "if"-et berakom elmászik minden, ha nincs bent akkor pedig jó, és 1.22V-ot és 4.88V-ot kapok a PWM kimeneten(200RPM = 0% = 1.22V, 800RPM = 100% = 4.88V).
Az előbb végig számoltam papíron, nincs hol túlcsordulnia, max. ha a tizedeseket nem levágja, hanem valami mást kezd velük. Szerintem az "if" feltételébe van a hiba, olyan mintha a set_temp új értéket kapna. Minden integer típusú, most már azzal se lehet gond, a túlcsordulásos részeket lekezeltem.
Megcsináltam... A probléma pedig a következő volt: a feltételeknél a számításokat beleraktam egy változóba, és a két váltózót hasonlítottam össze. Úgy néz ki nem szereti az első megoldásomat...
Idézet: „Az egyik "korlátozás" az, hogy csak PIC18-ig elérhető... Bővebben: Link” Lehet, hogy megint nagyon 'láma' a kérdés, de letöltöttema v3.44 et, csap éppen indítható file nincs esetleg valami tipp? Előre is köszi |
Bejelentkezés
Hirdetés |
