Sida 2 av 2

Re: Fix-punkts multiplikation i assembler

Postat: 6 februari 2009, 20:36:20
av strombom
Detta betyder att du konverterar tal som vanligt innan utskrift men att du ser till att kommat kommer in på rätt plats, när detta sker visar uträkningen kanske 8125 st 1/1000-delar men i en utläsning med rätt placerat komma blir det 0,8125, så enkelt är det.
hihi, det var nog inte riktigt så enkelt ändå :jimmyhacker:

var bara tvungen. :D

Re: Fix-punkts multiplikation i assembler

Postat: 7 februari 2009, 10:15:24
av Johel572
Faktum är att det var så enkelt. Bara jag som inte förstod vad Icecap menade och än mindre viste hur jag praktiskt skulle implementera det. När man väl fattat principen i att räkna i hundradelar (eller den upplösning man är ute efter) i stället för heltal var det inga som helst bekymmer.

Mitt projekt har en signal från en A/D på 12bitar (representerad i 16bitar så jag räknar på det). Och ger en precision på strax under en tiondel. Min justerings faktor som jag använder för att skriva ett reellt tal multiplicerade jag helt enkelt med hundra så blir ju produkten hundra gånger större och alltså representerar hundradelar (1/100 fel i beräkningen torde vara godtagbart om signalen har en upplösning på 1/10). Det fungerar utmärkt.

Det var dock lite trixande med att få allt att kunna beräknas med den 16x16bits multiplikations algoritm (från Microchip) som jag använder så jag fick justera talen med en faktor på 2^4 (shifta vänster 4ggr) för att hålla allt inom lämpliga intervall. Låter kanske lite konstigt men genom detta håller sig alla tal från sensorn som heltal och min faktor är alltid mindre än ett och svaret i hundradelar representeras av 16bitar.

Sen en rättelse. I tidigare inlägg har jag skrivit att jag har en faktor mindre än noll. Det är fel (hjärnsläpp). Det skall naturligtvis stå mindre än 1!

Tack för hjälpen!

Re: Fix-punkts multiplikation i assembler

Postat: 7 februari 2009, 12:37:15
av sodjan
> Mitt projekt har en signal från en A/D på 12bitar....

OK, det var lite skillnad. Du skrev ju det hela så att det verkade som att det var en
riktig 16-bitars ADC som användes... :-)

Det där med "mindre än 0" funderade jag också en del på. :-)