Svenska ElektronikForumet

Funderade på hur man brukar koda i assembler för att göra om ett binärt värde till ett decimalt. Kommer även behöva göra numeriska beräkningar i PICen. Division etc. Har inte sysslat med något sånt någongång och tänkte att det kanske finns nån som kan ge en kort genomgång över hur man brukar fixa sånt, vilka metoder finns samt fördelar/nackdelar?

I mitt projekt råkar jag använda 16F628 eller en 16F84 PIC, men det är nog snarare ett allmänt sätt att lösa problemet jag söker, så det har nog inte så stor betydelse vilken PIC jag använder.

Jag kommer skriva ut det omräknade decimala värdet på en LCD skärm.

Tråd flyttad!.

Vet inte hur svårt det är att konventera asm mellan AVR & PIC.
Men här finns ett fungerande kodexempel för AVR.
http://elektronikforumet.com/forum/view ... hp?t=25041

I det här fallet använder jag en fuktsensor som ger värdet SO som ett binärt 12bitars värde. Detta kommer jag vilja göra om till relativ fuktighet via formeln.

RH = -4 + 0.0405*SO + (-2.8*10^-6)*SO^2

http://www.piclist.com/techref/microchi ... /index.htm

> Kommer även behöva göra numeriska beräkningar i PICen. Division etc.

Se till att du tänker till ordentligt !
Om du t.ex kan begränsa dina divisioner till nämnare som är
jämna potenser av 2 så underlättar det oerhört...

Ofta kan komplicerade beräkningar nästa försvinna helt genom smarta
val av skalning, mätintervall o.s.v.

Tack sodjan för länken. Tror jag kommer kunna få mycket inspiration från de exemplen som anges. Skall läsa på mig lite mer om exemplena och sen får jag se hur jag väljer att lösa problemet. Tänkte att jag skulle få lite allmänna lösningsförslag till omvandlingen, och de exemplena verkar vara precis det... Tackar!

Jag såg inte formeln innan jag postade förra inlägget...

Ett sätt att lösa just denna typ av problem är en table-lookup
kombinerat med en linjär interpolering mellan värderna.

En fråga, du för ett 12-bitars värde från givaren (d.v.s > 4.000 olika värden).
Men vilken upplösning behöver du på RH ? Ofta brukar det bara anges
som en heltals procentsats.

Jag skulle lägga in formeln i Excel oxh se hur RH "ser ut" för
de olika tänkbara invärderna på SO. Sedan försöka hitta en
modifierad formel som ger *tillräcklig* noggranhet och som går
att överföra till en table-lookup med interpolering.

Jag testade en av omvandlingarna till Deciamalt från Hex "Binary to BCD unpacked 16 bit to 5 digit" från sidan du länkade till och det fungerade på först försöket. Tackar för det. Jag kommer som mest att använda mig utav värden upp till ca 3000 så jag använder bara de 4 lägsta bitarna vid omvandlingen.

Grejen är att jag redan har en "table lookup" från databladet för sensorn. Och som det ser ut med mitt ögonmått så skulle maximalt fel om jag gör en linjär uppskattning bli ca 2%. Det kan kanske tyckas lite, men jag får se hur pass stort fel jag kommer acceptera.

Får se hur jag gör med omvandlingsfunktionerna. Om beräkningarna blir för avancerade kanske jag nöjer mig med den linjära funktionen.

EDIT: Kollade lite på de olika multipliceringsformlerna. Skulle gärna vilja kunna multiplicera 3digits*3digits. Men det kanske blir för omständigt. Skall se ifall jag får nöja mig med 2*2 för att det inte skall bli för mycket kod. Fast det fanns ju en bra 24*24bit omvandlare såg jag nu, den skall jag nog ta.

Värden upp till 3000 kräver väl alla 12 bitar?
Eller menar du siffror?

Du ska först göra beräkningarna, sedan kan du räkna om resultatet till BCD. Att räkna med BCD kanske går men är nog mindre effektivt.

Om slutresultatet är mellan 0 och 100% behövs det faktisk inte så många värden.

Som jag valt att göra nu och som verkar fungera så använder jag en multipliceringsfunktion som multiplicerar maximalt FFFF*FFFF=FFFE 0001. Sedan har jag en BCD omvandlare som kan göra om maximalt FFFFFF till BCD ca 16.700 000 vilket borde räcka gott och väl.

Dock så anges svaret som en 8bit binärt tal, vilket gör att jag måste göra om tex 21BCD till 2 och 1. Men det borde väl gå enkelt.

EDIT: Jag tror inte jag tänkte till riktigt. Svaret kommer ju ut som 21h vilket är uppdelat i 0010,0001 ju. Behöver inte ändras på! Bara att plocka ut delarna för sig... Ibland tänker jag inte...

Det bror ju lite på vad din "displayrutin" vill ha in för typ av värden. Ibland skriver man det som att inskickad data är i BCD för att det är enkelt att plocka ut siffra för siffra. Ibland vill man ha binärt värde in, t.ex för att maximera storleken på värdet. Då måste man å andra sidan dividera med 10-potenser för att få fram siffrorna.