Simpi: hehe, észre se vettem.

Meg elég marhaság ide az opto is. Akkor lenne értelme, ha teljesen le lenne választva a relé áramköre, de itt a földjük közös. Sima tranyó is meghajthaná azt a relét, vagy akár maga a pic, ha pici a relé.

Két impulzus közti időt (periódusidőt) szeretnék mérni PIC-kel. A méréshez a a PIC órajelével vezérelt TMR0-át használnám mert azt 256-al is le lehet osztani és erre szükségem lesz. Azt nem tudom hogy hogyan tudnám az első impulzusra indítani a számlálót, a másodikra pedig megállítani, kiolvasni az értékét, lenullázni és azonnal indítani hogy a következő mérés is megtörténhessen. Arra gondoltam hogy a mérendő jelet egy INT lábra is bevezetem és a megszakításban kimásolok, nullázok és újraindítok. De ezt nem lehetne valahogy hardveresen, automatikusan megoldani?

Hi !

Olyan picet válassz, amiben a timer1 gate vezérelhető külső lábról, és van benne beépített gate flipflop (Gate Toggle Mode). Azaz 1. jelre indul a timer1, a másodikra meg leáll. Jah, és ehhez kell még egy single pulse vezérlő is, de az is van Pl a 16F1936 -ban. Ezzel a kettő kombinációval hardveresen tudod mérni két impulzus közötti időt.


Persze lehet szenvedni tmr0 val is...

A Capture móddal többre mennél, TMR0 esetén interruptban babrálni a regisztereket nem szerencsés, mert mire érvényre jut a megszakítás arra már rég tovább számlál a hardver, ráadásul az azonos prioritásszintű IT-k nem szakíthatják meg egymást.

PIC18F25K80-at nézegetem, ez szerencsére tud ilyet a TMR1-en és TMR3-on is.

Nem vagyok benne biztos hogy nekem erre van szükségem. Elindul meg leáll az rendben. Leálláskor viszont megszakítást kell generálnia, de ez sem gond mert a kapuzójelet egy INT lábra is rákötöm. A megszakításban kiolvasom az értéket majd nullázom és újraindítom szoftverből a számlálót. Itt továbbra is a szoftveres lekezelés miatt lesz hiba, mert kis idő múlva fog csak újraindulni a számláló.

Az miért kell?

A capture módon is töröm a fejemet, de azzal is ugyan az a baj: az időmérést szoftverből kellene indítani és ennek ideje levonódik a mérésből, mérési hibát okozva. Bár a capture modulos megoldás annyiból jobb, hogy nem kellene plusz egy INT lábat felhasználni.

(Számolgatok, lehet hogy a szoftveres értékmentés, számláló-nullázás és újraindítás ideje nem is összemérhető az időmérés felbontásával. Ha tényleg így van akkor pedig sokkal szabadabbak a lehetőségek. Ki kellene számolgatnom... )

A single pulse épp ezt oldja meg. Hw-esen megméri a periodusidőt, nézd meg az idő diagramot a működéséről.

Aha... Erre gondolsz, ugye? Mondjuk ez a diagram pont a toggle módot mutatja, szóval azt továbbra sem értem miért kell single pulse mód is.
Így már értem, csak minden második periódust tud így megmérni. Ez zavart eddig engem hogy hogy a bánatba tud minden impulzus közti időt mérni... sehogy, mert csak minden másodikat méri. Ez annyira nem is baj végül is.

Ja nem, te erre gondoltál! Minden világos, pont ez kell nekem! Már csak annyit kell kiderítenem hogy a T1GGO/!T1DONE bit hardveres nullába állása tud-e megszakítást generálni nekem.

Az induló hozzászólásodban azt írtad periódusidőt kell mérned. Én azonban nem mondtam, hogy a capture esetén törölni kéne a TMR regisztert.
Tehát, valamely élet (konfigurációtól függ) elkapja a modul, ekkor latcheli a TMR értékét. Aztán a következő capturenél meg a második élet kapja el és latcheli. Kivonva egymásból a két latchelt értéket megkapjuk timer inkremensekben az eltelt időt. Nyilván figyelni kell a TMR túlcsordulásokat is és annak megfelelően kell számítani az eltelt időt. 3 eset lehetséges:
1.) A TMR nem csordult túl és beesett a két capture esemény. Ekkor kivonva egymásból a két latchelt értéket, megkapjuk az eltelt időt.
2.) A TMR egyszer túlcsordult a két capture esemény között. Ekkor az eltelt idő: 65536-(első capture érték) + (második capture érték).
3.) A TMR többször túlcsordult a két capture esemény között. Ekkor az eltelt idő: 65536-(első capture érték) + ((n-1)*65536) + (második capture érték), ahol n a beesett TMR interruptok száma.

Szerintem nem ez kell neked! Ez két bejövő impulzus között számlál. Te pedig csak akkor akarsz számlálni, amikor a bemenetet magas szinten van. ITT és ITT már javasoltunk megoldást, próbáld ki!

Az általad linkelt hozzászólások óta (ma délután) nagyon sokat olvastam a témáról és rájöttem hogy az a fajta megközelítés nem igazán jó. Mert tegnap még fix időnként (mondjuk 0,5 másodperc) szerettem volna kiolvasni az értékeket és ezekkel továbbszámolni. Viszont azóta rájöttem hogy ez kis sebesség esetén nem jó mert mérési hibát okoz. Például 1km/h sebességnél fél másodperc alatt egy darab impulzus nem érkezik. És ez csak egy példa, lenne pár hasonlóan szélsőséges eset is amikor hülyeséget mérne a műszer.

Ezért döntöttem úgy hogy inkább nem az X idő alatti impulzusokat számlálom hanem az impulzusok közti időt. Ennek egy hátránya hogy minél gyorsabban megy az autó, annál gyorsabban kapom a mérési eredményeket. De ez senkit sem zavar mert ami minta nem kell azt eldobom és csak fix időnként jelzek ki új mintát.

Elmondom röviden az egész történetet ahogy most elképzelem:
A sebesség-jeladónál (egyszerű reed) periódusidőt mérek TMR1-el, így megkapom a sebességet. Az injektornál pedig a tegnap tárgyalt módon X idő alatti nyitási időt mérek, tehát hogy megtudjam hogy mondjuk fél másodperc alatt mennyi ideig volt összesen kinyitva az injektor. Ebből megvan a liter/secundum. Közben a sebesség-jeladó mérésével teljesen azonos módon, csak a TMR3-al periódusidőt is mérek, így ha akarom akkor megvan a fordulatszám is (bár ez nem fontos annyira). Ezekből már bármit ki lehet számolni. (Főleg ha a benzintank állapotáról is lenne korrekt visszajelzés.)

Ez is nagyon jó ötlet! Nem is tudom melyik megoldást válasszam.

Ez jobb megoldás mint a kombinált "single pulse+toggle mode"-os számláló-kapuzás, mert így nem csak minden második, hanem mindegyik periódus ideje mérhető.

Meg kéne értsd a CCP modul Capture üzemmód működését, mert neked nem kell más, és miután nekem jó, gondolom neked is annak kell lennie! Bármilyen túlcsordulásos kérdést le lehet kezelni, nem okozhat gondot az sem, hogy túl sok két impulzus között az idő, legfeljebb kidobod az értéket. Egyébként meg hatalmas idők is mérhetők, ha megfelelő bitszélességű regiszterszámlálót választasz, csak minek. Egy működő motor esetén nem fordulnak elő olyan értékek, amik gondot okoznának. A sebesség jeladó esetén pedig ha 30sec alatt nem jön impulzus, akkor az autó áll! Ha beérkezik az impulzus, akkor a távolságot növeled és elkezdesz sebességet is kiértékelni. Ennyi...

Nem véletlenül javasoltam ezt a megoldást!

Szép napot!
Valahogyan el kellene érnem azt, hogy egy viszonylag stabil a/d ref fesz mellet mégis picit változó kijelzés, teljesen elfogadhatóan ne táncolhasson a határon, de a sebessége ne nagyon romoljon az aktuális érték kijelzésének.

A sebesség még ennél is lehet jóval kisebb, mármint ami a kijelzést illeti. De ha átlagolom az utolsóbit változása miatt nem marad változatlan a végeredmény?

Köszi. Kipróbálom. Van egy rajzom, ahol a tl 072 erősítő egy jbc- pákahegy termoelektromos feszültségét erősíti, amit a pic dolgozna fel. A szimmetriája az egy fezsültségosztó így elvben jó is lehetne ha a nullpontja lehetne a pic negatív referenciája??

Törtem a fejem. Matematikailag egyszerű, csak mondjuk hogyan veszek le 10 mintát? 10 különböző regiszterbe? azaz 20? Mert a 10 bites a/d teteje 1024. Nem egyszerű elképzeléseim vannak mondjuk 10*1020/10 művelet végrehajtására

Ha assemblyben programozol célszerű 8 vagy 16 mintát venni. Igy elkerülheted az osztást helyette 3 ill. 4 bitléptetés művelettel megoldható. Persze 16bites számokkal

Elég két regiszter is.
Egy lehetséges megoldást mellékeltem.

Köszi!

Sziasztok!

Van valakinek ötlete hogyan kéne ezt c-ben lekódolni ?

azaz pontosabban engem csak az időzítés érdekel, hogy legyen egy pontos számlálóm.

előre is köszi!

Az időzítés a kristálytól függ, nincs mit rajta lekódolni, a többit a beépített modul megoldja.

Azt nem értem jelenleg hogy hogy fog az a kvarc ott berezegni...

valamit csak kell babrálni a beállításokkal nemde ?

A Timer1-et kell bekonfigurálni külső kvarcra, az kiolvasható az asm forrásból is, a C-ben ugyanazokat a regisztereket kell matatni. Az adatlapban is minden benne van ami kell.
Kezd el, és ha elakadsz, akkor tegyél fel konkrét kérdést, de ne olyat, hogy hogyan kell atomerőművet építeni!

Egy érdekes kísérletet végeztem el. A dolog oka az volt, hogy felmerült egy régebbi eszközben, hogy egy potmétert valahogy bele kellene illeszteni a rendszerbe. A szóban forgó vezérlő egy PIC16F628-as, aminek ugyan van analóg bemenete, de A/D átalakítója nincs. Az egyetlen lehetséges láb pedig az RB6-os, aminek az analóg jelekhez köze sincs. Az ötlet az volt, hogy az AN700-as ( delta-sigma a/d átalakítás ) mintájára dolgoztatom majd az RB6-os lábat, méghozzá úgy, hogy majd ő maga lesz a komparátor is egyben. Ehhez csak egy rövid pillanatra átváltom az amúgy kimenetnek használt lábat bemenetre, mintát veszek, és már megy is vissza kimenetnek. A mintavétel alatt ha a kb 0,7V-os küszöböt átlépte a jel, akkor azt magas bemenetnek olvasta a program, ha alatta volt, akkor meg alacsonynak. Úgy gondolom egy komparátor funkciónak ez meg is teszi ( bár erősen hőmérsékletfüggő ). Az érdekesség a kapcsolás és program tesztelése alatt jelentkezett, ugyanis alsó értékre 8 bites felbontásig figyelve a bemenetet 128-as érték jött ki, felsőnek meg 256. A kettő között egyébként a potméter állásának megfelelően arányosan alakultak a jelek. Csak hát így nem mondható a felbontás 8 bitesnek, hanem csak 7 bitesnek. Mivel a dolog nem a várt feltételezésem szerint működött, ezért kipróbáltam az AN700 szerinti kapcsolást is, ahol a PIC valódi komparátora dolgozik. Az eredmény az lett, amit az első megoldásomtól is vártam, tehát a pota alsó állásánál 0 ( majdnem nulla ) és a felső állásánál 255 ( ez 256 lett ).
Úgy gondolom, hogy a két módszer között (madjnem) csupán az a különbség, hogy a komparálási feszültség az egyik esetben 0,7V a másikban pedig 2,5V. Tehát csak annyi különbséget vártam az eredményben, hogy a 255-ös érték az előbbinél nem a pota véghelyzeténél, hanem a féltáv előtt már jelentkezik, de a legkisebb digitális érték nulla lesz. Ehelyett mást tapasztaltam és nem tudom, mi lehet az oka, hogy a legkisebb érték 128-ra adódott, azaz a bemenet 50%-ban váltogatott hol alacsony, hol pedig magas szintre. Valakinek van ötlete rá, hogy miért így alakul?

Sziasztok!
Lenne egy kis problémám A/D átalakitással. Be van állitva hogy ADRESH-ba rakja a mért érték 8 bitét. Ez eddig müködik is. Ilyenkor 255-ig jelez ki. De igy lemarad az alsó 2 bit. Gondoltam hogy akkor ADRESL-be rakja az alját és a felsö 2 pedig a ADRESH-ba kerüljön. Na itt jönnek a gondok. Ilyenkor bármit csináloki csak 1 és 3 közöt mutat. Olyan mindha nem irna ADRESL-be. Elvileg minden jól van beállitva. Tud valaki segiteni? Egyébként még kezdö vagyok. Köszönöm

Szia!

Az ADRESL és ADRESH nem azonos bank -ban van...