Allokering utav minne - Acceptabelt inom inbyggda system?

[TomasL]

Sodjan länkade till en pdf med MISRA, du kanske skulle studera den.
Där hittar du alla regler, en efter en.

[sodjan]

Här, så slipper du leta i alla fem sidorna tillbaka i tråden:
http://caxapa.ru/thumbs/468328/misra-c-2004.pdf.

Jag tror inte att det är senaste utgåvan, men det är sannolikt
mest marginella skillnader.

Sen är det ju så att MISRA kommer från ett speciellt användarfall
(bilindustrin, tror jag), och det är inte säkert att allt där äär vettigt
i alla andra användarfall. Men det kan ju ge en del idéer i alla fall.

[säter]

Heter det MISRA eller MIRSA?

[snigelen]

Prova med godtycklig sökmotor?

MISRA - The Motor Industry Software Reliability Association.

[säter]

DanielM påstår ju att det heter MIRSA.
Då kanske man får sämre med träffar när man söker?

[TomasL]

tja, han stavade väl fel eller nått.

[TomasL]

Hittar inte denna lista någonstans. Finns säkert in MIRSA C's standard, men att sammanfatta denna har jag ej tid med.

Och varför skall du sammanfatta det här?
Det viktiga är ju att du förstår varför reglerna finns, och applicerar dem i dina system.

[DanielM]

Jag förstår varför man ej ska allokera minnet under körning. Om minnet inte allokeras i tid så blir det ett tomt minne och då fallerar mikroprocessorn. Samma sak om man rekrusivt kallar samma funktion som man "står i". Då tar minnet slut väldigt fort.

[Shimonu]

Vad menar du med att det blir tomt minne om det inte allokeras i tid?

[DanielM]

Tänk att du allokerar 5 bytes under 5kHz och tänk efter 15 år om processorn råkade allokera 4 bytes då? Fallerat.

[TomasL]

Vad i göta-petter pratar du om.
Har du ingen kunskap om hur det fungerar?

Du kanske skulle studera lite elementär dator-teknik/teori/programmering

[snigelen]

DanielM: Det kommer inte att hända, du får endera alla byte du bad om eller ingen. Dessutom får du ju i programmet reda på om det lyckades eller inte. Sök på t.ex "heap fragmentation" om du vill veta mer om det verkliga problemet.

Sedan bör man ha lite koll på hur mycket stack man har tillgängligt för att t.ex veta hur många funktionsanrop man kan göra från funktioner (från funktioner...). Det spelar ingen roll om det handlar om olika eller samma funktion. "Fördelen" med rekursiva funktioner är att man enkelt kan hålla reda på hur många gånger man anropat sig själv.

Ett exempel på garanterat max 1 nivå av rekursion (som av en smart kompilator inte genererar någon rekursion alls).

Kod: Markera allt

void usartC0_putc(char ch)
{
    if (ch == '\n')
        usartC0_putc('\r');

    while ((USARTC0.STATUS & USART_DREIF_bm) == 0)
        ;
    USARTC0.DATA = ch;
}

Livsfarlig kod .

[DanielM]

Vad i göta-petter pratar du om.
Har du ingen kunskap om hur det fungerar?

Du kanske skulle studera lite elementär dator-teknik/teori/programmering

Hej.

Jag studerar vid behov. Jag lägger inte en sådan tid på att förstå exakt allt i en mikroprocessor. I verkligheten handlar det om att lösa problem. Inte hur man löser problem. Mina kärnämnen är systemidentifiering och reglerteknik samt numerisk analys. Jag har en del erfarenhet i C++ och Java också sedan gamla tider. Jag är relativt ny när det kommer till modern programmering utav hårdvara och jag har byggt några LCD exemplarer för mina reglerprojekt.

Att erfarna varnar mig från att använda malloc och calloc under körning köper jag utan bevis. Jag litar på de erfarna, så länge det handlar om det område som jag har behov utav.

[Icecap]

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.

[TomasL]

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.