Svenska ElektronikForumet

OK...

Först och främst - Stort tack för all hjälp hittills!

Åsså en sista (För just nu då alltså...) kollationering...

Nedåt räknaren uppför sig lite mysko, gör den inte?

Ännasomsåhärdåalltså... Hur många gånger kommer PC gå tillbaka till countDown...?

Ochomdetserutsåhärdå...?
Hur många gånger kommer PC gå tillbaka till countDown då...?


Varför heter det PC?
Borde inte typ IC vara mer beskrivande?

Förstår inte varför du blandar ihop PC med instruktionscykler.

> Varför heter det PC?

Program Counter.

> Hur många gånger kommer PC gå tillbaka till countDown...?

Ingen gång.

> Hur många gånger kommer PC gå tillbaka till countDown då...?

En gång.

Bra, tack Janne.

Därför att, Tomas, det är vad det är.
En rad, en instruktion, en programräkning.
Typ.

PC, programräknare, talar om *var* i programmet man befinner sig.
Instruction cycle, en tidsenhet. Ej direkt jämförbara, två olika saker.
Om du blandar ihop dom så blir det bara svårare.

Givetvis.

Och det är programräkningen som är intressant, den som håller reda på var i tiden programmet befinner sig.

Fan vad du rör till det för dig.

> Och det är programräkningen som är intressant, den som håller reda på var i tiden programmet befinner sig.

Den håller reda på *var* i programmet man befinner sig. Den har inte ett smack med någon tid att göra...

Du borde sluta med att hitta på egna hemsnickrade förklaringar på saker och ting.

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.

Det är en återvändsgränd att sitta och räkna instruktionscykler.
Du får bättre precision med de inbyggda timers som finns i processorn
samt att processorn inte behöver sitta och rulla tummarna.

Resonemanget att en instruktion tar en väldefinierad tid är inte heller sant
på de flesta processorer idag.
Kör du PIC så kan du få till det men då kan du inte köra med interrupt överhuvudtaget.
Finns även "häftigare" modeller med lite cache minne i och då är det helt kört.....

Sedan brukar räknarna idag kunna ha bättre upplösning än processorns instruktionscykler.
d.v.s. gå snabbare

Swech

Återigen, avbrottshantering är bra för vad det är bra på.
Om det är många olika väldigt korta signaler fungerar det sämre.

Och det är inte högre upplösning på tidsräkningen som behövs, det är att veta exakt var och hur långt till nästa, från den punkten, som vad jag söker.

Någon som missade vad det innebär att man kan om man kan få en 486'a att ge en timer med upplösning på 100kHz?

Jag har gjort /gör tidräknare som står i princip i varje svensk skola
Upplösning 100kHz med en 4MHZ 68HC11
Så 100kHz är i sig inte fantastiskt.....
Swech

Ja, för att ta reda på vilken maximal hastighet koden klarar så är räkna instruktionscykler antagligen vettigt. Om man t.ex. vill skriva ett digitalt filter och vill räkna ut vilken högsta samplingsfrekvens det går att köra med.

Du missar poängen Swech. Du använder en perifer krets. Som är speciellt byggd för det. Där bara den biten går lös på sisådär tvåhundra spänn... Resten oräknat.

Jag gör det i DOS, på en PC. Inklusive presenterande grafik och övrig racemanagment.
På en skrotdator som inte ens med skärm når upp till tvåhundra, och som hanterar all data runtomkring, sammanställningar, utskrifter, lagring etc i en å samma enhet. En enhet vem som helst har vana hantera.


Något åt det hållet, Nerre.
Men mer för att kunna fånga snabba och korta signalinstanser.

Exempel...
Flaggan, styrbladet på en slotcar är 20mm.
Ett varv om 45m går på 4s, dvs 45m/4s =11.25m/s.
Hastigheten på rakorna minst 50% högre, dvs 16.875m/s.
Flaggan är, som nämnts, 20mm.
Tiden för en sensor att reagera på flaggan är då alltså nere på sisådär 1ms.
På en... Men det är åtta stycken...
Å då är vi nere på 150µs.
Och 150 instruktioner gör man snabbt av med...
...speciellt om en avbrottshantering går in och hoppar iväg.

Om man förlänger sensorområdet?
Då tappar man omedelbart upplösning istället.


Det går alltid hitta på en fräckare lösning, ju mer speciell desto fräckare.
Vilket har lite och inget med tillgänglighet och användarvänlighet att göra.

Nog om detta, tycker jag.

Beroende på vilken processor du använder, kan du få en upplösning på de interna räknarna motsvarande klockan.
Då behöver man inte räkna instruktioner och instruktions cykler (PC-n är alltid ointressant för detta.)