Allokering utav minne - Acceptabelt inom inbyggda system?

[sodjan]

Frågar du mig? Nej, jag vet inte ett smack om MISRA förutom att jag
konstaterade att det var om mer än allokering av minne. Jag bara hjälpte
dig att hitta en källa (om ej helt aktuell) till det. Läs själv!

[hummel]

Antar att du är väl bekant med denna standard? Skulle du kunna peka på operationer i min C kod där jag gör fel enligt standarden?

Skaffa MISRA C-standarden och börja läsa, det är inte så enkelt som att trycka på en knapp. Om du väljer äldsta version så läs på dom 127 reglerna och se vilka du följer vid din programmering.
Vill du ha det automatiserat utan att själv läsa på har du lösningen på https://www.gimpel.com

[TomasL]

Antar att du är väl bekant med denna standard? Skulle du kunna peka på operationer i min C kod där jag gör fel enligt standarden?

Dynamisk allokering och rekursiva funktioner är väl det mest uppenbara.
Sedan finns det garanterat en hel hög med andra fel (har inte orkat studera koden i detalj).

Dynamisk minnesallokering leder alltid till minnesläckor och till slut programkrasch, eftersom minnet tar slut.
Rekursiva funktioner leder alltid till att stack och HEAP tar slut, vilket leder till programkrasch.

Lite hårdraget, naturligtvis, Du kan ju ha tur att du har lyckats hantera all allokering av minnet, eller att stacken/HEAP inte tar slut.

Programkrasch leder i bästa fall till en "blåskärm" annars till helt okontrollerbar system.

Och nej MISRA förbjuder inte assembler, om det ligger i egna funktioner/filer.
Dock tillåts inte assembler inline.

[DanielM]

Dynamisk minnesallokering leder alltid till minnesläckor och till slut programkrasch, eftersom minnet tar slut.
Rekursiva funktioner leder alltid till att stack och HEAP tar slut, vilket leder till programkrasch.

Intrssant. Kan du svära på det? Jag har hört att det inte gör så om man vet vad man gör. Eller menar du att så fort man anropar malloc -> calloc lite då och då, så kommer heap-minnet ta slut förr eller senare?

Jag håller på med Recursive Least Square.


\(\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)} ]\)

Ett praktiskt resultat är detta som visas nedan. Bilden visar en linjär model, som rekursivt estimeras till en modell. Nu är detta i en simulering och då ser exakt allt perfekt ut.

Målet som jag har är att applicera makiniellt lärande i mikroprocessorer. I detta fall är det regulatorer som ej behövs trimmas in. Endast ett knapptryck. Det finns PID-regulatorer som hanterar sådant, men dom är ej adaptiva. Min är både apdaptiv och självinställande och filtrerande.

RecursiveLeastSquare.png

Värt att notera så får man ett kalman filter om man använder sig av denna ekvation när \(n == e\)
\(K = (c_1 - a_1 \dots c_e - a_n)^T\)

[Shimonu]

Antar att du är väl bekant med denna standard? Skulle du kunna peka på operationer i min C kod där jag gör fel enligt standarden?

Dynamisk allokering och rekursiva funktioner är väl det mest uppenbara.
Sedan finns det garanterat en hel hög med andra fel (har inte orkat studera koden i detalj).

Dynamisk minnesallokering leder alltid till minnesläckor och till slut programkrasch, eftersom minnet tar slut.
Rekursiva funktioner leder alltid till att stack och HEAP tar slut, vilket leder till programkrasch.

Lite hårdraget, naturligtvis, Du kan ju ha tur att du har lyckats hantera all allokering av minnet, eller att stacken/HEAP inte tar slut.

Programkrasch leder i bästa fall till en "blåskärm" annars till helt okontrollerbar system.

Och nej MISRA förbjuder inte assembler, om det ligger i egna funktioner/filer.
Dock tillåts inte assembler inline.

Det där är ju enormt överdrivet. Risken är ofta inte värd det inom inbyggda system för att ha dynamiskt minne men i mindre kritiska system finns det ju ofantligt många exempel med dynamiskt minne som fungerar utan läckor och kraschar. Likväl kan man ha rekursiva funktioner och är man nojig kan man begränsa anropsdjupet

[TomasL]

Jo, det är något hårddraget, men det räcker med att missa en minnesallokering, så kan det vara kört.

[hawkan]

Vet man vad man gör kan man använda rekursion och dynamisk minnesallokering.
Å andra sidan, vet man vad man gör kan man lika gärna undvika det.

Det kostar för övrigt en del att använda dynamiskt allokerat minne.
Det sker en del administration för att hålla ordning på vad som är taget och
vad som är ledigt. Det kostar alltså tid, och det kan kosta olika lång tid
beroende på hur mycket man använt. Och att det tar olika lång tid då och då
det vill man normalt inte.

Den intresserade kan ju kolla vad det innebär att skriva en egen malloc() och free()
t ex här http://tharikasblogs.blogspot.com/p/how ... -free.html
(första google-träffen).

[DanielM]

Som tur så använder jag inte Malloc, free eller calloc. Däremot memcpy och memset använder jag för att sätta värden på elementerna i en array som är innuti en funktion. Testade med uint8_t minArray[5] = {0}; Men det fungerade inte.

[guckrum]

Det är bra att tänka på att RLS är ökänd för att ha stabilitetsproblem när precisionen är begränsad.

[DanielM]

Du får gärna ge ett exempel.

Annars så finns det något som heter insommningsproblemet. Detta inträffar när reglerbarheten är god och inga svägningar förekommer. Då blir modellen statisk och därmed ej passar in inom ett dynamiskt system.

Lösningen på detta är att koppla bort RLS efter en viss godtycklig tid vid deterministiska system.

[TomasL]

Som tur så använder jag inte Malloc, free eller calloc. Däremot memcpy och memset använder jag för att sätta värden på elementerna i en array som är innuti en funktion. Testade med uint8_t minArray[5] = {0}; Men det fungerade inte.

Nej, det sätter bara första elementet till noll.
Du kan ju alltid loopa igenom arrayen för att sätta alla element till noll.

[henkebenke]

Det är väl inte sant. Initialiserar man med en initializer-list så sätts alla element som inte är specificerade till 0. Dessutom om variabeln är static så sätts alltid alla element till 0.

[Icecap]

Om man kollar de "startup.asm" (eller vad den heter) som finns med i alla ensamstående projekt sker det vissa saker vid uppstart:
1: Evt. minnespekare (stack osv) ställs till standardvärden om inte man har lagt in speciella parameter för detta.
2: All känd RAM nollställs. Detta kan betyda att man - vid tillagt RAM - måste ange andra gränser.
3: OM det finns konstanter som måste läggas i RAM innan programstart kopieras dessa i från ROM.
4: main() anropas.

Så deklarerade variabler "nollas" inte som standard - men RAM gör. Jag garanterar dock inte att denna nollning av RAM sker i alla kompilers och/eller alltid, det finns rimligt säkert undantag.

Och jag har sett många gångar här i forumet att det har funnits problem och att programmörn MÅNGA gångar har påstådd att "det är status efter RESET enl. databladet" - men efter att de viktiga saker är ställd till vad de borde vara fungerar det hela.

Så att ANTA att något är på ett visst sätt är en farlig strategi, vill man vara säker måste man göra det själv.

[DanielM]

Vad har vi kommit fram till nu:

Följande ska inte användas under körning:

1. * Rekursiva anrop av funktioner - Ej bra
   * Malloc och calloc - Ej bra

Mer då? Vad säger er praktiska erfarenhet?

[hummel]

Vad gav MISRA C för idéer?