Hilfe! Ich schreibe ein Programm für Atmega 16 mit AVRStudio. Benutze Schleifen, Switch-Block, Struckturen und Funktionen. Die HEX-Datei für den Controller wird bald zu groß, obwohl ich noch nicht so viel gemacht habe. Kann mir jemand sagen, was ich vermeiden soll, damit die HEX-Datei nicht zu groß wird und in den Flash reinpasst. Danke
Die Größe der HEX Datei ist ein eher schlechter Indikator für die Größe des Programms. Als Faustregel: Eine HEX-Datei ist ca. 3 mal so gross wie das eigentliche Programm, so wie es dann zum AVR übertragen wird. > Kann mir jemand sagen, was ich vermeiden soll Keine unnötigen Dinge programmieren. Den Optimizer einschalten. Ansonsten gibt es nicht viel. Wenn dein Programm gewisse Dine tun soll, dann muss es diese Dinge auch tun. Und das bedeutet nun mal Programmcode dafür. Edit: Ach ja. Mach einen grossen Bogen um Fliesskommaarithmetik. Die schlägt richtig heftig zu Buche.
Nicht in C sondern in assembler programmieren. Evtl. kann man sich auch den übersetzten C Code in Assembler ansehen und darin was ändern und anschließend mit dem Assembler übersetzen. Statt mega16 den mega32 oder mega644 verwenden. mfg
> Nicht in C sondern in assembler programmieren. Evtl. kann man sich auch > den übersetzten C Code in Assembler ansehen und darin was ändern und > anschließend mit dem Assembler übersetzen. > Statt mega16 den mega32 oder mega644 verwenden. Mit heutigen C Compilern muss man schon richtig gut Assembler können um eine bessere Dichte zu erzeugen. Ich denke, dass sonst ein Assemblerprogramm (ausser bei ganz kleinen Projekten) sich mit der Zeit mehr aufbläst als ein C Programm, ausser es ist ein Assembler Experte am Werk.
Wolfram Quehl wrote: > Nicht in C sondern in assembler programmieren. Evtl. kann man sich auch > den übersetzten C Code in Assembler ansehen und darin was ändern und > anschließend mit dem Assembler übersetzen. > Statt mega16 den mega32 oder mega644 verwenden. > > mfg Da hat mal wieder jemand nicht verstanden, was das Problem ist: Eine (Intel-)Hex-Datei enthält einen "Overhead", damit das Programmier-Werkzeug weiß, an welche Adresse es welche Daten schreiben soll. Zwecks Überprüfung der Richtigkeit der Daten ist auch noch eine Prüfsumme beigefügt. Damit man als Mensch die Datei auch noch lesen kann, sind die einzelnen Byte auch noch als ASCII-Zeichen aufgeführt, was schon mal dazu führt, dass der Quellcode schon mal doppelt so lang ist, wie sie als Binärdatei wäre. http://www.roboternetz.de/wissen/index.php/HEX-Datei Es hat überhaupt nichts damit zu tun, wie das Programm erstellt wurde. Selbst ein Assembler erzeugt HEX-Dateien, wenn er das Programm assembliert. Der einzige Unterschied zwischen Assemler und einer Hochsprache ist, dass der Compiler und der Rest der Werkzeugkette dem Programmierer "lästige" Tätigkeiten wie Register-auf-Stack-Rettung, Beschreiben der Interrupt-Vektor-Tabelle etc., sowie kompliziertere Berechnungen abnimmt. Der Vergleich zwischen Assembler (eigentlich auch eine Hochsprache im Gegensatz zum manuellen programmieren eines Controllers mit Hilfe von Schaltern und Tastern...) und einer Hochsprache ist also völlig sinnfrei. Assembler kann man bis zu einer gewissen Projektgrösse (auch die Anzahl der mitarbeitenden zählt) benutzen. Ab einer bstimmten Grösse verliert man den Überblick. Mir fällt da immer das allseits beliebte Zitat von Dieter Nuhr ein...
Bei avr-studio wird jedesmal bein bauen angezeigt wie voll der Flash schon ist... kA wie die das machen sonst bauen auf jeden Fall mit -Os das spart ordentlich
>Bei avr-studio wird jedesmal bein bauen angezeigt wie voll der Flash >schon ist... kA wie die das machen Die interessieren sich auch nicht für das HEX-File...
ich habe das schon verstanden, habe mir die Hex Datei auch mal angesehen. Aber bei jeder Übersetzung wird doch der Speicherverbrauch angegeben und da habe ich vermutet, daß der angegebene Speicherverbrauch höher ist als der Mega16 fassen kann. mfg
Der Speicherverbrauch kann beim gcc nicht höher sein als das Target fassen kann. Der Linker prüft nämlich automatisch wie "voll" der Flash schon ist wenn er zu voll ist bekommt man das Projekt erst gar nicht gelinkt. Die Diskussion mein Controller ist so schnell voll hab ich auch ständig mit Kumpels die mit AVR anfangen. Da wird mal schnell ne LCD Library genommmen noch Floating Point mit eincompiliert und dann heissts Hilfe ich hab nur 20 Zeilen in meinem Hauptprogramm stehen und mein Controller ist schon zu 40% voll ich brauch nen grösseren Controller ...
> Da hat mal wieder jemand nicht verstanden, was das Problem ist: > Eine (Intel-)Hex-Datei enthält einen "Overhead", damit das > Programmier-Werkzeug weiß, an welche Adresse es welche Daten schreiben > soll. > Zwecks Überprüfung der Richtigkeit der Daten ist auch noch eine > Prüfsumme beigefügt. > Damit man als Mensch die Datei auch noch lesen kann, sind die einzelnen > Byte auch noch als ASCII-Zeichen aufgeführt, was schon mal dazu führt, > dass der Quellcode schon mal doppelt so lang ist, wie sie als Binärdatei > wäre. Ich glaub schon, dass er verstanden hat worum es geht. Wenn jemand sagt, die Hex datei passe nicht dann glaube ich ist nicht gemeint, dass die Hex Datei selbst zu groß ist sonder dass sie zu weit geht (z.B. bis 10400 und der Controller kann nur bis FFFF).
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.