Intel Format in Generic verwandeln

Kan mir niemand helfen? Verwendet ihr alle nur das Intel Format oder 
was?

Fritz7

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

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

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

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.)

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).