Med tanke på att en instruktion tar en väldigt specificerad tid att utföras så är just precis att hålla reda på var i koden programmet befinner sig som gör att jag lyckas med vad jag föresätter mig.
Och tid och plats är i exakt relation till varandra, vilket inte har ett skvatt att göra med hur lång tid som gått eller var i programmet räknaren befinner sig.
Fullständigt relevant är däremot att det går hålla reda på, väldigt exakt, tiden det tar för programmet att ta sig mellan två diskreta instruktioner.
Som RaceDax, mitt program skrivet i QBasic för tidtagning till slotracing, som på en 486'a gav stabil upplösning om 1/100'000s.
Anledningen till att jag nu till slut alls gått över till assembler, och
inte via exempelvis C, är hur tidsupplösning och instruktioner är hårdkodade till varandra.
För då vet jag vad för tidsintervall jag har att arbeta med, när och var och hur sensorer ska ses till läsas av.
Något som inte fungerar särskilt bra att använda avbrottshantering till.
Avbrottshantering fungerar utmärkt - när det inte är så viktigt med när och var de sker, typ i ett långsammare händelseflöde.
Det viktiga är dock att lyckas ludda ut vad det egentligen står i databladen - speciellt när det står fel i dem...
Och att
veta hur varje instruktion uppför sig. Inte hur den verkar uppföra sig. Inte hur den ska uppföra sig. Inte ens hur den anses uppföra sig.
Ledsen att jag gjort dig så upprörd att du svär.
Dina svar har varit väldigt hjälpsamma och Informativa.
