Tæller og Tachometer med PIC16F84

Hej Keld,

Kan du ikke bare bruge samme interrupthandler til begge dele ? (Hvad den så skal gøre ud af det, kan fx. afhænge af dit "mode selection" input).

Hvis du insisterer på at resette, kan du bruge samtidig bruge /MCLR, nappe strømmen til den et øjeblik eller lade interrupthandleren aflive watchdog'en, men det vil jeg nu mene er at overdrive :)

Er der en grund til ikke at lade den virke som både omdrejnings- og alm. tæller _samtidigt_ og så bare skifte mellem hvad der bliver udlæst ?

"Søren" skrev i en meddelelse news:Xns94D383A677877o8oLOOKatHOMEo8o@212.242.40.196...

.... mmhm det er der måske noget om, men ....

ved TÆLLING forestiller jeg mig at hver puls skal interrupte systemet - for at være sikker på at få dem alle med

ved OMDR/MIN forestillede jeg mig ......... ja, hvad forestillede jeg mig egentlig her ..... ?

jeg skal selvfølgelig stadig sikre, at alle pulser tælles med (så skal de hver for sig interrupte systemet - ikke ?), men der skal jo også være en tidskonstanst med her - hvor får jeg så den fra ? Kan man have flere interrupts konfigureret samtidigt - ét til at fange pulserne (for at tælle og huske omdrejningerne) og ét andet interrupt til f.eks. hvert sekund at vise 'optalte omdrejninger' og nulstille registret, hvorefter dette register igen tælles op af det første interrupt ? Kan dette lade sig gøre, skal omskifteren TÆLLER / OMDR pr. MIN som du siger blot bestemme, hvilket register, der skal vises i displayet.

Men er der ikke et problem med de pulser, der måtte komme IMENS visning/nulstilling af "OMDRprMIN"-registret foretages - hvordan sikrer jeg, at disse tælles med også ?

Mvh KS

Kan du bruge samme indgang til begge dele?

En timer i MPU'en.

Sagtens.

jeg,

Ved at disable interrupt mens du nulstiller (det behøver ikke at tage mere en nogle få usec at nulstille).

Hej Keld,

Det er vist her jeg bør spørge om max.frekvensen af tællesignalet - og max.RPM for den sags skyld. Hvad er det egentligt til ?

Beats me ;) Det er bedst at måle tiden mellem to pulser og så omregne det til RPM, evt. med løbende midling af de nn sidste pulser.

Jo.

Timeren.

Her er lidt du bør læse: "The interrupt control register (INTCON) records individual interrupt requests in flag bits." [...] When a valid edge appears on the RB0/INT pin, the INTF bit (INTCON) is set. [...] An overflow (FFh ® 00h) in TMR0 will set flag bit T0IF (INTCON). [...] An input change on PORTB sets flag bit RBIF (INTCON).

Selv med 1'000'000 RPM vil du have riiiigeligt tid (med mindre du singlestepper ;) Og jeg tror heller ikke din event-tæller klokker så højt at processoren får sved på panden (så havde du nok kaldt det en frekvenstæller :)

Det er nok en af de fælder de fleste falder i med begge ben, i starten af deres processoreksperimenter. Hvis du prøver at sammenholde frekvensen af dine ydre begivenheder med processorens instruktionstid får du nok en aha- oplevelse :)

"HKJ" skrev i en meddelelse news:4087b099$0$171$ snipped-for-privacy@dtext01.news.tele.dk...

Jamen sker så NETOP ikke det, at jeg mister de pulser, der kommer medens interruptet er disabled ?

Mvh KS

"Søren" skrev i en meddelelse news:Xns94D390E016BA3o8oLOOKatHOMEo8o@212.242.40.196...

En omdrejningstæller til en drejebænk - en induktiv føler i gearkassen aftaster et tandhjul med 80 tænder - så disse pulser skal danne grundlag for dels TÆLLING af omdrejninger og måling af hastighed ved Omdr/min.

Lige nogle stikord til hvordan jeg måler tiden mellem pulserne

Ja, jeg må til at nærlæse dette fra manualen

Ja, der er stor forskel på de frekvenser - men hvori består AHA-oplevelsen ?

Mvh KS

mere

Ikke så lang tid at interrupt er disabled mindre tid, end der er imellem interrupts. En MPU kan normalt huske et interrupt (fordi intr flaget bliver sat og først bliver slettet igen i intr rutinen).

"HKJ" skrev i en meddelelse news:c68mpv$1eoh$ snipped-for-privacy@news.cybercity.dk...

bliver

Selvfølgelig !

Der må så vel foretages en prioritering af interruptene

Mvh KS

Hej Keld,

Du regnede med at risikere at tabe pulser, men nu kan du vel se at du har utallige instruktioner at gøre godt med mellem hver puls ? Det vil jeg da kalde en aha-oplevelse (det var ikke ment som en fornærmelse på nogen måde :)

Det er vel overdrevent højt regnet med mwx. 10'000 RPM på en drejebænk ? Du har så 80 tænder pr. omgang ? max. 80'000 pulser pr. minut hvilket er mindst 750µs mellem hver puls. Med en instruktionstid på 1µs er du altså garanteret tid til min. ~750 instruktioner.

Da du måler begge dele på samme input, skal du blot lave begge beregninger løbende (jeg går ud fra du gerne vil kunne resette tallet, for det lyder som om du vil bruge den til spolevikling eller noget i den stil ?).

I pseudokode kan det fx. se sådan ud...

main: læs mode_ben ; det ben du vælger tæl/RPM på if mode_ben = 0 then call display(tæller) ; opdater med tælleværdien else call display(RPM) ; opdater med omdrejningstallet end if

læs tæller_resetben ; hvis du vil kunne resette if tæller_resetben = 0 then ; tællerværdien kan du tage tæller = 0 ; denne blok med. tæller_resetben = 1 ; set flaget igen via software, end if ; så virker det som var den ; kanttrigget. loop main

Int_handler: inc tæller ; (tæller++ i C) så er der talt op tid_ny = nuværende tidstagning ; gem timestamp interval = tid_ny - tid_gammel ; beregn intervallet mellem ; foregående puls og denne RPM = 3 / (4 * interval) ; beregn RPM ud fra fundne interval tid_gammel = tid_ny ; opdater tid_gammel til næste ; iteration Interrupt return

Så meget behøver der ikke ligge i int-rutinen, men hvis der ikke skal laves andet end at opdatere display og læses en tast ud over tælleriet kan det være hip som hap.

Der skal selvfølgelig også være proceduren display() der blader den overførte parameter ud på enkeltciffre og viser dem.

På de fleste små MPU'er er der en fast prioritet på interrupt og der udføres normalt også kun et af gangen (dvs. intr af intr bruges sjældent).

"Søren" skrev i en meddelelse news:Xns94D3B14BBC751o8oLOOKatHOMEo8o@212.242.40.196...

AHA-oplevelsen er nok druknet i manglende overblik og erfaring.

Bare fint - tak for det - det vil jeg prøve at lave !

Det har jeg til at køre, hvor hvert ciffer står i ca. 1 mS (det er vel med at have dette så KORT som muligt, men dog så displayet stadig synes at lyse stabilt - ikk' ?)

Jeg har nu valgt at holde hvert ciffer i hver sin variabel - i stedet for at skulle til at 'bladre cifrene frem' - er det ikke det du mener med 'bladre' ?

Mvh KS

"Søren" skrev i en meddelelse news:Xns94D3B14BBC751o8oLOOKatHOMEo8o@212.242.40.196...

Hvordan er't liiiige man laver sådan en tidtagning i ASM !

Kan jeg lokke dig til at compilere en lille stump, så jeg kan se ASM-koden

mvh KS

Hej Keld,

Velbekomme :)

Njaaa, så længe det skifter hurtigere end øjet kan opfatte det, så skal det helst stå så længe som muligt. Det er en balancegang der også må inkludere hvad der ellers er af housekeeping, men der sker nok ikke noget ved at køre langsommere.

Jo, men på et eller andet sted skal du jo trække dem ud fra tælleren. (Du laver vel ikke enkeltciffer tælling med mente til næste højere ciffer ?).

Hej Keld,

Sæt TMR0 i gang, og reset hver gang du har læst.

Jeg når det ikke i aften, men lad os se hvad weekenden bringer.

"Søren" skrev i en meddelelse news:Xns94D4FD24C946o8oLOOKatHOMEo8o@212.242.40.196...

Det er da lige det jeg gør - med 'vel ikke' antyder du det er galt - hvorfor ?

Mvh KS

"Søren" skrev i en meddelelse news:Xns94D41095FF16Bo8oLOOKatHOMEo8o@212.242.40.196...

Det behøver du ikke gøre - jeg opfattede din psoudekode som om der var en milighed for at 'aflæse et ur' svarende til det interne ur på en pc - det med TRM0 skal jeg nok få styr på.

Mvh KS

Hej Keld,

Ikke ligefrem galt, men det giver en mere logisk programstruktur at have skidt for sig og snot for sig og det giver også en rutine der tager lige mange clockcyckles hver gang hvis du blot incrementerer en tæller og så fordeler tallet ud i enkeltciffre i udlæsningsrutinen.

Men... Hvis det virker for dig og giver dig bedre overblik kan du da godt bruge metoden.

Hej igen,

OK, held med det så :)

kig på

han har en frekvenstæller som er nem at modificere til dit behov. den findes også i versioner hvor der bruges 4-7 7segment led displays.

Men grundlæggende er det du skal gøre følgende:

Brug en intern timer/tæller som eventcounter. når den laver overflow så tæller du manuelt et ekstra register op og sletter dit overflow flag.

til timing bruger du en software løkke (f.eks opdater display) og en gang for hver t-tid læser du dine tæller-registre og så kan du se hvor mange events/tid du har (frekvens, rpm, omd/min, km/t ...)du kan så resette alle tæller registre og starte igen eller hvad du nu måtte have lyst til.

hele humlen er at lade hardware tælle op og timimg i software (hardware hvis du har en ekstra timer der kan gøre det for dig) og så for guds og alle andres skyld undlade at bruge interrupts da de ellers vil ødelægge din timing. du kan heller ikke være sikker på at få et korrekt resultat hvis du bruger interrupts. hvad hvis du er i gang med at behandle tælleinterrupt når du får timer interrupt - eller omvendt?

bare en indspark

- patrick