A hexa értékek nullával kezdődnek és H-val végződnek, vagy 0x-el kezdődnek szerintem...
Fordító függő.
Az ANDLW -t nem hinném hogy módosítanod kéne, rossz helyre fog ugrani...

Úgy add meg a hexadecimális számokat, hogy 0xEE stb.
Valószínűleg a fordító, mivel betű van elöl, meghatározásnak veszi.

DT után 0x.. formátum kell. ANDLW után irandót pedig a "Disassembly Listing" segítségével tudod meghatározni.
(Most látom,hogy megelőztek a kollégák...)

Igen, ez a megoldás! Ha 0xEE formában írom, akkor hibátlanul fordítja. Mindenkinek köszönöm a segítséget! Tesztelni még nem tudom, előbb be kell fejezni az új hardvert.

#nemgyuri Azt nem tudom, hogyan határozhatom meg az ANDLW értékét a "Disassembly Listing" segítségével. Azért gondoltam, hogy a 0x7F helyett 0xFE-t kell írni, mert a régi program a 7. bitet nem használta, tehát 01111111 volt, ami megfelel 0x7F-nek. Most viszont 11111110 ez az érték.

Biztos nem fe, akkor ugye minden második bájt lenne csak érvényes ahova ugrani tud...

Ezt nem értem! Előzőleg is azt írtad, hogy "rossz helyre fog ugrani". Szerintem az ANDLW azért kell, hogy a nem használt bitet nullázzuk. De ebben nem vagyok biztos, lehet, hogy tévedek.

A PIC16F ugyan 14 bites utasításokkal működik, de az utasítás címzése egyesével történik.
Az alábbi programrész működése a következő:

A rutin hívása után a belső programszámláló az andlw utasításra mutat, a végrehajtása közben a következő címre lép. Az ADDLW PCL,F végrehajtása közben is lép előre és még a W regiszter tartalmát is a PCL regiszterhez adja, ami a belső programszámláló alsó byte-ja.
A DT direktíva azt írja elő a fordítóprogramnak, hogy a megadott értékekkel retlw utasításokat helyezzen el a programban.
Ha W értéke 0 volt az ADDWF PCL,F utasítás végrehajtásakor, a DT sor első elemének megfelelő retwl 0x7D utasítás végrehajtásával visszatér a program ebből a szubrutinból. Amennyiben a W érté 0 és 9 közé esik a megfelelő retlw utasítással tér vissza a program ebből a szubrutinból.
Probléma két helyen léphet fel:
- A W értéke nagyobb, mint 9.
Ekkor a DT sor utáni valamelyik utasításra kerül a vezérlés.
- A táblázat laphatárra kerül:
Egy lap 256 utasítást tartalmazó program memóriua részlet, ami olyan címen kezdődik, aminek az alsó byte-ja 0. Pl: 0x000 - 0x0FF címek közötti terület.
Mivel ez a programrészlet a PCL regiszterhez való hozzáadásnál nem kezeli a keletkező átvitelt, a vezérlés a addlw PCL,F utasítást tartalmazó lap elején levő utasításokra kerül.
Érdemes a táblázat elejére és a végére egy-egy címkét tenni és megvizsgálni, hogy az értékük felső byte -jaik nem térnek el. Eltérés esetén fordítási hibát generálni.

Köszönöm szépen kimerítő válaszodat! Számomra szó szerint kimerítő volt, mert már legalább 10 éve nem foglalkoztam PIC-programozással, így azt a keveset is elfelejtettem, amit akkor tudtam.

Viszont az eredeti programrészlet, melyet Te is idéztél, már 12 éve hibátlanul fut egy 4 digites Numitron órában, 16F887-es processzoron. Dehogy egy! Kb. 15-20 óra működik ezzel szerte az országban rokonoknál, barátoknál. Egyikre sem volt eddig panasz.

Ha jól értem soraidat, akkor az ANDLW utasításnál maradnia kell a 0x7F értéknek. Időközben befejeztem a hardvert, tehát már tudom tesztelni a programot. Nekiállok is átrágom magam az eredeti forráson, hogy megfejtsem, mit miért írtam akkor.

Jól működő program készítésénél két dolgot kell szem előtt tartani:
1 - csak jó adatot állítunk elő a rutinoknak,
2 - a rutinok tesztelik az adatokat és csak a jó adattal működnek.
Ebben az esetben a második a lényeges, hiszen, ha a W tartalma nem 0 és 9 közé esik (a határokat is beleértve), a program kiszámíthatatlanul fog működni.
A mostani andlw 0x7F -et alkalmazva 128 féle adattal működhetne a rutin. Elég lenne az andlw 0x0F is, ami csak 16 féle bemeneti adatot eredményez. A tisztességes kivitel az lenne, ha a 10 .. 16 tételeket is tartalmazná a táblázat. Ebben az esetben nincs program eltérülés.

A szükség nagy úr... Ez 6 felesleges utasítás, ami vagy belefér vagy nem.
Ha teljesen biztosak vagyunk abban, hogy csak 0..9 lehet a bemenő adat, az andlw el is maradhat...

Igazad van: ha tucatnyi helyen működik hibátlanul egy program, ez még nem jelenti azt, hogy korrekt megoldásokat is tartalmaz. Elnézést, ha félreérthetően fogalmaztam!

Jelenleg egyáltalán semmi sem látható a kijelzőn. Próbáltam az eredeti programmal is, úgy néz ki, azzal működik, de természetesen össze-vissza villognak a szegmensek. Holnap elölről kezdem az eredeti program átalakítását az általad megadott szempontok alapján.

Köszönöm fáradozásodat!

Sziasztok!
Évek óta nem foglalkoztam PIC-ekkel és úgy érzem kicsit berozsdásodtam, de most van egy megoldandó feladat.
Adott egy átfolyásmérő ami 1-120 l/min tartományban mér. Sima 40-60% kitöltésű négyszög jelet ad, az adatlap szerint 450 jel/l. Nekem az átfolyás sebességét kellene tudnom mérni vele. Úgy matekoztam, hogy ha az átfolyás pontosan 1 l/min akkor 450 jel/60 sec = 7,5jel/sec vagyis 7500ms/jel.
Arra gondoltam, hogy beállítok egy timert mondjuk 1ms (vagy több) megszakításra, ezzel léptetek egy számlálót. Az átfolyás mérőről érkező jelre mentem a számláló értékét és elosztom 7500-zal, az így kapott érték adja az áfolyás sebességét l/min-ben.
A kérdésem az lenne, hogy jól matekoztam, ha igen a megvalósítás is járható vagy tévúton járok?

Félrecsúszott a matek Jelenként 0,13333333333 másodperc telik el akkor, ha percenként 450 jelet kapsz. 120l esetén ezt még oszd el 120-al. Viszont ez a négyszög jel egy analóg feszültségnek is megfelelhet, ha ADC lábra kötöd és úgy mérsz, lehet egyszerűbb, mint számolgatni.

Igazad van, tényleg elrontottam. Tehát kb 133 ms/jel, a matek logikai része ugyanaz lenne, a számláló értékét osztanám 133-cal.
Ami az ADC-t illeti egyrészt kalibrálni kellene valahogy ami nem egyszerű, másrészt az ADC értéket is át kell számolni valahogy, hogy kijöjjön az eredmény, az sem biztos, hogy egyszerűbb.

Szerintem kár ennyire "sűrűn" olvasni az értéket a kijelzőt úgyis max másodpercenként érdemes frissíteni mert különben olvashatatlanul villogni fog, ha 6 másodpercig számolod a bejövő jeleket akkor is korrekt értéket tudsz a kijelzőre írni ...(45 imp/l) és nagyon leegyszerűsödik a számítás ..A 45. impulzussal léptetsz egy változót és 6 másodpercenként kiolvasod az értéket kiteszed a kijelzőre majd nullázod .

Az újabb PIC-ekben van Signal Measurement Timer (SMT, 24 bites számláló), azzal egyszerűbben megoldható, már ha jól értem a feladatot. Mellékletben a sok üzemmód közül az egyik. Egy trükk van a dologban, kezelni kell azt, ha folyamatosan H vagy L szintű a bemenet (elzárják a csapot), üzemmódtól függően nem mindegyikre ad megszakítást. Ehhez kell még egy időzítő, ami az időtúllépést tudja jelezni. Így több idő marad mást csinálni a programban (pl. átlagolni), már ha érdekes.

De ahogy egy problémára több megoldás létezik, úgy itt is. Kapuzható Timer 1, Capture modul stb. Kinek mi a szimpatikus.

Azon is múlik, hogy mit akarsz kezdeni a mért értékkel. Ha teljes átfolyást kell mérned, akkor az összes ticket kell megmérni, és utána szorozni egy előre kiszámolt arányszámmal. Csak azért mondom, hogy ha esetleg sebességet mérnél, majd idő szerint integrálnád...

Köszönöm, ez jó ötlet csak nem 45 hanem 450 impulzus van 1 lierre

Milyen PIC? Lehet nekem tűnik a feladat túl triviálisnak, és félreértek valamit, de...
Az egész megoldható HW-ből. Van sok PIC-ekben CAPTURE/COMPARE/PWM modul.
Ebből használnám a COMPARE módot valamelyik külső bemenettel rendekező TMR számlálóval.
A TMR számláló bemenetére bekötném az átfolyásmérő impulzusokat és ez a TMR számolná ezt.
A COMPARE modul CCPR regiszterbe beállítanék pl. 45-öt és ezt hasonlítaná össze a beállított TMR számláló által számolt impulzusokkal. Ha a kettő megegyezik, akkor jön egy megszakítás.
A megszakításban egy sw számlálót kell növelni és a TMR számlálót törölni, hogy újrainduljon a TMR impulzus számolás. Meghatározott időnként (mérés periódus ideje, pl. percenként) nullázni kell a sw számlálót. A nullázás előtt a sw számláló meg megmondja 0.1L-es pontossággal, hogy mennyi folyadék folyt át az adott intervallumban.
Ha a CCPR regiszterekbe pl. 450-et állítasz be, akkor pedig 1L-es pontossággal mutatja meg a számláló az átfolyt folyadék mennyiségét az adott intervallumban.
Nem kell osztani, semmit számolni, stb., csak kiírni a számláló értékét.
És csak megfelelően fel kell konfigurálni 2 TMR-t, meg egy COMPARE modult.

Majdnem jó csak nem az átfolyt mennyiség a lényeg, hanem az átfolyás sebessége vagy intenzitása ha úgy tetszik, tehát nekem liter/perc érték kell. Persze ezt lehet úgy is, hogy a te módszereddel percenként olvasom és törlöm az sw regisztert, de ez így túl pontatlan lenne.

Úgy látszik tényleg nem megy a számolás ...... 6 másodperc az éppen a tizede az 1 percnek akkor az impulzusok száma hogyan változik ?

Előző hozzászólásomban ott a kép, az SMT modullal könnyen mérhető két impulzus közötti idő. A modul kimondottan ilyen feladatokra lett tervezve.

Szia!
Ha jól értelmezem, neked csupán a percenkénti átfolyás megjelenítése a célod.
Ha tényleg csak ennyi kell, tudom ajánlani a mellékelt kapcsolást.
Ez a TM1637-M4 kijelzőhöz készült. A tüskesort ki kell a kijelzőben cserélni egyenesre és lefelé nézzen. Így akár csatlakozóval, akár direktben ráforrasztható a mellékelt apró panel. Az egész cucc a Hestoreból nincs 2000Ft.
Mivel ez eredetileg egy fordulatszám mérő, így az eredeti programjába csupán annyi módosítás kell, hogy át kell számolni néhány értéket. Így 0,1 litertől a jeladó teljes kapacitásáig tud mérni 1dl felbontással.
Ha ez megfelel neked, írj rám.
Ha magad szeretnél megküzdeni a szoftverrel, minden segítséget megadok, de ha akarod átírom neked.

Az ilyen problémáknál az segít, ha minden lépést és mértékegység átalakítást leírsz, ahogy fizika órán szokás. Nem szabad összevonni két lépést sem sosem. Ha nincsenek összevonva lépések, akkor ellnőrzésként könnyen végig lehet szaladni, hogy minden lépés jó volt-e. És mindent képlet amit leírsz, azt mértékegységgel együtt legyen! A képletekben a mértékegységekkel számolva ellenőrizni lehet, hogy jó-e, nem került-e valami a nevezőből a számlálóba véletlenül. Leírtam egy példát erre az esetre, hogy hogy lehet úgy megtervezni a programot, hogy biztosan helyes legyen. Amit tudunk:



Látható, hogy az idővel osztani kell, tehát ha az idő nem fix értékű, akkor mindenképpen kell osztani a programban. Ha az idő fix értékű, azaz mindig ugyanannyi ideig számolod, hogy hány jel jött, akkor az osztást előre le lehet tudni, a programnak már nem kell osztania. Ezt javasolták fentebb többen is.
Ha az idő fix, és a jeleket számolod, akkor lesz egy szisztematikus leolvasási hibád, mivel nem egész tick esik az időintervallumra. Ez beleférhet, de engem minden kiküszöbölhető hiba zavar, úgyhogy én időt mérnék, ahogy te is írtad: valahány darab tick idejét mérném, és ebből számolnék a képlet szerint. Az osztásra lehet vadászni ASM-es osztó rutint a PIC-re amit használni akarsz. (Amennyiben valóban ASM-ben akarod megírni a programot, én C-ben írnám inkább.)
A matekolást én úgy szoktam csinálni, hogy a képletet átírom olyan mértékegységekre, amiket valóban használni fogunk. Először is meg kell határozni az időmérés tartományát, hogy min belül lesznek a mért értékek:



Látható, hogy 1 milliszekundumtól 134 milliszekundumig fog terjedni a mért idő a műszer tartományában. Úgy kell megvalósítani az időmérést, hogy ezt a tartományt lefedje és lehetőleg pontos is legyen. 8 biten is meg lehet valósítani némi pontosság árán, de én inkább 16 bites számlálót használnék, ha van és úgy állítanám be az osztó értékét, hogy ennyi idő alatt ne forduljon át, de azon belül jó pontosságot adjon. Például ha 4MHz az órajel, és 64-es osztót állítunk be, akkor 62500Hz-es lesz a számlálónk, ami jó érték, mert a milliszekundumnál sokkal pontosabban tudunk mérni vele, viszont egy teljes másodpercet is átfog 16 biten. Nem tudom milyen lesz az MCU órajeled és milyen számlálók és milyen osztók állnak rendelkezésre, ez csak egy példa. Nem feltétlenül kell a hardveres számlálót használni az osztásra, az átfordulások számlálása is tökéletes, veheted úgy, hogy azzal is egy osztót valósítasz meg.

Megvan tehát, hogy az időegységünk 1/62500 s lesz, ezt kell beleírni a képletbe és az idő mértékét át kell váltani percről a választott időegységünkre. Tehát az a trükk, hogy úgy csinálunk, mintha az 1/62500s egy mértékegység lenne.
Plusz ha a kijelzés pontosságára 0.1l/min-t választunk, akkor már azt is beleírhatjuk a képletbe, hogy ebben a mértékegységben fogjuk kérni a végeredményt - mivel egész aritmetikával tervezünk -, azaz 10-zel szorozni kell mindent:



Az van még hátra, hogy úgy kell megtervezi a számítást, hogy ne csorduljon se túl se alul és kellő pontosságú legyen a végeredmény egészekkel számolva is! A 83333 már nem ábrázolható 16 biten. C-ben programozva ilyenkor 32 bites integeren szoktam elvégezni az osztást, vagy akár floatot használva. Legtöbbször bőven belefér a processzor lehetőségeibe. Ha 16 biten kell megoldani az egyszerűség kedvéért, akkor felezném mindkét oldalt. A mért idő felezése shiftelés művelettel egyszerű. Így a matek a következőképpen alakul:



Így tized l/perc egységben kapjuk meg az átfolyás sebességét helyesen kerekítve, amit közvetlenül meg lehet jeleníteni egy kijelzőn.

Ne haragudj, de ezt kissé túlgondoltad.
Egy kis előszámolással egy műveletre rövidíthető az egész. Legfeljebb kettőre, ha többszörözzük a mintavételt.
Azon kívűl szerintem nem vetted figyelembe, hog Pali79 átfolyásmérője 250L/P-ig mér.
Márpedig ezen a szinten az általad ajánlott frekvenvia és előosztás mindössze 8 jelet ad két impulzus között.
Ezzel nemhogy tized liter, de 10 liter pontosság sem érhető el 200L/P-e tartományban.
Nézzük az én matekomat.
Az egyszerűbb számítás kedvéért 60L/P megjelenítésére számolom ki.
Így ugye másodpercenként van 450 impulzusunk.
1/450=0,002222 usec.
Szeretem, ha a PIC gyorsan számol, ezért 16MHz-re állítom az oszcillátort.
Timer0-át használom 2-es előosztással.
Timer0 minden túlcsordulása megszakítást vált ki, ahol 1-el növelem a segédszámlálót. (timer0h és timer0u)
Tehát nézzük meg, 60 liternél hány jelünk lesz.
0,002222/0,0000005=4444
Ha tizedliteres kijelzést szeretnénk, akkor ezt az értéket 600-al kell szorozni.
4444*600=2666400
Tehát ha minden mérés után megjelenítjük az eredményt, ezt az értéket kell osztandóba írjuk, az osztóba a timer értékét, és kész. Persze 200L-nél már ez sem lesz pontos, de nagyságrendekkel pontosabb.
Ha többszörözzük a mintavételt, annyival fel kell szorozni osztandót is.

Abban teljesen igazad van, hogy ezt C-ben százszor könnyebb megírni. Rendelkezésedre áll az előre megírt osztó rutin, kijelzőkezelő, stb.
Az már csak az én fejlövésem, hogy nem vagyok hajlandó a szükségesnél nagyobb hardverrel dolgozni.
A kapcsolásban, amit itt feltöltöttem, egy PIC10F322-es van.
A jelenleg tárgyalt szoftver asm.-ben írva a programmemória 92%-át lefoglalja. C-ben írva nem férne rá.

Miért lenne pontatlan? Amit leírtam, az 0.1L pontossággal mér, de ezt még lehet javítani kisebb időközök hazsnálatával.
Amúgy nem írtad, hogy milyen pontossággal akarsz mérni?
Szerintem két impulzus közötti idő mérés sokkal pontatlanabb lesz, mert ahhoz nagyon pontos időzítések és időalapok szükségesek.
Jobban jársz, ha adott impulzust számolsz és ennek méred meg az idejét.

Az átfolyásmérő 1-120 l/min tartományban mér.
450 jel/l, azaz percenként 450 ... 54000 impulzus felel meg az 1 ... 120 liter/perc tartománynak.
másodpercenként 7.5 ... 900 impulzus
1,333 másodpercenként pedig 10 ... 1200 impulzus

Azaz megszámolnám hány impulzus érkezik 1,333 másodperc alatt, és direktben 1 tizedesjegy beiktatásával kiírnám a kijelzőre -> 1.0 ... 120.0 l/perc.

Semmi osztás, szorzás.

Az impulzusok számolásából eredően persze 0,1 liter tévedhet a nem egész impulzusok miatt mindig lefele, azaz 0,9 ... 0,99 liter az 0,9 liter a kiirásban. Ez kiküszöbölhető úgy, hogy kétszer annyi ideig számolom az impuluzokat, vagy fel-és lefutó éleket számolok, és nem 0-ról, hanem 1-ről indulok, majd a végén shifteléssel osztom kettővel az eredményt és azt irom ki. Ezzel már jól fog kerekíteni is.

Ott a pont.
Én a fordulatszám mérőből indultam ki.
De ha elég, (és miért ne lenne elég) az 1,333 másodpercenkénti frissítés, a te megoldásod messze a legegyszerűbb.

Igazad van, a gyors átfolyásoknál nagy lesz a hibája. (Az eredeti poszt 120l/mint írt, azzal számoltam 250l/min-nel nem.) Azt néztem, hogy az osztásunkkal beleférjünk a 16 bitbe, azt vettem alapul, hogy 16 bites osztást használunk. Így a nagy sebességeknél 10% körüli lesz a hiba. A hiba abból adódik, hogy 1ms körüli értéket mérünk 31kHz-es órával, tehát a lépésköz a mért érték 3%-a körüli lesz. Kis átfolyásnál nagyobb időket mérünk, ott a leolvasási pontosság sokkal jobb lesz.
A hiba abból adódik egyébként, hogy mindenképpen 16 biten belül akartam megoldani az osztást, és azt akartam, hogy az eredmény deciliterben legyen. Az eredmény 1200 kell hogy legyen, az osztandó pedig maximum 65535 lehet, a mért idő tehát maximum 54 lehet. Ezért választottam úgy az osztót, hogy kijöjjön a példa. Ha megvalósítjuk a 32 bites osztást, és a számláló túlcsordulásának mérését is, akkor az időt mérő számlálót nem kell osztani, és a leolvasási pontosságig növelhetjük a matek pontosságát is.
Azért írtam végig a számolást, hogy olyan példát mutassak, aminek minden lépése visszaellenőrizhető, hogy nem számoltuk-e el valahol. A szisztematikus hiba számolását lehagytam, mert akkor még hosszabb lett volna

Látszik, hogy a maximális frekvencia 1kHz alatti. Ilyen alacsony frekvenciát pontosabb periódusidőből számolni. Simán capture mód, a csúnya számításokat lehet egyszerűsíteni az előosztóval, vagy a mintavételek számával.