www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ATmega Überfüllung?


Autor: R. Richter (supersonic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo allerseits!

Ich bin seit kurzem bei einer Firma die ATmega einsetzen. Ich selbst 
habe noch keine Erfahrung mit den ATMEL-Microcontrollern, daher wende 
ich mich an die erfahrenen Entwickler.

Wir verwenden aktuell einen ATmega168, bzw. ATmega168P. Nun meint der 
Kollege, der die entsprechende Entwicklung tätigt, dass diese 
ATmega-Microcontroller Probleme machen, wenn der Flashspeicher zu 90% 
oder mehr belegt. Da wir aber voraussichtlich eine endgültige Belegung 
von 95% erreichen werden, wollte ich mal fragen, ob diese Problematik 
bekannt ist?

Mit freundlichen Grüßen und einen schönen Feiertag
supersonic

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>dass diese ATmega-Microcontroller Probleme machen, wenn der Flashspeicher
>zu 90% oder mehr belegt.

Und welcher Art sind die angeblichen Probleme?

MfG Spess

Autor: Crest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das einzige Problem eines fast vollen Flashs ist das es kaum noch Platz 
für die Weiterentwicklung gibt. Theoretisch kannst du den Flash bis aufs 
letzte Byte ausnutzen ohne das es zu Einschränkungen kommt.

Autor: Bastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ein Kollege hat einen Controller (kein Atmel) bis auf 4 Byte belegt.
Was soll ich sagen, er läuft problemlos.

Das einzige Problem ist die maximale Ausnutzung des RAMs, da man nie 
sicher sein kann das der Stack nicht doch mal ein paar Byte mehr wächst 
als gedacht.
Aber im Flash sehe ich kein Problem.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
R. Richter schrieb:
> Nun meint der Kollege...

Was hast du denn für Kollegen?

Das erinnert mich irgendwie an den Draufhobel und die 
Siemens-Lufthhaken.

Autor: Alter Hase (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie Bastler schrieb dürfte die größere Gefahr ein von "oben"
in den "Datenteil" des RAMS eindringender Stack sein.

Es gibt absolut keinen Grund warum ein bis auf's letzte Byte
uups, Word, gefüllte Flash nicht funktionieren sollte.

Außer nach einer Programmänderung wenn das Programm größer wird
als in den Flashspeicher passt........

Aber was soll's, ist der Flash vom ATMEGA168 zu klein,
gibt es immer noch den ATMEGA328 mit doppeltem Flash....

Wäre ganz interessnt was das für Probleme sind und wie die sich
äußern.

Poste die doch mal...

Autor: Experte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Nun meint der Kollege, der die entsprechende Entwicklung tätigt, dass
> diese ATmega-Microcontroller Probleme machen, wenn der Flashspeicher
> zu 90% oder mehr belegt.

Der Kollege hat recht. Es besteht die Gefahr, dass sich das Gehäuse 
aufbläht. Abhilfe ist ganz einfach: Auf der Platine einfach etwas Platz 
um den ATmega lassen, vor allem nach oben.

Alternative Lösung, wenn Stromverbrauch keine Rolle spielt: Den 
Controller etwas rechenintensives berechnen lassen. Dann hat er gut zu 
tun und schwitzt die überflüssigen Pfunde wieder weg. Das Fachwort dafür 
ist "Burn-In".

Ürbigens: Tolle Firma, wo Du arbeitest, bei der solches 
Spezial-Fachwissen vorhanden ist! Das ist nicht überall so. Sei stolz 
drauf!

Autor: -.- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dann kann der ja garnich mehr swappen :D

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vielleicht hat er einen bootloader, der noch 10% braucht

Autor: Andreas K. (derandi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klingt nach einem Missverständnis, einer schlechten Firma oder einer 
Lüge, bitte wählen.

Autor: Axel R. (axelr) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mal gehört, es gäbe Controller, die besonders
 seien. Und von Schaltreglern eines bestimmten Herstellers, die unter 
Last nicht anschwingen.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Denkbar wäre, daß zu dem eigentlichen Programm 
(.text+.data+.bootloader+...) noch Daten nachträglich hinzugefügt werden 
wie Kalibrierungsdaten, die zum Zeitpunkt der Programmerstellung noch 
nicht bekannt sind und von "extern" nachgeflasht werden.

Das problem ergibt sich wenn die Adresse, an der diese Daten stehen, 
hart im Probramm steht, etwa
((char*) 0x3800)
anstatt das sauber über eigene Section und Linkeskript zu erledigen.

Autor: Axel R. (axelr) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bearbeiten geht nicht?!? (Statt "Vorschau" auf "Absenden" geklickt)

Ich habe mal selbst mit angehört, es gäbe Controller, die besonders
 seien.
Und von Schaltreglern eines bestimmten Herstellers, die unter Last nicht 
anschwingen würden und deshalb AUF GAR KEINEN FALL zu verwenden seien. 
Das sind solche Urban - ähem Silicons Legends. Diese Legenden halten 
sich bis in Kreise von hochdotierten Entwicklungsinschenören.

Achja:
Das mit dem 90% Flash voll ist Unsinn.

Gruß
Axelr.

So - nun aber...

Autor: Rolf Degen (rolfdegen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallöchen..

Ich benutze für mein Projekt einen ATmega169 mit 16KByte Flash-Speicher. 
Mein C-Programm nutzt bis auf 10Byte den vollen Flash-Speicherplatz und 
läuft ohne Probleme.

Gruß Rolf

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht hat ihn der Fragesteller auch misverstanden und der Kollege 
redete in Wirklichkeit vom SRAM.

Wenn der Speicher zu 90% voll wird, gibts Probleme
Kollege meint 'SRAM'
Fragesteller denkt 'Flash'

Autor: R. Richter (supersonic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank erstmal für die Mitteilungen.

Richtig ist, dass ich ausdrücklich den Flashspeicher gemeint habe und 
dies auch so als kommuniziert wurde ("Ich möchte den Programmflash nicht 
mit mehr als 88% füllen, da es sonst eventuell wieder Probleme geben 
kann. µC läuft nicht richtig"). Ich habe auch nicht das RAM gemeint. 
Stackprobleme sind mir bestens bekannt, die sind nicht 
Controllerspezifisch. Auch das EEPROM war nicht gemeint. Ein bootloader 
wird nicht verwendet. Noch nicht mal Texte oder dergleichen. Konkreter 
genannte Probleme kenne ich nicht.

Also werde ich das Ganze mal genauer untersuchen müssen, falls es zu 
Problemen kommt, die ihre Ursachen in der Auslastung des Flash haben 
sollen. Vielleicht lag in den genannten alten "Flashproblemen" doch eine 
Unsauberkeit im Programmcode vor. ;-) So was in der Richtung dachte ich 
mir schon.

Grüße
Rudi

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einfach mal so ins blaue verdaechtigt, da liegt ein Hund begraben. Evtl. 
mal das Flash eines bestehenden Systems auslesen, ob sich da nicht in 
die oberen Bytes was "reingemogelt hat". Muesste allerdings in der 
Memory map ersichtlich sein!?
Hab in meinen vielen Jahren in verschiedenen Applikations Abteilungen 
schon viel gehoert ueber moegliche Ursachen von Fehlverhalten des 
Programmes aber das ist doch neu. Man lernt eben nie aus ;-)

Gehe ich richtig in der Verdaechtigung, dass nicht geringe Anteile des 
Programmes mit fraglichem Verhalten in ASM geschrieben sind? Nur so ein 
Gefuehl.

Gruss, Robert

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
R. Richter schrieb:
> Also werde ich das Ganze mal genauer untersuchen müssen, falls es zu
> Problemen kommt, die ihre Ursachen in der Auslastung des Flash haben
> sollen.

Mach das. Und bitte dann hier darüber berichten, und auch Atmel in 
Kenntnis setzen. Die pflegen üblicherweise ihre Errata in den 
Datenblättern, und solch eine Information würde da natürlich 
hineingehören.

Wie aber schon mal vorsichtig vermutet wurde, könnte das Problem deines 
neuen Kollegen eventuell vielleicht auch ganz andere Ursachen gehabt 
haben ;-)

Oliver

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich tippe auch eher auf das Flash des Kollegen und nicht das des MC.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich hab hier einen Tiny13 bis auf 30 Bytes befüllt.
Bisher gibt es da keine Probleme.

Was allerdings nicht unwahrscheinlich ist:

Man kann sich bei den FUSES gnaz schnell mal vertun. Z.B. beim 
Programmer
den falschen Controller auswählen. Wenn man die Signaturprüfung 
abgestellt
hat, dann kann es sein, dass zwar funktionierende FUSES (SW läuft)
geflashed werden, aber Nebeneffekte auftreten. Z.B. wenn mann die
"Boot-Reset" Fuse setzt. Dabei wird von einer hohen Adresse gestartet 
(Bootloader-Section). ISt der obere Flashbereich leer (0xFF => NOP),
dann gibt es einen Überlauf (Program Counter) und der Controller startet
die eigentliche Firmware problemlos.

Wenn man jetzt allerdings den oberen Bereich mit Code füllt, dann
wird natürlich irgendwas ohne Initialisierung und ganz willkürlich
ausgeführt. Das kann dann natürlich zu Fehlfunktionen führen.

Dazu noch ein kleiner TIP:

Wenn es neue AVR-Studio Versionen gibt, dann immer erst mit Vorsicht
aktualisieren und ganz genau beobachten. Die von Atmel sind auch keine
perfekten Programmieren. Da gabe es schon genügend Fehler bei den
XML-Dateien mit den Fuse-Beschreibungen, dann auch mal den Fall, dass
man keinen Bootloader mehr Flashen konnte, etc..
Und immer brav die "Changelog" lesen.

Wenn dein Kollege über einen solchen Fallstrick drüber ist, dann
muss man die daraus gezogenen "falschen" Schlüsse so Bald wie möglich
korrigieren!

Autor: Tropenhitze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Nun meint der Kollege, der die entsprechende Entwicklung tätigt, dass
>diese ATmega-Microcontroller Probleme machen,

Bei all der Heiterkeit, die diese Geschichte auslöst, wirst Du 
wahrscheinlich aufpassen müssen, dass dieser Kollege nicht Dein Problem 
wird.
Nichts ist schlimmer als dumme Menschen.

Autor: einen Namen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hatte eine Applikation (in Assembler) bei welcher
der ATtiny2313 bis auf das letzte Flash-Byte belegt
wurde. Kein Problem damit.

An dieser Stelle hätte ich mir aber einen ATtiny4313
gewünscht, analog zu 89C2051/89C4051. Das hätte manches
einfacher gemacht.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Tropenhitze (Gast)

>Nichts ist schlimmer als dumme Menschen.

Doch, es geht schlimmer. Menschen mit Halbwissen!!!

Ach ja, auch ich hab hier ein kleines Projekt auf einem ATmega8515, dort 
sind noch 4 (vier) Bytes im Flash frei. Läuft wie ne 1!

MfG
Falk

P S leider neigen auch Ingenieuere und andere technische Leute dazu, 
Effekte, die sie nicht erklären könnnen, mit nebulösen, esoterischen 
Begriffen zu erklären. Dabei entstehen dann solche Urban Legends.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.