Hoe converteer je 0x4C4C00 naar 5.00?

Ehr, met een 24-bit naar BCD conversie routine??? Zonder context is dit een vrij nutteloos topic.

Ik heb 0x4C4C00 staan in 3 registers, dat moet 5.00 gaan worden op een display.
Ja 24 bit naar BCD, maar kost dat niet enorm veel omzettijd? (microcontroller gebied 4-20 MIPS)
Is er geen snellere manier mogelijk?

hmm ik zou zelf toch even een shift operatie doen en dan maal 2.56 doen. Dan kun je de rest ditchen achter de komma, maar past het in een 16 bits getal, je bent dus dan iig 1 byte kwijt.

maar moet je wel floating point berekeningen beetje rap aankunnen.in een Atmega gaat dit niet geweldig...

beetje context is wel makkelijk hier idd.

Maw 4C4C * FF?

houd je hetzelfde over.. netto resultaat 0...verlies enkele mipsen die je niet kunt missen

je kunt niet vermenigvuldigen met een floating point getal...
en gewoon delen die hap? dus gewoon door 10.000 delen?

volgens mij gaat dat relatief snel

die . moet je dan zelf maar plaatsen. ik probeer in uC's altijd floats te vermeiden, daar worden ze rete traag van...

Ja floating point belast veel (veel instructies), gelukkig zitten er MUL instructies in vele microcrontrollers.
4C4C00 / FF = 4C4C.

ja maar 0x4C4C = 19532

maak daar maar eens 5 van..

overigens is 0x4C4C00 >> 16 = 0x4C4C

scheelt ook weer rekentijd (voorzover je optimizer dit neit doet voor je)

maar hetzeflde probleem..

gewoon 0x4C4C00 / 10000 doen. Werkt denk ik het snelste...

deze instructie spaarde ZEEËN aan tijd uit:

value = ((((141*ucur*ucur)/1000)*ucur)/1000*ucur)/10000+(((1077*ucur*ucur)/1000)*ucur)/100000+(2556*ucur*ucur)/1000000+(367*ucur)/1000+102;

heb redelijk wat moeten vogelen om de scaling op pijl te houden.. Maar werkte prima... Achteraf had ik beter door 255 kunnen delen met een bit shift operatie, maar das altijd achteraf...

overigens is dit een 4e graads polynoom benadering van een bepaalde specifieke sensor in een regelcircuit....
er staat feitelijk zoiets als:
141*X^4 + 1077*X^3 + 2556*X^2 + 367*X + 102

overigens had dit zoiets moeten zijn: 1,41 X^4 + 10,77 X^3 + 25,56 X^2 + 3,67X^2 + 1,02 ofzo.

echter door alles producten te vermenigvuldigen en later de komma later plaatsen is het ook opgelost. ik wist immers dat de uitgang 100 te groot was...

[Bericht gewijzigd door High met Henk op woensdag 4 maart 2009 14:42:18 (18%)]

Heb even zitten puzzelen, maar delen door 9984 (0x2700) geeft precies 0x1F4 (500).
En 9984 is precies 39*256. (/256 is dus 8x shift right)
39/2 wordt dan weer lastiger, dan moet je eerst weer maal 10 doen met een MUL, dan 390/2=195, en dan weer, dit een aantal keer herhalen.
Lijkt erop dat dit het gaat worden, want een MUL instructie uitvoeren duurt kort en shift right ook.
En daarna een simpele BCD omzetting met een klein getal dat overblijft.

(39/2) == (39 >> 1)
??

Ik probeer die /10000 zo kort mogelijk te maken kwa instructies.
39*256=9984.
Bedoelde dit.
0x4C4C / 0x27 (19532 / 39) Dan gaat het x10 weer simpeler.
195320 / 390, want 390 kan ook door 2. Maar dan zit je op 97660 / 195, etc. Die teller moet ik op 0 zien te krijgen (dan in de noemer 500 over) zonder teveel verlies in de LSB. (gaat telkens 0,5 af als je telkens grof /2 blijft delen, uiteindelijk verlies je teveel nauwkeurigheid in het eindresultaat.

Ik zie het probleem niet echt... Ik neem aan dat je uitlezing niet meer dan, zeg, 10 keer per seconde geupdate wordt, en dan is een integer deling door 10000 toch niet zo'n grote ramp?

Ja heb nu maar een standaard 24 /16 bit unsigned routine gepakt en zelf een BCD routinetje gebouwd.