Allokering utav minne - Acceptabelt inom inbyggda system?

[TomasL]

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?

Att alla variabler explicit skall initieras till ett känt värde.
Man skall alltid använda hårt definierade typer, dvs aldrig "int", "char" eller liknande.

[DanielM]

Så instället för int, så använd uint8_t eller uint32_t om så behövs?

Orsaken varför? Stabilitet, eller minnesläckor? Eller handlar det endast om att minimera minne? Om man har ca 512 kB till 1024 Kb flash att röra sig på då?

Jag har en fråga som är ganska djup. När jag gör mina numeriska simuleringar så kan talen bli för stora. Hur undviker jag att jag ska få NaN eller Inf i C?

[säter]

Detta är ett reglersystem som jag håller på med.

Du kanske skulle dra i väg ett PM till Al_Bundy.
Han håller ju på med reglersystem på inbyggda system.

[TomasL]

Så instället för int, så använd uint8_t eller uint32_t om så behövs?

Orsaken varför? Stabilitet, eller minnesläckor? Eller handlar det endast om att minimera minne? Om man har ca 512 kB till 1024 Kb flash att röra sig på då?

Jag har en fråga som är ganska djup. När jag gör mina numeriska simuleringar så kan talen bli för stora. Hur undviker jag att jag ska få NaN eller Inf i C?

Därför att storleken på typer tenderar att skilja mellan olika system, och det kan ge oanade konsekvenser.

Orsaken till att alla variabler skall initieras till kända värden, är just för att du inte alltid kan lita på att det görs av kompilatorn.

[DanielM]

Tolkar det som att det skulle endast vara vid behov, och inte av säkerhetsrisk.

[TomasL]

Man kan aldrig lita på att kompilatorn initierar de variabler som egentligen skall initieras automatiskt, i vissa system görs det helt enkelt inte., därför skall man alltid initiera dem manuellt.

Beträffande typeerna, så var de tidigare väldigt löst specificerade, där den enda garantin var att en int är minst lika stor som en char, så ibkland kunde en int vara 8 bitar, ibland 16, ibland 32 och ibland 64 bitar.
Naturligtvis så blir det ju väldigt fel om man förutsätter en viss längd, och den inte stämmer.

[DanielM]

Är det därför C89 standarden används än idag?

En for-loop ser ut så här:

Kod: Markera allt

int i;
for(i = 0; i < 10; i++)
    printf("i = %i", i);

[TomasL]

C18 är väl den senaste
https://en.wikipedia.org/wiki/C18_(C_standard_revision)

[DanielM]

Jo. Men har hört att många kör fortfarande med ANSI C. C89 med andra ord.

[TomasL]

ANSI C är per definition den senast antagna standarden, så ANSI C är C18

[DanielM]

Bilden här visar C89 som ANSI C standard.

[TomasL]

Det är fel, C89/C90 finns inte längre, de är tillbakadragna av ISO/ANSI-

ANSI C refererar alltid till den senaste standarden vilket i dag är C18, dvs C11 med alla tillägg och ändringar.

[gkar]

Återigen, det är normalt inget problem att använda malloc i realtidssystem.
Men du får inte använda free. Avallokeringen vet du inte hur lång tid den tar och minnet blir fragmenterat.

Så dynamisk minnesallokering är inget problem, dynamisk minnesavallokering är det.
(Dvs, du avallokerar aldrig minnet, används tex när du initialiserar drivers mm.)

[guckrum]

Du får gärna ge ett exempel.

På temat instabil RLS. Googla i stil med "RLS numerical stability". Denna verkar relevant: http://www-public.imtbs-tsp.eu/~regalia ... jan-99.pdf

[Findecanor]

ANSI C refererar alltid till den senaste standarden vilket i dag är C18, dvs C11 med alla tillägg och ändringar.

En stor anledning till förvirringen är nog att för GCC så betyder kommandoradsparametern "-ansi" att det ska vara C89/C90.
Clang kopierar GCC's kommandoradssyntax, inklusive detta, för att vara kompatibel. Det kanske fanns någon ännu äldre kompilator som GCC härmar.