Svenska ElektronikForumet

Ja som titeln säger. Jag håller på och skriver ett program som i princip kommer fylla ut ROM till max (I bästa fall 1% kvar) och lämna ca 15%RAM. Är detta illa. Typ en dator mår ju inte bra av att ha minnet helt fyllt. Vad kan hända?

Inget problem alls.
En dator skriver en massa saker till hårddisk sporadiskt, det gör inte en MCU om du inte programmerat den till det (vilket vore olämpligt).
Samt en dator allokerar minne till olika program hur som helst, heller inte det gör ditt program så länge du inte använder en massa dynamisk minnesallokering (malloc) i vilket fall man får se sig för vad man gör.

Om du med ROM avser det minne där applikationen ligger, så ja,
jag skulle säga att det inte är bra. Det finns stor risk att du behöver
ändra designen och byta processor om två år då du vill lägga till
något i funktionen. Mycket enklare att välja en modell med mer
"head-room" redan från början.

Malloc och liknande funktioner är i mitt tycke förbjudna.

Den enda nackdelen med för lite minne är ju att man inte kan lägga in fler funktioner, utan att ändra hårdvaran, vilket är dyrt.
Nu vet vi ju inte vilken plattform du jobbar ed, men i mitt tycke är det smart att välja en processor med dubbelt så mycket flash och ram som man behöver, typ.

edit Sodjan hann före

Jag brukar acceptera malloc in min kod, men jag tillåter inte free...

Ok. Så det är eg inga problem.

Jag valde faktiskt den mcu med mest minne i 20pins kapsel faktiskt. Går inte riktigt klämma in större kres utan stora omtag.

Och jag har inte skrivit ngn malloc eller andra konstigheter.

Tack för svar.

Ja, som sagt, det är ju inget direkt tekniskt problem med att fylla
programminnet till 99% (om det nu är det som avses med "ROM"),
men det ger inte mycket utrymme för nya funktioner i framtiden...

Rent teknisk ÄR ROM redan fylld till 100%!!!
Skillnaden är att om man använder 15% av den är resten (85%) fylld med 0xFF (om det är flash eller EPROM).

Likaså med RAM: den finns där oavsett om den används fullt eller delvist.

Men jag ger sodjan rätt: rent designmässigt är det ett fel att klämma in så pass mycket att det kan bli svårt att lämna plats för uppdatering. Men det är inget teknisk problem.

Om ROM(flash) är nästan fullt så har det ingen inverkan,
Däremot om RAM närmar sig gränsen så kan man få otrevliga problem om
man har nästlade interrupts, eller får interrupt
samtidigt som man använt mycket stack.
Fel kan då uppträda sporadiskt och är mycket lömska och svåra att hitta

Swech

Icecap skrev:Rent teknisk ÄR ROM redan fylld till 100%!!!
Skillnaden är att om man använder 15% av den är resten (85%) fylld med 0xFF (om det är flash eller EPROM).

Likaså med RAM: den finns där oavsett om den används fullt eller delvist.

Men jag ger sodjan rätt: rent designmässigt är det ett fel att klämma in så pass mycket att det kan bli svårt att lämna plats för uppdatering. Men det är inget teknisk problem.

Ja jag håller med.

Swech skrev:Om ROM(flash) är nästan fullt så har det ingen inverkan,
Däremot om RAM närmar sig gränsen så kan man få otrevliga problem om
man har nästlade interrupts, eller får interrupt
samtidigt som man använt mycket stack.
Fel kan då uppträda sporadiskt och är mycket lömska och svåra att hitta

Swech

Ska lägga detta på minnet def

Det brukar krävas en del analys av programkoden för att verkligen avgöra hur mycket RAM som används. Vad använder du för den analysen?

Jag utgår fr vad kompilatorn säger. Tycker den själv att jag är på noll så kompilerar den inte koden ens

Jag skrev en gång ett program till en PIC som fyllde alla 1024 words av ROM =)

Man blir ju lite tveksam till det här med Arduino när ett nästan tomt program tar upp mer plats.

Ja, kompilator (och länkare, om det är separata funktioner) brukar rapportera
användningen av ROM (flash) och RAM. Men det brukar normalt vara de
statiskt allokerade delarna vilka är enkla att rapportera, bara att summera.

Att bedöma om t.ex. stacken räcker till är mer komplicerat och det behövs
beräkningar av "call-depth" och liknande. Han man sedan även interrupt i
flera nivåer och rekursiva funktioner, så ökar komplexiteten.

Visst, man köper sig en viss bekvämlighet genom att låta en utvecklingsmiljö
länka in mer eller mindre av olika runtime delar. Det kan även vara bra att
ha lite kläm på vad det innebär att använda olika konstruktioner. Flyttal
är ju klassiskt. Bibliotek för printf() kan vara stora. O.s.v... Jag utgår
också från att runtime miljön för Arduino funktionerna tar lite plats.
Inget konstigt med det, man köper sig som sagt lite bekvämlighet...