Atmel AVR ATTiny 2313 & Intel Hex

Siegfried Schmidt schrieb:

Keine Ahnung, worüber du da schreibst. In den Umgebungen, in denen ich arbeite, wird TIFF G3 seit mindestens 15 Jahren sauber unterstützt.

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
 Click to see the full signature
Reply to
Joerg Wunsch
Loading thread data ...

Rafael Deliano schrieb:

Genau. Warum eine Lösung nehmen, die dem dritten Jahrtausend gerecht wird, wenn man stattdessen einem Dateiformat aus den Anfangszeiten der Computerei noch drei weitere Knöpfe an die Backe nähen kann, um an seinen Unzulänglichkeiten vorbei zu arbeiten...

Muss man ja auch nicht. Auf derartigen Geräten /entstehen/ diese Daten ja nicht, sondern sie entstehen auf 32- und 64-Bit-Maschinen, und zu allem Überdruss ist ELF genau das Format, mit dem die Toolchain dort ohnehin bereits arbeitet. Von einer derartigen Maschine auf ein kleines Programmiergerät mit 8-bit-Controller muss es sowieso auf die eine oder andere Weise gelangen, und die dafür notwendige Software kann dann auch gleich eine ELF-Datei lesen.

Es gibt übrigens in der Tat darin auch Offsets, allerdings sind die etwas größer als die von dir gewünschten (und damit unabhängig vom tatsächlich zu benutzenden AVR, also bei allen AVRs gleich). Der EEPROM müsste 0x820000 haben als Offset, bei den Fuses müsste ich erst nachgucken. Mehr als 16 bits muss man im Intel Hex sowieso verarbeiten können, da es AVRs mit mehr als 64 KiB Flash-ROM bereits seit vielen Jahren gibt.

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
 Click to see the full signature
Reply to
Joerg Wunsch

Ack. Ich sehe da auch keinen wirklichen Leidensdruck, also warum bleibt man nicht einfach bei der Methode die bei AVR seit allen Zeiten funktioniert hat: Man macht einzelne Files (flash.hex, eeprom.hex, fuses.txt, lock.txt) und liefert das ganze als ZIP-File ab. In der fuses.txt steht dann z.B.:

---------------------------------------------------------------------- # Low High Extended E0 DA FF

---------------------------------------------------------------------- Das versteht jeder Mensch, so dass er es notfalls von Hand in seine Software eintragen kann und einen Parser dafuer zu schreiben waere auch trivial. Die Spec steht gleich mit drin und man muss nicht erst hunderte Seiten PDF runterladen ;-)

Mir kommt das ganze ein bisschen so vor wie das Spielchen ein Configfile in Textform auf XML umzustellen. Das mit ELF sehe ich zwar prinzipiell ein, weil es aus dem GCC sowieso herausfaellt, aber bis sich das als Austauschformat durchsetzt werden noch viele Jahre vergehen - und letztlich wird es IMHO mehr neue Probleme schaffen als es vorhandene loest.

Just my 0.02EUR

Micha

Reply to
Michael Baeuerle

Ein Teil der Software läuft als Bytecode der als ASCII-File über V24 in ein 24C02 EEPROM compiliert wird. Damit ist für triviale Unterschiede wie unterschiedliche Speichergrösse ausreichend Flexibilität vorhanden.

Das Programmiergerät basiert aut einem 8 Bit Controller mit 32kByte Flash und 0,5kByte RAM. Da will man kein ZIP-File dekodieren.

Es wird wohl so aussehen ( System basiert auf FORTH ):

Der Anwender kann mit cut&paste sein Intel-Hex per ASCII-Editor einbauen und die Fusebits eintippen. Das über V24 ankommende File wir sofort binär in das 24C512 EEPROM eingelesen, bzw Datenworte mit D-E! gespeichert. Da der Datenspeicher intern bigendian sein soll wird abschliessend mit /ENDIAN dieser Teil nochmal umgegraben.

MfG JRD

Reply to
Rafael Deliano

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.