Hallo zusammen, folgendes Problem. Ich habe ein Bootloader HexFile und ein EEPROM HexFile, in dem Initialwerte stehen, und versuche dieses zu flashen. Bislang verfahre ich so das ich im Atmel Studio unter Device Programming->Memory zunächst den Bootloader und im Anschluss das EEPROM flashe. Dies ist mir zu umständlich. Ist es möglich das ich beide Files merge und dann im Anschluss mit einem Flash auf meinen Controller übertrage? Sicherlich müssen dazu Anpassungen im Makefile gemacht werden, aber wie sehen die genau aus? Vielen Dank für Eure Hilfe!
Der Programmer des AVR Studios kann doch beide Files zusammen programmieren, mit den Fuses, mit dem Protections. Das mancht man nicht einzeln.
Hi, vielen Dank für deine schnelle Antwort. Leider verstehe ich noch nicht genau was du meinst. Vielleicht formuliere ich mein Ziel nochmal etwas anders. Ich möchte beim kompilieren im AVR Studio ein HexFile generieren, in dem der Bootloader sowie die EEPROM Daten stehen. Dieses eine HexFile soll dann mit AVR Studio geflahst werden sodass die Daten an die entsprechende Stelle im Controller geschrieben werden geschrieben werden. Die Fuses habe ich bereits richtig gesetzt, da der Bootlaoder auch schon nader richtigen Adresse steht.
Entweder ist der Bootloader schon da oder auch nicht. Geht es um den Programmer, oder dn Bootloader? Weil beim Programmer diese Probleme nicht auftreten.
Ok vielleicht hab ich mich zu mißverständlich ausgedrückt. Es geht um das Programmieren. 1) Ein funktionsfähiger Bootlaoder als HexFile ist vorhanden. 2) Außerdem habe ich ein Hex File mit EEPROM Werte. 3) Als Entwicklungsumgebung verwende ich Atmel Studio. Als Programmer habe ich den AVR ONE! 4) Nachdem ich jetzt F5 drücke, soll mir Atmel Studio den Bootloader sowie die Initialwerte des EEPROMs (beide HexFiles) auf den Controller schreiben. 5) Frage: Wie teile ich Atmel Studio beim Flashen mit, dass er für den Bootloaderbereich im Controller das BootloaderHexFile und für das EEPROM im Controller das EEPROM-HexFile HexFile nehmen soll?
Dann wird der Bootloader ueberschrieben. Wo ist die Applikation ?
Angehängte Dateien:
-
Unbenannt.png
67 KB
Hi, wenn der Bootloader läuft wird die Applikation im Betrieb später übr I2C geflasht. Daher braucht die Applikation zunächst nicht betrachtet werden (funktioniert im übrigen auch schon). Ich möchte lediglich wenn der Bootloader geflahst wird, parallel auch das EEPROM flashen. Den Bootloader überschreibe ich nicht da EPPROM und BOOTLOADER Adressen ja unterschiedlich sind. Das Foto zweigt nochmal wie ich es momentan mache. Erst den Bootloader und dann dann das EEPROM. Ich will es aber in einem Schritt machen. Bin mir sicher das man das im Makefile einstellen kann.
T. F. schrieb: > 5) Frage: Wie teile ich Atmel Studio beim Flashen mit, dass er für den > Bootloaderbereich im Controller das BootloaderHexFile und für das EEPROM > im Controller das EEPROM-HexFile HexFile nehmen soll? Wenn du in deinem Brenndialog keinen Abschnitt "brenne alles in einem Aufwasch in den Chip" siehst, dann wird das nicht funktionieren. EEPROM und Flash müssen vom Brennprogramm unterschiedlich behandelt werden. D.h. das Brennprogramm muss wissen, was wohin kommt. In den Hex-Files steht das aber nicht drinnen. Daher muss der menschliche Benutzer händisch eingreifen und festlegen: dieses Hex-File kommt ins Flash und dieses Hex-File kommt ins EEPROM. Wieviele tausend µC musst du denn programmieren? Einen Bootloader brennt man einmalig in den µC (ok, während der Entwicklung auch schon mal öfter), genauso wie die Defaultwerte. Wenn es also darum geht 5 µC vorzubereiten, dann hast du mit 2 mal of den Button drücken weniger Zeit verbrutzelt, als wenn du hier nach einer Lösung suchst. Und sobald der Bootloader im µC ist, ist das alles ja sowieso kein Thema mehr, denn dann wird ja über den Bootloader gebrannt.
Ich seh, zwei mal click ist zuviel... Ich hab's grad nicht da.. Kann man das Erase chip durch ein Program ersetzen?
T. F. schrieb: > Bootloader überschreibe ich nicht da EPPROM und BOOTLOADER Adressen ja > unterschiedlich sind. Die Sache ist schlimmer. Anhand der Adresslage, kann ein allgemeines Brennprogramm nicht entscheiden, was wohin kommt. Im File steht nur die Hausnummer drinnen. Ob das Paket jetzt in die "Kaiserstrasse" oder in die "Parkallee" zugestellt werden muss, ist anhand dieser Hausnummer nicht eruierbar. Der automatische Paketzusteller braucht also deine Hilfe, damit du ihm sagst: dieses Paket kommt in die Kaiserstrassse und dieses in die Parkallee. Und das weißt du deshalb, weil du derjenige warst, der dabei war, als ihr Inhalt zusammengestellt wurde. Deshalb, und nur deshalb, weißt du, was wohin muss. An den Paketen selbst ist das nicht mehr ablesbar.
> wenn der Bootloader läuft wird die Applikation im Betrieb > später übr I2C geflasht. Warum kann auf gleichem Weg nicht auch die Default-Belegung des EEPROMS geflasht werden? Kann das der Bootloader nicht?
Ich kann mir nicht vorstellen, dass das geht. Nicht nur, dass der zugehörige Dialog explizit zwei Menüpunkte mit zwei getrennten Dateien zur Verfügung stellt.In den Quelldateien gäbe es zusätzlich noch Adressduplikate. Code an 00A0 und EEPROM an 00A0 z.B. Möglicherweise würde der Brenner eine solche Datei sogar annehmen, da das Hex-Format sogar Lücken zulässt, aber es gibt keinen Befehl, der das Ziel definiert, im Hex-Befehlssatz.
> Als Programmer habe ich den AVR ONE!
Hast du da ein Command-Line Tool dazu?
Wenn ja und du wirklich 500 µC auf die gleiche Art und Weise
programmieren musst:
mach dir ein Bat-File, in dem 2 Aufrufe dieses Tools drinnen sind, und
welches die jeweils richtige Hex-Datei mit den richtigen Parametern in
die richtige Speicher-Sektion brennt.
Manachmal sind gute alte Command-Line Tools den ganzen Klicki-Bunti
Oberflächen haushoch überlegen. Vor allen Dingen dann, wenn es um
automatisierte Abläufe über mehrere Stufen geht. Wo du noch in einem
Dialog nach dem richtigen Button suchst, hat man in einem Bat-File (oder
auch einem Makefile) einfach das zuständige Programm 2-mal
hintereinander mit unterschiedlichen Parametern eingetragen und
aufgerufen.
So wie ich's begriffen habe, heissen die EEPROM files *.eep und die code files *.hex
i-Troll (c) schrieb: > So wie ich's begriffen habe, heissen die EEPROM files *.eep und die code > files *.hex Ist aber nur eine Konvention. Im Fileinhalt sind beide gleich. Auch ein EEP File ist ein Intel-Hex File.
Zumindest koennte ein abgestimmter Programmer, resp software die beiden unterscheiden.
Mein Programmer, resp Software kann das. Da muss ich nur angeben mach alles, und er macht das. Wil eben die files unterscheidabr sind.
Hi Warum erstellst du nicht ein ELF-File Mit dem Booloader und dem EEP-File? Programming Dialog -> Production File MfG Spess
Vielen Dank für Eure Hilfe.. @ Karl Heinz Buchegger: Also es ist wirklich gedacht später mehrere hundert µC zu flashen. Und da ich das Flashen nicht übernehmen werde, möchte ich halt Fehlerquellen vermeiden wie z.B. "es wurde nur der Bootloader gebrannt und das EEPROM zB nicht". Die Idee das EEPROM im Anschluss zu schreiben wenn der Bootloader läuft ist gut und wäre sicherlich eine Alternative. Möchte ich jedoch nur als letzte Lösung nehmen. Einen Flash Button alles in einem Abwasch gibt es leider im Atmel Studio nicht. Aber genausowas möchte ich nachbilden. Dies Sprichst du ja im Prinzip auch hier an: > "Manachmal sind gute alte Command-Line Tools den ganzen Klicki-Bunti > Oberflächen haushoch überlegen. Vor allen Dingen dann, wenn es um > automatisierte Abläufe über mehrere Stufen geht. Wo du noch in einem > Dialog nach dem richtigen Button suchst, hat man in einem Bat-File (oder > auch einem Makefile) einfach das zuständige Programm 2-mal > hintereinander mit unterschiedlichen Parametern eingetragen und > aufgerufen. Wie müsste ich das Makefile denn dann anpassen? Oder wie mussi ch das mit der Bat-Datei erstellen?
@spess53 Leider habe ich das noch nie gemacht. Klingt aber als ob es funktionieren könnte. Könntest du mir dazu die einzelnen Schritte erklären?
Thread beobachten
Seitenaufteilung abschaltenBitte 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.