Svenska ElektronikForumet

Får inte min ATMEGA32 att göra som jag vill.

Någon som är lite händig på C/AVR kan kanske säga mig om just detta ser rätt ut..

Några rader ryckta ur mitt program.

> Får inte min ATMEGA32 att göra som jag vill...

Vad vill du och vad händer ?

Har ett program som behöver spara ett float i eeprom. Har fått allt att fungera med heltal men när jag bytt till float blir något mindre bra, då händer egentligen ingenting. Vill försäkra mig om att just läs/skriv till eeprom fungerar som det skall..

Dessa rader har fungerat bra med heltal..
Det jag byggt är längdmätning till en processor (mäta längden på trädstammar)
Jag har en "rotary encoder" 1000 pulser/varv, ATMega32 (japp, overkill!) och tre sjusegments leddisplayer.

Det blir inte bättre med ".....sizeof(edivk)...." ?

Sen kanske en union mellan edivk och en vanlig byte array skulle fungera ?
(D.v.s du använder byte arrayen till/från EEPROM'er).

Slutligen så tror jag att mycket blir enklare om du undviker float helt.
Det behövs knappast för att räkna längder på trädstammar.

gånga ditt tal med 10 alt 100 och skippa float om inte annat.

Jo jag har försökt strunta i float genom att göra som danielr112 skriver. Men han vägrade fungera ändå. Variabeln divk skulle behövt vara 16.66666667 har jag för mig när jag testade, så jag multiplicerade med 10, 100, 1000 osv. Men resultatet blev ändå det som motsvarade ett divk = 16. Höll på bli tokig då så jag tänkte köra med float istället..
Nu är jag tokig...

Edit: Det blev inte bättre med "Det blir inte bättre med ".....sizeof(edivk)...." "

> Variabeln divk skulle behövt vara 16.66666667....

Låter helt otroligt! Det skulle betyda att du behöver en upplösning
på bara några enstaka "my" på ett 20 meters träd. Det kan inte vara rimligt.
Behöver du verkligen finare upplösning än, säg, hela millimeter på en stock ?

För att göra det lite enklare och slippa tänka så mycket på decimalerna
kan du tänka dig att alla värden är i antal hela millimeter. Sedan får du ha
16, 24 eller 32 bitars int's beroende på vilket intervall du behöver kunna hantera.
Alla beräkningar göra med heltalsberäkningar. Eventuell konvertering till meter
(eller vad du nu vill ha) kan vänta tills värdet (längden) ska presenteras på något sätt.
Eller konvertering och konvertering, det handlar ju bara om att stoppa in ett
komma på rätt ställa när man *visar* värdet...

Sen kan/bör man se över givare o.s.v. Ofta kan man se till att det man får in
blir enkelt att hantera i vidare beräkningar. Inte alltid, men ofta...

> Jag har en "rotary encoder" 1000 pulser/varv,

Som har ett hjul som snurrar mot stammen i stammens längdriktning ?
Du skulle t.ex kunna fixa så att ett varv blir en "bra" sträcka genom att
se till att använda ett hjul med "rätt" omkrets...

16 2/3 blir ju det samma som att multiplicera med 50 och sedan dela med 3 eller hur?

Och du vet att de där eeprom_write_block() och eeprom_read_block() faktiskt kan skriva och läsa block korrekt?
Om inte, testa först med en enkel "unsigned char" att du kan läsa ut samma värde som du skrev dit.

Sodjan: Nu var det inte så att divk behövde vara 16.66666667, utan det var något liknande den skulle varit om det fungerade som jag tänkt, dvs inte "bara" heltalet 16. Displayen kommer enbart visa hela cm..
Men jag vill ha möjlighet att kalibrera mätaren, så en passande givare med ett hjul med rätt omkrets vill jag inte ha. Det på grund av att hjulet går lite olika långt beroende på utseendet på barken, tex grov tallbark eller en slät björk. Även mellan frusen och ofrusen tall skall det skilja en del då mäthjulet sjunker in olika långt i barken.

Ska göra ett nytt försök nu.
Tack för alla tipsen! Men kom gärna med fler om ni kommer på något..

Får jag inte till det nu så tar jag ännu en vända med heltalen tror jag..

Hur som helst är det en mycket dålig idé med float!

Man bör, i µC-sammanhang, använda heltal så långt det går, man kan fint multiplicera med ett stort heltal och sedan dela med en fast faktor, t.ex. multiplicera med 16667 och dela resultatet med 1000. Float ger ju knappast någon speciell noggrannhet alls, du kan inte förvänta dig att 16,6666666666666667 sparas som just det tal, det kommer att bli närmsta som kan passas in med det antal bits som en float har.

Precis, fördelen med float är ju inte noggrannheten utan att det klarar ett större intervall.

Annars är det ju enklare att köra med "fixed".

Float handlar ju om att du sparar mantissa plus exponent. Men om exponenten hela tiden är samma (t.ex. att talen du sparar är nånstans mellan 4 och 8) så ger float inget mervärde.

Istället för att spara 0,412345678*10^1 så sparar du 412345678 (fast egentligen bör du välja att multiplicera med jämna multiplar av 2 istället för 10).

http://en.wikipedia.org/wiki/Binary_scaling hette det visst.

Notera slutklämmen: "Although floating point has taken over to a large degree, where speed and extra accuracy are required, binary scaling is faster and more accurate."

Det ger alltså bättre noggrannhet OCH snabbare exekvering att göra så. Skillnaden är främst att det kräver lite mer tänkande när man kodar.

Aldrig hört beteckningen "binary scaling". Har alltid kallat metoden "fixed point".
Fixed point är inte snabbare per definition. Det beror ju helt på processorn. En processor kan ju ha en flyttalsdel som är extremt snabb (som i dagens PC'er). Dessutom har en flyttalsprocessor ofta många andra nyttiga beräkninginstruktioner, som sin, cos, osv.

"Although floating point has taken over to a large degree, where speed and extra accuracy are required, binary scaling is faster and more accurate."

Den där meningen är ju total svada, eller så är det jag som inte kan engelska.

"Även fast flyttal tagit över i stor utsträckning, där hastighet och hög noggrannhet krävs, så är binary scaling ändå snabbare och mer noggrann."

Det är ju lite samma sak som jag skrev tidigare: Fördelen med flyttal är ett större talomfång. Men 32 bitars fixed point har ju fler decimaler än 32 bitars flyttal (eftersom flyttalet använder några bitar för exponenten).


Binary scaling är som jag förstår det ett sätt att skapa fixed point. "Äkta" fixed point har man så att säga stöd av direkt i processorn, men binary scaling är ett sätt att använda processorns heltalsaritmetik för decimalbearbetning.

Binary scaling kan ju som sagt var göras med andra faktorer än bas 2, och då blir det inte längre samma sak som "fixed point".

Så "fixed point" är binary scaling med en faktor med bas 2.

Tänkte till lite å la till 0000 på fyra ställen i mitt program så fungerade det som det skulle, med heltal..

Anledningen till att jag valde float var att JAG TRODDE att det var enklare, bara att göra som man skulle gjort med miniräknaren helt enkelt. Men så enkelt var det ju inte..

Men det hade ju varit intressant att veta varför float inte ville fungera, men det får bli en annan gång.. Nu skall jag svarva en hållare för givaren..