mikrocontroller.net

Forum: Compiler & IDEs Intel Format in Generic verwandeln


Autor: Fritz7 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Fritz7 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kan mir niemand helfen? Verwendet ihr alle nur das Intel Format oder 
was?

Fritz7

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wir verwenden alle Programmer die mit vernünftigen Dateiformaten 
klarkommen :-)

Welchen Programmer hast du denn? Vielleicht gibt es eine alternative 
Software die ihex kann.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Fritz7 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ach so, Elektor... jetzt wird mir alles klar ;-)


Probier's mal mit dem Programm im Anhang.

Autor: Fritz7 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was funktioniert "nicht so richtig"? Bei mir funktioniert das Programm, 
und erzeugt genau die gleichen Ergebnisse wie der AVR-Assembler.

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Fleury (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Fritz7 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Fritz7 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.)

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: Fritz7 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Fritz7 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

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.