Svenska ElektronikForumet

Hittade om Bresenham för linjer:

http://en.wikipedia.org/wiki/Bresenham's_line_algorithm

Principen är densamma, ursprungligen var det för linjer på plotters. De kan ju bara röra sig i fasta inkrement, precis som en heltalsräknare. Då kan man få en noggrannhet som ligger inom steglängden genom att använda en sådan algoritm. I långa loppet blir det helt exakt. Ju längre ju mindre blir det relativa felet i förhållande till helheten.

Angående assembler så är det inte alls svårt att hantera flera instruktionsset. Det är bara olika tabeller för OP's och dekoderrutiner för addressmodes. Hela den "tunga" delen med symbolhantering, beräkningar, inläsning av källkod, filhantering o.s.v. är gemensam. Eftersom det följer samma mall hela tiden så kan det vara på detta sätt. Skulle varit svårare om tillverkarnas OP's skulle ha använts.

Det är just att "normalisera" källkoden mellan processorerna och at få bort onödigt krångel som är avsikten med den. Där finns inga onödiga saker som stökar till det. Dessutom är den blixtsnabb. Över 1M kod för 8088 till färdig binärfil på mindre än 1/10 sekund med en modern dator. Givetvis är det ett kommandoradsprogram skrivet i assembler. Version 0 i TP3 för att komma igång, sedan konvertering så den kan assemblera sig själv.

Marta: Jag börjar bli lite klokare på hur du menar (tror jag ).

Om jag använder en 19,17MHz kristall så blir det:

19 170 000Hz / 4 = 4 792 500Hz / 65536 = 73,12774658203125Hz

Då ska heltals variabeln vara 73. Ta bort heltalet och multiplicera med 256:
0,12774658203125 * 256 = 32,703125

Då ska undervariabel1 vara 32. Ta bort heltalet och multiplicera igen:
0,703125 * 256 = 180

Då ska undervariabel2 vara 180.

Har jag fattat rätt? Måste läsa på lite mera, men om jag tänker rätt och förstog din förklaring rätt så ska det fungera ungerfär som en delaylop, så varje gång.. Nää.. Nu blir tänker jag fel i alla fall Bara att läsa på lite mer..

----

Från databladet

When the Timer1 oscillator is enabled (T1OSCEN is
set), the RC1/T1OSI/CCP2 and RC0/T1OSO/T1CKI
pins become inputs. That is, the TRISC<1:0> value is
ignored and these pins read as ‘0’.

Så jag använder inte samma kristall till timern som jag kör PIC'en på?

--
Aha! Ett ljus tändes precis Så det är inte den interna osculatorn de menar med det andra alternativet utan den kristallen som jag kör PIC'en på, och då är det bara en fjärdedel av av kristallens freqvens?? Då blir allt mycket mer sammanhängande

Mvh.

Edit: Bara för skojjs skull gjorde jag ett program i C++ där jag skrev in kristallens freqvens (19,17MHz), så räknade den ut att jag kan ta och sätta timern på prescale 1:1 och låta den göra 245760 interrupt innan jag ökar minut variabeln med 4096. Det borde fungera, men en lite hackig klocka som bara uppdateras ungefär var tredje dygn

Har inte kollat Ditt sista räkneexempel, men det verkar som att Du förstått hur man skall göra delaren när det är en udda frekvens.

Kristallen delas mycket riktigt ned med 4 utan att man kan påverka detta i sitt program. Sedan kan man välja prescaler till 1, 2, 4 eller 8 innan räknaren delar med 65536. Det är olämpligt i en klocka att ställa om räknaren, det kan leda till att man tappar pulser och den går fel. En onödig risk att ta. Speciellt om man även har en snabb interrupt för att t.ex. scanna en display och/eller intensitetsstyra denna.

Marta: Det glädjer mig att du lyckades få någon att bli intresserad av denna enkla metod.

Eftersom din kod är av lite ovanligare karaktär så postar jag mitt typexempel.
Den enda nackdelen med metoden är att sekundpulsen blir lite ojämn om man har ett lågfrekvent interrupt, men till en vanlig klocka fungerar det utmärkt.


Interruptrutin avsedd att exekveras med 65536 cyklers intervall (Pic16)