Svenska ElektronikForumet

Kan man inte knacka det tidskritiska i inline-ASM?

Dvs hela interruptrutinen?

Bara det blir interrupt så ska work-register sparas undan som alltid men C-kompilatorn sparar undan massa annat trams oxå vilket tar tid. Sedan håller den på och leker med dessa variabler i koden också.

Mitt problem fast för MikroPascal.
http://www.mikroe.com/forum/viewtopic.p ... erhead+asm

Problemet kan ju vara att de kanske bygger på samma kolpilator fast för olika högnivåspråk som Basic, Pascal och C.,

> En instruktion i 20 Mhz tar 50ns

200 ns.

> ...men 71 st eller var det nu var extra verkar rätt mycket....

Inte 71 extra, det är 72 instruktioner totalt i PIC18 arkitekturen.

Men, 90% av koden består normalt av 10-15 olika instruktioner.
Många av de nya instruktioneran är för specialfall som t.ex
tabell hantering eller likannde, och de använder du kanske inte alls.

> eller en delay är delay_ms(100).

Så skriver man i alla fall inte kod, så vad är poängen ??
Och vad är skillnaden mot att göra "call delay_100ms" ?
Förrutom att tiden är fast, men det kan enkelt fixas...

> Att skicka via USART i C är ju bara Usart_Write('X');

Det kan det vara i assembler också, efter att du har skrivit
subrutinen Usart_Write...

> Kan man inte knacka det tidskritiska i inline-ASM?

En del av det tidskritiska är den extrakod som kompilatorn lägger
in vid ingången av interruptkoden. Jag vet inte hur inline-asm
hjälper mot det.

Eftersom jag redan har använt en hel del av de olika färdiga funktionera i MikroC så blir det rätt mycket jobb att skriva om alla dessa funktioner i ASM för att kunna skriva om koden till ASM.

> En instruktion i 20 Mhz tar 50ns
200 ns.

Stämmer såklart. Tänkte på klockkristallen periodtid jag Glömde visst att varje cykel är uppdelad i fyra perioder.

4Mhz är iaf 1 µs /cykel det är jag bombsäker på den är lätt att räkna på och står om jag inte missminner mig i manualen.

Räcker iaf garanterat inte till C kods tjaffande med intosc på 4Mhz

8 bitars hårdvarumultiplikator är trevligt i PIC18...