WinAVR / GCC alapszabályok:
1. Ha ISR-ben használsz globális változót, az legyen "volatile"
2. Soha ne érjen véget a main() függvény
3. UART/USART hibák 99,9% a rossz órajel miatt van
4. Kerüld el a -O0 optimalizációs beállítást minden áron
5. Ha nem jó a _delay időzítése, akkor túllépted a 65ms-et, vagy rossz az optimalizációs beállítás
6. Ha a PORTC-n nem működik valami, kapcsold ki a JTAG-et
Bővebben: AVR-libc FAQ
Ha ISP mkII-ről van szó, akkor támogatom meg nem is. Ezzel minden 8 bites AVR-t tudsz programozni, de a hátránya az hogy csak programozni. Kisebb programoknál debuggolás nélkül is lehet ügyködni, de amint csinálsz egy komolyabb dolgot rögtön hiányozni fog. Dragon annyival jobb hogy ott debuggolni is tudsz.
Ha már dragon akkor így érdemes meg venni Bővebben: Link, mert így egy Xmega fejlesztő panelt is kapsz majdhogynem ingyen.
Hehe, hát azért függ attól, hogy milyen nehézségű programot írsz.
Arról nem is beszélve, hogy a szimulátor elég gyatra néha.
Legújabb példa: Atmega48PA-nál az OCR1A -nak hiába adok értéket, a szimulátorban ez nem történik meg. A valóságban természetesen jól működik.
Én évek óta programozok AVR-t, és elég cifra dolgokat is művelek. Fejlesztőpaneleket és fényeffekteket
is építgetek, illetve belefogtam egy aszinkron motorral hajtott villanygokart tervezésébe,
természetesen AVR-el oldom meg a főáramkör háromfázisú vezérlését hajtással és visszatöltő fékezéssel.
Nem vagyok valami hűdenagy májer, de eddig egyetlen alkalommal sem volt szükségem sem debuggerre,
sem szimulátorra. Való igaz hogy volt amikor 1-1 apró hiba miatt elakadtam.
De a "hagyományos" módszerekkel is kb. ugyanolyan gyorsan(vagy picivel gyorsabban) sikerült
a hibákat elhárítani, mint egyetemi sorstársaimnak szimulátorral/debuggerrel.
Hozzászólva az előzőhöz egy remek példa - VGA vezérlés tisztán AVR-el!
Na ezt debuggolhatnám pár évig, pedig "csak" 900 sornyi assembler kód az egész...
Na jó ennek is a "Ki mit épített" topikban lenne a helye...
Pedig nagyon hasznos tud lenni . Jó múltkorában ismerőssel csináltunk egy virtuális digi oszcit melynek programja 4000+ soros (PIC32 C-ben), és bizony nagyon jól jött az online debug. Pl. mikor a uC lábait néztük, hogy van-e jel, akkor csak simán lépkedni kellett és azonnal látszódott, a műszeren, hogy van-e vagy sincs a lábon fesz. Nem kellett külön erre programot írni.
Nem mellesleg AVR-e egyelőre én is szimulátor és debuggolás nélkül írok programokat, de mondjuk nem ekkorákat, mint pl te.
AVR Studio C szimulátora egy bughalmaz, az asm oké, de a C része elképesztő.
Le a kalappal akkor.
Én mindenesetre kényelmes maradok, és ahelyett, hogy Soros porton kiküldött infók alapján jöjjek rá, hogy mi történik bizonyos esetekben, inkább belenézek a lelkébe debugerrel.
Segítséget szeretnék kérni PID szabályozásban, illetve elég lenne a PI is. Az interneten sok mindent olvastam róla, de mindenhol matematikai levezetéseket találok, és a problémám az, hogy nem tudom leírni programban. Vannak programok amik már működnek, de nagyon kezdetlegesek, és a lengést egyikben se sikerült kiküszöbölnöm. Ezt a pdf-et kaptam hozzá, ami alapján meg kéne tudnom csinálni, de sajnos nem nagyon tudom értelmezni. Tudna ebben segíteni valaki?
Adott egy 32UC3B1256 mikrokontroller. Továbbá egy DC motor amelynek mindig tudom a pontos helyzetét 12biten. Egyik irányba nő a másikba csökken, értelemszerűen. Egy végtelenített potmeter ami 2bites GRAY kódot ad, gyakorlatilag egy körbefordulás alatt 48szor "ad jelet". Továbbá interruptban minden pwm jel lefutásakor mérem a kapocsfeszültséget egy analog érzékelővel. Ez, ha áll a motor ez decimális számként 423-at jelent, az egyik irányban ha felpörög le megy 0-rá a másik irányba pedig fel 846-ra.
Ezek alapján tudtok segíteni hogyan is kéne hozzálátnom a program megírásához?
A programozás részében nem tudok segíteni, de itt a fórumon a CNC-és topicban foglalkoznak PID szabályzással.
Amit viszont fontosnak tartok, hogy minden PID rendszert az adott "hardwerhez" hozzá kell hangolni, ami nem is egyszerű ! Anélkül nem ér semmit.
Olvastam már öntanuló (hangoló) PID rendszerről, szerintem afelé kellene neked is elindulnod!
Régebben gyűjtöttem a PID rendszerről szóló leírásokat, ha érdekel megosztom veled!
PI szabályzást javaslom, mivel a PD-ben, illetve PID-ben a D deriváló tag könnyen destabilizálhatja a rendszert.
A PI szabályzáshoz a következőket kell tudnod:
Milyen paraméterrel szabályzol, milyen paramétert szabályzol, illetve a rendszered milyen gyors.
Nos, tételezzük fel, hogy a DC motor sebességét szabályzod. A bemenő paramétered amit tudsz állítani pedig a feszültség, mégpedig egy PWM jel által. A rendszered gyorsasága a motorod és a forgatott tehetetlenségi nyomatékától függ elsősorban. Fontos, hogy a szabályzás sokkal gyorsabb legyen mint a rendszered, vagyis jelen esetben a motoros felpörgési ideje 0-ról max ford. számra. 2 nagyságrend eltérés biztos hogy kell lennie.
Röviden ennyit kell tenned:
dt időnként mintavételezni a sebességet(ez az ami min 2 nagyságrenddel rövidebb idő mint a motorállandód).
Mivel neked pozicióvisszajelzésed van a motorrol, így értelemszerűen ezt először deriválnod kell (itt máris bejöhet egy jó kis hiba, amivel a deriválás mindig járhat). Az utolsó pár mérésre vonatkozóan tedd ezt meg.
Most már tudod az aktuális sebességet. Mivel neked van egy előírt sebességed, ami eltér az aktuális sebességtől, ezért feszt kell kapcsolnod a motorra. Ekkor szorzod meg az előírt és az aktuális különbségét az erősítéssel (P-vel). Értelemszerűen, ha az erősítés 0, akkor sosem indul el a motor, ha az erősítés túl nagy, akkor elindul a motor mint a mérgezett egér.
Az I része a szabályzónak abból áll, hogy minden dt időben, integrálod, vagyis összegzed a különbségét az előírtnak az aktuálistól. Ezt az összegzett értéket is hozzáadod a P szabályzóval kiszámolt értékhez. EZ kb arra jó, hogyha a P erősítési értéke nagyon kicsi, mondjuk 0, akkor is szép lassan egyre csak összeadod a hibát, és végül eléred az előírt értéket. Az I résznek is van egy erősítési tényezője.
Az egészet pedig a Ziegler-Nichols módszerrel tudod behangolni. Ez amolyan ökölszabály dolog. Ziegler-Nichols
Hadd linkeljek egy képet, ami ezt a konyhanyelv leírásom jól személteti:PID
Valaki próbált már AVR-ről adatot küldeni MATLAB környezetbe UART-on keresztül? Egy USB-UART konvertert szeretnék használni mindehhez. Nézegettem neten az Instrument Control Toolbox-ot ami olybá tűnik alkalmas ilyesmire de egy kicsit el vagyok még veszve a leírás részleteiben. Nekem ugyanis semmi másra nincsen szükségem csak arra, hogy 8 bites adatcsomagokat (gyakorlatilag "unsigned char" méretű számokat) küldjek a programnak és azt feldolgozás után grafikusan ábrázoljam.
Jobb híján köss össze két PC-t. Aztán hiperterminálban írogass dolgokat matlabnak. Még azt is megteheted, hogy csinálsz szoftveresen 2 RS232-t a PC-n és azokat loopbackkel összekötöd. Van erre valamilyen szoftver.
Igen, nagyjából értem, hogy ez a lényege, de sajnos még mindig nem áll össze a kép, hogy hogy is kéne erre programot írni. Szóval a sima arányos tényezőt úgy írtam le hogy:
sebesség = konstans*(beállított pozíció érték - aktuális pozíció érték)
Akárhogy is csináltam, mindig az történt, hogy olyan gyorsan forgott a motor, hogy egyből túllendült a 0 értéken ami után 4095 jön és forgott tovább mint az őrült. Ezek után raktam bele mindenféle "if" parancsokat ami valamit javított, de nagyon össze-visszaság lett belőle.
"dt időnként mintavételezni a sebességet"- ez például világos, meg a többi is, de az nem, hogy hogyan is csinálom meg. A Zeigler-Nichols dolgot pedig egyáltalán nem értem .
Aham, tehát pozícióra szabályzol. Nos tegyük fel, hogy 360 fok a körbefordulás (értelemszerűen). Te előírsz 350 fokot és éppen 0 fokon van. Természetes, hogy felgyorsul mint az állat, eléri a 350 fokot és úgy elhúz mellette, hogy máris 0 foknál van. Ott aztán megint nagy a hiba és rákapcsol megint kakaót, a nagy hiba miatt.
Egyáltalán mindkét irányba tudod forgatni a motort? Neadj isten fékezni?
Egy P szabályzó önmagában bitang nagy lengéseket okoz, amennyiben nincsen I tag mellette. Amúgy meg vedd le kicsire a "sebesség = konstans*(beállított pozíció érték - aktuális pozíció érték)" -ben a konstanst.
Aggódni nem kell, hogyha a sima P szabályzó nem éri el az előírt értéket, hiszen a nagykönyv is megírta, hogy mindig lesz maradandó hiba.
Sziasztok!
Kérnék egy kis segítséget. Adott egy kapcsolás, Attiny13-al menne, de valamiért az egyetlen darabom megdöglött, nem látja a programozó. Viszont szükségem lenne az eszközre, amibe a proci menne. Mivel esélytelen a héten újat beszereznem, így át kellene alakítani a programot Attiny24-re, mert az van itthon. A gond csak az, hogy asm-ben van a program. A procit átírtam a kódban, 5 hibát adott, de életemben sosem foglalkoztam asm-el, így nem is nagyon tudom javítani. Ha valaki rá tudna nézni a programra és esetleg nem bonyolult átírni a másik procira az megcsinálná nekem? Itt a link a cucchoz. Bővebben: Link
A Ziegler-Nichols módszer egy kísérleti módja a szabályozás behangolásának. Lényege, hogy megkeresed azt az erősítést amelynél a kimeneti jel állandósult lengésbe jön, oszcillál. (Pl. egy motor periodikusan felpörög-lelassul, felpörög-lelassul és így tovább állandó időközönként) Ezt az ismert ún. kritikus körerősítést felhasználod a paraméterek számítására PI szabályozás esetén a következőképpen: P=0.45*kkritikus (ez gyakorlatilag a szabályozó erősítése lesz) illetve Ti=0.85*Tkritikus. Ahol Ti az integráló tag időállandója melyet a lengések periódusidejének ismeretében (Tkritikus) határozol meg. Látható, hogy ehhez már bizony műszeres méréseket is kell végezni. Remélem nagyjából érthető volt a dolog.
Egy gyors kérdésem lenne ahhoz aki használt már TCN75 IC-t. A három címbit közül amit 1-nek szeretnék, azt mindenképpen fel kell húzni magas szintre? Vagyis nincs az IC-n belül felhúzva? Sajna adatlapban erről nem találtam semmit. (Univerzális panelt szeretnék csinálni, ahol utólag ki lehet jelölni az IC címét)
Szia!
Köszi a tippet! Találtam egy leírásfélt ehhez. Itt végülis a COM portot kell neki megadni ahogy látom és működik a dolog (elvileg). Még annyi, hogy ha kérhetem tudnál nekem egy kis fejtágítást adni ,hogy ha én összekötöm USB-UART konverterrel a gépemet akkor pontosan milyen szabvány szerint kommunikálok illetve mit is csinál ez az USB UART átalakító? Használtam már AVR-rrel HyperTerminal-ban, működött is de szeretném tudni pontosan mi történt akkor a háttérben. Ha nagyon OFF a téma itt és inkább máshová írod a választ kérlek jelezd majd!
Így próbáld meg. Az a baja hogy az Attiny13-ban kicsit az SRAM így csak simán SP regiszter van. Az Attiny24-ben pedig már elég nagy ahhoz, hogy SPL és egy SPH regiszter kelljen.
OFF:
Hello!
Olvastam ám adatlapot meg ezt is. A legfelső postból számomra egyértelműen az derül ki, hogy a max 232 önmagában alkalmatlan arra, hogy USB felületen kommunikáljunk a PC és egy UART modul közt. Ez csak az RS232 szabványú jelek szintillesztését végzi úgy, hogy a mikrovezérlő számára az megfeleljen semmi mást. Tehát evvel csak a soros portra csatlakozhatunk. Míg az FT 232 már USB protokoll szerinti kommunikációt tesz lehetővé. Ezért voltam némileg zavarban mikor azt írtad, hogy :"Összekötöd max232-vel az AVRt és az usb com portot." Nem mondom, hogy Te hülyeséget írtál csak számomra nem egyértelmű most a dolog. Ezért kérdeztem.
ON:
Hírek.rss
.
» A fájlok letöltéséhez be kell jelentkezned! «
. Jó múltkorában ismerőssel csináltunk egy virtuális digi oszcit melynek programja 4000+ soros (PIC32 C-ben), és bizony nagyon jól jött az online debug. Pl. mikor a uC lábait néztük, hogy van-e jel, akkor csak simán lépkedni kellett és azonnal látszódott, a műszeren, hogy van-e vagy sincs a lábon fesz. Nem kellett külön erre programot írni.
.