Sida 1 av 2

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

Postat: 20 augusti 2008, 16:06:52
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)



Postat: 20 augusti 2008, 16:28:43
av sodjan
Stopwatch.

Postat: 20 augusti 2008, 16:43:01
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?

Postat: 20 augusti 2008, 16:47:03
av sodjan
Du kan inte räkna snabbare än vad du hinner med, korrekt...
Men det är väl ganska självklart !?

Postat: 20 augusti 2008, 17:20:30
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.

Postat: 20 augusti 2008, 17:36:08
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... :-)

Postat: 20 augusti 2008, 17:44:26
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)

Postat: 20 augusti 2008, 17:50:22
av sodjan
> och låter fullskaleutslag vara 3333kHz

3.3 MHz ??

Postat: 20 augusti 2008, 17:57:53
av AndersG
Äh.. 3333Hz menar jag givetvis ;)

Postat: 20 augusti 2008, 21:11:14
av Marta
Varför inte ta hjälp av de hårdvaruräknare som finns i PIC?

Postat: 20 augusti 2008, 21:48:56
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

Postat: 20 augusti 2008, 22:43:05
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.

Postat: 20 augusti 2008, 22:56:19
av blueint
Toggla en I/O pinne och koppla till ett oscilloscope.

Postat: 21 augusti 2008, 00:08:29
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.

Postat: 21 augusti 2008, 08:27:13
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 ;)