Należy pamiętać, że jednostki FPU w tych mikrokontrolerach to często jednostki FPU o pojedynczej precyzji.Zmiennoprzecinkowa pojedyncza precyzja ma tylko 24-bitową mantysę (z ukrytym MSB), więc w niektórych przypadkach możesz uzyskać lepszą precyzję z 32-bitowych liczb całkowitych.

Pracowałem z użyciem arytmetyki stałoprzecinkowej, aw sytuacjach, w których dane mają ograniczony zakres dynamiczny, można osiągnąć taką samą precyzję jak zmiennoprzecinkowa pojedynczej precyzji przy użyciu 32-bitowego stałego punktu z poprawą o około rząd wielkościw czasie realizacji.Widziałem również, że kompilator wciąga spore obciążenie biblioteki dla FPU.

Jeśli kupujesz procesor ze sprzętową jednostką FPU, nie masz takich samych obaw o precyzję *, zachowanie ponownego wejścia itp. Śmiało i używaj ich!

Jednak kilka przemyśleń:

• Możesz wziąć pod uwagę, że procesor może wyłączyć (duży) FPU, gdy nie jest używany, więc sprawdź, czy uruchamianie procedur FP oszczędza energię (jeśli Ci na tym zależy), zamiast robić to w oprogramowaniu.

• W zależności od implementacji, FPU może również mieć różne rejestry w rdzeniu - czasami kompilatory mogą sprytnie je wykorzystać.

• Nie używaj FPU jako podpórki do złego projektu oprogramowania.Na przykład, czy mógłbyś zrobić to samo ze stałym punktem i zamiast tego użyć normalnego rdzenia?

(* FPU powinno być zgodne z daną implementacją standardu, więc pamiętaj o wszelkich wynikających z tego ograniczeniach.)

Niektóre z obaw nadal obowiązują

• Arytmetyka zmiennoprzecinkowa jest z natury bardziej intensywna obliczeniowo niż liczba całkowita.Ale w przypadku jednostki z punktem flotacji prawdopodobnie już tego nie zauważysz, może kilka dodatkowych cykli procesora lub trochę większe zużycie energii.
• Operacje są atomowe, więc obawy zniknęły.
• problem precyzji / zaokrąglania / porównania nadal występuje, do dokładnie takiej samej wielkości, jak w obliczeniach programowych.

Szczególnie ten drugi może powodować bardzo nieprzyjemne problemy i zmusić do napisania nieintuicyjnego kodu, np.zawsze porównując z zakresem, nigdy nie testując równości względem ustalonej wartości.

I pamiętaj, że zmiennoprzecinkowa pojedyncza precyzja ma tylko rozdzielczość 23 bitów, więc może być konieczne zastąpienie 32-bitowej liczby całkowitej zmiennoprzecinkową podwójną precyzją.

Obliczenia są często dobre, jeśli masz FPU, a kompromisy są łatwe do zrozumienia.

Ale uważaj na wynik.Jeśli masz coś takiego jak biblioteka C, byłbyś zdumiony złożonością właściwą dla printf ("% 0.6g", x); Widziałem biblioteki, które używają malloc() wewnątrz printf () , a to nie jest coś, co chciałbyś w mikrokontrolerze.

Szczerze mówiąc, jest to rodzaj mikrooptymalizacji, którą powinieneś wykonywać dopiero po uzyskaniu w pełni działającej bazy kodu.Niektóre MCU mają również problemy z dzieleniem, nawet w przypadku liczb całkowitych.Więc zrobienie czegoś takiego jak "pomnóż fp przez 100, zrób jakąś manipulację, podziel przez 100" może zająć znacznie więcej czasu niż tylko manipulowanie zmienną.

Tutaj pojawia się profilowanie, musisz wybrać swoje bitwy, nie ma jednej odpowiedzi.Gdy masz już działającą bazę kodu, możesz zidentyfikować wąskie gardła i dokonać selektywnej optymalizacji.Unikanie czegoś w postaci ogólnej instrukcji prowadzi do mikrooptymalizacji, które wymagają więcej czasu na kodowanie, niż w rzeczywistości oszczędzają.Optymalizacja ruchów zmiennoprzecinkowych z procedury o niskim priorytecie, która jest uruchamiana raz na godzinę, jest bezużyteczna, natomiast optymalizacja pływaków w przypadku trudnych zadań jest przydatna.

Zasadniczo nie musisz tego unikać, jeśli masz FPU, a twój RTOS obsługuje również przełączanie kontekstu FPU.Problem z precyzją nadal istnieje, jeśli masz FPU, czy nie.Możesz również swobodnie używać zmiennoprzecinkowych bez FPU, jeśli masz odpowiednią wydajność - sporadyczny zapis debugowania zmiennej zmiennoprzecinkowej jest po prostu dobry na Cortex-M3 bez FPU.Ale oczywiście na ograniczonym 8-bitowym MCU z małą pamięcią, obciążenie związane z użyciem nawet jednej operacji zmiennoprzecinkowej może przynieść wiele setek bajtów kodu biblioteki typu soft float, więc czasami używanie liczb zmiennoprzecinkowych nie ma sensu.

Wgdy nie używać zmiennoprzecinkowych

Pierwszą rzeczą, którą należy sobie uświadomić, jest to, że zmiennoprzecinkowy nie oznacza "Potrzebuję liczb dziesiętnych". To jest sytuacja, w której około 95% wszystkich potencjalnych programistów wbudowanych niewłaściwie wykorzystujących zmiennoprzecinkowe zawodzi.

Lekarstwem na to niedowierzanie jest uświadomienie sobie, że wewnętrznie program powinien używać jednostki, która ma sens dla MCU , a nie takiej, która ma sens dla ludzi.

Na przykład, jeśli mierzysz prąd w mA za pomocą 10-bitowego przetwornika ADC na chipie, wygodną jednostką do wykorzystania w oprogramowaniu są „stałe, surowe wartości ADC od 0 do 1024”. W programowaniu w C oznacza to uint16_t lub opcjonalnie uint_fast16_t . Nie int i na pewno nie float .

Używanie jednostki mA w obliczeniach oprogramowania sprzętowego jest wygodne tylko dla mózgu programisty, na wypadek gdyby nie mógł obsługiwać abstrakcyjnych jednostek. Jest to jednak niewygodne dla programu, ponieważ oznacza, że ​​trzeba przeskalować wszystkie odczyty i potencjalnie dodać niedokładność zaokrągleń. Dodatkowo kod skalujący to po prostu nadmiar narzutu. Prawdopodobnie będzie to obejmować podział, który może być bolesny dla wielu MCU.

Tak, odczytujesz prąd w mA. Ale jeśli faktycznie nie musisz drukować tego prądu na wyświetlaczu lub czymś dla człowieka, jednostka ta nie jest w rzeczywistości pomocna. Wykonaj ponowne skalowanie mA na długopisie i papierze podczas projektowania algorytmu, zamiast przeciągać go do oprogramowania układowego.

Wiedy używa się zmiennoprzecinkowych

• Jeśli Twój MCU ma FPU i faktycznie potrzebujesz zaawansowanej matematyki , powinieneś użyć liczb zmiennoprzecinkowych. W przeciwnym razie nie powinieneś.

„Zaawansowana matematyka” niekoniecznie oznacza zaawansowaną z punktu widzenia programisty, ale z punktu widzenia oprogramowania.„Zaawansowane” obejmuje takie rzeczy, jak pierwiastki kwadratowe, geometria lub trygonometria, ogólnie użycie math.h , liczby zespolone, matematykę sztucznej inteligencji itp. Rzeczy, które byłyby trudne do wdrożenia w punkcie stałym.

• Wykluczyłbym operacje nieatomowe z listy powodów, ponieważ twoje sposoby obsługi innych złożonych struktur można również zastosować do operacji zmiennoprzecinkowych.

• Chciałbym również wykluczyć wymaganą moc obliczeniową z listy powodów, ponieważ jest to wysoce zależne od aplikacji i procesora.

Skoncentrujmy się na „nieoczywistych” problemach powodowanych przez zmienną precyzję float

• Najbardziej podstawową z nich jest to, że arytmetyka FP nie jest asocjacyjna, (a + b) + c nie jest równe a + (b + c). Wyobraź sobie a = 1, b = -1, c = 1e-20. Brzmi nieszkodliwie, ale wyobraź sobie, że aplikacja używa skończonego filtru impulsów i uruchamiasz przypadek testowy, który powinien być dokładnie zerowy

• dla mnie drugim powodem jest fakt, że operacje na liczbach całkowitych i stałych przecinkach mają przepełnienie w zakresie, którego oczekuję (ok, domyślnie nie jest włączone w C). na przykład W przypadku liczb zmiennoprzecinkowych integrator może łatwo uciec do bardzo dużych wartości, nie zauważając nikogo ...

Jak wiele rzeczy, zależy to od twojego przypadku użycia.

Specjalny algorytm liczb całkowitych może być bardziej wydajny (np. w przypadku mnożenia), jeśli znasz dozwolony zakres wartości wejściowych.Gdy te wartości się rozszerzają, wszystko, co zakodowałeś, zdegeneruje się w zmiennoprzecinkowe pomnożenie bez korzyści sprzętu.

Możliwe jest radzenie sobie z powolnymi obliczeniami, które mają trudne do określenia czasy w systemie wbudowanym, uruchamiając je w pętli w tle lub nawet mając różne procesory, np.kontrola i obliczenia.