Hier gerade am Bau eines Programmiergeräts. Dabei sollte man IntelHex oder ähnliches über V24 ins Geräte einlesen können. Gehe ich recht in der Annahme daß das übliche Format für den 16 Bit Programmspeicher 8 Bit IntelHex little endian ist ? Der Controller hat ja wohl noch weitere Speicherbereiche ( EEPROM, Fuse Bits, Lock Bits ). Das ist beim 68HC08 kein Problem weil alles in der 64k MemoryMap liegt und damit im S19-File abgelegt werden kann. Gibt es ein Fileformat, ASCII-Format das diese Daten enthält das von Atmel, GCC und ähnlicher Software einheitlich unterstützt wird ?
F=FCr Windows-Nutzer w=FCrde ich mal einen Blick auf PonyProg riskieren, das kann alle m=F6glichen Varianten verdauen und passend f=FCr den Controller ausspucken (sogar beim 64-Bit-Windows).
F=FCr Linux gibt es wohl auch Software, die auch die verschiedensten Formate umwandeln kann. (big endian, little endian und intel-hex, motorola-hex)
Das interessante beim Intel ist aber dass die je nach Einstellung der CPU-Flags oder der Befehlspr=E4fixe so fast alles in HW fressen.
Wenn du auf ein einheitliches Dateiformat anspielst, was alle Programme einheitlich erkennen ohne dass du Ihnen sagst was es ist (Intel-hex little endian): Vergiss es, jeder backt da seine eigenen Br=F6tchen.
Allerdings gibt es in Details durchaus Mäkligkeiten diverser Software. Manche will z.B. zwingend wenigstens einen Extended Segment Address Record vor den Daten sehen, obwohl beides bei den meisten AVRs ja eigentlich über ist.
Andere Software wiederum kommt nicht mit Mehrfachvorkommen von Zieladressen klar, wie er bei Vorhandensein solcher Records möglich ist und von mancher Software auch tatsächlich unter bestimmten Umständen generiert wird.
Nein, es existiert kein anerkanntes und weithin unterstütztes Adressmapping für Lock- und Fusebits sowie EEPROM-Daten. Atmel war wohl anfangs überhaupt nicht daran interessiert, diesbezüglich einen Standard zu setzen und jetzt ist es wohl schon zu spät dazu.
Üblich sind getrennte *.hex-Dateien für EEPROM-Inhalte (Basisadresse wie beim Flash 0000:0000). Für Lock- und Fusebits hingegen gibt's überhaupt nichts auch nur halbwegs einheitliches.
Stimmt so nicht mehr. Spät, aber nicht zu spät, wurde nun begonnen, ELF selbst dafür zu benutzen. Müsste mittlerweile von AVR Studio unterstützt werden, während ich beim AVRDUDE da noch hinterher hinke. Die Idee dahinter ist, dass man (ähnlich wie mit dem configuraton word bei PICs) die Fuses über Pseudo-Befehle im C-Programm angeben kann (letztlich Makros, die initialisierte Daten in speziell benannten sections der ELF-Datei anlegen).
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
) hat einen einheitlichen lokalen 64kByte Speicher und da werde ich wohl das Programm unten und das EEPROM und die Lock/Fuse-Bits per Offsets weiter oben ablegen. Die Steuerung per Bytecode wird damit dann schon klarkommen.
Das ist eine andere Spielwiese. Damit kriegst du den Kram aus den Quelltexten in irgendein proprietäres Objectfile und von da auch noch in irgendein proprietäres Binary. Da endet die Sache dann aber, weil für den Schritt vom Binary zum Austauschformat Hex-File eben genau dieses Adressmapping fehlt, welches aus deinen speziell benannten Sections eine spezielle Segmentadresse im Hexfile macht. Benannte Sektionen gibt es nämlich in einem Hexfile nicht.
Natürlich kann man prinzipiell beliebige Adressen dafür benutzen (außer denen, die den Flash überlappen), sie müssten eben bloß von jeder Software gleich interpretiert werden. Irgendwer muß also z.B. festlegen, daß ab fe80:0000 die Inhalte von Lock- und Fusebits abzulegen bzw. zu finden sind und meinetwegen ab e000:0000 der EEPROM-Inhalt. (oder adäquates mit linearer Adressierung, scheißegal)
Es hat aber niemals jemand gemacht und heute ist es angesichts der Vielzahl verfügbarer Entwicklungssysteme fast unmöglich geworden, noch nachträglich einen einheitlichen und überall akzeptierten Standard durchzusetzen.
Ich sehe da nur eine Chance, wenn sich Atmels Studio-Leute, die avr-gcc-Leute und der BASCOM-Entwickler an einen Tisch setzen. Auf diesen drei Umgebungen dürften zusammen wohl >90% der Entwicklung für Atmel AVRs ablaufen. Zusammen (und nur zusammen) gäbe es eine Chance, sowas jetzt noch zum akzeptierten Standard zu machen. Wenn's auf den drei Systemen benutzt wird, würde der Rest sicher über kurz oder lang folgen (oder mittelfristig sterben)
Damit deckst du gängige ATmegas schon nicht mehr ab, insbesondere wenn auch noch ein Teil des Adressraumes für die Sonderaufgaben abgezwackt werden soll. De facto wäre beim ATmega32 dann Schicht im Schacht. Das wäre mir zuwenig.
Ja klar. Aber viel weiter oben, keinesfalls in dem Adressraum, der schon für den Flash heute verfügbarer AVRs vorn und hinten nicht langt.
Klar, du kannst das für deinen Zweck sicher so machen, aber es hat definitiv nicht das Zeug, ein Standard zu werden. ;o)
ELF würde ich jetzt nicht als proprietär bezeichnen. Das Format ist gut dokumentiert und gut handhabbar, und kann vor allem wesentlich mehr als Hex.
Beim Hexfile brauchst du ein Adressmapping. Bei ELF brauchst du eben die entsprechenden Sonder-Sektionstypen. Davon ist eins nicht besser oder schlechter als das andere, es muss halt nur jemand definieren und der Rest mitmachen. ELF hat den Vorteil, dass es sauberer ist, weil der Platz für Sonder-Sektionen direkt vorgesehen ist. Mit Hex fliegst du auf die Nase, wenn Schaltkreis X+1 auf einmal dort Flash hat, wo Schaltkreis X noch Fusebits hatte.
Genau das ist der Grund, warum man sich ELF statt irgendwelcher ominöser Offsets in Hex- oder Srecord-Dateien ausgesucht hat. Eine ELF-Datei kann man mit mehreren frei erhältlichen Bibliotheken problemlos zerlegen.
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Natürlich kann es wesentlich mehr als Hex. Viel zu viel mehr sogar. Unter anderem deshalb ist es als einfaches Austauschformat für kleine Controller auch total ungeeignet und wird sich _als solches_ nicht durchsetzen.
Das Adressmapping hätte doch rein garnix mit mit dem realen Adressraum zu tuen. Schließlich liegen EEPROM, Fusebits und Flash ja überhaupt nicht in einem gemeinsamen Adressraum. Es wäre eine genauso willkürliche Festlegung, wie es irgendwelche Spezialsektionen sind.
Jaja, solche berühmten Sätze mit ,niemals' haben schon ganz andere Leute von sich gegeben. ;-)
Hier ist ja auch nicht viel *auszutauschen*, sondern es sind einfach mal Daten weiterzugeben. Der Overhead ist übrigens im Vergleich zu dem aufgeblähten ASCII-isierten Hex- oder Srecord-Dateien schon bei kleinen Speichergrößen fast zu vernachlässigen, während bei großen Speicherinhalten die ELF-Datei kleiner ist als eine Hex-Datei.
Die Logik, wonach ein Dateiformat, das mehr Möglichkeiten bietet, sich im Vergleich zu einer Krücke wie Intel Hex sich bereits vom Prinzip her nicht durchsetzen /kann/, darfst du nochmal erläutern. :)
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Warum nicht? Bringt heutzutage nur nicht mehr so viel, da die dort erreichbaren Kompressionsgrade durch heutige Dateiformate in den meisten Fällen überholt worden sind. Eine Ausnahme dabei ist es sicher, falls irgendwelche Informationen nur als echtes Fax vorliegen, da TIFF eine G3 explizit als mögliche Codierung kennt. Damit ist das dann kleiner als bspw. PNG oder JPEG (allerdings bei der gleichen relativ schlechten Qualität wie ein entsprechendes Papierfax).
Dass man ein Bild eher nicht als unkomprimierte 24-bit-Datei mailt, ist wohl keine Frage. Aber nicht alles, was hinkt, ist ein Vergleich: eine Intel-Hex- oder Motorola-Srecord-Datei hat ja einen schlechteren ,,Kompressions''grad als ELF.
Davon abgesehen geht's hier ja nicht um einen ,,Austausch'' zwischen x-beliebigen Partnern, sondern um die Weitergabe einer CPU-spezifischen Information an die entsprechende Programmiersoftware, die notgedrungen ohnehin controllerspezifisch ist.
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Irgendwie schon seltsam. Zuerst wird hier der Mangel einer Initiative des Herstellers beklagt, sich um ein Dateiformat bemüht zu haben, das alle notwendigen Informationen enthält. Wenn man darauf hinweist, dass es eine derartige Initiative (wenn auch spät) gibt, dann wird gleich ein ganzes Bündel Haare in der Suppe gesucht... Was der Bauer nicht kennt, das frisst er nicht?
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Letztlich hätte es für Atmel gereicht für seine unterschiedlichen Datenbereiche fiktive Adressen im Datenblatt zu vergeben und für 16 Bit Daten festzulegen daß little-endian. Dann sind die beiden gängigen Hex-Formate problemlos verwendbar. D.h. für diesen Controller
000 - 7FF FLASH 16 bit littleendian
800 - 87F EEPROM 8 bit
900 - 901 lockbits 16 bit littleendian
902 - 903 fusebits 16 bit littleendian
904 - 905 extended fusebits 16 bit littleendian
Dieses da
formatting link
sieht nicht aus als ob es für 8 Bit Controller und kleine Programmiergeräte geeignet wäre.
Die Initiative etwas in ein neues Format zu packen führt allein nicht notwendigerweise zu Lösung des Problems. Die (uralte) Möglichkeit, G3- Grafiken in Tiff zu transportieren hat von sich auch nur wenig bewirkt, erst die breitere Verwendung von CTI-Software hat in neuerer Zeit den nötigen Druck erzeugt, dass die Formate auch korrekt unterstützt werden.
Das fliegt dir aber eben auf die Nase, wenn dann das nächste Controllermodell auf einmal mehr Speicher hat. "Eigentlich alles kompatibel, aber die Software bitte doch mal neu generieren, weil sich unser Adressmapping geändert hat".
ELF kann von Objektdateien über ausführbare Programme, Bibliotheken und Coredumps alles mögliche darstellen. Ich hab das Format sogar mal für Statefiles eines inkrementellen Linkers benutzt. Natürlich ist die allumfassende Beschreibung daher etwas dicklich.
Für ein Programmiergerät ist nur die "execution view" interessant. Kurzform:
- ELF-Header lesen und Adresse der Program Table auslesen
- Program Table auslesen
- iteriere über alle Program-Table-Einträge: - wenn Typ=PT_LOAD (IIRC), brate das Zeuch in den Flash - optional noch eigene Typen für Fusebits, EEPROM usw. verarbeiten
Klar, das ist ein bisschen mehr als bei Hex. Aber nicht wirklich schwer. Ich generiere hier u.A. Bootimages, wozu ich die Dateien, die aus dem Compiler rausfallen, parsen muss. Letztlich hat mich der ELF-Parser nicht viel mehr Zeit gekostet als der Hex-Parser, und schneller ist es auch noch (ELF sagt eben: hier kommen jetzt soundsoviel kByte Daten, da allokiert man einmal und lädt am Stück; Hex bringt dir die Daten in
32-Byte-Häppchen vorbei). Auch die Gegenrichtung, aus einem Bootimage wieder ein ELF generieren, war nicht schwer.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.