flyttal enligt IEEE 754. Hur får man så stora värden?
Om du tycker de verkar lite jobbigt att hantera, så fins det anledning till att dessa löses av HW-coprocessor på olika nivåer i alla lite större system, DSP och grafikkort inkluderat.
---
Skall du ha koordinatransformeringar med sin,cos,tan och dess inverser så kan CORDIC vara något att titta på - de använder addition, skiftning av register och tabelluppslag för operationer av önskad nogranhet.
(tex om du skall hantera GPS-data mm.)
---
Skall du ha koordinatransformeringar med sin,cos,tan och dess inverser så kan CORDIC vara något att titta på - de använder addition, skiftning av register och tabelluppslag för operationer av önskad nogranhet.
(tex om du skall hantera GPS-data mm.)
> men också för att kunna programmera program till 8-bitars PICar som hanterar flyttal.
I de flesta fall då man tror att man behöver det, så har man inte
tittat på problemet tillräckligt noggrant. Om nte själva programmerings-
uppgiften är målet, vill säga.
Här är en sida som ger lite tips om varför fixed-point väldigt ofta
fungerar lika bra (oftast bättre) än fp :
http://www.piclist.com/techref/method/math/fixed.htm
För just trig funktioner så har Scott Dattalo (en av de vassaste PIC
programmerarna i värden) denna sida :
http://www.dattalo.com/technical/software/software.php
Inte speciellt lättläst kod och man bör vara ganska slängd i matte, men
väldigt underhållande för den som är lagd åt det hållet...
T.ex en 14-bit vinkel -> 8-bit SIN värde (inom +/- 1 bit) inom 48 instruktionscykler !
Eller samma kod för PIC18 på 30 cykler (d.v.s 6 us vid 40 Mhz).
I de flesta fall då man tror att man behöver det, så har man inte
tittat på problemet tillräckligt noggrant. Om nte själva programmerings-
uppgiften är målet, vill säga.
Här är en sida som ger lite tips om varför fixed-point väldigt ofta
fungerar lika bra (oftast bättre) än fp :
http://www.piclist.com/techref/method/math/fixed.htm
För just trig funktioner så har Scott Dattalo (en av de vassaste PIC
programmerarna i värden) denna sida :
http://www.dattalo.com/technical/software/software.php
Inte speciellt lättläst kod och man bör vara ganska slängd i matte, men
väldigt underhållande för den som är lagd åt det hållet...
T.ex en 14-bit vinkel -> 8-bit SIN värde (inom +/- 1 bit) inom 48 instruktionscykler !
Eller samma kod för PIC18 på 30 cykler (d.v.s 6 us vid 40 Mhz).
nja, detta kan antagligen endast lösas med floating point eftersom jag har tänkt leka lite med grafiska displayer och vill kunna ha det hela lite som en dator, dvs att man kan programmera diverse applikationer till den och skapa variablar fritt. Men allt detta är mest för att jag är nyfiken på det och vill prova hur det fungerar i praktiken.
Edit: Men om det är för jobbigt så kan man ju alltid ta en byte som kan gå upp till 255 och dela med 10 när man behöver värdet. Så byten istället räknar till 25,5. Men vill man ha stora värden så blir det ju en hel del minne som ryker.
Edit: Men om det är för jobbigt så kan man ju alltid ta en byte som kan gå upp till 255 och dela med 10 när man behöver värdet. Så byten istället räknar till 25,5. Men vill man ha stora värden så blir det ju en hel del minne som ryker.
> detta kan antagligen endast lösas med floating point...
Med väldigt stor sannolikhet helt fel.
Det är mycket, mycket enklare att t.ex ta 4 eller 8 bytes och
göra en stor fixed-point variabel, än att försöka med floating point.
Det finns dessutom massor av kodexempel för fixedpoint, t.ex division:
http://www.piclist.com/techref/microchi ... /index.htm
Den enda motivet för floating point är för väldigt stor dynamik (d.v.s omfång,
skillnad mellan det minsta och det största värdet). Och det har du i alla fall
inte för att räkna ut pixlar på en display.
Med väldigt stor sannolikhet helt fel.
Det är mycket, mycket enklare att t.ex ta 4 eller 8 bytes och
göra en stor fixed-point variabel, än att försöka med floating point.
Det finns dessutom massor av kodexempel för fixedpoint, t.ex division:
http://www.piclist.com/techref/microchi ... /index.htm
Den enda motivet för floating point är för väldigt stor dynamik (d.v.s omfång,
skillnad mellan det minsta och det största värdet). Och det har du i alla fall
inte för att räkna ut pixlar på en display.
jo med 6 bytes till heltalen och 2 bytes till decimalerna kan man få hyfsat stora tal med 4 decimaler rätt. Men det tar ju mer minnesutrymme. Inte för att det spelar någon roll precis men det är ju alltid kul att kunna utnyttja minnet maximalt men samtidigt kunna köra programmen så snabbt som möjligt.
Tänkte prova att rita diverse kurvor på skärmen och behöver då ha decimaltal när matten utförs och sedan göra om till heltal när det ritas på skärmen.
Tänkte prova att rita diverse kurvor på skärmen och behöver då ha decimaltal när matten utförs och sedan göra om till heltal när det ritas på skärmen.
> det är ju alltid kul att kunna utnyttja minnet maximalt men samtidigt kunna köra programmen så snabbt som möjligt.
Generella floating point rutiner kanske är 10-100 gånger långsammare
än motsvarande trimmade och applikationsanpassade rutiner för fixed point.
Bara att välja...
> och behöver då ha decimaltal...
"Decimaltal" behöver inte automatiskt betyda "floating point".
Fixed point kan också vara decimaltal, det beror på var du definierar "kommat"...
Men men, det verkar som om du behöver jobba lite mer med kravspecen...
Generella floating point rutiner kanske är 10-100 gånger långsammare
än motsvarande trimmade och applikationsanpassade rutiner för fixed point.
Bara att välja...
> och behöver då ha decimaltal...
"Decimaltal" behöver inte automatiskt betyda "floating point".
Fixed point kan också vara decimaltal, det beror på var du definierar "kommat"...
Men men, det verkar som om du behöver jobba lite mer med kravspecen...
Hehe, jo jag har inte riktigt tänkt efter hur högt jag ska lägga mina mål för detta projekt. Men det jag är ute efter är att göra någon liten dator som man kan skicka program till från datorn och sedan kunna köra dessa program på den. Lite som windows på en dator. Den ska ha ett färdigt Operativsystem som kan köra många olika program. Detta är iofs också ett av problemen med detta projekt. Antingen får jag köra med en PIC som har selfwrite så att den snabbt kan programera om sig och köra den aktuella applikationen, eller så får jag ha en PIC som håller reda på programmen och programmerar en annan PIC som i sin tur kör applikationen. Lite knepig det där 
