Du bör komma ihåg att FPU: erna på dessa mikrokontroller ofta bara är FPU: er med en precision.Enkel precisionsflytpunkt har bara en 24-bitars mantissa (med den dolda MSB) så att du i vissa fall kan få bättre precision från 32-bitars heltal.

Jag har jobbat med att använda fastpunktsberäkning, och för situationer där data har ett begränsat dynamiskt område kan du uppnå samma precision som enpunktsflytpunkt med 32-bitars fixpunkt med ungefär en storleksordningi exekveringstid.Jag har också sett att kompilatorn drar in en hel del bibliotekskostnader för FPU.

Om du köper en processor med en hårdvarufPU har du inte samma problem med precision *, återupptagande beteende osv. Fortsätt och använd dem!

Ett par tankar dock:

• Du kan tänka dig att processorn kan stänga av den (stora) FPU när den inte används, så kontrollera att du kör dina FP-rutiner sparar du kraft (om du bryr dig om det) över att göra det i programvara.

• Beroende på implementeringen kan FPU också ha olika register i kärnan - ibland kan kompilatorer använda dessa smart.

• Använd inte FPU som en krycka för dålig firmwaredesign.Kan du till exempel göra samma sak med fast punkt och använda den vanliga kärnan istället?

(* FPU: n ska överensstämma med en given standardimplementering, så var medveten om eventuella begränsningar som uppstår på grund av detta.)

Några av bekymmerna gäller fortfarande.

• Flytpunktsräkning är i sig mer beräkningskrävande än heltal.Men med en flottpunktsenhet kommer du förmodligen inte att märka det längre, kanske några extra CPU-cykler eller lite mer strömförbrukning.
• Operationerna är atomära, så att oro är borta.
• Precisions- / avrundnings- / jämförelsesproblemet finns kvar, i exakt samma mängd som i programvaruberäkning.

Särskilt den senare kan orsaka mycket otäcka problem och tvinga dig att skriva icke-intuitiv kod, t.ex.alltid jämföra med ett intervall, aldrig testa jämlikhet mot ett fast värde.

Och kom ihåg att en flottör med en precision bara har 23 bitars upplösning, så du kan behöva ersätta ett 32-bitars heltal med ett dubbelt precisionsflott.

Beräkningar är ofta bra om du har FPU och avvägningarna är lätta att förstå.

Men se upp för produktionen.Om du har något som C-biblioteket skulle du bli förvånad över komplexiteten i printf ("% 0.6g", x); Jag har sett bibliotek som använde malloc() inuti printf () , och det är inte den typen av saker du vill ha i en mikrokontroller.

Ärligt talat är detta en typ av mikrooptimering som du bara bör göra efter du har en fungerande kodbas.Vissa MCU har problem med division också, även med heltal.Så att göra något som "multiplicera fp med 100, gör lite manipulation, dela med 100" kan ta mycket mer tid än att bara manipulera flottören.

Det är här profileringen kommer in, du måste välja dina strider, det finns inget svar.När du har en fungerande kodbas kan du identifiera flaskhalsar och optimera selektivt.Att undvika något som ett filtuttryck leder till mikrooptimeringar som tar mer tid att koda än de faktiskt sparar.Det är värdelöst att optimera ut floats från en rutin med låg prioritet som körs en gång i timmen, medan det är användbart att optimera floats för en tung uppgift.

I grund och botten inget behov att undvika om du har en FPU, och din RTOS stöder också kontextväxling av FPU.Precisionsfrågan finns fortfarande om du har en FPU eller inte.Du kan också använda flytpunkt utan FPU om du har prestanda att göra det - enstaka felsökning av float-variabel är bara bra på en FPU-mindre Cortex-M3.Men uppenbarligen på en begränsad 8-bitars MCU med litet minne kan kostnaden för att använda till och med en enda flottöroperation få in många hundra byte med mjukt flottörbibliotek, så ibland är det inte meningsfullt att använda flottörer.

WNär man inte använder flytande punkt

Det första man behöver inse är att flytande punkt betyder inte betyder "Jag behöver decimaler". Det är här som cirka 95% av alla inbäddade programmerare missbrukar flytande punkt misslyckas.

Kuren för den misstro är att inse att internt bör programmet använda en enhet som är vettigt för MCU att använda, inte en som är meningsfull för människor.

Om du till exempel mäter ström i mA med en 10-bitars ADC på chipet, är den praktiska enheten att använda i "fasta råa ADC-värden från 0 till 1024". I C-programmering betyder det en uint16_t eller eventuellt en uint_fast16_t . Inte en int och absolut inte en float .

Att använda enheten mA inuti firmware-beräkningar är bara bekvämt för den mänskliga programmerarens hjärna, om den inte kan hantera abstrakta enheter. Men det är obekvämt för programmet, för det betyder att du måste skala om alla avläsningar till och eventuellt lägga till avrundningsfelaktigheter när du gör det. Plus skalningskoden är bara uppblåst. Och det kommer sannolikt att inkludera delning, vilket kan vara smärtsamt för många MCU: er.

Ja, du läser strömmen i mA. Men om du inte behöver skriva ut strömmen på en skärm eller något till en mänsklig användare, är den enheten faktiskt inte till hjälp. Gör mA-skalning på penna och papper medan du utformar algoritmen istället för att dra den till din firmware.

W När du använder flytande punkt

• Om din MCU har en FPU och du faktiskt behöver göra avancerad matematik bör du använda flytande punkt. Annars bör du inte.

"Avancerad matematik" betyder inte nödvändigtvis avancerad ur programmerarens perspektiv, utan ur programvarans perspektiv."Advanced" inkluderar saker som kvadratrötter, geometri eller trigonometri, användning av matematik.h i allmänhet, komplexa siffror, AI-matematik etc. Saker som skulle vara smärtsamma att implementera i fast punkt.

• Jag skulle utesluta icke-atomära operationer från listan över skäl eftersom dina sätt att hantera andra komplexa strukturer också kan tillämpas på flottöroperationer.

• Jag skulle också utesluta den beräkningsstyrka som behövs från listan över skäl eftersom det är mycket applikations- och processorspecifikt.

Låt oss fokusera på de "icke uppenbara" problemen som orsakas av variationen i flottörprecisionen

• Det mest grundläggande är att FP-aritmetik är icke-associerande, (a + b) + c är inte lika med a + (b + c). Föreställ dig a = 1, b = -1, c = 1e-20. Låter ofarligt, men tänk dig att din applikation använder ett ändligt impulsfilter och du kör ett testfall som antar vara exakt noll

• för mig är den andra anledningen det faktum att heltal och fasta kommaoperationer har ett överflöde i det intervall som jag förväntar mig (ok, inte aktiverat som standard i C). t.ex. I flytande punkt kan en integrator lätt fly till mycket stora värden utan att någon märker ...

Liksom många saker beror det på ditt användningsfall.

En skräddarsydd heltalalgoritm kan vara effektivare (t.ex. för en multiplicering) om du känner till det tillåtna intervallet för ingångsvärden.När dessa värden vidgas kommer allt du har kodat att degenereras till en flytande punkt multipliceras utan att dra nytta av hårdvara.

Det är möjligt att hantera långsamma beräkningar som har svårt att bestämma tidpunkter på ett inbäddat system genom att köra dem i en bakgrundsslinga, eller till och med ha olika processorer för t.ex.kontroll och beräkning.