multiplicera 24bit-tal cc8e-kopilator

[tobbetabbe]

nej avbrottsrutinen går bara in och avläser TMR0(5MHz) mellan två inkommande flanker(TMR1(FFFF-värde)-avbrott) på varje puls och nollställer denna.Detta görs varje 1mS (TMR3)Beräkningen borde kunna göras däremellan.

[sodjan]

Om x = antal räknade pulser på en minut.

1024 pulser/varv.

rpm = x / 1024 (vilket är en enkel shift 10 steg).

Eller om du mäter antalet pulser på 15 sekunder :

rpm = x / 256 (vilket är en enkel shift 8 steg).

Eller med 7.5 sek mätning :

rpm = x / 128 (vilket är en enkel shift 7 steg).

Varken multiplikationer eller divisioner...

[sodjan]

> men en allmän fråga är 18xxx kretsarna lämpliga för såna här beräkningar

Lite tidig fråga när det inte är riktigt klart vilka beräkngar det handlar om.

> om det nu finns någon gräns för hur ofta avbrottsrutinerna slår in.

Bara dina cykler räcker till, så nej.

> antar att en för hög frekvens av avbrott i programmet spökar.

Det är inte helt klart *vilka* avbrott du har eller hur ofta de kommer.

Inlägget om TMR0, TMR1 och TMR3 var redigt rörigt...

[tobbetabbe]

en timer används för externt inkommande avbrott,om varje puls(TMR1=FFFF slår runt)

en annan TMR0 intern räknare 5MHz,räknar mellan två externa inkommande flanker.

TMR3 används för att räkna 1mS.

[tobbetabbe]

avbrotten kan vara från nåra kHz till 100kHz

[sodjan]

OK, har du kollat på att köra TMR1 som *counter* istället ?
Och räkna pulser under en viss tid.

Om x = antal pulser (räknat med TMR1 som "counter") under 468 ms

så är rpm = TMR1 / 8 (en 3 pos shift).

Eller om du räknar pulser under (ca) 58.6 ms, så är rpm = TMR1 !!

Vilken noggranhet behöver du på rpm värdet ?

Använd en annan timer för att "ta tid" för hur länge TMR1 ska räkna.

[tobbetabbe]

nogrannheten vill jag ska vara så hög som möjligt ca 2-3 decimaler.
från början räknade jag pulser/tidsenhet men detta gav för dålig upplösning.
nu har jag tvingats att mäta tiden med snabb klocka (5MHz) mellan ingående pulser med enheten tidsenhet/pulser dvs inverterat värde som jag ska sampla varje 1mS för att skicka vidare till FFT-analys (intressanta varvtalsavvikelser är högst 300 Hz).hade tänkt lite avancerade metoder med linjärisering av värdet vid samplingsögonblicket då detta samplingen kan ske mellan två pulser. men skräver mycket PIC-matte och tror jag klarar mig ändå

[bearing]

OK, nu fattar jag. Du mäter perioden på signalen. Då är det klart att du måste göra en division.

Är dessa 5Mhz den interna klockan? dvs du har en 20 MHz kristall?

Om du vill se varvtalsavvikelse föreslår jag att du inom den här millisekunden sparar min-, max- och medelvärde på alla inkomna perioder under millisekunden. Om FFT-analysen sker i dator kan du väl skicka perioderna till datorn, så får den räkna ut varvtalet. (Om det är så att PICen inte hinner.)

[tobbetabbe]

ett problem är att varvtalet ska presenteras på en lcd-display också men då är det inte så viktigt med noggrannhet noggrannheten är viktigast till PC:n då via RS232.då kanske pulser/pulsenhet är att föredra och görs enkelt med en avbrottsrutin.eftersom jag gör exjobb börjar jag bli fb-annat trött på att aldrig bli färdig att jag kanske lämnar de tunga beräkningarna till PC-experten.jag fick bra tips från forumet tidigare då jag använder D/A som visualisering av varvtalsavvikelserna då det gäller ökad upplösning och slippa DC-nivån.ännu en till som stödjer att använda PC:n som räknemaskin detta är kanske en enkel väg ut om PIC:en inte klarart

[sodjan]

> Jag ska sampla varje 1mS...

Jaha, du vill alltså ha ett *nytt* rpm-värde *varje* millisekund ???
Eller åtminstånde *underlag* för att beräkna rpm.
Jag kan inte påstå att det var speciellt tydligt tidigare...

> nogrannheten vill jag ska vara så hög som möjligt ca 2-3 decimaler.

OK. Problemet är att du har en tidmätning med en upplösning på
0.2 us. Vid 100.000 Khz på ingången ger detta 2% upplösning och det
ger knappast "2-3 decimaler" vid ca 5800 rpm. D.v.s om man mäter
perioden mellan två pulser.

För 3 decimaler vid 5800 rpm behövs en mätosäkerhet under 1 ppm !
Alltså för att se skillnad på 5799.999, 5800.000, 5800,001 o.s.v rpm.
Är det realistiskt ?

Även om man utsträcker mätningen till en hel ms så får man 0.2/1000
= 0.02 % upplösning, vilket vid 5800 rpm ger +/- lite drygt 1 rpm.

Så här på rak arm ser jag inget sätt att få bättre noggranet om man inte
utsträcker mätningen över en längre tid en 1 ms.

Eller också har jag missat något fundamentalt, mycket möjligt...

[tobbetabbe]

jag kanske har uttryckt mig otydligt och enbart plockat ut enskilda isolerade frågor.

jag är tvungen att sampla(läsa av värdet) varje 1mS för det antar jag att FFT-beräkningen(för att se frekvensen på varvtalsavvikelsen om motorn går ojämt)) kräver då man ser varvtalet går ojämnt.

jag har möjlighet att hoppa över antal inkommande pulse som genererar avbrott som då kan ge bättre mätupplösning det var en bra beskrivning du gav mig.
har även provat att koppla in en 50MHz oscillatorkrets för att öka mätupplösningen.
men som alltid måste man kompromissa och vrider o vänder på allt och måste ändra en massa register.

[tobbetabbe]

måste sova läser i morrn