U potrazi za tartufima AVR-a

[InTheStillOfTheNight]

"U potrazi za tartufima AVR-a" - Blink control

Kada govorimo o zadatku većina početnika bi pokušala čitati tipku i kontrolirati impulse LED-a, što je apsolutno krivo razmišljanje. Istovremeno paziti na korisnika, njegovu tipku, brojati impulse koje on unosi, paziti na debounce, paziti na dugi pritisak tipke (1 S) i kontrolirati rad LED-a, moram priznati NEMOGUĆE JE. Nemamo baš tako dobar mozak da možemo sve ove kombinacije programirati paralelno. To je ono što početnici stalno pokušavaju i uvijek se gube u kombinacijama "što bi bilo kad bi bilo".

Prvenstveno moramo znati razdvojiti problem na zasebne cjeline, koje su u pravilu trivijalne. Tipka po kojoj lupa korisnik programski gledano gotovo nema nikakve veze sa blinkanjem LED-a. Zamislimo da imamo 2 crne kutije, jedna kontrolira LED, a druga kontrolira tipkalo. Jedina poveznica između ove dvije kutije govana je uključi, isključi i blinkaj toliko puta u sekundi.

Evo nas na prekretnici "što prvo pisati"?
Kako god da okrenemo ne smijemo pisati obe stvari istovremeno, dakle nikako pokušati napisati program onako "iz rukava".

Između njih 2 koliko ih ja vidim, prvo ću odabrati kontrolu LED-a, a to istovremeno znači da tipke za mene ne postoje. Uopće ne želim razmišljati o debounce, 1S, na kojem je portu... Za mene moj izbor kutije znači što u nju ulazi, što izlazi i što kutija radi.

Ulazi:
Uključi ili isključi blinkanje
Blinkaj n puta u sekundi

Izlazi:
Ništa

Radi:
Blinka

Ove 2 stvari ne moraju biti u posebnoj datoteci, što je najgore mogu biti u istoj datoteci, u istoj funkciji, pa čak i izmješane u funkciji. Jedino moraju biti odvojene u našoj glavi dok programiramo jednu ili drugu stvar. Ovim načinom razmišljanja svaki program, da je ne znam koliko kompliciran možemo razdvojiti na niz jednostavnih stvari. U konačnici samo povežemo jednu, drugu ili petu kutiju govana i čudom stvar radi savršeno.

[InTheStillOfTheNight]

"U potrazi za tartufima AVR-a" - Blink control

Pošto sam program ranije objavio u njemu postoji samo nekoliko razlika koje su napisane zbog kontrole blinkanja LED-a. Pa evo da ih i navedem:

Code: Select all

if(t_led >= (500/led_status)){     /* t_led timeout? (500/led_status time)     */

Code: Select all

if(!led_status){	    /* blink LED not enabled?   */
    LedOff();          /* Turn off LED	          */
    return;            /* end of Blink LED service */
}

Da bi kontrolirali brzinu blinkanja LED-a očito smo morali promjeniti onaj statičan uvijet "if(t_led >=1000)". No zašto baš na "500/led_status"? Najlakše vam je na to gledati ovako:

led_status = 1 -> if(t_led >= (500/1)) -> LED će promijeniti stanje svakih 500mS, dakle 1 blink/sekunda
500 ms ON, 500 ms OFF

led_status = 2 -> if(t_led >=(500/2)) -> LED će promijeniti stanje svakih 250 mS, dakle 2 blinka/sekunda
250 ms ON, 250 ms OFF, 250 ms ON, 250 ms OFF

led_status=250 -> if(t_led >=(500/250)) -> LED će promijeniti stanje svakih 2 mS, dakle 250 blinka/sekunda
........

Čitava nauka oko blinkanja je završena dodavanjem samo ovog uvjeta. Ona druga kutija programa koja kontrolira tipkalo nema nikakve veze sa blinkanjem LED-a. Njezin čitav posao je sporazumiti se sa korisnikom tipke i promijeniti led_status varijablu.

Zašto sam dodao LedOff(); u slučaju da je led_status = 0?
Znam da onaj drugi dio programa koji kontrolira tipku sigurno neće paziti na to hoće li LED ostati uključen ili isključen kada on postavi led_status = 0;

Kada pišemo drugu stranu programa, tj tipkalo, nikako si ne smijemo dozvoliti da moramo razmišljati hoće li LED ostati uključen ili isključen. Svaka ona kutija, od njih dvije, pune xxxxxx, moraju se brinuti za svoj dio posla, a jedina poveznica između njih je led_status varijabla.

Zaboravih navesti "!" u c-u je negacija. Kada napišem if(!led_status) to je isto kao da sam napisao if(led_status == 0)

[InTheStillOfTheNight]

"U potrazi za tartufima AVR-a" - User Button

Drugi dio programa nešto je kompliciranije napisati, pošto još nismo ni otvorili onu drugu kutiju xxxx tvari. Nikad ne znaš što je sve unutra dok ne otvoriš. (Kao kinder jaje, misliš da si neš' dobio, kad unutra sranje.)

Prvo bi trebalo odrediti lokaciju na kojoj to pisati. Sve ono što se vrti u glavnoj loop petlji je funkcija RunLedBlinkService(); Naravno da bi mogli napisati sve za tipku u posebnoj datoteci i posebnoj funkciji, ali to nećemo napraviti iz jednog jednostavnog razloga. Nema puno programa, nema potrebe, a i tipka kao takva dio je programa za kontrolu LED-a. Suludo je otvoriti još jednu c i h datoteku jer kasnije ćemo imati 100 datoteka za 50 sitnih funkcionalnosti.

Uostalom, prilikom poziva svake funkcije mikrokontroler gubi nešto vremena da pozove funkciju, a samim time i nešto FLASH-a. Znači li to da bi naš program bio manji i brži da je napisan u funkciji main? Da, bio bi nešto zanemarivo manji i nešto zanemarivo brži, ali drastično lošiji za održavanje. Zamislio da imamo u main funkciji 50 stranica programa koji upravlja sa 100 čuda... Sumljam baš da bi nam bilo sasvim jasno čemu što služi u programu... Dakle treba naći nešto optimalno za održavanje programa, a opet osloboditi main funkciju. Iz tog razloga ovo pišemo u istoj RunLedBlinkService(); funkciji.

Ako smo već u istoj funkciji naprosto imamo 2 izbora:
1. Napisati to prije blinkanja LED-om
2. Napisati to nakon blinkanja LED-om

Ne bih ovo uopće pisao da jedna od ovih opcija nije fatalan BUG. Kontrolu tipkala i korisnika nikako ne možemo napisati nakon blinkanja LED-om i sve zato jer sam ja napisao sveti return;
U slučaju da je led_status = 0, return će se vratiti u main, što znači da tipku više nikada nećemo provjeriti.

Zašto bih ja onda uopće napisao return, a ne to uvjetovao sa if-om.
Čisto zbog toga što ne volim da mi se pod if-om nalazi još jedan if, pa još jedan pa... Svaki if, while, for... pomiče program za jedan tabulator desno, što znači ako napišete 10 if-ova pod if-om treba vam barem 2 duža monitora da to prikažete. Zato često u praksi kad mogu osječem funkciju sa returnom. Da to nisam napisao tako, onda bi napisao ovako:

Code: Select all

if(led_status){		
    cli();
    if(t_led >= (500/led_status)){
        LedToggle();
        t_led = 0;	
    }
    sei();
}
else{
    LedOff();
}

i tek u ovoj situaciji bilo bi apsolutno svejedno hoćemo li tipkalo pisati ispod ili iznad blinkanja LED-om.

Gledam u ovu drugu kutiju, i ne mogu se oteti dojmu da program u njoj izgleda kao plod ljubavi između Sibirskog Haskia, i Azijske rogate žabe.

[InTheStillOfTheNight]

"U potrazi za tartufima AVR-a" - User Button - Korisnički mozak

Kada god sam nešto programirao direktno za korisnički mozak imao sam pitanja da boli glava, valjda mi je trebalo 10 godina da shvatim kako niti jedan korisnik zapravo ne zna što točno želi. Evo neka pitanja koja mogu postaviti korisniku ovog uređaja:
1. Zamisli da 3 puta brzo stisneš tipku i onda je 4 puta držiš duže od sekunde? Jesu li to 4 blinka u sekundi ili je to isključivanje blinkanja?

2. Koje vrijeme je vama potrebno da prestanete dirati te tipke i da LED prihvati vaš unos za blinkanje?

3. Kako će blinkati LED-ica kada je podesite na 5 puta u sekundi, ugasite i upalite blinkanje? Hoće li blinkati 5 puta ili će se resetirati na default?

4. kada uključujete, isključujete blinkanje LED-a, ili mjenjate broj blinkova u sekundi, hoće li LED odmah početi blinkati novom frekvencijom, ili želite da završi zadnji period blinkanja starom frekvencijom?...

Nemojte takva pitanja postavljati korisničkim mozgovima, oni ne znaju što žele. Očito mi za njih moramo odlučiti. To znači da sve ove sitnice moramo imati u tom programu, i još moramo znati što korisniku točno treba jer on to ne zna. Za njega pritisak tipke znači: "ono crno gurnuti unutra, i pustiti da se vrati samo".

Ove korisničke stvari definirati ćemo kada dođemo do pojedinih sitnica, no nažalost sve ih moramo imati. Svaki imalo dobar program pazi na ove detalje i uvijek se prilagođava korisniku, ne nama. Jasno je meni da su neke sitnice apsolutno nepotrebne, ali trebali bi ih naučiti napraviti.

U tom drugom segmetu programa koji je ostao ima dosta posla. Nemojte misliti da kad kažem ima dosta posla mislim na to da nekoga obeshrabljujem. Stvar je jednostavna i sve se napiše za nekih 10 min - 4h, ovisno o programeru, ali komplicirana je jer se trudim objasniti kako to napraviti pa se na svakoj sitnici moram zadržati određeno vrijeme.

U toj drugoj kutiji, nažalost još 2 manje kutije.
Na prvoj piše DEBOUNCE, pa uzmimo nju za početak.

[InTheStillOfTheNight]

"U potrazi za tartufima AVR-a" - User Button - Debounce i Beginner Switch

Najteži dio ulaska u programiranje je upravo ovaj Beginner Switch, nekako ga moramo prebaciti u drugo stanje, a ja baš nemam najbolju ideju kako... Dvoumim se između 2 stvari:

Ako napišem onako kako treba, većina početnika neće shvatiti zašto sam to tako napravio.
Ako napišem onako kako će svi shvatiti, onda nisam napisao ono što želim napisati.

Razumijem tu problematiku, jer svatko od nas jednostavno mora prebaciti jedan način razmišljanja o programiranju u totalno suprotan način. Nažalost, moram vas razočarati kako je taj suprotan, zapravo jedini ispravan.

Probati ću se uhvatiti istine, pa kako bilo. Djed mraz ne postoji, Milkina krava nije ljubičasta i BASIC-OV debounce nije programerski ispravan debounce.

Znamo da možemo provjeriti PIN mikrokontrolera i znati jeli on "High" ili "Low", ali ne možemo na taj način znati jeli korisnik stisnuo tipku jednom ili 10 puta. Svaki pokret ruke prema tipkalu ima jedan specifičan trenutak kad korisnik u nekoj nS prebacuje stanje iz "pušteno" u "stisnuto".

Na mikrokontroleru smo toliko brzi da uhvatimo nekoliko uzastopnih puštanja i stiskanja tipke i sve to u nekoliko ms. Moramo definirati ono što je stisnuto, a ono što je pušteno.

Kako to radi BASCOM? Programerski krivo, evo paste s njihove stranice o debounce naredbi:

The DEBOUNCE statement tests the condition of the specified pin and if true there will be a delay for 25 mS and the condition will be checked again. (eliminating bounce of a switch)

Ne morate uopće znati eng da vas ubode samo jedna kriva stvar: "DELAY" Bascom će provjeriti stanje tipke, pricekati 25mS, pa provjeriti ponovno i tada tek biti siguran...

Češkam se po glavi, pa vas pitam koliko se vama čini 25mS vremena?
Meni iskreno čitava vječnost, s obzirom da se TIMER podesi za 0.001mS, da izvršimo čitavu funkciju za blinkanje LED-a u nekih 0.001mS, i da nužno moramo izvršiti RunLedBlinkService() češće od 1mS.

Sama pomisao da iskoristite BASCOM naredbu u mom programu već ste napravili problem... Pratite TIMER i t_led varijablu u jednu mili sekundu, a čekate debounce punih 25. To znači da će LED krivo blinkati u najgoru ruku kasniti će za promjenom stanja 25mS. (jer čekamo u debounce)

Moramo isključiti beginner switch i pustiti program da se vrti u while(1){} main funkcije maksimalnom brzinom, te napraviti pravi servisni debounce, koji nam ne krade 25 mS vremena.

edit:
Natipkah to nabrzinu, pa evo debounce gotov, u sljedecem postu objasnjenje...
Treba imati na umu da niti jedan program ne testiram pa je moguce da sam sebe negdje prevarim u razmisljanju i u slucaju da nesto krivo napisem javite da mogu ispraviti...

[InTheStillOfTheNight]

"U potrazi za tartufima AVR-a" - User Button - Debounce i Beginner Switch (2-dio)

Program je već napisan i objavljen u prošlom postu, pa evo i detaljnije objašnjenje zašto sam to baš tako napisao. Prvenstveno moramo znati, vraćam se kao i uvijek, da DELAY ne smijemo koristiti. Ne zato što ga ne bi mogli napisati i izbjeći muke sa razmišljanjem nego zato jer bilo koje čekanje ne utječe samo na blinkanje LED-a, utječe na čitav program, i sve ono što još želite napisati u budućnosti. BASCOM-ov debounce meni je osobno nož pod vratom. Jako dobro sam svjestan činjenice da svi moji programi sigurno budu izvršeni ispod 1mS, osim kad nužno moram emulirati neki protokol komunikacije koji je spotiji od 1ms.

Uastom zašto bi uopće čekali 25mS, kad znamo da smo svake 1mS u ISR-u, tj našoj prekidnoj rutini. To je naš sat za potrebe realnog vremena. Do sada bi trebali znati da TIMER svake 1mS prekida glavni main program i skače na ISR rutinu i kad smo već u stanju tamo biti svake 1mS, što bi čekali 25 mS? (25 ms je debounce bascoma).

Što god da programirali, moramo se učiti nikada ne stati i nikada ne čekati. Što se prije ponovno pojavimo u glavnoj loop petlji, to smo napisali bolji program. Metodom palac oko, mogu reći kako je funkciji RunLedBlinkService() potrebno oko 5 us da se izvrši. Naglašavam "mikro sekunde, ne milisekunde". Po toj moj predpostavci ispada da ćemo cca 200 puta provjeriti t_led varijablu prije nego li je prekidna servisa rutina ISR, poveća za 1. (200uS*5 = 1mS ->ISR CALL). Točna brzina može se provjeriti osciloskopom ili računanjem vremena izvršavanja assemblerskih instukcija.

Da bi uopće razumjeli moj debounce morate postati svjesni stvarne brzine mikrokontrolera i onoga što je on u stanju programski izvršiti kada ga pustimo sa lanca. Gledajmo onda na to ovako. Idemo zavrtiti moj dio programa na cca realnu brzinu koju sam definirao palac-oko metodom (izvrši se svakih 5uS):

Code: Select all

if(t_debounce >= 50){					
    t_debounce = 0;	
    button = Button();		
}
else if(button == Button())	
     t_debounce = 0;

t_debounce - moj sat u RAM memoriji koji mi ISR povećava svakih 1mS.
Button() - MACRO naredba koja vraća stanje tipkala spojenog na PC1
button - moja varijabla u RAM-u koja govori o stvarnom stanju tipkala (debounce)

Čisto si malo zavrtite dio programa u glavi brzinom kojom ga izvršava mikrokontroler do idućeg posta.
Obratite pozornost da je Button() registar tipkala, i na njemu korisnik mijenja stanje tipkala, i upravno na njemu imamo smetnje pušteno, stisnuto. Također obratite pozornost da t_debounce ISR povećava svakih 1mS, što možete vidjeti u programu prošlog posta.

[InTheStillOfTheNight]

"U potrazi za tartufima AVR-a" - User Button - Debounce i Beginner Switch (3-dio)

Code: Select all

#define Button()   ((PINC>>PC1)&0x01)

Tipkalo ovog programa spojeno je na port PC1, ali da bi pročitali samo PC1 opet moramo imati malo hijeroglifa u programu. U prošlim postovima kod konfiruracije DDR i PORT registara pisano je o tome kako se pristupa jednom bit-u u C-u, i uvijek smo 1 gurali lijevo, kad najednom ja PINC registar pogurao desno i maskirao ga s 0x01.

Bez obriza podesimo li DDRC (Data Direction Register C) kao ulaz ili kao izlaz, čitanjem PINC registra uvijek dobivamo trenutno stanje čitavog porta C. Prvi problem je taj jer je naše tipkalo spojeno na ulazu PC1, i ono što mi dobivamo iz registra PINC izgleda ovako:
(BIN)000000X0

U crvenom sranju je problem, jer se naš bit za PC1 nalazi na 2 poziciji gledano s desne strane. Prvenstveno želimo da nam MACRO naredba za čitanje tipkala vrati vrijednost 0 ili 1, a ne stanje čitavog porta [0-255] i iz tog razloga ja najprije poguram port desno za PC1 kako bih dobio ovo:
(BIN)0000000X, i prislio moj PC1 bit da dođe na prvu desnu poziciju.

No sad moram ignorirati stanje svih ostalih bitova jer me oni ne zanimaju, pa radim AND operaciju sa 0x01 kako bih svih ostalih 7 bitova postavio na 0, što bi izgledalo ovako:
(BIN)0000000X AND
(BIN)00000001
-----------------------------------------------------
(BIN)0000000X

I u ovoj situaciji moja MACRO naredba Button() uvijek će mi vratiti samo 0 ili 1, ovisno o stanju mog tipkala spojenog na PC1 ulaz.

Moramo znati razdvojiti situaciju kada pišemo po registru, a kada ne pišemo. Nemojte se zavarati sa ovom linijom programa i pomisliti kako sam ja stvarno pogurao stanje PINC registra u desno. PINC registar samo je pročitan u radni registar mikrokontrolera, a sam radni registar je poguran desno i maskiran s 0x01.

Evo nekoliko primjera pisanja po registru:

Code: Select all

PINC |= 17;
PINC++;
--PINC;
PINC = 45;
PINC = (1<<3) | (4<<1);
if(PINC = 5){}

I evo nekoliko primjera koji samo čitaju PINC registar i koriste njegovu vrijednost za nešto:

Code: Select all

if((PINC>>PC1)&0x01 == 1){}
while(PINC<<5)){}
button = PINC>>2;

Kada pišemo po registru, naprosto moramo izjednačiti registar sa nekom vrijednosti, povećati ga, ili smanjiti.

Najbolji primjer je ovo:

Code: Select all

if(PINC = 5){}

Svaki imalo dobar compiler će vas odmah upozoriti da neki vrag ne štima, neće vam reći da je greška, ali će vas upozoriti. U ovoj liniji programa vi ne uvjetujete PINC registar, nego pišete po njemu, i upisujete vrijednost 5, a tek nakon toga provjeravate istinu ili laž. Svaki broj koji nije 0 sigurno je istina bez obzira bio on pozitivan ili negativan, i normalno da vas dobar compiler upozorava da ste napisali upravo ovo:

Code: Select all

PINC = 5;
if(5){}    /* ako je istina jednaka istini izvrši nešto*/

Uvijet if(5) je sulud i bez smisla, baš zato jer će uvijek biti zadovoljen.
I evo te razlike između "==", i "="; Ako je "==" onda nešto provjeravate, a ako je "=" onda nešto izjednačujete. Čisto da kolega kukinjos ne ostane zakinut za ovu misteriju

[InTheStillOfTheNight]

"U potrazi za tartufima AVR-a" - User Button - Debounce i Beginner Switch (4-dio)

Code: Select all

if(t_debounce >= 50){               
    t_debounce = 0;   
    button = Button();      
}
else if(button == Button())   
     t_debounce = 0;

Možda se nekome čini kako je 1ms malo vremena, a zapravo radi se o brdu korisnog vremena i u samo u tih 1ms možemo isprogramirati čitav FLASH mikrokontrolera. S druge strane namjerno pišem program na bazi ISR-a 1ms čisto da ne smijete napisati DELAY. Da se vratimo dakle programu. Testirao sam svoje vještačke sposobnosti i za čitavu funkciju sa pozivom iz maina i returnom potrebno je nešto malo više od 5us na 8Mhz.
Moj debounce nužno se svađa sa ISR-om jer do sada već moramo znati kako naš ISR nije baš tako brz. U samoj ISR rutini smo tek svakih 1ms, a u main programu sve odradimo za 5us. Zamislimo dakle da nitko ne dira tipkalo a program se i dalje izvršava svakih 5us. Pa ako ga baš nitko ne dira onda će ovaj dio programa biti izvršen uvijek:

Code: Select all

else if(button == Button())   
     t_debounce = 0;

Bez obzira što se ISR trudi povećati t_debounce u mainu ga stalno resetiramo na 0. Postavljamo t_debounce na 0 i samo čekamo trenutak kada ćemo ISR-u dozvoliti da ga povećava. Taj trenutak je upravo ovo:

Code: Select all

else if(button == Button())

Jedini način da nam ovaj uvjet nebude zadovoljen je kada netko pokuša stisnuti tipkalo, naprosto će malo zaplesati po PINC registru, i varijabla tipkala u RAM-u neće biti jednaka stvanom stanju tipkala i PC1 ulaza. Netko bi možda pomislio kako bi nešto programski trebali napraviti, no mi opet ništa ne radimo, jedino puštamo t_debounce da se povećava. Ako je baš toliki frajer da uspije nabrojati do 50ms, onda je netko sigurno stisno tipkalo.

Code: Select all

if(t_debounce >= 50){

Sve smetnje na tipkalu pokupiti će naš reset t_debounce varijable jer da bi uopće prihvatili novo stanje tipkala naprosto mora proći punih 50ms. Ovaj dio bi trebao biti jasan:

Code: Select all

t_debounce = 0;   
button = Button(); 

Nakon 50ms prihvaćamo novo stanje tipkala, upisujemo ga u RAM, i opet resetiramo brojač. U toj situaciji evo nas opet na početku posta i istoj stvari.

Ovim načinom napravili smo puno precizniji debounce od bilo koje DELAY metode jer je dovoljno samo 5uS smetnje na portu i opet nastupa reset t_debounce brojača. S druge strane, ne čekamo i zadržavamo brzinu mikrokontrolera, jer ako to izgubimo to bi bio i kraj programa.
http://www.youtube.com/watch?v=IhHUsgmewW8

[InTheStillOfTheNight]

"U potrazi za tartufima AVR-a" - Application (1 - dio)

Evo nas kod trenutka kada počinjeno govoriti o aplikaciji, ili aplikativnom programu. Čisto da ne mješate pojmove: Nije sve ono što programiramo aplikacija! Aplikativni program je primjenjiv program kojime korisnik upravlja uređajem i od kojeg očito ima nekakve koristi, inače ne bi niti korisio uređaj. To je i jedini dio koji je ostao za napraviti. Ako već sami nešto programirate, ili pokušavate programirati, obavezno program pišite od repa prema glavi. Ovaj rep očito je ISR, debounce, blink, a glava bi tada bila aplikacija.

Zadatak je već definiran:
Svaki pritisak tipkala na duže od 1 sekundu upaliti će ili ugasiti blinkanje LED-a.
Broj impulsa na tipci treba odrediti broj impulsa LED-a u jednoj sekundi.

Je, naravno da je definiran, ali u očima korisnika. Mi se ipak moramo pozabaviti malo većom problematikom vezano za ovu korisničku definiciju programa. Kao što sam već rekao, korisnik ne zna što točno želi, no kako naš uređaj baš i nema nekog posebnog smisla, a niti korisnika koji će ga koristiti, onda ćemo glumiti i korisnika i programera te se praviti da uređaj stvarno ima nekog korisnog smisla. Idemo dakle definirati ono što korisnika ne zanima, a mi moramo za njega znati:

1. Zamisli da 3 puta brzo stisneš tipku i onda je 4 puta držiš duže od sekunde? Jesu li to 4 blinka u sekundi ili je to isključivanje blinkanja?

Kada korisnik silno želi nešto ugasiti dobro će nagaziti tipkalo i neće ga pustiti. Gotovo je nemoguće držati tipkalo 1 sekundu, a željeti da uređaj blinka 4 puta. Bez obzira na prethodno unesene parametre, korisnik sigurno želi ugasiti blinkanje LED-a.

2. Koje vrijeme je vama potrebno da prestanete dirati te tipke i da LED prihvati vaš unos za blinkanje?

Ajde recimo iz glave cca 400 mS. No svakako moramo imati na umu da trebamo napraviti MACRO naredbu i datoteku config.h u kojoj ovo možemo promjeniti i naštimati "na ruku".

3. Kako će blinkati LED-ica kada je podesite na 5 puta u sekundi, ugasite i upalite blinkanje? Hoće li blinkati 5 puta ili će se resetirati na default?

Teško pitanje, pošto se program i tako u praksi ne može korisno iskoristiti. Barem meni ne pada na pamet nikakva korisna ideja. Čisto da zakompliciramo, idemo napraviti ovako: Kada se blinkanje isključi 1S pulsom, može se uključiti jedino 1S pulsom, i blinkati će starim stanjem koje je bilo podešeno prije isključivanja.

4. kada uključujete, isključujete blinkanje LED-a, ili mjenjate broj blinkova u sekundi, hoće li LED odmah početi blinkati novom frekvencijom, ili želite da završi zadnji period blinkanja starom frekvencijom?...

Kvragu, ružno je kad gasiš uređaj, a on baš krene paliti LED. To izgleda kao random blink koji je kraći od ostalih. Idemo radije malo zakomplicirati stvar i napraviti da zadnji blink bude izvršen jednakim periodom blinkanja.

[InTheStillOfTheNight]

4. kada uključujete, isključujete blinkanje LED-a, ili mjenjate broj blinkova u sekundi, hoće li LED odmah početi blinkati novom frekvencijom, ili želite da završi zadnji period blinkanja starom frekvencijom?...

Kvragu, ružno je kad gasiš uređaj, a on baš krene paliti LED. To izgleda kao random blink koji je kraći od ostalih. Idemo radije malo zakomplicirati stvar i napraviti da zadnji blink bude izvršen jednakim periodom blinkanja.

Pa nek admini ispravljaju zajebe:

4. kada uključujete, isključujete blinkanje LED-a, ili mjenjate broj blinkova u sekundi, hoće li LED odmah početi blinkati novom frekvencijom, ili želite da završi zadnji period blinkanja starom frekvencijom?...

Kvragu, ružno je kad gasiš uređaj, a on baš krene paliti LED. To izgleda kao random blink koji je kraći od ostalih. Idemo radije malo zakomplicirati stvar i napraviti da zadnji blink bude izvršen jednakim periodom blinkanja. U slučaju promjene brzine blinkanja stvar je identična. Nećemo odrezati zadnji period stare frekvencije, nego ga odraditi do gašenja LED-a i tek onda promijeniti frekvenciju blinkanja.

[InTheStillOfTheNight]

"U potrazi za tartufima AVR-a" - AVR Studio Sranje

Atmel svakih malo izbaci novu verziju AVR Studija, danas je to AVR Studio 6, no ja i dalje tipkam u AVR Studio 4. Nekoliko je razloga tome. Niti jedan software koji se čudom pojavi kao najveći, najbolji i najnoviji ne valja. Uzmite recimo Windows Vista kao promjena nakon XP-a. Nije prošlo niti godinu dana kako su izbacili WIN 7. Vista je kaos, prototip na tržištu software-a. Sa atmelom je slična stvar. Nakon AVR studio 4 izašao je AVR Studio 5 koji je bio na njihovim stranicama oko pola godine, i čudom nestao. I danas možete pronaći njihov AVR Studio 6.

Ovo pišem jer imam sve verzije AVR Studia sa svim Service Packovima koji su izašli u prošlih 7 godina. Nešto se drastično promjenilo. Evo sve verzije koje imam:
AVR Studio 4.13
AVR Studio 4.14
AVR Studio 4.15
AVR Studio 4.16
AVR Studio 4.17
AVR Studio 4.18
AVR Studio 4.19
AVR Studio 5.01
AVR Studio 6.0 Build 1843

U prvom postu prije nekoliko godina napisao sam da je potrebno instalirati AVR Studio i WINAVR, i to se danas promijenilo. Sve do verzije AVR Studio 4.18 treba WINAVR, a 4.19 je prva verzija AVR Studia u koju je ATMEL implementirao svoj compiler i biblioteke imena Toolchain.

Zadnja verzija AVR Studia 4.19 je kaos, totalni kolaps sa ne predviđenim sranjima. Izbacili su default postavke za compiler WINAVR i ubacili toolchain, no nije implementiran u instalaciji, tako da ne možete napraviti compile bez da ručno podesite datoteke za WINAVR.

Verzija 5 očito je bila tako loša, da su je sakrili nakon pola godine i izbacili AVR Studio 6.0 Build 1843
Danas još uvijek koristim verziju AVR Studio 4.18 čisto da se ne moram zajebavati sa podešavanjem WINAVR-a i Atmelovog Toolchain-a. Navodno, kako sam čitao na njihovim stranicama razlog implemetacije njihovog compilera je zbog LINUX-a, jer WINAVR ne radi na linuxu.

Ovo pišem samo da se ne zajebete i instalirate AVR Studio 4.19, taj je kaos sa prelazom na Toolchain i svaki puta potrebno je ručno podešavati make.exe i avr-gcc.exe WINAVR-a.
Kada govorimo o AVR Studio 4, obazevno dižite verziju 4.18 i WINAVR.

AVR Studio 5 je pao u vodu nakon pola godine, a AVR Studio 6 je izašao tek prije pola godine, dakle još se radi na AVR Studio 4 verzija 4.18 i WINAVR.

[InTheStillOfTheNight]

Prestao sam pisati tartufe jer većina čitatelja uopće ne želi saznati način pravog programiranja i danas sam ponovno popizdio... Čitam neki source code arduiono za ultrazvučne senzore HC-"Neki *urac" i čisto se divim ograničenosti programskih rješenja. Naposto ne mogu shvatiti zašto ljudi koče brzinu programa samo da bi brzo nešto napravili... Ne znam, možda bih trebao objaviti svoje biblioteke koje sam pisao za brdo stvari... Ali i da sve svoje projekte u zadnjih 10 godina dignem na net, opet nitko ne bi shvatio kako treba programirati, niti bi želio shvatiti. Možda tipovi osoba kao @buco, @kizo, @trax @pedja... jednostavno nemaju volje, kao više niti ja, da nekoga učim programirati... Na ovom forumu sam pisao besplatno, ne mogu reći da sam nešto puno napisao ili napravio, ali brate mili moja programerska satnica u fušu je 100 kn/h. Ispod toga ne želim gledati C kod. Ne mogu ja sebe uspoređivati sa forumašima kada 80% svoga budnog vremena provedem u programiranju i razvoju hardware-a. Pisao sam o AVR-u jer ga dobro poznajem i jer je jednostavan, ali većina mojih projekata koje danas radim je na ARM-u što je nauka za AVR. Stoga, ako imate problem, mislim na forumaše koji su tu već godinama, slobodno pošaljite PM i pomoći ću koliko mogu, ali ne vidim više smisao da pišem jer mi to oduzima previše vremena, a imam posla da mogu dan i noć programirati.

[zigzag9]

IMHO, šteta. I to što si prestao pisati, a i zbog toga jer nema zainteresiranih. Tartufi su svakako dobar temelj za shvaćanje nekakvih osnovnih principa i ukazuju na koji način treba razmišljati.

Vjerujem da Arduino platformi zamjeraš dosta stvari, i vjerojatno bi prešao preko svega, ali "delay" je neoprostiv, i apsolutno se slažem s tobom, no smatram da je Arduino izvrsna stvar za početnike, budući korisnika uz relativno mali trud dovodi do finalnog rezultata, pri čemu je fokus uglavnom na programiranju.
Količinu gotovih projekata i dostupnih libova neću uopće spominjati. Da ne zaboravim i shieldove spomenuti. No, o mnogo drugih stvari netreba razmišljati, što je možda i dobro u početku, kao recimo PWM tajming, UART postavke, broj ciklusa, itd.

Ipak, bez obzira na sve te prednosti, primjećujem da je generalni interes veoma malen čak i za Arduino, a kamoli za AVR, gdje trebaš paziti doslovno na sve sitnice. Nije problem u platformi već u ljudima, koji su očito prelijeni za upregnuti vlastite vijuge. A uostalom, tko je voljan učiti, ionako će veliku većinu stvari pronaći u Atmelovim application note-ima.

Također, vječito se povlači ona famozna tema "PIC vs AVR", što je bolje. Primjećujem da ljudi i dalje trče prije na PIC (iako ne smatram da je to inferiornija platforma u odnosu na AVR u bilo kojem pogledu), samo iz razloga jer se uglavnom programira u Basicu, jer je eto "lakše", a C je užasni veliki lav koji će te pojesti čim ga takneš.

I naravno, kad se počne pričati o novcu - PIC je jeftiniji. S čim se nebi složio. Za PIC treba kupiti prvo mikrokontroler, pa univerzalnu pločicu, pa kupiti nekakav programator, i to sve u finalu ispadne skuplje od Arduino Uno pločice koja košta 10$, zatakne se u USB port, dolazi sa već instaliranim bootloaderom, besplatnim IDE-om, gotovim sketchevima itd. I naravno, tko misli da je prerastao Arduino, može početi programirati u čistom C-u, i kompajlirati sa AVR-GCC - odmah bez ikakvih preinaka.

Znam da je post ispao malo kao reklama, ali samo sam htio skrenuti pažnju da nije problem u platformi, nego u lijenom stanju svijesti, posebno novijih "internet generacija", koje su navikle dobiti sve besplatno, jer sve što postoji, već bi trebalo postojati na Googleu, a ako ipak slučajno ne postoji, onda ćemo se regati na forum, jer na forumima žive mali nolajferi koji programiraju za vas besplatno, i prave vam maturalne, seminarske, diplomske. Jer su forumski nolajferi stvoreni za to.

Imaš moju potpunu podršku što nećeš pisati, iako bih volio čitati i sudjelovati u raspravama ovakve tematike.

[mbruck]

Imaš moju potpunu podršku što nećeš pisati,

Moju nemaš
Ja većinu softwera pišem u BascomAVR, a stalno se pokušavam natjerati da pređem na C. Ovdje je Arduino meni zakon, jer imam šanse da se preobratim.
Po meni C nije nimalo težak jezik, čak je dosta stvari LAKŠE i brže uraditi. C kod se može pisati na način da jednako čitljiv i razumljiv kao Basic. Nažalast ili na sreću, ne ostanu svi na toj razini.
C++ možda nje izbor pravih embedded gurua, no mora se priznati da ko savlada c++, lako će se vratiti na čisti C. Iako je kad čitam neke Arduino biblioteke, skoro sve isto.
Tvoji tekstovi su drama dobri... Pisao dalje ne pisao, hvala za ovo do sada.
Živio ti nama drugar!

[InTheStillOfTheNight]

Čitava nauka oko programiranja mikrokontrolera se svodi samo da to da ne smijete napisati delay. E sad druga stvar je naučiti programerske metode kojima to možemo izbjeći. U protokolima komunikacije ponekad delay ne možemo izbjeći, ali smo svjesni koliko on traje i radi se samo o mikrosekundama.

Problem tartufa je taj jer sam pisao sve tekstove kao da ne postoji niti jedna gotova bibiloteka, a početnici često vole nešto uključiti, kliknuti na tri gumba i stvar radi. Arduino je za to najbolji početak jer ima gotove biblioteke. Možda sam trebao izabrati nekakav smisleni projekt koji bih programirao korak po korak, i tako bih opet moram koristiti sve pojmove koje sam pisao u tartufima.

U principu moja ideja je bila da čitatelji shvate stvarnu brzinu mikrokontrolera i nauče je koristiti. Većina programa koje čitam po forumima nema nikakvih dodirnih točaka sa načinom programiranja mikrokontrolera. Većinom programe tuku i ubijaju delay-om, čudo da su još živi.

Uglavnom, nedavno sam imao seansu sa pomenutim ultrazvučnim senzorima i triger signalom. Naime, triger kod tih senzora treba biti pulse trajanja 10 us, a nakon toga senzor generira echo signal proporcionalan udaljenosti senzora od prepreke. Ma vjerojatno bih se osjećao čitav dan loše da sam napisao _delay_us(10); Kvragu, nedam ni tih jebenih 10us u delay! I naravno, opet sam uzeo jednu od čarolija iz vreće cirkusa u mojoj glavi i napisao genijalan lib kakvog sigurno ne mogu naći na netu.

U toj svrsi sam slučaju pregledao rješenja za PIC, arduino i primjere koji već postoje na netu i nisam našao ništa dovoljno mudro da bi mi bilo od koristi. Daljna problematika mojih metoda je ta što oduzimaju brdo vremena da se shvate, brdo vremena da se pokrenu na drugom mikrokontroleru, na drugoj frekvenciji MCU-a. Puno je tu parametara i potrebno je jako puno teksta da se takvo nešto opiše.

Trebalo mi je pola godine tipkanja da objasnim način konfiguracije TIMER0 za generiranje ISR-a svakih 1ms, pa predpostavljam da bi vjerojatno ostario dok napišem sve što bih mislio napisati. Pogotovo ako sve pišem od nule. U takvom tekstu morao sam objašljavati kako se upravlja bitovima, registrima.... bla, bla bla, ali realno gledajući to su stvari koje su trivijalne i nema tu puno mudrosti.

Čak i da sam nastavio pisati i završio aplikativni program, on stvarno ne bi imao nikakvu smislenu svrhu. Bolje da sam onda odabrao nešto smisleno i napisao nekakav program od kojeg netko može imati koristi. Ali, ajde barem je korisno znati kako konfigurirati TIMER za realno vrijeme jer bez toga se gotovo ne može ništa kvalitetno isprogramirati...

No ako se dobro sjećam, pitao sam na forumu što da radimo??? Meni je i tada bilo svejedno što programirati i razvijati, ali nitko nije dao nikakvu ideju što napraviti...

[pedja089]

Mene bas zanima sta je taj procesor radio tih 10uS
Prekratno za spleep, i za bilo sta korisno odraditi...

[InTheStillOfTheNight]

Koristan posao u mainu @pedja...

[pedja089]

To sam i pretpostavljao, ali koliko ga je odradio?
Ne znam na kojoj brzini radi taj procesor, ali za 10ak obavljenih instrukcija meni se stvarno ne bi dao setovati tajmer i interapt... Na setovanje toga otice 6 instrukcija, tako da za 4 instrukcije mislim da nije problem napisati koci misko
Ove brojeve samo lupio iz glave...
Ono sto se meni pokazalo kao najbolja kombinacija, ono sto mora odma interapt na pinu, ono sto je dovoljno proveravati svakih xy ms, redovni ulazi, tastatura itd , podesi tajmer i odradjuj u interaptu, a svu ostalu sporu komunikaciju samo slazi kako pase, i ako treba nesto sacekati tu se bez problema gurne i pauza i sleep, i bilo sta trece... Pogotovo ako radim nesto sto ide na net, tu ping ide i po nekoliko desetina sekundi...

[InTheStillOfTheNight]

O da, problem je ako radiš dobar lib za aplikativni program. Prvenstveno trebalo je podržavati 8 ultrazvučnih senzora tako da zapravo imaš 8 triger-a po 10us. Daljni problem je taj jer ne možeš trigati svih 8 senzora i očekivati kako ćeš dobiti pravilan echo od svih 8 jer bi se očito svi posvađali oko očitane vrijednosti. Dakle potrebno je čitati jedan po jedan.... No aplikaticni program može tražiti stanje bilo kojeg senzora, a to mjerenje, u slučaju da je prepreka izvan dometa traje točno 200ms, a ako je unutar dometa traje i do 30 ms.

U tom slučaju aplikativni program bi morao čekati punih 30 ms da pročita vrijednost ultrazvučnog senzora, i zato sam morao sve napraviti state mašinom u ISR-u...

Evo za proučavanje datoteke pisane za ATMEGA1280 u kojima je implementirano uključivanje, isključivanje senzora, state mašina koja sve uključene čita u krug i vrijednost pohranjuje u RAM-u. Aplikativni program samo povuče iz RAM-a koji senzor hoće i nikada ništa ne mora čekati. ISR rutina traje najviše oko 10us i to u STATE-u kada for petljom traži sljedeći enable senzor za čitanje (eng.state == ENG_WAIT_ECHO_DELAY)

[pedja089]

To je onda ok... Cisto me malo zanimalo o cemu se radi...