Fórum témák
» Több friss téma |
Idézet: „Arra, hogy pontosan mi a hiba, a mikrovezérlős szervó vezérléssel, még nem jöttem rá teljesen” Szerintem az a probléma, amit icserny is irt: nem tisztán hardveres (PWM) a szervó jel előállítása. Mivel valószínűleg egy timer megszakításban történik a jel előállítása ezért a megszakítás(ok) kezelésének ideje is hozzáadódik a tényleges impulzus hosszhoz. Ez főleg akkor gond, ha több megszakítás is felléphet egyszerre. Akkor ez a hozzáadott idő folyamatosan változik, ez okozza a remegést. Vagyis hiába állítjuk elméletileg középállásba a szervót, az impulzus hossz folyamatosan változni fog pl.: 1,54ms 1,59ms 1,55ms ... Én a CCRx regiszterek segítségével (MSP430G2553 hardver PWM OUT) teszteltem egy szervót: semmilyen remegés nem jelentkezett. A 28 lábú MSP430G2553-nél ezzel a módszerrel 4 szervó kezelhető, sajnos a 20 lábúnál még kevesebb.
Sziasztok.
Tegnap egy különös dolgot tapasztaltam, és nem tudom hova tenni. A modell terepasztal vezérlést fejeztem be, és a programot kiegészítettem pár dologgal, LCD vezérlés, szoftveres UART, pár adat mentése flash (info) memóriába. Miután úgy éreztem, hogy teljes a program, és az alap tesztek is sikeresek voltak, a végleges verziót szerettem volna "beégetni" (de csúnya szó ez) a mikrovezérlőbe, de nem sikerült. Hibának azt írta az IAR, hogy nem tudja írni az info mem. adott szegmensét. Gondoltam ez furcsa, hisz nem is írok bele semmit, csak ha majd fut a program, akkor lesz írva a flash. Mindegy...., kivettem a flash írást a programból, ami a Timer_A0 megszakításban volt. Így már lefordult a program, viszont hiányzott az adat amit a flash-ből kellett volna kiolvasni. Nem szaporítva tovább a szót, rájöttem, hogy "kis" programból sikerült egy olyan programot fabrikálnom ami már nem fért bele a mikrovezérlőbe. (kicsivel több mint 8k-s a program, a uC g2452-es) Elkezdtem játszani az optimalizálással, és így már sikerült belepréselni a teljes programot g 2452-be. Az első kérdésem az lenne, hogy mi alapján optimalizál az IAR, ill. egyáltalán mit optimalizál... A próbálkozásaim közben volt olyan, hogy egy-egy utasítást, egyszerűen nem hajtott végre a mikrovezérlő, de csak azokat az utasításokat amik a Timer_A0 megszakításban voltak. Mintha azokat a parancsokat kihagyta volna a fordító, és nem kerültek bele a uC-be. Ez, hogy lehetséges? És miért csak a Timer megszakításban lévők vesztek el? Bocsi a regényért...
Ez fura. Nem kéne szólnia a programnak, ha nem sikerült maradéktalanul lefordítani az adott mikrovezérlőre a programot? Elvileg tudnia kéne, hogy mennyi a szavad memória nem?
Erőteljes optimalizálásnál a fordító "kioptimalizál" minden olyan programrészt, amit feleslegesnek talál. Ennek igen furcsa következményei lehetnek, mert ha jól belegondolsz, a fordító szemszögéből nézve például egy szoftveres késleltető ciklus is "fölösleges"... Hasonló lehet a helyzet a megszakításból kioptimalizált kódrésszel is: a fordító szerint bizonyára nem csinált semmi "hasznosat".
Nem értem ezt az egész optimalizációs részt. (eddig nem foglalkoztam vele)
Tehát, ezek szerint azzal, hogy én alacsonyról közepesre kapcsoltam az optimalizációt, bizonyos programrészek kikerültek a programból? Mi alapján dönti el a program, hogy mi marad, és mi nem? És ha számomra kulcsfontosságú egy késleltetés.... Meg lehet nézni valahol, a már optimalizált programot? Kíváncsi lennék rá, hogy az IAR-nak miért nem fontos egy adat mentése a flash memóriába..... Idézet: Fogalmam sincs, a dokumentáció is elég szűkszavú. „Mi alapján dönti el a program, hogy mi marad, és mi nem?” Idézet: A Disassembly ablakban biztosan. „Meg lehet nézni valahol, a már optimalizált programot?”
Lehet, hogy a megszakítást azért szedi ki, mert azt hiszi, hogy soha nem lesz meghívva. Mert ugye nem a szoftver hívja meg, ezért ha csak a kódot nézi az analizáló, tényleg nincs értelme bent hagyni egy függvényt, amit senki nem hív meg. Ugyanez lehet a várakozásnál is, látszólag semmit nem csinál a processzor közben. Hiszen semminek az értéke nem módosul alatta.
Idézet: „Lehet, hogy a megszakítást azért szedi ki,” Nem a megszakítást szedi ki, hanem a megszakításból a flash írást meghívó parancsot. Röviden: A Timer számlál adott értékig, ha eléri az értéket megszakítást okoz, elvégez a megszakításban pár parancsot, és mielőtt visszatérne elmenti az adatot a flash-be. Ez utóbbi parancsot nem hajtotta végre. Közben visszaállítottam az optimalizációt alacsonyra. Lefordítottam a program (kivettem pár részt, hogy elég legyen a 8k) és megnéztem/kimásoltam a disassembly ablak tartalmát. Ezek után, ugyanezt medium optimalizációval is megcsináltam, de nem találtam semmi különbséget a két assembly "program" között. Érdekes... Most megpróbálom átrakni az egész programot CCS-be. Kíváncsi vagy az mit csinál vele...
Ez egy igen érdekes cikk arról, mi mindenre képes (és mire nem) egy ügyes fordító.
A falsh írása nem túl gyors dolog, ezért megfontolandó lenne kipiszkálni a megszakításból, ami lehet megoldaná a problémádat is egyúttal.
Kivettem a flash írást, és beraktam máshova. Így a Timer megszakításban mindössze három változó növelése maradt.
Erre a fordító kivette az első változó növelését, illetve a program nem hajtotta végre. Ezért érdekes. Miért pont a Timer megszakítással vacakol... Azt elfelejtettem írni, hogy amikor "eltűntek" a programrészek, az optimalizációt már visszaállítottam, és egy-két részeltet kiszedtem a programból, hogy pont (~7,99k) beleférjen a uC-be.
Bocsánat hogy belekontárkodom, csak egy ötlet.
WinAVR-ben C nyelven a megszakításban (is) használt változókat "volatile" klcsszóval kellett megjelölni, ezzel mondtuk meg a fordítónak, hogy a "tudtán kívül", megszakításban is megváltozhat az értéke, így nem optimalizálta ki regiszterbe, illetve minden használat előtt kiolvasta az értékét a memóriából. Nem lehet hogy itt is hasonló megfontolásból szedi ki?
Sajnos nem. Jelen esetben a változókat csak a megszakításban használom, ezért nem kell a volatile.
Szép napot!
Lenne egy olyan kérdésem, hogy szeretnék csinálni egy bicikli világatást 8 ledből ami úgy működne, hogy 1 gombnyomás 8 Led villogtatása egyszerre. 2 gombnyomás Knight Rider "fénycsóva. 3 gombnyomásnál ez futna le OLI felirattal. Ehhez írtam egy kódot és meg szeretném kérdezni a hozzá értőket, hogy jó e? A válaszokat előre is köszönöm. kód:
Csak átfutottam a kódot, de ez így nem jó!
Az első hiba, hogy 2 "main" függvény van, abból csak egy lehet! A P2.6 bit (bemenet) vizsgálata utána, a program bemegy egy végtelen ciklusba, és így a "23." sortól, már semmilyen utasítás/parancs nem kerül végrehajtásra..... Szerintem: A gomb figyelését tedd be megszakításba, majd egy "switch/case" parancs kombinációval döntsd el, hogy mit csináljon a továbbiakban a program. A 3. gombnyomásnál lévő feltételt, hogy képzelted el? Kezedbe veszed a lámpát, és menet közben rázod? Számomra kicsit fura....
Szép napot.
Tényleg észrevettem, hogy több main van, a kelleténél a többi gondon még majd gondolkodok. A 3. at azt úgy gondoltam, hogy rá teszem a kerékre. Üdv. Olivér Idézet: „A 3. at azt úgy gondoltam, hogy rá teszem a kerékre.” Akkor nem lesz világításod... 
Akkor valahogy a pozícióérzékelést is meg kéne oldani. Pl egy hall szenzorral, meg egy mágnessel, mint a sebességmérőnél szokás. Mondjuk, ha elég úgy, hogy pl. kb 20-25 km/h között legyen látható rendesen, akkor nem kell, de ez elég bizonytalan.
Sziasztok.
Először is mindenkitől elnézést kérek, hogy itt a fórumon személyes kérdést teszek fel, de hátha mást is érdekel. (és nem szeretek privát üzenetet küldeni) Icserny fórumtársunkhoz szólna a kérdésem, mégpedig az Ő általa írt szoftveres UART-al kapcsolatban. Egy G2553-ba használom a hw UART-ot, és szükségem lenne még egy UART küldés funkcióra. Beraktam a szoftveres UART-ot, de már két napja nem sikerül "behangolni" 3,4MHz-re. 1MHz-en szépen működik mindkettő. Lehet, hogy a nem pontos 3,4MHz (adatlap szerint beállítva) miatt nem megy?
A gyártó honlapján fent levő mintaprogramok között van egy nagyon jól megcsinált timer alapú UART megoldás. A szinkronizált bemenetek, meg a kimeneti módok miatt tökéletesen pontos, független a szoftveres pontatlanságoktól. Én egy olyan projektet csináltam most g2553-al, amiben 3 UART is kell, és az egyik timerre mindig szükségem van. Így használok egy HW uart-ot, egy timer_uart-t és a watchdog timer segítségével csináltam magamnak a harmadik uart-ot. Teljesen jól működik.
Az órajeleket DCO szolgáltatja. Annak a beállítását szintén a példaprogramok közötti DCO pontos kalibrálását segító programmal csináltam. Ennek az a lényege, hogy a kristály frekvenciájához tökéletesen be tudja állítani DCO-t, csak meg kell mondani, hogy hányszor olyan gyorsa állítsa. Kicsit át kell azt alakítani, mert a flashbe akar írni. Ja, és 9600bps kommunikációt használok 8N1 üzemmóddal. Ha nem találod, akkor el tudom küldeni a linkeket. Amúgy minek pont a 3.4MHz? Miért nem használod valamelyik kalibrált frekvencián? Akkor nem lenne ilyen gond. Mert szerintem elég nehéz lehet adott frekvenciára rendesen beállítani a fent említett módszer nélkül. A hozzászólás módosítva: Júl 2, 2013
Idézet: „Amúgy minek pont a 3.4MHz?” Külső kvarcot nem akarok használni, 1MHz kevés, a 8MHz meg sok. Továbbá mind a három Timer foglalt, a WDT meg az eredeti feladatát látja el. Ezért használom az Icserny által írt UART-ot, plusz az "egyszerűsége" miatt. Már akartam kérdezni tőled, hogy sikerült ezt a problémát megoldani? A minap szembesültem egy hasonló "Timer reset" problémával én is. Beállítottam a Timert, hogy megszakítást okozzon, és ahogy engedélyeztem a megszakításokat a mikrovezélő újraindult (resetelt). A probléma az volt, hogy a TACTL-ben engedélyeztem a megszakítást (TAIE), és nem a TACCTLx-ben.
Használd a 8MHz-et és használd az órajelleosztást ott, ahol kell. Amúgy az adott példaprogram eredetileg arra van, hogy az információs memóriába elprogramozza a kalibrációs adatokat. Szóval az is lehet, hogy egy 32kHz-es kvarc segítségével kalibrálod a chipet a kívánt frekvenciára, utána újraprogramozod a neked szükséges programmal, úgy, hogy az információs memóriát ne törölje, és a programodban a kívánt adatokat töltöd be DCOCTL és BCSCTL1 regiszterekbe.
Az én megoldásom az volt, hogy nem a XOR műveletet használtam, hanem szépen beítam újra a kívánt paramétereket a regiszterbe. (Ugye az én problémám csak az NMI bekövetke után jelent meg. Ekkor viszont a timer regiszterébe mindig egy adott értéket kellett írni, ezért nem volt szükség a XOR-ra.) Ezután már nem jelentkezett a hiba. De hogy az miért történt, máig nem tudom. Lehet, hogy az ERRATA-t kéne tanulmányozni hozzá. Idézet: „Használd a 8MHz-et és használd az órajelleosztást ott” 2,35-ös osztás sajnos nincs. A ciklusidőkhöz, és a kijövő PWM jelekhez, a 3,4MHz kell nekem. Csak az SW UART nem megy, minden más tökéletes, és pontos. Próbáltam 4MHz-en is a programom, de túl sokat kellett volna korrigálnom.
Lassítani mindig lehet valahogy szoftveresen.
 Gyorsítani nem.Mondjuk szerintem, ha nagyon pontatlan lenne a 3,4 MHz és ehhez van beállítva a HW UART, akkor annak sem kéne rendesen működnie. De azért az jobban tolerálja az eltérést szerintem, mint a SW UART. Én anno, mikor még nem értettem a működését a HW UART-nak, csináltam magamnak egy szoftveres UART vevő programot is. Amikor 1MHz-ről járattam, akkor nem működött, nem vette a géptől kapott jeleket rendesen, amikor 16MHz-ről járattam, akkor működött. Valószínűleg pontosabb lett, a rövid utasítások miatt. Mondjuk Icserny adó kódja 1MHz-en is működik. Igaz, az adás egyszerűbb, mint a vétel szerintem. Mondjuk én sem a legjobb megoldást választottam...
Sziasztok. Olvastam Icserny új cikkét és gondoltam kipróbálom az energia fejlesztőprogramot is. De valamiért, amikor leakarom tölteni a programot a Launchpad-ra, akkor a következő hibaüzenetet kapom: Cannot run program "E:\......\HARDWARE\TOOLS\MSP430\BIN\msp430-g++" : CreatePRocess error=2, A rendszer nem találja a megadott fájlt
véleményetek szerint mi lehet a probléma? A hozzászólás módosítva: Júl 2, 2013
Idézet: Biztos, hogy nem pontos. Az adatlapban található értékek csak körülbelüliek, a gyártási szórás miatt. Ha kiméred, meg tudsz határozni egy beállítást, ami arra a példányra jó. „Lehet, hogy a nem pontos 3,4MHz”
Próbáld meg valami egyszerűbb helyre kibontani, pl. C:\Energia! (Szóköz, ékezetes karakter ne legyen az elérési útvonalban!)
Méréseim szerint, csak AD konverziónál változik a freki, +- pár 100Hz-et. Miután vége a konverziónak visszaáll a beállított 3.4MHz-re. Még a hőmérséklet változásra is érzékeny, de jelen eseteben ez elenyésző. Három g2553-t próbáltam, és mindegyiknél ugyanezt tapasztaltam.
Szerencsémre találtam a kacataim között egy 3,42700MHz-es kvarcot, ezzel pontosítom a frekit, és remélhetőleg az sw UART is megjavul. Köszi.
Sziasztok. Még egy kérdés. Sima C-ben oké, de ebben az Energia feljesztői környezetben azt, hogy érem el, hogy a végtelen ciklus csak a PUSH2 megnyomására induljon?
Szerintem csinálj egy kis ciklust a loop elején, ami csak akkor lép tovább, ha lenyomod a billentyűt. És valami feltételvizsgálattal oldd meg, hogy később már ne akadjon el ott.
Pl. char n = 1; loop{ while( "gomb nincs lenyomva" && n); n = 0; //És innentől kezdődhet a tényleges feladat. } |
Bejelentkezés
Hirdetés |
