Hjälp med att tajma rutiner i PIC/MPLAB?

PIC, AVR, Arduino, Raspberry Pi, Basic Stamp, PLC mm.
Användarvisningsbild
AndersG
EF Sponsor
Inlägg: 9127
Blev medlem: 25 februari 2008, 17:10:58
Ort: Mariehamn
Kontakt:

Hjälp med att tajma rutiner i PIC/MPLAB?

Inlägg av AndersG »

Undrar bara om det finns ngn magisk lista eller verktyg som kan lista den tid olika instruktioner tar i ett program så att man kan summera?

Man kan ju göra det för hand i programlistningen, men man är ju lat...

Typ:

Kod: Markera allt

	movwf   w_temp            ; 1
	movf    STATUS,w          ; 1
	movwf   status_temp       ; 1
          incfsz foo,1                    ; 2 (worstcase)


sodjan
EF Sponsor
Inlägg: 43251
Blev medlem: 10 maj 2005, 16:29:20
Ort: Söderköping

Inlägg av sodjan »

Stopwatch.
Användarvisningsbild
AndersG
EF Sponsor
Inlägg: 9127
Blev medlem: 25 februari 2008, 17:10:58
Ort: Mariehamn
Kontakt:

Inlägg av AndersG »

Perfekt! Jag fick 35 cykler på min ISR. Ett litet problem är dock att den kallar en rutin som räknar och den kan ta olika tid beroende på hur stort talet är:

Kod: Markera allt

;Inc32z 
;From Dmitry Kiryashov
inc32z:
        movwf   FSR
        clrz

        incfsz  INDF,F
        return

        incfsz  FSR,F
        incfsz  INDF,F
        return

        incfsz  FSR,F
        incfsz  INDF,F
        return

        incfsz  FSR,F
        incf    INDF,F
        return
Tror jag fick 51 cykler som worstcase då jag räknade på papper, sedan kommer det 3-4 till för själva interrupten. Om jag då antar 4Mhz klocka tar varje cykel 1us. Om jag skall räkna frekvens på detta sätt så blir väl gränsen för vad jag kan läsa med interrupt on change, 1/(55us*2) = 9kHz ?

Eller är jag ute och cyklar?
sodjan
EF Sponsor
Inlägg: 43251
Blev medlem: 10 maj 2005, 16:29:20
Ort: Söderköping

Inlägg av sodjan »

Du kan inte räkna snabbare än vad du hinner med, korrekt...
Men det är väl ganska självklart !?
Användarvisningsbild
AndersG
EF Sponsor
Inlägg: 9127
Blev medlem: 25 februari 2008, 17:10:58
Ort: Mariehamn
Kontakt:

Inlägg av AndersG »

Ahum.. Jo det är det, ville bara kolla mitt räknande av cykler att jag inte gjort ngt korkat fel eller så.

Att eventuella nollgenomgångar som anländer under min ISR går förlorade, är ju självklart.
Senast redigerad av AndersG 20 augusti 2008, 17:45:01, redigerad totalt 1 gång.
sodjan
EF Sponsor
Inlägg: 43251
Blev medlem: 10 maj 2005, 16:29:20
Ort: Söderköping

Inlägg av sodjan »

MPSIM/stopwatch räknar cyklerna. Dock sker det med de värden
som du använder just då, inte med/som "worst case". Men å andra sidan,
om du har så små marginaler så att det spelar roll om en instruktion
går på 1 eller 2 cykler, så har du nog andra problem... :-)
Användarvisningsbild
AndersG
EF Sponsor
Inlägg: 9127
Blev medlem: 25 februari 2008, 17:10:58
Ort: Mariehamn
Kontakt:

Inlägg av AndersG »

Jo, bättre hålla marginaler. Om jag i teorin skall klara 9kHz och låter fullskaleutslag vara 3333kHz för 12A så borde jag vara trygg och dessutom få en upplösning på 3,6mA (12A/3333)

(3333 * 60 * 60 * 10 = 120Ah)
sodjan
EF Sponsor
Inlägg: 43251
Blev medlem: 10 maj 2005, 16:29:20
Ort: Söderköping

Inlägg av sodjan »

> och låter fullskaleutslag vara 3333kHz

3.3 MHz ??
Användarvisningsbild
AndersG
EF Sponsor
Inlägg: 9127
Blev medlem: 25 februari 2008, 17:10:58
Ort: Mariehamn
Kontakt:

Inlägg av AndersG »

Äh.. 3333Hz menar jag givetvis ;)
Användarvisningsbild
Marta
EF Sponsor
Inlägg: 7487
Blev medlem: 30 mars 2005, 01:19:59
Ort: Landskrona
Kontakt:

Inlägg av Marta »

Varför inte ta hjälp av de hårdvaruräknare som finns i PIC?
Användarvisningsbild
AndersG
EF Sponsor
Inlägg: 9127
Blev medlem: 25 februari 2008, 17:10:58
Ort: Mariehamn
Kontakt:

Inlägg av AndersG »

Därför att de bara kan räkna åt ett håll. Jag tänkte mäta Ah genom att förvandla till ett pulståg och sedan räkna pulser. Upp för laddning och ned för urladdning. En PIC med upp/nedräknare vore onekligen perfekt.

Finns mera info om projektet bla här:
http://elektronikforumet.com/forum/view ... hp?t=28031
Användarvisningsbild
Marta
EF Sponsor
Inlägg: 7487
Blev medlem: 30 mars 2005, 01:19:59
Ort: Landskrona
Kontakt:

Inlägg av Marta »

Vad är anledningen att Du inte mäter strömmen med en A/D som finns inbyggd i PIC? Finns ju 12-bit om det skulle behövas och det går att få denna precicion med tanke på störningar o.dyl.

Hur som helst har Du laddfaktor, självurladdning, störningar o.dyl. som skapar osäkerhet. Det är ill fga nytta at försöka bygga något med större precicion än vad som kan utnyttttas med tanke på alla de osäkerhetsfaktorer som finns.
blueint
Inlägg: 23238
Blev medlem: 4 juli 2006, 19:26:11
Kontakt:

Inlägg av blueint »

Toggla en I/O pinne och koppla till ett oscilloscope.
Användarvisningsbild
Marta
EF Sponsor
Inlägg: 7487
Blev medlem: 30 mars 2005, 01:19:59
Ort: Landskrona
Kontakt:

Inlägg av Marta »

Det bästa/enda är att räkna instruktioner om man måste få fram worst-case tider för att t.ex. veta att en interrupt inte kan "bita sig i svansen".

Annars är det ett bra sätt att mäta med scope, men man ser bara en diffus linje om där är gitter och det finns inga garantier för att man verkligen ser bortre gränsen. Inträffar denna bara var femtioelfte gång så syns den inte, men när den väl inträffar så kan det hända något om marginalerna saknas.
Användarvisningsbild
AndersG
EF Sponsor
Inlägg: 9127
Blev medlem: 25 februari 2008, 17:10:58
Ort: Mariehamn
Kontakt:

Inlägg av AndersG »

Vad är anledningen att Du inte mäter strömmen med en A/D som finns inbyggd i PIC? Finns ju 12-bit om det skulle behövas och det går att få denna precicion med tanke på störningar o.dyl.
Egentligen noggrannhet, plus att jag får integreringen på köpet. En 12-bitars AD blir bara 11 om man beaktar tecken. Dessutom måste jag ändå ha en massa analog elektronik för att anpassa signalen från shunten. Hade en diskussion per epost med en tillverkare i USA som tillverkar en batterimätare för elcyklar. Hade köpt den om den klarat både laddning och urladdning, men det klarade den inte och orsaken var att de inte ville offra halva DACens upplösning.
Hur som helst har Du laddfaktor, självurladdning, störningar o.dyl. som skapar osäkerhet. Det är ill fga nytta at försöka bygga något med större precicion än vad som kan utnyttttas med tanke på alla de osäkerhetsfaktorer som finns
Det stämmer, men nu är detta inte ngt jag tänkte serieproducera. Börjar helt enkelt i denna ände, dvs att mäta hur mycket jag tar in och kör ut. Det som gör det komplicerat är att vissa laster är transienta och att laddning från en solpanel (till skillnad från tex en generator) varierar hej vilt med tiden.

Jag är fullt medveten om att jag ännu kan få designa om en massa, men jag börjar i denna ände ;)
Skriv svar