LCD counter

[vojinilic]

Odavno nisam u PIC-vima. Ovo sto Miki kaze bi trebalo da moze, ali ne znam za PIC. Za XMega bih mogao detaljno da kazem.

[Želja]

Vojine, Gorane, Miki
Sada je mnogo jasnije !

Hvala drugari - Mnogo mi znači vaša pomoć.

[mp3police]

Stariji (a i novoji) PIC-ovi imaju 'prirodno' nešto za tu svrhu (pričam iz teorije, nisam probao), ali povezuje T0 i T1. Kad T0 dođe do overflow-a onda generiše impuls na ulaz T1 (ovaj valjda inckrementira). Brlja mi PDF i select, tako da mi teško ide selektovanje, pa nisam citirao.
Edit
U stvari mislim da grešim, to se odnosi na gate control, pa se stvari komplikuju.

[vojinilic]

Zeljo, nema na cemu, ili kako bi tri amigosa rekla:
Wherever there is injustice, you will find us. Wherever there is suffering, we'll be there. Wherever liberty is threatened, you will find...
THE THREE AMIGOS

[vojinilic]

Stariji (a i novoji) PIC-ovi imaju 'prirodno' nešto za tu svrhu (pričam iz teorije, nisam probao), ali povezuje T0 i T1. Kad T0 dođe do overflow-a onda generiše impuls na ulaz T1 (ovaj valjda inckrementira). Brlja mi PDF i select, tako da mi teško ide selektovanje, pa nisam citirao.

To je kaskadno vezivanje tajmera u brojackom modu. Kod AVR se to zovu event-i. To je skroz hardverska srtvar koja nema usporavanja u programu.

[Želja]

Zeljo, nema na cemu, ili kako bi tri amigosa rekla:
Wherever there is injustice, you will find us. Wherever there is suffering, we'll be there. Wherever liberty is threatened, you will find...
THE THREE AMIGOS

Ma nema vas nadalekooo ...

[Želja]

Gorane,

Još jedno pitanje :

Onaj gubitak prvog impulsa, da li se to dešavalo stalno ili povremeno ?
Jesi li našao uzrok, ili bar sumnjaš na nešto ?

Pozz

[mp3police]

Željo,
Kako misliš da zaustaviš brojanje?

[Želja]

Željo,
Kako misliš da zaustaviš brojanje?

Pa i ne zaustavljam brojanje u tom brojaču, već u spoljnom uredjaju sa koga ću brojati impulse.

[vojinilic]

Zeljo, ajde molim te definisi tacno ti treba. @mp3police je postavio pravo pitanje. Ako koristis TMR da rade u modu brojaca, moras da im postavis neku granicu kada da zaustave brojanje (generisu interapt). Bilo bi dobro da imas i jedan ulaz za zaustavljanje brojanja u slicaju nepredvidjenih situacija. Takodje, moras voditi racuna i o smetnjama. Sta ako ti smetnja napravi par nepredvidjenih impulsa. Sta ti je davac? Ako je to neki mehanicki prekidac, onda ce biti velike frke. Znam da sve ovo vec znas, ali ajde cisto da te podsetim, ako si mozda prevideo.

[gorankg]

Ne moraš da znaš kada prestaje brojanje. U glavnoj petlji samo periodično očitavaš TMRH:TMRL i osvežavaš LCD. Tajmer se stavi da radi kao counter. Ako odaberš da se je ulaz nesinhronizovan sa glavnim klokom onda će takav counter da broji čak i signale koji su brži od master kloka. Jednostavno radi kao bilo koji drugi brojački registar! Jedino na šta treba da obratiš pažnju je trenutak kada pređe sa vrednosti 65536 na 0. Ali tada se događa prekid i to  je znak da je nastupio overflow i da na novo očitanu vrednost treba da dodaš 65536. Tajmeri se kod ovih PIC-eva za koje ja znam ne mogu nastavljati kako bi se formirao 32 bitni brojač. 
Ne znam zašto se dešava da broji za jedan manje. Ja sam to simulirao u Proteusu, možda je to i problem do njega. Ako neko želi da proba mogu ovde postaviti sourc, hex i proteus fajl.

[Želja]

Nisam onda dobro razumeo mp3police

****

Tačan opis zadatka koji mi treba je sledeći :

Imam generator impulsa (poseban uredjaj sa mikrokontrolerom) koji šalje POZNAT broj impulsa
recimo 50.000 na frekvenciji od naprimer 100KHz, impulsi su širine oko 5uS.

Impulsi se vode kroz širmovan kabl od nekih 10 metara i na drugom kraju okidaju
optokapler 6N137. Na ulazu optokaplera postoji RC filter koji seče sve što je kraće
od nekih 2uS - upravo zbog pojave mogućih smetnji kroz dovodni kabl.

Cilj je probrojati koliko je zaista nastalo impulsa na izlazu 6N137
(naravno sada invertovanih)

***

Mislio sam da ne pravim ništa, - ali izgleda da ću morati ..
Goran je već dao jedan primer u C.

Godinama koristim samo PBP kompajler i unjemu se dosta dobro snalazim.
(pisao sam slične softvere, obrtometri, brojači itd .. sa asemblerskim blokovima kroz interapte unutar PBP)

C kompajler ne poznajem ! - i samo zato ću raditi u PBP
Onaj dsPIC što sam spominjao, - našao sam neki primer (tu su se koristili capture interaptii - već smo pričali o tome ...)

U principu, sve mi je jasno ( dobrodošla mi je i vaša pomoć )
Ako negde zapne - tražiću pomoć

Pozz

[gorankg]

ZA 50000 impulsa radiće ti i ovo moje. Sad ću da ti sredim fajlove.
Evo Proteus simulacije:

[Gosha]

Koliko sam ja shvatio Zelja hoce da izbroji neku povorku impulsa, npr 1000 impulsa cija je frekvencija max 150 KHz.
Mi ne znamo kad ce ta povorka da se zavrsi, zato bi trebalo brojati impuls po impuls i prikazivati na displeju.
Detektujemo prednju ili zadnju ivicu impilsa, inkrementiramo neki registar i odmah povecamo sadrzaj displeja za jedan, zatim cekamo sledecu ivicu impulsa.
Imamo 6.66 us vremena da obradimo rezultat, ako nam je klok 20Mhz, vreme masinskog ciklusa je 200ns znaci imamo na raspolaganju oko 33 masinska ciklusa. Maksimalni broj instrukcija je manji jer se neke izvrsavaju u dva ciklusa. Sad sta moze da se uradi sa tim, treba probati.
Zeljo, ako ogranicis max frekvenciju impulsa na 100KHz imaces na raspolaganju 50 ciklusa sto mislim da je vec dovoljno.
Pricam o seriji 16F i o asembleru, naravno.
Drugi nacin je, sto rece Vojin, da predvidis jedan ulaz koji ce da da primi informaciju o kraju povorke. To je sigurno bolje resenje ali ti treba jos jedna fizicka veza sa objektom brojanja.

[Želja]

Odlično Gorane,

Kolika je frekvencija impulsa ?
Gubi li i dalje prvi impuls (što si ranije spominjao ?)

Ništa me ne sprečava da iskoristim taj brojač Hex je Hex

[Želja]

Tako je Gošo,

Samo što prikaz ne moramo raditi impuls po impuls već recimo kada se generiše TMR interapt.
Svejedno su impulsi toliko brzi da jedino što možem stvarno videti je konačna zadnja cifra - što je i potrebno !

[Gosha]

Ne moraš da znaš kada prestaje brojanje. U glavnoj petlji samo periodično očitavaš TMRH:TMRL i osvežavaš LCD. Tajmer se stavi da radi kao counter. Ako odaberš da se je ulaz nesinhronizovan sa glavnim klokom onda će takav counter da broji čak i signale koji su brži od master kloka. Jednostavno radi kao bilo koji drugi brojački registar! Jedino na šta treba da obratiš pažnju je trenutak kada pređe sa vrednosti 65536 na 0. Ali tada se događa prekid i to  je znak da je nastupio overflow i da na novo očitanu vrednost treba da dodaš 65536. Tajmeri se kod ovih PIC-eva za koje ja znam ne mogu nastavljati kako bi se formirao 32 bitni brojač. 
Ne znam zašto se dešava da broji za jedan manje. Ja sam to simulirao u Proteusu, možda je to i problem do njega. Ako neko želi da proba mogu ovde postaviti sourc, hex i proteus fajl.

Zelja je rekao da mu tebaju 6 cifara i max frekvencija 150KHz. Da bi se napunio brojac sa 6 cifara ovom frekvencijom treba da prodje 6.6666 s.
Kad da ocitavamo stanje tajmera ili registara? A sta ako je frekvencija jos manja, povecava se vreme puinjenja brojaca.
Ipak mislim da treba brojati impuls po impuls.

[Gosha]

Odlično Gorane,

Kolika je frekvencija impulsa ?
Gubi li i dalje prvi impuls (što si ranije spominjao ?)

Ništa me ne sprečava da iskoristim taj brojač Hex je Hex

Pa postoje gotove rutine za Hex----BCD konverciju.
Imam negde u asembleru naravno, ne govorim druge jezike.

[Gosha]

Tako je Gošo,

Samo što prikaz ne moramo raditi impuls po impuls već recimo kada se generiše TMR interapt.
Svejedno su impulsi toliko brzi da jedino što možem stvarno videti je konačna zadnja cifra - što je i potrebno !

A kad ce da se generise TMR interupt? A sta ako se TIMER nije napunio, recimo treba da izbrojis povorku od samo 10 impilsa.

[Želja]

Ne moraš da znaš kada prestaje brojanje. U glavnoj petlji samo periodično očitavaš TMRH:TMRL i osvežavaš LCD. Tajmer se stavi da radi kao counter. Ako odaberš da se je ulaz nesinhronizovan sa glavnim klokom onda će takav counter da broji čak i signale koji su brži od master kloka. Jednostavno radi kao bilo koji drugi brojački registar! Jedino na šta treba da obratiš pažnju je trenutak kada pređe sa vrednosti 65536 na 0. Ali tada se događa prekid i to  je znak da je nastupio overflow i da na novo očitanu vrednost treba da dodaš 65536. Tajmeri se kod ovih PIC-eva za koje ja znam ne mogu nastavljati kako bi se formirao 32 bitni brojač. 
Ne znam zašto se dešava da broji za jedan manje. Ja sam to simulirao u Proteusu, možda je to i problem do njega. Ako neko želi da proba mogu ovde postaviti sourc, hex i proteus fajl.

Potpuno se slažem, promakao mi je ovaj post.