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
Gast
#1709507
Hi >dass diese ATmega-Microcontroller Probleme machen, wenn der Flashspeicher >zu 90% oder mehr belegt. Und welcher Art sind die angeblichen Probleme? MfG Spess
Gast
#1709509
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.
Gast
#1709526
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.
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.
Gast
#1709539
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...
Gast
#1709543
> 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!
Gast
#1709566
dann kann der ja garnich mehr swappen :D
vielleicht hat er einen bootloader, der noch 10% braucht
Klingt nach einem Missverständnis, einer schlechten Firma oder einer Lüge, bitte wählen.
Gast
#1709584
Ich habe mal gehört, es gäbe Controller, die besonders
seien. Und von Schaltreglern eines bestimmten Herstellers, die unter Last nicht anschwingen.
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
1 | |
anstatt das sauber über eigene Section und Linkeskript zu erledigen.
Gast
#1709588
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...
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
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'
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
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
Gast
#1710331
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
Ich tippe auch eher auf das Flash des Kollegen und nicht das des MC.
Gast
#1710354
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!
Gast
#1710367
>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.
Gast
#1710383
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.
@ 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
Bitte melde dich an, um einen Beitrag zu schreiben.