Allokering utav minne - Acceptabelt inom inbyggda system?

[Swech]

När man har en generell dator som skall kunna utföra godtycklig uppgift
så är malloc nödvändigt.
När man bygger ett embedded system som har ett begränsat eller kanske bara en uppgift så tillför en malloc ingenting

Jämför ett entertainmentsystem i en bil som ena minuten visar en tecknad film, andra minuten en GPS karta, Motordata o.s.v
med ett styrsystem som styr trafikljus i en korsning.
Det är inte vettigt att allokera 3 bytes för röd / gul / grönt ljus eftersom uppgiften att hantera ljusen inte ändras
och det vore katastrof om korsningen slocknar för att systemet plötsligt
inte har minne för att hantera ljusen.

Embedded måste klara sina begränsade uppgifter med de resurser som finns till hands.
Det kommer sällan okända nya uppgifter som kräver ett okänt antal nya resurser samtidigt som någon / några
gamla uppgifter skulle försvinna.

Swech

[TomasL]

Ofta finns ingen flyttalsprocessor, så därför undviker man flyttal.
Istället så använder man heltal i med processorns nativa ordbredd, vissa processorer hanterar både 32 och 16 bitars tal lika effektivt andra gör det inte.

Vissa processorer har skuggregister vilket gör att task-switchning går snabbt andra måste skicka allt på stacken.
Vissa processorer har DMA, andra har det inte.

Så det är viktigt att förstå plattformens begränsningar (och fördelar) och skriva program utifrån det.

[DanielM]

Det rör sig inte om HUR man allokerar minnet men om att man inte OMALLOKERAR.

Detta betyder att man antingen allokerar direkt i källkoden ELLER allokerar EN gång dynamisk i starten av programmet och sedan är det så.

Att du inte förstår vad det rör sig om är en indikation på att du saknar en de vetande som KOMMER att ge dig problem framåtriktat.

Grejen med dynamisk allokering och släpp av minnet är att minnet fragmenteras med tiden och efter en viss drifttid går det inte att allokera rätt storlek varfor systemet MÅSTE ha handhavande av allokeringsfel och det betyder också att systemet ju inte fungerar rätt när allokeringen misslyckats.

Eller i klartext: med dynamisk allokering och deallokering bygger du in en felkälla i systemet. Om det är vad du önskar är det OK för mig, personligt vill jag helst göra stabila system.

Jag förstår inte djupets teori och det gör inte du heller. Det räcker bara att man får rekommendationer från erfarna att si och så ska man göra. Jag lyssnar på er och jag använder inte malloc eller calloc när det kommer till C-programmering. Tror jag har upprepat detta några gånger.

När man jobbar med embedded, så jobbar man ofta direkt mot "Bare Metall" dvs du har inget operativsystem som fixar saker för dig, du har ingen runtime som hanterar garbage etc.
Du har dessutom kraftiga restriktioner i minne och processorkraft. Du har alltså ingen 24-kärning processor som snurrar i 6GHz med 64GB ram.

Det innebär att, för att få bra fungerande och effektiva program, så måste man förstå hur plattformen fungerar, och hur applikationen fungerar på plattformen.
Bara att gilla läget, man måste läsa in sig på plattformen i fråga, och förstå hur det fungerar och hur det inte fungerar.
Finns inga genvägar där.

Jag vet att man programmerar direkt mot kisel och jag vet man har lite minne att arbeta mot. Har en Nucleo hemma som jag pysslar på med lite. Enkel att komma igång med. ST har verkligen gjort det snabbt och enkelt att hoppa in i processorvärlden om man använder deras produkter. Lika väl som Spring Framework har lanserat Spring Boot som slår ut alla sina konkurrenter då man kan sätta oerfarna bakom ratten.

Ofta finns ingen flyttalsprocessor, så därför undviker man flyttal.
Istället så använder man heltal i med processorns nativa ordbredd, vissa processorer hanterar både 32 och 16 bitars tal lika effektivt andra gör det inte.

Vissa processorer har skuggregister vilket gör att task-switchning går snabbt andra måste skicka allt på stacken.
Vissa processorer har DMA, andra har det inte.

Så det är viktigt att förstå plattformens begränsningar (och fördelar) och skriva program utifrån det.

ST har FPU. Jag är behov utav flyttal då jag utför numeriska beräkningar på en mikroprocessor.
Nu är jag klar med min rekursiva algoritm som estimerar en modell från mätatat \(u(t), y(t)\) och hittar insignalerna.

Inte för att skryta, men jag är väldigt stolt över arbetet. Regulatormodell som har följande:

• Systemidentifiering
• Modellbygge
• Prediktion
• Integration
• Filtrering

Dessutom:

• Adaptiv filtrering
• Adaptiv reglering
• Flervariabel
• Självinställande

Allt detta utan att använda malloc, calloc eller några avancerade funktionaliteter i C. Allt är call-by-reference för att spara minne.

[TomasL]

Går alldeles utmärkt att göra numeriska beräkningar utan att använda flyttal.

[DanielM]

Du menar att om jag byter ut alla floats mot ints så kommer jag ändå få samma resultat i slutändan om jag skalar om dessa?
Låt oss säga att vi leker med att sampla ADC data med upplösningen 12 bit. När jag har fått fram mitt resultat så är det bara heltal. Hur gör jag med dessa heltal då för att räkna om dessa till floats?

[Icecap]

Kanske inte nödvändigtvis till int's, variabeltypen ska vara stor nog till att hålla högsta talet som kan komma under uträkningarna.

Men iaf. beror det ju på hur du använder slutresultatet. Om du t.ex. styr en värmeenhet kan du styra den på ett visst sätt, låt oss säga att du kan ställa den i 100 steg mellan 0% och 100%, alltså 0,1% per steg.

Då behöver du bara att skala slutresultatet till att passa 0-1000 och då den reglering ändå är i heltalssteg är det ju bara att ta slutresultatet och multiplicera/dividera med en faktor och saken är biff.

Men det är klart, jag förstår ju inte detta enligt dig... så jag har nog inte fattat detta heller.

[TomasL]

Vi kör 24 bits upplösning på ADC och heltalsaritmetik.

[DanielM]

Kanske inte nödvändigtvis till int's, variabeltypen ska vara stor nog till att hålla högsta talet som kan komma under uträkningarna.

Men iaf. beror det ju på hur du använder slutresultatet. Om du t.ex. styr en värmeenhet kan du styra den på ett visst sätt, låt oss säga att du kan ställa den i 100 steg mellan 0% och 100%, alltså 0,1% per steg.

Då behöver du bara att skala slutresultatet till att passa 0-1000 och då den reglering ändå är i heltalssteg är det ju bara att ta slutresultatet och multiplicera/dividera med en faktor och saken är biff.

Men det är klart, jag förstår ju inte detta enligt dig... så jag har nog inte fattat detta heller.

Skulle uppskatta om någon löste följande med ints only.

Linjär ekvation:
\(Ax=b\)

Löses som:
\(x = (A^TA + \alpha I)^{-1}A^Tb\)

Kvadratisk programmering:
\(\bigtriangledown (x^TQx + c^Tx)\)

Med subjektion till:
\(Ax\leq b\\
x \geq 0\)

Löses via KKT-begränsningarna
\(\begin{bmatrix}
2Q & A^T & -I_n &0 \\
A& 0& 0& I
\end{bmatrix}\begin{bmatrix}
x\\
u\\
v\\
s
\end{bmatrix}=\begin{bmatrix}
-c\\
b
\end{bmatrix}\)

Och Recursiv minsta kvadratmetod:
\(A(q)y(t) = B(q)u(t) + C(q)\epsilon(t)\)

Löses som:
\(\theta = (a_1 \dots a_n, b_1 \dots b_m, c_1 \dots c_e)\)
\(\phi^T(t-1) = (-y(t-1) \dots -y(t-n) \dots u(t-1) \dots u(t-m) \dots \epsilon(t-1) \dots \epsilon(t-e))\)

Som anropas rekrusivt via
\(\epsilon(t) = y(t) - \phi ^T(t-1)\hat \theta(t-1)\)
\(\hat \theta(t) = \hat \theta(t-1) + P(t) \phi(t-1) \epsilon(t)\)
\(P(t) = \frac{1}{\lambda}[P(t-1) - \frac{P(t-1)\phi(t-1)\phi^T(t-1)P(t-1)} {\lambda + \phi^T(t-1)P(t-1)\phi(t-1)} ]\)

Diskret algebraisk Riccati ekvation:
\(P = A^T P A -(A^T P B)(R + B^T P B)^{-1}(B^T P A) + Q\)

Löses som:
\(P(k+1) = A^T P(k) A -(A^T P(k) B)(R + B^T P(k) B)^{-1}(B^T P(k) A) + Q, k = 0, 1, 2, 3, 4, \dots , n\)
\(P(0) = I\)

Pesudo invers:
\(x = A^{\dagger}b\)

Löses som:
\([U, E, V^T] = svd(A)\)
\(x = U^TE^{-1}(V^T)^T\)

[hummel]

Menar du int i C vilket ofta på inbyggda system är 16 bitar eller menar du med heltalsberäkningar?

[DanielM]

I detta fall så betraktar jag int:en som oändlig upplösning. Men för att ta hänsyn till begränsingarna så menar jag att en int skulle vara uint32_t i detta fall.

[guckrum]

Man kan implementera valfri algoritm med heltal, det handlar bara om dynamiskt område. (Varför skulle det inte gå?) Allmänt bygger man inte specifika signalprocessorer på kisel som telekommodem etc med flyttalsaritmetik, trots komplexa algoritmer. Det är för dyrt. Dessutom har flyttal diverse issues.

Stora fördelen med flyttal är att det är "enkelt". Men som vanligt finns det en baksida och det gäller att om man inte vet vad man gör så skall man ta det försiktigt.

[DanielM]

Varför skulle det inte gå?

Jag tvivlar inte på att det inte skulle gå. Jag undrar mest bara varför andra inte gör det.

[TomasL]

Därför att de allra flesta som jobbar inom embedded använder just heltalsaretmetik, eftersom det är fasiken så mycket snabbare, jämfört med flyttal.

[baron3d]

Vanligt när man använder heltal är att man delar upp de binära bitarna till heltalsdel och decimaldel.
Till exempel:
Formatet q31 är ett 32-bitars heltal där man låter det motsvara -0,999999999 - 0 - 0,999999999.
Formatet 16:16 är ett 32-bitars heltal som är uppdelat i 16 bitar heltal och 16 bitar decimal, -32768,0 - 0 - 32767,99998.
Formatet 8:8 är ett 16-bitars heltal som är uppdelat i 8 bitar heltal och 8 bitar decimal, -128,0 - 0 - 127,996.

Detta gör att man kan få decimaler med heltalsberäkningar.

Signalprocessorer använder vanligtvis q31 och q15.
Äldre 3D spel använde ofta 16:16.

Skall vi vara petiga så skall det vara binaler och inte decimaler.

[hummel]

I detta fall så betraktar jag int:en som oändlig upplösning. Men för att ta hänsyn till begränsingarna så menar jag att en int skulle vara uint32_t i detta fall.

Med oändlig upplösning på dina heltal får du högre dynamik än dina flyttal.