Tajming, tänker jag rätt?

[AndersG]

Det är fortfarande mitt GPIB-diskprojekt...

Jag har ju ingen RTC, men om jag sätter upp Timer0 att räkna, med den interna klockan och 256 prescale:

Kod: Markera allt

	T0CON = 0b10000111;
	INTCONbits.TMR0IF = 0;

sedan har jag en snutt jag kallar:

Kod: Markera allt

void Time(void)
{
unsigned int ticks = TMR0L + 256 * TMR0H;
	sprintf(string,(const far rom char*)"\r\nTicks:%u %d\r\n", ticks, INTCONbits.TMR0IF);
	sio_puts(string);
	INTCONbits.TMR0IF = 0;
}

Systemklockan är 32MHz (8MHz med x4 PLL) så borde ett tick motsvara 1/(8MHz/256) = 32us?

Om det då tar 5377 ticks att föra över 256 byte, så tar varje byte 672us, vilket blir 1,5kb/s?

En "riktig" HP 9122 har 45kb/s överföringshastighet, så det finns rum för förbättringar...

[Swech]

"unsigned int ticks = TMR0L + 256 * TMR0H;"

Håll bara koll så att den läser de båda bytes i rätt ordning.
Kanske C kompilatorn fixar detta....

Swech

[AndersG]

Håll bara koll så att den läser de båda bytes i rätt ordning.

PIC 18F4620 fixar detta i hårdvara. Den höga byten är inte läsbar direkt, utan då man läser den lägre så läses samtidigt den höga in i TMR0H som en atomisk händelse.

[kimmen]

Fast för att det skall fungera krävs det ju att man läser den låga byten först - och det finns det ingen garanti för i din kod. (om nu inte din kompilator specifikt garanterar det av någon anledning)

I C är ordningen i vilken underuttryck evalueras ospecifierad. Se t.ex följande sida för detaljer:

https://www.securecoding.cert.org/confl ... take+place

[AndersG]

I think izi already looked at the source code, but the peripheral library should definitely read/write the timer registers in the correct order. If the library functions don't use the correct order, it's a bug.

Och är man osäker kan man ju göra det i assembler. Som det är nu så använder jag bara 8-bitarsläger och dessutom kollar jag bara TMT0IF (när räknaren slår runt)

[Icecap]

Jag använder XC8 i ett PIC-projekt och ville läsa timern på samma sätt med denna atomic-läsning aktiverat. Kompilern gjorde inte samma sak i rätt följd varför jag fick fixa det manuellt.

[AndersG]

Det är ju inte helt fel att kolla den genererade koden att det blir rätt.

[MiaM]

Det är fortfarande mitt GPIB-diskprojekt...

Jag har ju ingen RTC, men om jag sätter upp Timer0 att räkna...

Du skulle kunna göra en testmjukvara som bara kör klockan och matar ut vad den tycker klockan är, och logga output ihop med riktiga klockslag till en loggfil, för att se hur rätt/fel den visar.

Om det då tar 5377 ticks att föra över 256 byte, så tar varje byte 672us, vilket blir 1,5kb/s?

En "riktig" HP 9122 har 45kb/s överföringshastighet, så det finns rum för förbättringar...

Har du provat att "profilera" din kod för att se vad som händer?

Captain obvious hälsar att det givetvis är vettigt att "förbererda nästa byte" åt ena eller andra hållet vid de punkter i koden som du ändå måste vänta på extern enhet.

[AndersG]

Har du provat att "profilera" din kod för att se vad som händer?

Ja, jag vet exakt var flaskhalsarna är och jag har filat på de bitarna och fått ned antal instruktioner avsevärt. Är nu på en nivå när jag har ungefär samma prestanda som den gamla HP floppy jag emulerar.

I många av fallen jag testat dessutom så är jag betydligt snabbare än instrumentet. Dvs det är mätinstrumentet som är flaskhalsen, inte diskemulatorn. Min 1631D är tex 10x långsammare än min 44788-kort.

[MiaM]

Gött!

Min poäng, ifall den inte framgick, är att det givetvis är bra om du kan korsbefrukta dina flaskhalsar med instrumentets flaskhalsar, så att i väntan på instrumentet gör du förberedelser som t.ex. att läsa från halvlångsam flash till snabbare RAM eller liknande. (Även om du inte har nån avacerad cachealgoritm så är det väl dels helt självklart att instrumentet lär fullfölja en begärd läsning, och högst sannolik att instrumentet är suget på att fortsätta läsa nästföljande delar av en fil som det börjat läsa av o.s.v.).

[AndersG]

Visst.