Da li si hardverski dobro rije¹io sklop? Ja sam jednom zaboravio staviti kondenzator (100nF) kod mikrokontrolera i de¹avale su mi se svakakve gluposti, a bio sam uvjeren da ne¹to ne valja sa programom. Ima¹ li stabiliziranih 5V, kako upravlja¹ motorom?
Damir
u
aj
a i
to ne valja =
pic16F722 ima interni hardverski 16Mhz oscilator, tako da ne koristim =
nista van chipa. ali sa 18F imam problema sa jednim koji nije zalemljen, tu nisam ni =
stavljao kondenzatore, mislim da je to definitivno tu problem, ali kao s= to =
mi je chupo rekao, za moj problem i 16F bi morala raditi dovoljno brzo..= .
5V je stabilnih, nadam se, jer nista osim PIC-a ne opterecije sklop po =snazi, a izvire iz PICKIT2 programatora, tako da ocekujem da je sve ok.
trenutno sam ga pustio takvog kakv jest, i radim na PC strani softvera =
ciji je nedostatak postojanja "ocitiji" jer sam na ovo potrosio daleko =
previse vremena.
no uocio sam jednu neobicnu stvar kompajler mi nije javljao gresku, ali ako je varijabla definirana kao =
longint, a njoj dodjeljujem neku word varijablu, nista ne radi... ne vid= im =
zasto to ne bi moglo raditi, kompajler se ne buni, ali... ne radi. vjerujem da imam gresaka tih vrsta pregrst...
A kako upravlja¹ steperom? Koristi¹ neki driver ili si ne¹to sam slo¾io?
Damir
=B9to sam slo=C2=BEio?
za sada koristim 4 pina na pic-u, koristim neku shemu rotacije brojaca na PORTA: 1,2,4,8 kojom mjenjam =
stanje PORTA i to koristim kao ulaz na H-mostu l298. inkrementacijom =
steper ide u jednom smjeru i obrnuto. ako mi se ucini da je potrebno imati jaci steper, ili to trzanje bude =
preocito, onda cu kupiti nesto ovakvo za 13-15 dolara, iako jos ne znam = =
sta njemu treba... pretpostavljam jedan pin koji daje "idi sad" i jedan = =
pin koji kaze smjer
za sada to moram pustiti i posvetiti se PC-softveru pa se vratim ovoj =
problematici nekad kasnije. inace, procitao sam na jednom forumu da je kod timera (a koristim timer = za =
vrijeme kad se steper pokrece) potrebno program sloziti da bude:
if INTCON.TMR0IF then TMR0=3D195 'setiranje vremena timera INTCON.TMR0IF =3D 0 ' clear the flag '------------------------ 'rutina koja obradjuje stvar '------------------------ end if
a ne ovako:
if INTCON.TMR0IF then '------------------------ 'rutina koja obradjuje stvar '------------------------ TMR0=3D195 'setiranje vremena timera INTCON.TMR0IF =3D 0 ' clear the flag =
end if
-ne znam koliko ima veze, ali isprobat cu to tek kad nadjem vremena, iak= o, =
kako kaze "chupo", taj pic je dovoljno brz da mu taj redosljed stvari ne= =
bi smio predstavljati problem
U prvom slucaju bi se, ako bi ti trajanje rutine bilo predugo mogo propustiti jedan interrupt. Jer, ako bi se za vrijeme dok se jos izvrsava obrada desi novi timer overflow pa bi ga ti na kraju rutine resetirao, onda bi se morao cekati novi overflow, a ako flag resetiras odma na pocetku i ako se overflow desi za vrijeme obrade, ce se novi interrupt generirati odmah nakon izlaska iz obrade prethodnog. Ali rutina za obradu ne smije trajati vise vremena nego sta je vrijeme izmedju timer overflow-a. Ako se npr. TMR interrupt generira 1000 puta u sekundi, onda se ne smije desiti da ti rutina traje vise od 1/1000 s.
-- Chupo
Ima veze - naime, u drugom sluèaju se timer re-inicijalizira tek po izvr¹enju rutine. Ako vrijeme izvr¹avanja zbog nekog razloga nije uvijek isto (npr. ima nekakvih if-else uvjeta i slièno), niti vrijeme izmeðu dva timer-overflowa neæe biti isto. U prvom sluèaju se timer re-inicijalizira na poèetku, uvijek jednako, bez obzira na ono ¹to se izvr¹ava iza toga, pa æe i vrijeme izmeðu overflow-a biti isto. U tvojoj aplikaciji, to æe dati "glatki" rad motora jer æe step-impulsi biti uvijek pravilno razmaknuti.
Inaèe, pravilo je da interrupt service rutine budu èim je kraæe (i br¾e) pa bih ja to napravio ovako:
- timer interrupt rutina iz mem.lokacije proèita novo stanje porta (ili vi¹e njih) i postavi nekakav flag. Glavni program u petlji detektira postavljeni flag, izraèuna novo stanje za portove i upi¹e u mem.lokaciju iz koje æe ih int. rutina "pokupiti". Jedini uvjet da ovo radi savr¹eno je da glavni program zavr¹i sa raèunom prije slijedeæeg interrupta.
-- - while (1); "I don't believe anything I hear and only half of what I see..."
Krivo sam napisao - ovo sta je napisao while(1) je tocno.
Moj komentari bi vrijedili ako bi prvi slucaj bio:
if INTCON.TMR0IF then TMR0=195 'setiranje vremena timera '------------------------ 'rutina koja obradjuje stvar '------------------------ INTCON.TMR0IF = 0 ' clear the flag end if
a drugi:
if INTCON.TMR0IF then TMR0=195 'setiranje vremena timera INTCON.TMR0IF = 0 ' clear the flag '------------------------ 'rutina koja obradjuje stvar '------------------------ end if
U svakom slucaju, najprije treba reinicijalizirati timer (brojac) a ako je rutina napisana ispravno (ako traje manje od vremena izmedju dva timer overflow-a), onda nema veze da li ces flag resetirati na pocetku ili na kraju.
Atmeli recimo imaju CTC (Clear Timer on Compare Match (Auto Reload)) mode pa se u tom mode-u reinicijalizacija rjesava automatski, a svaki interrupt ima svoj vector pa se ne mora zezati s odgonetavanjem zbog kojeg je interrupt-a rutina pozvana. Ovaj PIC kojeg koristis ima interrupt priority mode pa bi se s tim (vjerojatno) moglo postici da tvoje 2 interrupt rutine budu odvojene, a u datasheet-u vidim poglavlje 'Module Reset on CCP Special Event Trigger' - cini se da je to nesta ko Atmelov CTC mode (pa da se nakon interrupta timer reinicijalizira automatski). Nisam radio s 18F2450 pa ne znam 100% ali mi izgleda ko da se radi o istoj stvari.
-- Chupo
Kod njega je situacija malo specificna jer mu za TMR1 vrijeme izmedju interrupt-a nije konstantno nego se svaki put unutar interrupt rutine na osnovu parametara (PWM) za svaki od serva izracunava vrijednost s kojom ce se timer inicijalizirati ali to je samo nekoliko linija koda na 16 MHz a i ta mu rutina izgleda ne radi probleme. U rutini za TMR0 sam previdio da se najprije zove potprogram pa se tek onda inicijalizira timer - cini se da bi to mogo biti uzrok trzanja.
-- Chupo
Gledam mailove i ne vidim da smo diskutirali o tom redoslijedu ali sad kad ponovo gledam source, vidim da najprije pozivas step1_MOVE a tek onda reinicijaliziras TMR0, moguce da je to uzrok - reinicijalizaciju timera obavezno stavi na vrh pa javi da li je nestalo trazanja...
-- Chupo
(i br=BEe) =
ili =
anje =
eno =
da se javim svima i ne budem bezobrazan. dakle, probao sam za pocetak promjeniti slijed resetiranja timera, ali n= e =
mogu otkriti pravilnost. cini se od oka da je malo bolje, ali ne mogu bi= ti =
objektivan, nisam detaljno testirao. trenutno se zezam s upravljackim =
programom za PC, posvetit cu se picu kasnije, a i probat cu malo izmjesa= ti =
kod u glavnoj petlji, pa da probam ovu shemu sa sa flegovima. iako... ci= ni =
mi se da su tada pravilni intervali za glatki rad stepera jos vise =
podlozni nepoznanicama, jer tada je moguce da se glavni program (koji pa= li =
pinove porta nakon sto okrije promjenu flega) prekida jos vise puta zbog= =
ostalih interrupta...
inace, par stvari koje sam otkrio a vezane su za PC:
-na win 7 .NET, event timer ne moze ici ispod 20ms, iako je moguce =
namjestiti interval cak i na 1ms, on se ne ponasa tako (kod mene).
-serijski port na 115200 nije dovoljno brz za direktno upravljanje radom= =
stepera (inkrementiranjem pozicije +1)
Nije problem u brzini (baud rate), veæ u Windowsima. Ako misli¹ upravljati koracima step-motora izravno preko RS232 i Windowsa, zaboravi. Tu je latencija Windowsa jednostavno prevelika. I jo¹ je gore preko USB-RS232 konvertera. A osim toga, generiranje vi¹ih frekvencija (>10Hz) iz Win7 (kao ¹to si i sam primjetio) takoðer ba¹ ne ide. Windowsi jednostavno NISU za real-time aplikacije (mada postoje RT-kerneli za iste, no to je veæ druga prièa). Upravo zato se najèe¹æe i koriste pametni kontroleri kojima, umjesto izravnih komandi za svitke motora, ¹alje¹ naredbe tipa "naprijed 150 koraka" ili slièno.
Alternativa je da napi¹e¹ vlastiti driver za RS232 port i kontrolu motora ili da krene¹ putem MACH3 softvera...
-- - while (1); "I don't believe anything I hear and only half of what I see..."
n7 =
esto =
=
hm, da... vidim. a jos gore su latencije peko BT-RS232!!!
pa nista, back to reality, krecu prvi kompromisi :) zamislit cu da mi je dovoljna i manja preciznost, sto pozicionalno, sto = =
vremenski :)
Pa kad veæ ima¹ mikrokontroler, za¹to u njemu ne implementira¹ kompletno upravljanje motorima, a iz PC-a ¹alje¹ samo ¾eljenu poziciju? To æe sigurno raditi bolje...
-- - while (1); "I don't believe anything I hear and only half of what I see..."
to =
kompletno =
o raditi =
da, nema druge pa evo, radio sam danas na tome. as of today, PC moze poslati:
-poziciju stepera
-brzinu stepera
-steper enable (...i ostalo sto nije povezano s ovim...)
a pic moze poslati:
-trenutnu poziciju stepera
-stanje 4 switcha (krajnje mrtve tocke)
pic moze:
-sam inkrementirati dok ne dovede ili motore ili steper u zeljenu ili =
krajnju poziciju
-sam prekinuti inkrementaciju pri nailasku na neki od swicheva
pic jos uvijek ne moze:
-zapamtiti gdje je bio u koje vrijeme ili bi mogao, ali bi to previse =
zakompliciralo sve (recimo mem kartica bi trebala)
-sam prepoznati kad je dobro vrijeme da steperu smanji struju (odnosno, = =
upali PWM) dok samo stoji na mjestu
-imati glatke prijelaze (recimo neka kubna funkcija) izmedju naglih =
promjena pozicije koju dobiva s PC-a
-u ovisnosti o jednom proizvoljnom parametru (steper pozicija) mjenjati = =
drugu (servo x)
-...
........................................................... s obzirom na kolicinu problema, skuzio sam zasto svaki softver ima tolik= o =
bagova i updatea. zato jer je bitno napraviti makar nesto da radi, pa se= =
poslije vracati onome sto nije dovoljno dobro :) od svega ovoga najvise me iznenadilo ovo s PC-em dakle, ideja svega ovoga sto radim jest ponovljivost. korisnik ce jednom= =
nesto napraviti, bez neke pravilnosti, a sistem bi trebao moci zapamtiti= =
sve to i ponoviti radnju proizvoljan broj puta (ocekuje se uvijek dostup= an =
PC). sada, ta ponovljivost ce biti rezultat PC funkcije koja snima stanje =
svakih 50ms.
a sad opet O.T. jos jedna stvar koju sam naucio u vezi PC-a:
-standardni mis (od 100 kn) na windowsima je prilicno neprecizan, odnosn= o, =
"skakutav" je! ako se on koristi kao REAL_TIME davac inputa (koristenjem slider kontrol= e =
u .NET-u), dobije se trzava stvar. mozda je neki gejmerski mis bolji, al= i =
koji korisnik ima gejmerski mis?
drugo: mislim da cu morati prouciti direct-x da vidim kakvo je stanje s =
joystickom kao inputom :)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.