Att det inte är speciellt ovanligt betyder ju inte att den som Tomas använder har FPU.
Eller för att uttrycka det på ett annat sätt, vi saknar information för att råda...
Nej, processorn har ingen FPU.
Hade den haft det, hade det varit enkelt.
Som Sodjan skrev, jag vill undvika och länka in ett flyttalsbibliotek.
Processorn är en PIC32MX, och att byta till en med flyttal är inte helt enkelt, då det kräver omdesign av kort samt byte av utvecklingsverktyg.
Och det finns inte på kartan, dessutom så skall det kunna fungera i befintlig utrustning.
samt det faktum att jag slått i taket med programminne på nuvarande.
När jag byter, i framtiden, så blir det väldigt radikalt, med en SOC i stället.
Nu ligger iofs framtiden nära, då jag jobbar med en ny SoC-baserad version.
Läste du inte vad jag skrev?
Det är i dag en omöjlighet att byta uC, dessutom skall det vara kompatibelt med existerande system, i framtiden blir det naturligtvis en uC med FPU, men i existerande system finns det ingen FPU, och jag vill inte länka in ett tungt flyttals-bibliotek.
Jag tror inte du har missat det, men finns kanske samma värde att läsa på annan modbustyp?
Har varit för att samma värde kan finnas över de olika modbustyperna så att säga.
Vad jag hittat hittills är 0.0000 - 22000000,0000
Vissa kan naturligtvis avrundas, men inte alla.
Effektfaktorn till exempel, ligger mellan 0.00 - 1,00
Det är ju väldigt enkelt att filtrera bort ovidkommande tal genom att kontrollera exponenten innan man börjar omvandla talet.
T.ex. om max inläst värde får vara 65535 så returnerar man error om exp > 243.
Om exp < 127 så betyder det att talet är mindre än 1 och då kan resultatet eventuellt avrundas till noll.
Effektfaktorn till exempel, ligger mellan 0.00 - 1,00
Då kan man ju addera t.ex. 16 till exp så får man ju ut 0 - 65536 med baronens kod. (det kan ju "opt" användas till... sätt opt till 16 och gör exp += opt; i början... ( efter raden "exp = exp >> 23;")
och anropa funktionen med resultat = float2int(data.x, 16);
Avrundning genom att addera 0.5 före trunkering har den obehagliga
egenskapen att den oftare avrundar uppåt än nedåt, vilket innebär
att signalens medelvärde ökar efter avrundning. Speciellt illa är det
om man använder den för negativa tal också. Till exempel kommer
då en ren AC-signal att få en positiv DC-komponent efter avrundning,
och det finns applikationer där det inte är bra.
Enbart trunkering har samma effekt, medelvärdet minskar, eftersom
man alltid tar bort bitar med positiv vikt (vi pratar uteslutande tvåkomplement).
Default i IEEE-754 flyttalsaritmetik är att avrunda till närmsta jämna
heltal. Detta är en enkel och utmärkt metod som inte ger någon bias.
Man kan implementera den genom att ta beslut på de två mest
signifikanta bitarna som trunkeras bort.
Om det är viktigt att det blir rätt är det en bra ide' att använda beprövad kod.
Om man tittar på 87.00 som var första talet som nämndes.
I IEEE-754 format är 2^6 * (1 + 1/4 + 1/16 + 1/32 + 1/64) = 87.0 (slå gärna på räknaren.)
Följer samma som koden som visats i tråden redan så inget konstigt.
Det man kan göra är att ta mantissans första 6 bittar och lägga till 2^6.
Mantissan för detta talet är 01011100000000000000000. Såååå