PIC, ASM. Frågetecken kring delayrutiner

[ylle]

Ett par nybörjar frågor, tänkte att det är bra att lära sig rätt från början

Finns det något "optimalt" sätt att göra en delay på? Tänker mest på goto delayer men också med timers


Och var ligger gränsen när det ena börjar bli bättre än det andra?

Tänker främst på dom vanligare modellerna pic16/18, kan säkert skilja mellan modeller men generellt sett.

[vfr]

Jag skulle säga att det är helt beroende på din applikation. Får den inte alls "stå stilla" under ens en kortare tid, så måste man börja använda timers vid mycket kortare tider. Å andra sidan så ger timers en viss overhead också med initiering, och framförallt, avbrottshantering.

[sodjan]

Nja, för korta fördröjningar (där risken att något annat skulle
behöva göras under tiden är liten) fungerar loopar i programvaran OK.
Sen finns det en gräns (som varierar från fall till fall och från
applikation till applikation) där det blir mer praktiskt med timers...

Så för att svara på dina frågor :

> Finns det något "optimalt" sätt att göra en delay på?

Nej.

> Och var ligger gränsen när det ena börjar bli bättre än det andra?

It depends...

[JimmyAndersson]

Notera att "goto $+1" är det samma (tidsmässigt) som "nop, nop",
men tar bara en instruktion istället för två. En smart men kanske
inte så uppenbar optimering. Så "goto $+1, nop" ska bytas till
"nop, nop, nop" för att det ska bli samma exekveringstid.

Så sant. Har fixat det nu.
Delay_1s-rutinen har jag inte städat på det sättet, men den är hyfsat "ren" ändå, för att vara en delay på hela 1 sekund:

Kod: Markera allt

;Delay 1s  (1,00056s)
Delay_1s
	movlw	0x5A
	movwf	d1
	movlw	0xCD
	movwf	d2
	movlw	0x16
	movwf	d3
Delay_1s_0
	decfsz	d1, f
	goto	Delay_1s_1
	decfsz	d2, f
Delay_1s_1
	goto	Delay_1s_2
	decfsz	d3, f
Delay_1s_2
	goto	Delay_1s_0
	nop
	return

Så delayrutinerna ger nu 1,00056s , 5,0003ms och 1µs. Den sistnämnda rutinen fixade jag med 8st nop istället för decfsz.


Man kan få ganska mycket gjort vid datorn när det blåser för mycket (7-8m/s just nu) för att man ska kunna göra någon större nytta ute.

[Swech]

Mjukvarudelays för att t.ex slöa ned signaler till en extern LCD display är helt ok. Dessa brukar vara
max 20ms och egentligen inte kritiska så länge de uppfyller minsta delaytiden som krävs.

Övrigt som att mäta tid är helt vansinnigt att köra med mjukvaruloopar.
Om man nu har fått fram en rutin för 1.00056s som du skriver Jimmy så ställer man sig frågan
"vad händer den dagen du slår på t.ex. ett AD interrupt" Jo din delayrutin råkar ut för avbrott
och 1.00056s blir då helt upp efter väggarna....

Det kan bli ännu värre om man återvinner koden och i ena applikationen har man inga interrupts medans
i nästa har man.. samma delay kommer inte att ge samma resultat och man får buggar som är vansinniga att hitta.

Nästa sak.
Du har ett program som skall multitaska. T.ex. scanna ett tangentbord, kontinuerligt uppdatera en ledmatris samt
skicka serieinformation via RS232.... då kan ju processorn inte sporadiskt stoppas under 1 sekund. Alltihop stoppar ju då.

Använd de inbyggda timers som finns. Det är just till fördröjningar och tidmätning som de finns.

Swech

[v-g]

Swech:Det hela beror på applikationen i vissa går det utmärkt med delays i andra fall inte.

Kan lugt säga att de senaste dagarna har jag provat ALLA varianter och det á la tidskritiskt maner (Onewire kommunikation) delayer är bra i vissa fall timers i andra. Nu köra jag en kombination.

Tex jag väntar på att pinnen ska bli hög MEN för att programmet inte ska hänga om den inte blir hög sig drar jag igång en timer som efter ett tag förbigår rutinen. Dock är detta svårt om tiderna som pinnen kan svänga på är varierande.

För att inte påverka delays med tunga interuptrutiner krävs att man tänker innan man kodar eller helt enkelt gör om gör rätt när det inge fungerar

För att vänta i en strömsnål app däremot där är det mycket att vinna på timers.