Also hab mal erste Schritte mit acrgcc und studio 3 gemacht. Ging zwar ne Ewikeit bis das ganze funktioniert hat aber gut. Das Hex file das der AVR gcc erstellt ist aber im Intel Format. Meine Prog. software Akzepiert aber nur das Generic Format Adresse:Wert Wie kann ich das im gcc umstellen? Gibt doch sicher irgenweine Direktive für das? Im makefile? Fritz7
Kan mir niemand helfen? Verwendet ihr alle nur das Intel Format oder was? Fritz7
Wir verwenden alle Programmer die mit vernünftigen Dateiformaten klarkommen :-) Welchen Programmer hast du denn? Vielleicht gibt es eine alternative Software die ihex kann.
Stimmt, ich verwende auch nur das Intel-Hex. Alle meine Programmer kommen damit klar. Von "Generic" habe ich bisher noch nie was gehört. Das einzige andere gebräuchliche Format, daß ich kenne, ist "Motorola S-Record". Manche einfache Programmer können nur das reine Binary, aber da muß man dann alle ungenutzten Lücken auffüllen. Im Web findest Du vielleicht Konverterprogramme. Peter
Generic ist ein bekanntes Format. Beim AVR Studio 4 kann man das bei AVR Assembler Setup wählen: Intel, Motorala S, und Generic. Hab den einfachen Elektor Programmer aus dem Halbleiterheft. Diese Software kann eben nur das Generic Format lesen. Es ist ziemlich einfach Aufgebaut: Adresse im Speicher:Code Fritz7
Ach so, Elektor... jetzt wird mir alles klar ;-) Probier's mal mit dem Programm im Anhang.
Ok so richtig funktioniert das mit deinem prog. nich... Es gibt 100% irgend etwas was man beim gcc umstellen kann das man das Generic Format raus bekommt. Die Bemerkung über meinen Programmer hab ich überhört! (zumals nicht um den Programmer sondern um die Software geht) Fritz7
Was funktioniert "nicht so richtig"? Bei mir funktioniert das Programm, und erzeugt genau die gleichen Ergebnisse wie der AVR-Assembler.
Es gibt 100%ig nichts, das man bei avr-objcopy ,,umstellen'' könnte, damit es dieses ominöse Format erzeugen würde. Allerdings ist der Sourcecode Dein, wenn Du denkst, daß das Format Deines Programmers wirklich so verbreitet wäre, dann kannst Du ja sicher einen neuen Ausgabetreiber für die libbfd schreiben, der "Generic" erzeugt... Wenn Du einfach nur (auf 'ner Kommandozeile!) mal avr-objcopy eingibst, siehst Du in den letzten Zeilen, welche Dateiformate er unterstützt.
@Fritz Bau besser meine ISP Programmierschaltung nach: http://www.mysunrise.ch/users/pfleury/avr-starterkit.html Die funktioniert mit Pony Programmer Programmer-Software, die Intex Hex oder Motorola S-Records Files direkt versteht und auch unter Win2000/XP oder Linux einwandfrei läuft.
OK, ich will das hier: (Intel) :020000020000FC :100000000FEF01BB02BB0A951A95F1F72A95E1F7AC :02001000F9CF26 :00000001FF In dieses hier: (Generic) 000000:ef0f 000001:bb01 000002:bb02 000003:950a 000004:951a 000005:f7f1 000006:952a 000007:f7e1 000008:cff9 Dein prog macht aber aus obigem, dieses: (oder so ähnlich) 00000f:4231 000010:3042 000011:4232 000012:3042 000013:3941 000014:3135 000015:3941 000016:4635 000017:4631 000018:3237 000019:3941 00001a:4535 00001b:4631 00001c:4137 00001d:0a43 :02001000F9 00001e:303a 00001f:3032 000020:3130 000021:3030 000022:4630 000023:4339 000024:3246 000025:0a36 :00000001FF Weis auch nicht wie do auf bintogen kommst, von bin war nie die Rede! Fritz7
Dann mach halt einfach vorher das hex zu einem bin, z.B. mit http://www.keil.com/download/docs/hex2bin.zip.asp oder avr-objcopy -I ihex -O binary hexdatei binaerdatei
Kann er ja auch gleich statt des ihex aus dem letzten objcopy seines Makefiles machen lassen... Wie verbreitet ist dieses "Generic" eigentlich wirklich? Gibt's dafür irgendwo einen Standard oder eine offizielle Beschreibung, oder ist das eher ein privates Süppchen eines einzelnen Herstellers? Eventuell will ja mal jemand ein Backend für BFD schreiben, so daß das offiziell in objcopy drin ist?
Jo ein Privaten Süppchen DES Herstellers! Nämlich Atmel! Aber ok, hat sich erledigt. Ich programmier jetz halt weiter in Assembler, mit Studio 3... Schon die Installation des gcc find ich viel zu kompliziert und dann noch das gebastel bis man son einfaches Format draussen hat. Trotzdem danke, für eure Mühen. Fritz7
Ja gut, also ein privates Süppchen eines Herstellers. Heißt nicht, daß man es nicht trotzdem supporten könnte. Wenn wir uns Mühe geben, AVR-COFF offiziell mit einzubauen (obwohl Atmel seit Jahren erzählt, daß sie endlich auch ELF unterstützen wollen...), warum nicht auch dieses Format? Aber das beantwortet den zweiten Teil meiner Frage nicht: ist das irgendwo dokumentiert? (Nicht daß das bei Atmel was bedeuten würde, die dokumentierte Schnittstelle zum STK war ja auch kaum draußen, schon wurde sie wieder inkompatibel geändert...) Mach ruhig weiter in Assembler, wenn das für Dich eine Option ist. Für mich wär es keine, dafür ist mir mein bißchen Freizeit einfach zu schade. (Keine Sorge, ich bin in meinem Leben schon an ausreichend Assemblern vorbeigekommen, angefangen beim Macro-11 der PDP-11/RSX.)
Eine Google-Suche nach "generic hex" oder "atmel generic" bringt keine relevanten Ergebnisse, also ist stark anzunehmen dass das Format nur aus der Langeweile eines Atmel-Programmierers entstanden ist und keine wirkliche Bedeutung hat. Alle Generic Hex-Dateien die ich bis jetzt gesehen habe besitzen folgenden äußerst primitiven Aufbau: Adresse:Datenwort Dürfte trivial sein das in die binutils zu integrieren, aber es ist praktisch nutzlos.
Ja, wahrscheinlich ist es trivial, wäre als Hausaufgabe für einen Informatik-Studenten geeignet :), wenn da nicht diese ellenlange Zeremonie bei GNU wäre, bis man dort auch Code submitten darf... Außerdem besteht BFD darauf, auch eine Leseroutine für jedes Format zu besitzen, d. h. man darf dann eine solche Datei anschließend in avr-objcopy füttern und sich ein ELF-File draus basteln lassen. ;-)
Auch tavrasm unterstütz das Atmel Generic Hex Format. Jetz habe ich endlich per google suche passende Konverter gefunden. Ob das irgenwo dokumentiert ist, weis ich nicht. Eine Google Suche hat bei mir sofort Resultate gebracht. Atmel Generic Hex Code war das Suchwort. Ich bin nach wie vor davon überzeugt, das avr-gcc dieses Format kennt. Jeder sonstige Compiler unterstützt es auch. Fritz7
Du kannst ja überzeugt sein, wie Du willst. Ein paar andere Leute dagegen hier wissen, was von den Tools unterstützt wird. Du willst es nur nicht glauben. Ansonsten kannst Du Dich ganz einfach selbst davon überzeugen, indem Du "avr-objcopy --help" (ohne die Anführungszeichen) auf der Kommandozeile aufrufst. In der vorletzten Zeile findest Du eine Liste der unterstützten Formate. Du solltest einfach dran denken, daß im Gegensatz zu tavrasm, den Atmel-Tools etc. pp. avr-gcc und avr-binutils eine Toolchain sind, die keineswegs in irgendeiner Form als Projekt für den AVR gestartet worden sind; es handelt sich vielmehr um einer Portierung einer Toolchain, die ...zig verschiedene Architekturen und Binärformate unterstützt, auf den AVR. Solange sich halt noch niemand hingesetzt hat, AVR-"Generic" dafür zu schreiben, gibt es das dann auch nicht dort. Da es leider im Gegensatz zu seinem Namen alles andere als wirklich "generic" ist, hat es aber eben auch noch niemand geschrieben, der nicht aus der AVR-Ecke kommt, während wir wohl für Dinge wie Intel Hex oder Motorola Srecord einfach von den anderen (nicht-AVR) Architekturen profitieren, da diese Formate allgemein sehr weit verbreitet sind. Keine Ahnung, warum Atmel/AVR überall ihr eigenes Süppchen kochen mußten. Deren "nordic object format" verstehen ich ja zur Not noch (das ist das Ausgabeformat ihres mitgelieferten Assemblers): ein simples Format, das kaum Debuginformationen transportieren kann (für C praktisch ungeeignet), dafür war es sicher schnell zu implementieren. Aber schon, warum sie sich als offizielles Austauschformat noch für COFF entschieden haben, wo doch zu diesem Zeitpunkt die Mängel in der Formatdefinition von COFF alle schon lange bekannt waren und die Ablösung ELF bereits praxiserprobt war, bleibt mir völlig unklar. Gleiches gilt eben auch für dieses "Generic", Intel Hex und Motorola Srecord sind jahrzehntealte Standards für EPROM-Formate, und sooo schwierig sind sie ja nun wirklich nicht zu implementieren.
Das hier sollte das Problem lösen: http://srecord.sourceforge.net/ Wenn ich es recht in Erinnerung habe, will Eric das auch mit in WinAVR aufnehmen, zumindest streut er das Announcement von SRecord regelmäßig auch selbst mit breit.
Danke, für deine Bemühungen. Is jetz en bisschen OT: Jetz hab ich aber en Problem das SRecord überhaupt zu compilieren. Wahrscheinlich liegt es daran das ich gcc 3 irgenwas 2 glaub ich habe. (Red Hat 8) Hat es bei dir funktioniert? Wüstest du etwas darüber, wie man dieses problem beheben könnte? Einfach en älteren gcc zu installieren soll noch kompliziert sein. Fritz7
Nö, funktioniert bei mir allerdings auch nicht. Ich kenne mich aber mit der Syntax der STL zu wenig aus um beurteilen zu können, was da foul ist. Frag doch mal den Autor (Fehlermeldung nicht vergessen).
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.