Hallo ReAVR-Freunde, es freut mich zu lesen, dass mein AVR-Dis- oder vielmehr Reassembler (weil er direkt wiederverwertbaren Assemblercode erzeugt) auch in den 2020ern noch immer wieder einmal Thema ist. Vielleicht freut es Euch dann auch, dass ich ihn Ende des letzten Jahres noch einmal angepackt habe, um ihm nun auch den Umgang mit den vielen neuen AVRs seit den XMegas beizubringen. Das hat sich zwar als ein etwas umfangreicheres Unterfangen herausgestellt, aber ich bin dabei und hoffe, in den nächsten Monaten eine erste Testversion auf meine Website stellen zu können. Über den Namen bin ich mir noch nicht klar - "ReAVR_II" oder "ReAVRplus" - doch einen neuen Namen wird die neue Version auf jeden Fall erhalten. Außerdem wird es ein Companion-Tool geben, das die avrasm-*def.inc-Dateien aus den Studio-7- oder MPLAB-Repositories liest und in die ReAVR-internen Listen mit MCU-Spezifikationen und IORegister-Adressen umwandelt. Nicht zu vergessen die Möglichkeit, eigene Kommentare einzufügen, wahlweise am Ende einer Zeile oder als neue Zeile, wegen derer ich die ganzen Änderei überhaupt angefangen hatte... ;) Ich werde die neue Version ASAP veröffentlichen. Also "stay tuned." Beste Grüße Johannes
Ich wüßte nicht, wozu man so etwas gebrauchen könnte. Interessante Geräte sind gelockt, da kommt man also an den Code nicht ran. Und größere Projekte sind in Hochsprachen geschrieben, da sieht der Assembler wie Kraut und Rüben aus. Bei komplexen Projekten ist neu programmieren oftmals einfacher als reassemblieren.
Peter D. schrieb: > Ich wüßte nicht, wozu man so etwas gebrauchen könnte. In dem Moment, in dem du das Ding brauchst, weißt du, wofür du das brauchst. Oliver
Oliver S. schrieb: > In dem Moment, in dem du das Ding brauchst, weißt du, wofür du das > brauchst. Hä?
Ich bin gespannt! Wie schaut es mit der Unterstützung der ATTiny4/5/9/10 aus? Da hätte ich das ein oder andere Projekt, bei dem das super nützlich wäre!
Oliver S. schrieb: >> Ich wüßte nicht, wozu man so etwas gebrauchen könnte. > > In dem Moment, in dem du das Ding brauchst, weißt du, wofür du das > brauchst. Und Apfelmus ist Mus aus Äpfeln!
Ghidra … auch wenn es ausgerechnet von der NSA kommt, es ist Opensource, und es zimmert gleich noch ein C-Code-Gerippe zurecht. Hab's gerade mal auf einem aktuellen AVR-Projekt (mit ATtiny204) probiert. Gut, die Vektortabelle, die sie benutzen, hat nicht die korrekten Namen (und Länge), muss man halt korrigieren. Aber ansonsten schon durchaus beeindruckend, was sie da aus dem Stand heraus erkennen. Das das nicht ohne Interaktionen geht, ist natürlich klar. J. A. schrieb: > weil er direkt wiederverwertbaren Assemblercode erzeugt Geht auch mit dem ganz normalen Disassembler aus den Binutils. Man muss nur die Headerzeilen und die Spalten mit Adressen und Opcodes wegwerfen. Gerade probiert:
1 | avr-objdump -d myfile.hex --disassemble-zeroes -b ihex -m avr5 -j .sec1 | sed -e '1,7d' -e 's/^..................//'> foo.s |
2 | avr-as -mavr5 -o foo.o foo.s |
3 | avr-ld -o foo.elf foo.o |
4 | avr-objcopy -O ihex foo.elf foo.hex |
5 | diff -u myfile.hex foo.hex |
6 | # -> keine Unterschiede gefunden |
Ey, @Folks, macht doch bitte J.A. nicht nieder. Das Programm ist kostenlos benutzbar, hat ne freie Lizenz und ist unter anderem in Delphi geschrieben. Als Hacker oder reverse engineer ist man bei seinem Hobby auf jeden "Strohhalm" angewiesen, der einem gereicht wird, da ist das Proggy dann doch gut! @J.A., wie willst Du das Millitär von Deinem Proggy fernhalten? Hast Du da ne besondere Strategie? ;-O ;-))) mfg
J. A. schrieb: > Über den Namen bin ich mir noch nicht klar - "ReAVR_II" oder "ReAVRplus" Üblich ist die Vergabe von Versionsnummern: An erster Stelle für Mayor-Releases (hochgezählt bei wesentlichen Änderungen, Inkompatibilitäten) und danach Minor (Bugfixes, Tippos in der Doku, etc.). Ansonsten wird's irgendwann komisch Tool ToolII ToolPlus ToolBesser ToolNochBesser ToolSuperGutUndNochViiielBesser ToolSuperHypeMegaUnglaublichHyperGutBestEverII
Lotta . schrieb: > und ist unter anderem in Delphi geschrieben. Macht das irgendwas besser, außer daß es mancher Leute religiöse Gefühle bedient?
Harald K. schrieb: > Lotta . schrieb: >> und ist unter anderem in Delphi geschrieben. > > Macht das irgendwas besser, außer daß es mancher Leute religiöse Gefühle > bedient? Hey, Du hast es genau erfasst: Philippe Kahn hat damals in der Wende den "Raubkopier-Ossis" nicht juristisch nachgestellt, sondern Ihnen ne kostenlose Lizenz gegeben, also ihre Raubkopien legalisiert. Das hat natürlich Auswirkungen auf die Loyalität der Leuts zu Borland bis heute, auch wenn Borland ja inzwischen leider zigmal umfirmiert wurde. Hatte bestimmt auch mit guten Beziehungen des Ostblocks mit Frankreich zu tun, (der osten hat zb. das Secam Fensehsystem übernommen) Philippe war ja Franzose. mfg
Harald K. schrieb: > Muss man nicht verstehen. Es war einfach ne geile, interessante Zeit damals. Philippe hat damals einfach den "Ossis" geholfen, die mit 100 DM Begrüßngsgeld in ne neue Gesellschaftsordnung mit "keiner Ahnung von Tuten und Blasen" gestoßen wurden. Heut machen die Superreichen und Politiker lieber Bombenangriffe auf Krankenhäuser und Kindergärten. das macht ja auch mehr Spass. :-((((((( mfg
Echt fantastisch, was ich so alles zu lesen bekomme. Na dann stelle ich mal in den Raum, dass ich von Geburt Niedersachse bin und mein ganzes bisheriges Leben dort verbracht habe, von gelegentlichen Ausflügen in andere Gegenden Deutschlands und Europas abgesehen. Dass ich etliche Programme in 8080- und Z80-Hex-Code geschrieben und meinen HD64180-CP/M-Computer erst aufgegeben habe, als ich mich, von außen gedrängt, in die AT-kompatible Welt begab. Da waren dann schon alle 8088-, 8086-, 80186- und 80286-Maschinen an mir vorbei gegangen, und das damals noch übliche MS-DOS hatte schon die Version 5 erreicht. Von Windows war in der Zeit noch allenfalls gerüchteweise zu hören, bis Windows 3.0 herauskam, und als soweit erschwingliche höhere Programmierumgebung gab es nur TurboPascal. Linux und Open-Source waren damals noch überhaupt kein Thema. Ich war damals und bin es bis heute in einem Betrieb der produktiven Industrie beschäftigt und hatte/habe daher einige Möglichkeiten, stellte aber irgendwann fest, dass ich beim Programmieren durcheinander kam, als ich versuchte, alle meine Aufgaben in C zu erledigen. Weshalb ich mich entschloss, C nur für meine AVR-Projekte zu verwenden, und für meine PC-Anwendungen Pascal, im weiteren dann Delphi. Diese Entscheidung war rein pragmatisch und hat nichts mit religiösen Gefühlen zu tun. Wenn derlei je im Spiel gewesen wäre, hätte ich mich auch wohl kaum darauf eingelassen, für den c't68000 Anwendungen in Pearl zu schreiben, oder die Testprogramme für ein Transputer-Projekt in Occam. Im Übrigen bin ich am Überlegen, den neuen ReAVR, wenn er erstmal alles so tut wie gewünscht, in ein Lazarus-Projekt umzuwandeln und ihn anschließend dem Open-Source-Verfechter aus der Runde zur weiteren Betreuung zu übergeben. Dann wären seine Mäkeleien mit einem Schlag aus der Welt. Und ich hätte nichts mehr damit zu tun. Ein paar Anmerkungen zu speziellen Kommentaren noch: Die erste zum Namen. Klar ist die übliche Methode, einfach die Version hochzuzählen, und das habe ich in der Vergangenheit auch immer so gehalten. Nur gehen diesmal die Änderungen so weit, dass ich mir einfach solche Fragen ersparen möchte wie "Warum geht dies und das auf einmal nicht mehr?" Die zweite dazu, wozu ReAVR gut ist. Lieber Kommentator, es wird Dich wahrscheinlich überraschen, wie viele AVRs für professionelle embedded Anwendungen ungelockt sind. Tatsächlich sind mir bei meinen Untersuchungen zu meiner eigenen Überraschung nur wenige gelockte untergekommen. Ansonsten kann man sich, wenn man mit Assembler so weit vertraut ist, problemlos in den Hex-Code eines Compilers einlesen. Ok, bei größeren Codes ab 8 oder 16KB wird das zeitaufwändig, und man muss entscheiden, ob man es wirklich vertreten kann. Und zu den binutils: Klar bekommt man damit mit etwas Editor-Gefummle auch ein wieder assemblierbares Disassembly hin. Aber auch nur das, mit allen kryptischen Labels, wie sie sind. Und wenn man dann zum Beispiel bei den in/out-Instruction die richtigen IO-Namen haben will, muss man für jeden einzeln ein Suchen/Ersetzen anstoßen. Genau das macht aber ein Reassembler wie ReAVR von sich aus automatisch - und interaktiv.
J. A. schrieb: > Genau das macht aber ein Reassembler wie ReAVR von sich aus automatisch > - und interaktiv. Wie geschrieben, Ghidra letztlich auch, und das erzeugt auch gleich noch ein C-Code-Gerippe. Man könnte den Aufwand also eigentlich auch da reinstecken, dass Ghidra von Haus aus noch möglichst viele AVRs mit all ihren Register-Details kennt, damit man diese automatisiert konvertieren kann. > Nur gehen diesmal die Änderungen so weit, ReAVR NG :-) Aber auch das hätte natürlich das Problem, was Johann beschreibt: wenn die übernächste Version wieder alles über den Haufen wirft, suchst du wieder einen neuen Namen. Daher die übliche Konvention, dass man bei inkompatiblen Änderungen die major number hochzählt. Aber seit Feuerfüchse und dergleichen alle nasenlang die Nummern komplett hochzählen, ist das natürlich auch irgendwie Vergangenheit.
J. A. schrieb: > Ok, > bei größeren Codes ab 8 oder 16KB wird das zeitaufwändig, und man muss > entscheiden, ob man es wirklich vertreten kann. Ja, bei Anwendungen über das Anfängerniveau hinaus wird das schnell unhandlich. Ich habe schon lange keine Hemmungen mehr, float, printf, scanf zu verwenden, um bequem programmieren zu können. Auch Structs und Arrays sehen in Assembler extrem kryptisch aus, erhöhen aber in C erheblich die Lesbarkeit und Flexibilität. Den typischen Spaghetticode möchte man eigentlich nicht mehr haben. Und um Fehler zu suchen oder Abläufe zu verstehen, ist es oftmals einfacher, das Programm im Debugger laufen zu lassen.
Jörg W. schrieb: > Wie geschrieben, Ghidra letztlich auch, und das erzeugt auch gleich noch > ein C-Code-Gerippe. Und was ist mit den Kommentaren und selbsterklärenden Namen?
Noch ein paar Anmerkungen, bevor ich mich verabschiede, bis der neue ReAVR fertig ist: @Jörg: Ich habe kurz bei Ghidra vorbei gesehen und festgestellt, dass da im Prinzip dasselbe Schema verfolgt wird wie bei Microchips MPLAB - der Code ist Java-basiert und damit recht einfach auf alle drei "großen" OSse anzupassen (Linux, MacOS und Windows). Was die includes angeht, habe ich noch nicht weiter geforscht und kann deshalb nicht sagen, ob die geradeaus oder vielleicht etwas skurril sind. Vielleicht magst Du mir einmal ein Beispiel zukommen lassen, gerne auch als PN? Die "NG"-Idee ist übrigens nicht schlecht ;) Und keine Sorge. Es wird danach keine weitere so tiefgreifende Änderung von ReAVR mehr geben. @Peter: Wie kommst Du eigentlich darauf, dass 8 bis 16KB AVR-Code Anfängerniveau sind? Aber vielleicht hast Du bisher einfach nie eine kostenkritische embedded Anwendung programmieren müssen, bei der die gehobenen Funktionen uninteressant waren, weil es dort weder floats noch Schnittstellen gab, auf die printf oder scanf angewendet werden konnten. Ansonsten finde ich C-Code im Disassembly keineswegs kryptisch. Ich brauche mich nur etwas einzulesen und dabei vielleicht ein Dutzend Aufruf-Labels global zu ändern. Was mit ReAVR ganz einfach geht... Nach meiner Erfahrung gibt es nur einen Compiler, der wirklich kryptischen Assemblercode erzeugt, und das ist Bascom. @Georg: Genau. Dazu hat bisher keiner etwas beigetragen. Beste Grüße Johannes
J. A. schrieb: > Was die includes angeht, habe ich noch nicht weiter geforscht und kann > deshalb nicht sagen, ob die geradeaus oder vielleicht etwas skurril > sind. Vielleicht magst Du mir einmal ein Beispiel zukommen lassen, gerne > auch als PN? Sorry, nein, die Interna von Ghidra habe ich mir nicht angesehen. Ich hatte es nur mal kurz auf mein aktuelles (dienstliches) AVR-Projekt losgelassen und dabei gesehen, dass sie zwar IO-Ports und Interruptvektoren benennen, die aber für meinen ATtiny204 natürlich nicht korrekt sind. Ich wurde auch erst vor kurzem drauf aufmerksam gemacht, weil ich eine 68000er Firmware analysieren möchte (meines Spektrumanalysators, für den es schon lange niemanden mehr gibt, der einem Fragen zu den Interna beantworten könnte).
Hallo J. A., lasse dich nicht ärgern. Ich verstehe den Threadverlauf auch nicht. Viel zu viel Gemecker.
Hallo, ich möchte sagen, dass ich durch diesen Thread gerade erst auf ReAVR aufmerksam geworden bin und werde ihn auf jeden Fall ausprobieren. Mit den Binutils kann ich bestätigen, ist das Ergebnis eher durchwachsen. Zu TurboPascal und Delphi. Die Sprache ist genial und wurde lange in der Lehre verwendet. Der Borland Compiler ist super schnell, dass war damals einzigartig! Und Delphi war zu Windows 3.1 und Win95 Zeiten das einzig brauchbare RAD Tool und das hat Eindruck hinterlassen! Von daher verstehe ich das Gemecker nicht ;-) ReAVR als Lazarus Projekt und Open-Source würde ich begrüßen
Johann L. schrieb: > Üblich ist die Vergabe von Versionsnummern: An erster Stelle für > Mayor-Releases ...für den Bürgermeister? :-)
J. A. schrieb: > Wie kommst Du eigentlich darauf, dass 8 bis 16KB AVR-Code > Anfängerniveau sind? Nun, das sind so meine Erfahrungswerte. Einfache Projekte (Timer, Meßgeräte) sind damit noch kein Problem. Aber für komplexe Steuerungen und Regelungen steigt der Aufwand schnell an. Typisch sind auch Schnittstellen zur Fernbedienung, Kalibration und Diagnose nötig. 10k Codezeilen kommen da schnell zusammen. J. A. schrieb: > Aber vielleicht hast Du bisher einfach nie eine > kostenkritische embedded Anwendung programmieren müssen Ich habe keine so hochvolumigen Anwendungen, wo man ewig lange dran rum entwickeln kann und erst recht nicht in Assembler. Bei unseren geringen Stückzahlen ist die Entwicklungs- und Testzeit der Hauptkostenpunkt. Außerdem werden die Projekte sehr oft erweitert, so daß gute Wartbarkeit und hohe Flexibilität eine wichtige Voraussetzung sind. Der Kunde weiß beim Start des Projektes oft selber noch nicht so richtig, was die Software alles können soll. So sind sehr oft noch viele Änderungen und Erweiterungen nötig. J. A. schrieb: > weil es dort weder floats noch > Schnittstellen gab, auf die printf oder scanf angewendet werden konnten. Sobald Standardfunktionen einen Entwicklungsvorteil bieten, werden sie eingesetzt. Mehr Flash kostet ja nichts im Vergleich zu längerer Time-to-Market.
Ich habe mir 1995 mal angeschaut, wie der Keil C51 die Matheroutinen implementiert hat. Die Lib-Funktionen werden nicht im Listing angezeigt, nur deren Aufrufe. Daher habe ich ein C-Programm geschrieben, es im Simulator gestartet und dann aus dem Codefenster den Assembler rauskopiert. Die Routinen des Hern Keil waren natürlich viel effizienter, als meine Versuche. Das war quasi mein einzigstes Reassembling.
Sehr gerne fasse ich auch Variablen zu Structs und Arrays of Structs zusammen. Das erhöht deutlich die Übersicht und ist auch leicht mit weiteren Members erweiterbar. In Assembler möchte ich mir das allerdings nicht ansehen. Ich verlasse mich voll darauf, daß der Compiler die ganzen Indirektionen, Indexes und Offsets schon richtig berechnet.
J. A. schrieb: > Wie kommst Du eigentlich darauf, dass 8 bis 16KB AVR-Code > Anfängerniveau sind? In der Codesammlung habe ich mal eine DCF77-Uhr mit ATtiny12 veröffentlicht. Das war aber mehr eine Demonstration, was mit nur 512 Befehlen im Flash so geht. Am meisten hat mich dabei der nur 3-Level Hardwarestack geärgert. Ursprünglich war die DCF77-Uhr in C51 auf dem AT89C2051 mit 2kB Flash geschrieben. Daher wußte ich schon recht genau, wo ich noch was eindampfen konnte.
Peter D. schrieb: > Am meisten hat mich dabei der nur 3-Level Hardwarestack geärgert. Das hat ja jenseits von AT90S1200 und ATtiny11/12 auch keiner mehr sonst gehabt. ;-)
Moin zusammen, doch noch ein paar Anmerkungen vor dem Abtauchen. Dazu waren die letzten Beiträge einfach zu gut ;) @Jörg: Schade, ich hatte von Dir als demjenigen, der so auf Ghidra abhob, erhofft, dass Du mir dazu ein paar Tips geben könntest... Ansonsten finde ich, dass der Tiny28 - der erste Tiny mit mehr als 8 Pins - und der Tiny15, der noch nach den 11/12/28 kam und als erster mit interner x4 PLL "richtig" schnelle 8bit-PWM ermöglichte, durchaus auch einer Erwähnung bei den RAM-less AVRs wert sind. @Peter: Im Prizip hast Du mit Deinen weiteren Erläuterungen fast alle Deine Einwände so weit relativiert. Und in einem Punkt fast ad absurdum geführt: Dein "einzigstes" (gibt es im Deutschen gar nicht, nur "einziges") Reassembly war von 8051- und nicht von AVR-Code. Aber auch egal. Jedenfalls bist Du schon einmal mit Reassemblieren weiter gekommen. Also denk einfach, dass selbst ich, der Autor, ReAVR heutezutage zumeist dazu benutze, durch fremden Lib-Code, wie etwa den ~8KB großen für STs Time-of-Flight-Sensoren durchzusteigen, um ihn für meine C-Anwendungen bestmöglich zu konfigurieren und die zurück gelieferten Daten bestmöglich zu verarbeiten. Im übrigen noch zweierlei: Erstens habe ich in meiner Anfangszeit bei der Firma, für die ich bis heute arbeite, einen IAR-8051-C nacharbeiten dürfen, den anscheinend 1:1 aus einem int Pascal geschriebenen Versuchscode abgeleitet worden war. Ich hoffe, Du verstehts, was ich meine... Zweitens habe ich mit der Vorgabe THT und noch bevor der ATmega128 verfügbar wurde auf Grundlage des ATmega161 eine Fax-Anwendung programmiert, bei der über den externen Bus ein SRAM für die zu übertragenden Daten sowie ein EPROM für die TIF-Muster verwendet wurden, weil für beide die internen Speicher des AVRs nicht ausreichten. Mit den heutigen AVRxxDs und allgemein verbreiteter SMT wäre das ein Klacks und C für alles keine Frage, aber vor über 20 Jahren war es einfach noch nicht so. @Thorsten: Falls Du ein IOR-File für einen AVR brauchst, das noch nicht existiert, schreibe mir einfach eine PN. Der Generator für alle möglichen IOR-Files existiert bereits, ist aber vielleicht etwas zu groß für den bisherigen ReAVR. Ansonsten hast Du recht. TurboPascal war der Vorreiter und Delphi war unter Windows lange Zeit das RAD IDE schlechthin. Bis Microsoft mit seinen Visual-Progammierumgebungen den von Delphi eingeführten Objectinspector abkupferte... Und @Veit: Danke. Aber Gemecker macht mir hier nichts mehr aus. Irgendwie scheint es für Manche ein Muss zu sein ;)
J. A. schrieb: > @Jörg: Schade, ich hatte von Dir als demjenigen, der so auf Ghidra > abhob, erhofft, dass Du mir dazu ein paar Tips geben könntest... Sorry, dazu bin ich auch noch zu neu dort. > Ansonsten finde ich, dass der Tiny28 - der erste Tiny mit mehr als 8 > Pins - und der Tiny15, der noch nach den 11/12/28 kam und als erster mit > interner x4 PLL "richtig" schnelle 8bit-PWM ermöglichte, durchaus auch > einer Erwähnung bei den RAM-less AVRs wert sind. Historisch halt, genauso wie AT90S1200 und ATmega103, der dann ziemlich schnell einen ATmega128 als Nachfolger bekam. Dieser wiederum wurde zum „Dauerbrenner“, der wird als ATmega128A sogar zwei Jahrzehnte später noch produziert.
Moin alle zusammen, und sorry, dass ich mich jetzt erst, ein Jahr nach meinen letzten Posts, wieder melde. Das hat private Gründe... Aber nun bin ich wieder mit ReAVR V5 am Gange, wie ich mich entschlossen habe, die neue Version zu nennen. Und auch wenn ich im letzten Jahr noch gedacht hatte, die Neuerungen erstmal mit Delphi 7 fertig zu machen, bin ich dieses Jahr gleich auf Lazarus und FreePascal übergegangen. Was bei diesem Projekt nicht ganz so trivial war, denn ReAVR hat immerhin 6 Units mit jeweils eigenen Forms, auch wenn die von der MainForm nur jeweils eine zur Zeit dazugeschaltet werden. Inzwischen habe ich immmerhin die MainForm stabil laufen, und kann nun eine der weiteren Forms nach der anderen auf die Notwendigkeiten von Lazarus/FreePascal umstellen. Das wird alles in allem wohl noch ein paar Monate brauchen, aber Ihr könnt Euch schon mal auf die drei bedeutendsten Neuerungen freuen: 1. Die Möglichkeit, im erzeugten ASM-Quelltext am Zeilenende sowie in extra Zeilen Kommentare einzufügen, 2. die Möglichkeit, in den Disas Settings für absolut jeden (neuen) AVR alle benötigten Einstellungen machen zu können, und 3. ein extra Tool, das aus den .inc-Dateien des Atmel Studio oder Microchips XLAB für ReAVR verwendbare .reas_ior Dateien erzeugt, in denen außer den IO-Adressen auch die Anfangsdressen von RAM und EEPROM hinterlegt sind, die bei moderneren Chips ab den xMegas bis zu den AVRxxAAyy benötigt werden, weil sie deutlich von dem Schema der alten AVRs abweichen. Beste Grüße
Noch ein Nachtrag @Jörg W. Nicht nur der der Mega128A wird immer noch produziert, sondern auch der Mega8A und weitere "As". Und wie man im Shop von Microchip sehen kann, sind sogar noch ältere AVRs zu haben. Ich bin mir nicht sicher, weil ich hier zu Hause den Login nicht habe, aber ich glaube, sogar der gute alte AT90S8515 wird immer noch angeboten. Und falls doch nicht mehr, geht zumindest noch der ATmega8515(A?). Und warum auch nicht? Nach all den Jahren sind die alten Teile ein so genanntes "Brot und Butter"-Geschäft. Für die Anbieter billig, weil die Fertigung voll im Griff ist, und solange es genug Kunden dafür gibt, behält man sie halt im Angebot... Am Rande: Bis auf wenige Ausnahmen war der Wechsel auf "A" vor allem ein Die-Shrink. Also um mehr Chips mit derselben Funktionalität je Silizium-Wafer zu erhalten, und damit an einer der wichtigsten Kostenschrauben zu drehen.
J. A. schrieb: > ein extra Tool, das aus den .inc-Dateien des Atmel Studio oder > Microchips XLAB für ReAVR verwendbare .reas_ior Dateien erzeugt Dafür (und für ggf. noch weitere Informationen) wäre allerdings die XML-Datei die deutlich besser strukturierte Quelle gewesen. Im Prinzip kann man daraus auch Dinge mit XSLT entnehmen (habe ich schon für verschiedene Projekte gemacht). J. A. schrieb: > Nicht nur der der Mega128A wird immer noch produziert, sondern auch der > Mega8A und weitere "As". Schon klar, deshalb ja die As überhaupt. An den Preisen kann man aber gut sehen, dass Microchip das entweder trotzdem allmählich ausphasen möchte, oder aber dass das (weitgehend automatisiert vorgenommene) die shrinking allein eben immer noch vergleichsweise teure Chips erzeugt (oder beides). Die wirklichen AVR-Neuentwicklungen sind bei gleichen oder besseren Features jeweils deutlich billiger.
Jörg W. schrieb: > Dafür (und für ggf. noch weitere Informationen) wäre allerdings die > XML-Datei die deutlich besser strukturierte Quelle gewesen. Ja, da diese Dinger inzwischen auch für die ganz ollen Chips verfügbar sind, wären die XML-Dateien sicher mein Mittel der Wahl, wenn ich so einen ReAssembler schreiben würde. Dazu ergänzend noch: man kann das DevicePackage-System aus dem Atmel/Microchip-Studio herauslösen und vollkommen unabhängig davon betreiben. Auch unter Wine. Die Frage ist hier nur, wie lange das noch liefert... MC will ja ganz offensichtlich das Studio zugunsten MPLABX lieber heute als morgen sterben lassen. > An den Preisen kann man aber > gut sehen, dass Microchip das entweder trotzdem allmählich ausphasen > möchte, oder aber dass das (weitgehend automatisiert vorgenommene) die > shrinking allein eben immer noch vergleichsweise teure Chips erzeugt > (oder beides). Jepp. Das Zeug wird halt produziert, so lange es Käufer gibt, die die überzogenen Preise zu zahlen bereit sind. Kein schönes System, aber immerhin besser als z.B. das von MAXIM... > Die wirklichen AVR-Neuentwicklungen sind bei gleichen > oder besseren Features jeweils deutlich billiger. Ja. Mit Ausnahmen bei den Features. Für manche Features oder gar Kombinationen aus Features gibt es leider einfach keinen "neuzeitlichen" Nachfolger. Mir fällt da sofort die TinyX5-Reihe ein. Da muss man schon deutlich im Sortiment aufsteigen, um die wirklich in vollem Umfang ersetzen zu können und ist bei den Kosten dann praktisch auf gleicher Höhe. Da lohnt der Aufwand des Redesign einfach noch nicht. Aber klar: die ollen werden weiterhin jedes Jahr teuerer werden. Irgendwann ist der Punkt erreicht, wo's dann doch lohnt...
J. A. schrieb: > Nach all den Jahren sind die alten Teile ein so > genanntes "Brot und Butter"-Geschäft. Für die Anbieter billig, weil die > Fertigung voll im Griff ist, und solange es genug Kunden dafür gibt, > behält man sie halt im Angebot... Ja, zumindest theoretisch, wenn du klassisch produzierst und ne eigene FAB hast. Es gibt aber auch genug FABless Buden, die nur bei Auftragsfertigern produzieren lassen. Mit einer StammFAB mag das auch noch angehen, aber gerade bei Exoten, wo nur sporadisch mal ein paar Lose aufgelegt werden, kann es passieen, das die heute Der und morgen Jener produziert.
Na, da muss ich doch noch ein paar Kommentare schreiben, bevor ich mich weiter mit ReAVR beschäftige ;) Gerald B. schrieb: > Ja, zumindest theoretisch, wenn du klassisch produzierst und ne eigene > FAB hast. Es gibt aber auch genug FABless Buden, die nur bei > Auftragsfertigern produzieren lassen. Sorry, aber weder Atmel, die die AVRs erfanden, noch Microchip, die Atmel übernahmen, sind "FABless Buden". Tatsächlich hatte Atmel, als sie mit den AVRs begannen, noch >5 eigene Fabs, von denen 3 in Europa lagen - in D, F und UK - und zumindest die in Frankreich hat auch einige AVRs produziert, insbesondere die AT90USB... Die meisten Fabs hatte Atmel aber schon Jahre vor der Übernahme durch Microchip abgestoßen, bis auf die in Colado, USA, in der wohl bis heute etliche der AVR-, UC3- und SAM-Chips gefertigt werden. Jörg W. schrieb: > Schon klar, deshalb ja die As überhaupt. An den Preisen kann man aber > gut sehen, dass Microchip das entweder trotzdem allmählich ausphasen > möchte, oder aber dass das (weitgehend automatisiert vorgenommene) die > shrinking allein eben immer noch vergleichsweise teure Chips erzeugt > (oder beides). Oh, die As waren, als sie herauskamen, damals noch von Atmel, alle deutlich günstiger als die Originale. Es gab da zunächst nur der Haken, dass Atmel, wie etwa beim Tin13A, zusätzliche Features, in dem Fall die BOD Control, eingebaut und deshalb die Chip-ID geändert hatte. Was in der Produktion beim Gang-Programming zu massiven Störungen führte, weshalb bei späteren As, entweder keine neuen Features mehr implementiert oder sie trotzdem mit derselben ID versehen wurden wie die Nicht-As. Im übrigen wurde das Die Shrinking wohl in keinem Fall automatisiert vorgenommen, sondern jeweils absichtlich und gezielt. Nach gründlicher Prüfung, ob die vorliegenden Logik-Files nach dem Durchlauf durch die neueren, ich nenne sie mal Silicon-Compiler, wirklich einen kleineren und vor allem sich bis ins letzte genauso verhaltenden Chip ergab. Im übrigen 2 hätte Microchip anno 2022, als infolge der corona-lock-down-bedingten weltweiten Lieferkrise problemlos diverse ältere AVRs, insbesondere die teuren XMegas ausphasen können. Das haben sie aber nicht gemacht. Vielmehr haben sie sich bemüht, alle AVRs immer wieder auf den Markt zu bringen, zur Not in 1000er Stückzahlen. Ob S. schrieb: > Mit Ausnahmen bei den Features. Für manche Features oder gar > Kombinationen aus Features gibt es leider einfach keinen "neuzeitlichen" > Nachfolger. Mir fällt da sofort die TinyX5-Reihe ein. Mir auch. Nach deren interner PLL für schnelle PWM suche ich selber bisher vergebens. Ok, die XMegas haben die noch, aber zu welchem Preis? Ansonsten noch @Jörg W. und @Ob S.: Ihr habt ja grundsätzlich recht, dass die .atdf XML-Files alles beinhalten, was es für einen einzelnen AVR zu wissen gibt - aber warum soll ich mich mit XML-Transcoding aufhalten, wenn mich für ReAVR nur die Assembler Headers interessieren, die sowohl vom Atmel Studio als auch vom Microchip MCC oder MPLAB vollständig mitgeliefert werden? Ansonsten: Das Atmel Studio wurde von Microchip eingefroren und unterstützt die neuestens Chips der AVRxxD- und -E-Serien nicht mehr. Für mich gar nicht so unverständlich. Warum sollen sie auch, nebem dem OS-unabhängigen, weil Java-basierten MPLAB X noch das rein MS/Windows-basierte Atmel Studio weiter pflegen? Ich halte die Entscheidung für völlig legitim, zumal das MPLAB die vom Atmel Studio bekannte packs-Verzeichnisstruktur beibehalten hat. Nur halt anderswo als das Studio, dafür immer auf dem neuesten Stand.
J. A. schrieb: > Oh, die As waren, als sie herauskamen, damals noch von Atmel, alle > deutlich günstiger als die Originale. Logisch, denn die Dies brauchen weniger Fläche – sonst hätte man den ganzen Zirkus ja gar nicht machen brauchen. > Im übrigen wurde das Die Shrinking wohl in keinem Fall automatisiert > vorgenommen, sondern jeweils absichtlich und gezielt. Natürlich erfolgt es absichtlich und gezielt. Der Punkt ist halt, dass ein die shrink auf diesem Wege zwar kleinere Chips ergibt und im Vergleich zu einem vollen Redesign auch viel weniger Aufwand bereitet. Andererseits hat das Ganze in dieser Form Grenzen, sodass die später erfolgten Redesigns halt deutlich billigere Dies hervorbringen. > in D, F und UK - und zumindest die in Frankreich hat auch einige AVRs > produziert Von Nischen-Dingen (ATAxxx) abgesehen, hat aber Heilbronn nie AVRs gefertigt.
Jörg, Du bist anscheinend genauso gut informiert wie ich. Zumindest. was die alten Fabs von Atmel angeht. Bloß hast Du mich nicht richtig zitiert. Auf die alte Telefunken-Fab in Heilbronn war ich in Bezug auf die AVRs bewusst gar nicht weiter eingegangen. Ansonsten hast Du es ja schon selber gesagt: Richtig günstigere Chips haben nur ein echtes Redesign gebracht. Nur dummerweise sind die alle nicht pinkompatibel zu den bisherigen geraten.
J. A. schrieb: > Zumindest. was die alten Fabs von Atmel angeht. Hab' in der Zeit mal dort gearbeitet … das war die Zeit, als die As gemacht worden sind (zumindest die meisten). Hab auch (weit entfernt) miterlebt, wie sie außer Colorado Springs eine Fab nach der anderen abgestoßen haben.
Jörg W. schrieb: > Hab' in der Zeit mal dort gearbeitet … das war die Zeit, als die As > gemacht worden sind (zumindest die meisten). Hab auch (weit entfernt) > miterlebt, wie sie außer Colorado Springs eine Fab nach der anderen > abgestoßen haben Na dann, sorry für meinen Vorbehalt.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.