Svenska ElektronikForumet

Hej!
Jag sitter med ett projekt som jag har kört fast på. Jag kör med float i några beräkningar som jag ska skicka till en lcd men jag lyckas inte göra om det till ascii. Jag har tidigare kört med char och unsigned long med en kod som ser ut så här: Programmet jag kör med är CC5X från B Knudsen Data. Jag har sökt på hans hemsida men inte lyckats hitta något. Är det någon som vet hur jag ska bete mig för att göra om float till ascii.

Mest standard måste ju vara att använda
snprintf(mybuffer,MYBUFFLEN,"%f",floati);

Om du har en float 1234.5 och delar med 1000, 100, 10, 1 och 0.1 i ordning
och sparar heltalssiffrorna och konverterar de till ASCII.
Borde inte det fungera?

det finns också en del olika ftoa() implementationer på nätet.

men oftast är det en dålig implementation om man behöver floats i µC, det tar en evinnerlig tid att räkna med..

Enklast är att antigen trunkera, avrunda eller gångra med ex.vis 10 och på så sätt spara som heltal.

Tro mig jag har också levt i den villfarelsen att man "måste" ha float

> Jag kör med float i några beräkningar

Som flera andra har antytt så är det sannolikt just där du har problemet.
Eftersom många använder float av misstag, så kanske du ska förklara
varför du tror att du måste ha float just i denna applikation. Om inte
annan så för att det är intressant i sig...

Hej!
Jo jag håller på med att göra digitalutrustning till en fräs. Jag ska med den se X, Y o Z axlarna. Där är det tänkt att den ska visa med på 100-dels mm. Så därför vill jag kunna göra om float till ASCII o visa det på en LCD.
Eller finns den något annat sätt att lösa det?

Men räkna då med 100-dels mm. Tex med en uint16 kan du då få 0,000 - 65,536 mm, uint32 0,000000000 - 4,294967296 m.

Den enda fördelen med float är det mycket stora dynamiska omfånget.
Det har du ju inte i ditt fall. Du har "bara" några sträckor som kan
vara max i storleksordningen en eller ett par meter som du vill beskriva
i 100-dels mm. Det är inte något speciellt stort omfång, en vanlig
integer med lämplig storlek fixar det enkelt.

> Tex med en uint16 kan du då få 0,000 - 65,536 mm, uint32 0,000000000 - 4,294967296 m.

Det blir väl : "Tex med en uint16 kan du då få 0,00 - 655,36 mm, uint32 0 - 42949,67296 m (alltså 4.2 *mil*) ?
I unit16 fallet har du räknat med 1000-dels mm och i det andra fallet vet jag inte hur du har tänkt...

En 24 bit (3 bytes) integer ger : 0 - 167,77216 m, vilket sannolikt räcker till de flesta fräsar...

24bit integer beräkningar är betydligt snabbare än motsvarande generella float beräkningar.

Nej huvudet befann sig nog på nått annat ställe vid tillfället. Men förhoppningsvis gick iaf principen fram.

Och en sak som oftast glöms bort: noggrannheten med float är inte nödvändigtvis speciellt bra! Med heltalsvärden i 1/100mm kan man, som tidigare skrivet av andra, dels snabba upp beräkningen och dels har man en känd noggrannhet. Om en float ta t.ex. 4 bytes går en del av dessa av till mantissan varför man förlorar upplösning, kan ju vara att 1 byte är mantissan varför resten av värdet ska vara i 3 bytes.

Som redan nämts, kolla upp ftoa (float to Ascii).
Att floats är långsamt är inte automatiskt ett problem som måste åtgärdas, det hänger naturligtvis på om applikationen behöver bli snabbare.