Forum: Mikrocontroller und Digitale Elektronik Hex File von Atmega16 in Atmega32 verwandeln

Mein_erstes_Mal schrieb:
> Ist es möglich das Hexfile so anzupassen das es für den Atmega32 passt?
> Danke für die Hilfe

Im Prinzip schon, der wesentliche Unterschied ist die Interrupttabelle. 
Die muss man manuell anpassen. Der Rest ist identisch.

HEX-File im HEX-Editor laden, ändern, wieder speichern. Kann man auch 
direkt als ASCII editieren, muss dann aber die Prüfsummen der Zeilen neu 
berechnen.

Spontan würde ich sagen, das ist ohne Änderung möglich - einfach mal 
ausprobieren.

Ohne den Code zu disassemblieren, geht das nicht. Man weiß ja nicht, was 
ist Code und was sind Daten. Wenn man die zu ändernden Stellen gefunden 
hat, kann man die natürlich im Hexfile patchen.
Beitrag "Re: was ist der unterschied zwischen dem atmega16 und dem atmega32"

Falk B. schrieb:
> Mein_erstes_Mal schrieb:
>> Ist es möglich das Hexfile so anzupassen das es für den Atmega32 passt?
>> Danke für die Hilfe
>
> Im Prinzip schon, der wesentliche Unterschied ist die Interrupttabelle.
> Die muss man manuell anpassen. Der Rest ist identisch.
>
> HEX-File im HEX-Editor laden, ändern, wieder speichern. Kann man auch
> direkt als ASCII editieren, muss dann aber die Prüfsummen der Zeilen neu
> berechnen.

Wie findet man die Interrupttabelle?
Danke für die Hilfe

S. L. schrieb:
> Spontan würde ich sagen, das ist ohne Änderung möglich - einfach
> mal
> ausprobieren.

Nein ohne Änderung geht es nicht

> Wie findet man die Interrupttabelle?
Steht direkt am Anfang des Programms.

Mein_erstes_Mal schrieb:
> Wie findet man die Interrupttabelle?

Anhand der Adresse

Mein_erstes_Mal schrieb:
> da wir keine Atmega16 auftreiben können und jede Menge Atmega32 am Lager
> haben war die Überlegung die Atmega32 zu verwenden.

Kein Problem, das Hex läuft unverändert.
Der überschüssige Flash und SRAM bleibt unbenutzt.
Lediglich ein Bootloader müßte auf die neue Startadresse compiliert 
werden.

> Kein Problem ...

Ja, das dachte ich auch - da haben wir beide Atmels Frühzeit 
überschätzt; s. Mario M.s Beitrag.

S. L. schrieb:
> Ja, das dachte ich auch - da haben wir beide Atmels Frühzeit
> überschätzt; s. Mario M.s Beitrag.

Ja, Punkt 4 und 5 könnten kritisch sein.
Ich heb ja immer den Quelltext auf, dann muß man nur das Target 
umstellen.

Mein_erstes_Mal schrieb:
> Ist es möglich das Hexfile so anzupassen das es für den Atmega32 passt?

Nach Assembler disassemblen, und auf die kritischen Punkte hin prüfen. 
Ist halt etwas Aufwand.

Oliver

Oliver S. schrieb:
> Nach Assembler disassemblen, und auf die kritischen Punkte hin prüfen.
> Ist halt etwas Aufwand.

Problem ist, der Disassembler weiß nicht, was ist Code und was konstante 
Daten. Z.B. ein switch/case kann eine Sprungtabelle anlegen.
Ich würd mal sagen, ohne Quellcode, vergiß es.

Peter D. schrieb:
> Mein_erstes_Mal schrieb:
>> da wir keine Atmega16 auftreiben können und jede Menge Atmega32 am Lager
>> haben war die Überlegung die Atmega32 zu verwenden.
>
> Kein Problem, das Hex läuft unverändert.
> Der überschüssige Flash und SRAM bleibt unbenutzt.
> Lediglich ein Bootloader müßte auf die neue Startadresse compiliert
> werden.

Bist du sicher?
Danke für die Hilfe

Peter D. schrieb:
> Problem ist, der Disassembler weiß nicht, was ist Code und was konstante
> Daten. Z.B. ein switch/case kann eine Sprungtabelle anlegen.
> Ich würd mal sagen, ohne Quellcode, vergiß es.

Das hat bei uns an der Hochschule mal ein Student gemacht: es war sehr 
mühselig, aber er hat es geschafft! Das Ganze wurde dann eine 
Diplomarbeit...

Mein_erstes_Mal schrieb:
> Bist du sicher?

Jetzt nicht mehr, siehe:
Beitrag "Re: was ist der unterschied zwischen dem atmega16 und dem atmega32"

Es sind einige Interrupts hinzu gekommen und damit verschieben sich alle 
nachfolgenden.
Es kann aber durchaus sein, daß Dein Programm keine Interrupts benutzt. 
Man kann auch alle Interruptquellen in der Mainloop pollen.

Die Interruptsprungtabelle zu bearbeiten sollte möglich sein. Wenn das 
Programm aber Sleep-Modi verwendet, dann wird es schwierig.

Dietrich L. schrieb:
> Peter D. schrieb:
>> Problem ist, der Disassembler weiß nicht, was ist Code und was konstante
>> Daten. Z.B. ein switch/case kann eine Sprungtabelle anlegen.
>> Ich würd mal sagen, ohne Quellcode, vergiß es.
>
> Das hat bei uns an der Hochschule mal ein Student gemacht: es war *sehr*
> mühselig, aber er hat es geschafft! Das Ganze wurde dann eine
> Diplomarbeit...

Solange kein Bootlader vorhanden ist, ist es in diesem Fall einfacher. 
Es muss nur die Interrupt Vektor Tabelle anders sortiert werden und 
falls das MCUCR Register benutzt wird, müssen da eventuell zwei Bits 
getauscht werden.

Ich schätze den Aufwand für einen Test auf weniger als einen halben Tag. 
Einen Versuch ist es wert.

Peter D. schrieb:
> Problem ist, der Disassembler weiß nicht, was ist Code und was konstante
> Daten. Z.B. ein switch/case kann eine Sprungtabelle anlegen.
> Ich würd mal sagen, ohne Quellcode, vergiß es.

Ich habs schon gemacht. Ja, es ist teilweise mühsam, aber nicht 
unmöglich. Letztendlich muß man ja nur die Interrupttabelle und eben die 
Zugriffe auf MCUCR prüfen.

Oliver

Das sind alles Fragen, auf die niemand eine Antwort weiß. Der TE 
wahrscheinlich auch nicht.

Ich würde gerne wissen - falls das bekanntgegeben werden kann - was 
macht der Controller bzw. das Programm und wie groß ist die .hex-Datei? 
Ist bekannt, ob das Ding einen Bootloader benutzt (erkennt man an den 
Fuses, die müssten ja bekannt sein wenn das Ding programmiert wird).

Das Disassemblieren solcher Programme ist nicht ganz so schwer wie bei 
PC-Programmen, da im Flash nur statische Daten liegen. Man kriegt also 
recht schnell raus, was Code ist und was Daten. Wenn das Programm 
übersichtlich geschrieben wurde, dann liegen die Daten alle am Ende. 
Außerdem sind alle Befehle außer JMP/CALL und LDS/STS exakt 16 Bit lang 
(die beiden Ausnahmen sind 32 Bit lang).

S. L. schrieb:
> Die Interruptsprungtabelle zu bearbeiten sollte möglich sein.

Das reicht aber nicht. Durch die größere Vectortabelle verschieben sich 
auch sämtliche anderen Jumps, Calls und Arrays im Code.
Nur RJMP und RCALL könnten nicht betroffen sein.

> ... größere Vectortabelle ...

?
  Sind doch beide Male 21 Vektoren?

S. L. schrieb:
> Sind doch beide Male 21 Vektoren?

Ja, Du hast Recht. Die sind nur umsortiert, nehme also alles zurück.
Alle Ziele bleiben an ihrer Adresse.

S. L. schrieb:
>> ... größere Vectortabelle ...
>
> ?
>   Sind doch beide Male 21 Vektoren?

Wers offiziell nachlesen will, Microchip Appnote AVR089

https://ww1.microchip.com/downloads/en/Appnotes/doc2538.pdf

Oliver

Peter D. schrieb:
> Alle Ziele bleiben an ihrer Adresse.

Also muß man doch nur in der Interrupttabelle die Jumps umsortieren und 
die Rjumps umrechnen.

Peter D. schrieb:
> Also muß man doch nur in der Interrupttabelle die Jumps umsortieren und
> die Rjumps umrechnen.

und das kann man im Hexfile machen?
Danke für die Hilfe

Mein_erstes_Mal schrieb:
> und das kann man im Hexfile machen?

Ja, wenn man die Interrupttabelle findet, und weiß, wie so ein hexfile 
aufgebaut ist, und die Prüfsummen selber berechnen kann, dann ja.

Also eher nein.

Da die Interrupttabelle aber am Anfang des flashs steht, kann man die 
Interrupttabelle einzeln aus dem alten hexfile disassemblieren, dann 
ändern, und daraus ein neues hexfile erstellen lassen. Damit dann die 
entsprechenden Zeilen im alten überschreiben. Gibts dazu noch einen 
bootloader, muß man da auch noch nachschauen.

Wenn dir das alles gar nichts sagt, dann wird es Zeit, jemanden bei euch 
mit dem Problem zu beauftragen, der sich damit auskennt.

Oliver

Mein_erstes_Mal schrieb:
>> Also muß man doch nur in der Interrupttabelle die Jumps umsortieren und
>> die Rjumps umrechnen.
>
> und das kann man im Hexfile machen?
> Danke für die Hilfe

Ja. Man muss nur die JMPs an die richtige Stelle schieben und die NOPs 
oder JMPs auf die leere ISR (bad ISR) verschieben.
Lad dein Hexfile mal hier hoch.

Oliver S. schrieb:
> Ja, wenn man die Interrupttabelle findet, und weiß, wie so ein hexfile
> aufgebaut ist, und die Prüfsummen selber berechnen kann, dann ja.

Kann man. Denn das Hexfile ist Intel-HEX und damit einfach.

> Also eher nein.

Wollen wir wetten?

Falk B. schrieb:
> Mein_erstes_Mal schrieb:
>>> Also muß man doch nur in der Interrupttabelle die Jumps umsortieren und
>>> die Rjumps umrechnen.
>>
>> und das kann man im Hexfile machen?
>> Danke für die Hilfe
>
> Ja. Man muss nur die JMPs an die richtige Stelle schieben und die NOPs
> oder JMPs auf die leere ISR (bad ISR) verschieben.
> Lad dein Hexfile mal hier hoch.

Da File ist hier.
Danke für die Hilfe

Mein_erstes_Mal schrieb:
> Da File ist hier.

1

         ******************************** 

2

:100000000C9473000C9490000C9490000C9490004D

3

:100010000C9490000C9490000C9490000C94900020

4

:100020000C9490000C9428090C9490000C94020FEE

5

:100030000C94410F0C9490000C9490000C94900040

6

:100040000C9490000C9490000C9490000C949200EE

7

:100050000C9490003F01410143012B012D012F0120

Das ist der Anfang der Datei, die Interrupttabelle. der erste Eintrag in 
der ersten Zeile ist 0C947300. Vorsicht, das ist durch die little Endian 
Maschine AVR ziemlich verdreht! Als big endian ausgeschrieben heißt das

94 0C 00 73

Wenn man das gemäß AVR Instruction Set dekodiert, ist das ein

JMP $73

Dort fängt das Programm nach dem Reset an.

Der nächste und viele andere Einträge sind 0C949000, big endian

94 0C 00 90 bzw.

JMP $90

Das sind die ungenutzten Interrupts. Die springen alle auf eine leere 
ISR, die meist einen Softwarereset auslöst, wenn diese im Programm durch 
einen Fehler aktiviert werden.

Die letzten beiden Ziffern der Zeile sind die Prüfsumme, keine 
Programmdaten
Folgende Einträge weichen ab

1

ISR Tabelle, ATmega16

2

Zeile V-Nr  Name        Code     Big      ASM

3

  3    10   TIMER0 OVF  0C942809 940C0928 JMP $0928

4

  3    12   USART, RXC  0C94020F 940C0F02 JMP $0F02

5

  4    13   USART, UDRE 0C94410F 940C0F41 JMP $0F41

6

  5    20   TIMER0 COMP 0C949200 940C0092 JMP $0092

Beim ATmega 32 liegen die Verktoren anders

1

ISR Tabelle, ATmega32

2

Zeile V-Nr  Name        Code     Big      ASM

3

  3    12   TIMER0 OVF  0C942809 940C0928 JMP $0928

4

  4    14   USART, RXC  0C94020F 940C0F02 JMP $0F02

5

  4    15   USART, UDRE 0C94410F 940C0F41 JMP $0F41

6

  3    11   TIMER0 COMP 0C949200 940C0092 JMP $0092

Damit sieht die neue Interrupttabelle als Intel-HEX so aus

1

         ******************************** 

2

:100000000C9473000C9490000C9490000C9490004D

3

:100010000C9490000C9490000C9490000C94900020

4

:100020000C9490000C9490000C9492000C942809FF

5

:100030000C94410F0C94020F0C94410F0C949000FF

6

:100040000C9490000C9490000C9490000C949000F0

7

:100050000C9490003F01410143012B012D012F0120

Die Püfsummen der geänderten zeilen kann man hier leicht berechnen 
lassen.

https://www.fischl.de/hex_checksum_calculator/

Dazu muss man nur die Zeile mit zusätzlichen 00 eintragen und Analyze 
drücken.
Die Seite spuckt dann die korrekte Prüfsumme aus, die man eintragen 
kann.

Im Anhang die neue Datei, probier mal.

Falk B. schrieb:
> Beim ATmega 32 liegen die Verktoren anders

Soweit ich das richtig verstehe, sind die Jumps relativ. Wenn sich der 
Ort des Vektors um einen Offset verschiebt, müssen sich die Sprungwerte 
ebenso um diesen Offset vergrößeren/verkleinern?

Du schreibst jedoch dieselben Jump-Werte nur an die andere Stelle, wenn 
ich Deinen Beitrag richtig verstanden habe.

Frank M. schrieb:
> Soweit ich das richtig verstehe, sind die Jumps relativ.

Nö. Es sind ja JMP, absolute Sprünge im 4M Adressraum.
Ein RJMP ist relativ, Nomen est Omen! Die gibt es aber nur bei kleinen 
AVRs mit max. 8k Flash. Z.B. ATmega88

Falk B. schrieb:
> Ein RJMP ist relativ, Nomen est Omen! Die gibt es aber nur bei kleinen
> AVRs mit max. 8k Flash.

Je nach Optimierung darf der AVR-GCC auch bei den großen RJMP benutzen 
und tut dies auch, wenn das Ziel innerhalb +/-4kB ist.
In der Vectortabelle benutzt er aber nur JMP, also muß nichts 
umgerechnet werden.

Falk B. schrieb:
>> Also eher nein.
>
> Wollen wir wetten?

Die Antwort galt nicht für dich. Das du das für den TO machen wirst, war 
eh klar.

Oliver

Falk B. schrieb:
> Mein_erstes_Mal schrieb:
>> Da File ist hier.
>          ********************************
> :100000000C9473000C9490000C9490000C9490004D
> :100010000C9490000C9490000C9490000C94900020
> :100020000C9490000C9428090C9490000C94020FEE
> :100030000C94410F0C9490000C9490000C94900040
> :100040000C9490000C9490000C9490000C949200EE
> :100050000C9490003F01410143012B012D012F0120
>
> Das ist der Anfang der Datei, die Interrupttabelle. der erste Eintrag in
> der ersten Zeile ist 0C947300. Vorsicht, das ist durch die little Endian
> Maschine AVR ziemlich verdreht! Als big endian ausgeschrieben heißt das

> Im Anhang die neue Datei, probier mal.

Ich muss mir das erst heute Abend ansehen.
Im Moment gucke ich wie das Schwein ins Uhrwerk.
Fettes Danke schon jetzt ich gebe Feedback

Guten Morgen Falk B.

Ich habe es mir angesehen und ich staune.
Funktionieren tut es noch nicht.
Das Atmelstudio mekert das die Prüfsumme nicht stimmt.

Ich versuche später ob ich den Fehler finde

Danke für die Hilfe

Mein_erstes_Mal schrieb:
> Das Atmelstudio mekert das die Prüfsumme nicht stimmt.
>
> Ich versuche später ob ich den Fehler finde

Soll das Satire sein?

Und zum eigentlichen Probelem: Entweder das Ding läuft ohne Änderung auf 
einem binärkompatiblen Controller oder du compilierst es neu.
Alles andere ist Pfusch und wird gerade dir nicht gelingen.

Mein_erstes_Mal schrieb:
> Funktionieren tut es noch nicht.
> Das Atmelstudio mekert das die Prüfsumme nicht stimmt.

Zeile 3 ist falsch. Die lautet richtig:
:100020000C9490000C9490000C9492000C9428096D

Oliver

Cyblord -. schrieb:
> Soll das Satire sein?

Nein überhaupt nicht.
Ich dachte mir das wenn ich jetzt die Anleitung von Falk habe das ich es 
vielleicht auch selbst schaffe.

Wollte nur die Hilfsbereitschafft nicht überstrapazieren.

Oliver S. schrieb:
> Zeile 3 ist falsch. Die lautet richtig:
> :100020000C9490000C9490000C9492000C9428096D

Hmm, hab mich schon gewundert, warum zweimal FF als Prüfsumme 
rausgekommen ist. Hab vermutlich zweimal die gleiche Zeile kopiert. 8-0

Habe jetzt das Angepasste File ausprobiert.
Es ist so das anscheinend der Rx Uart Interrupt nicht so läuft wie er 
soll.

Kann das sein?

Flash doch aus Spaß mal die unveränderte Datei. Mich und bestimmt noch 
andere mit dem gleichen Problem würde interessieren, ob das funktioniert 
oder nicht.

Mein_erstes_Mal schrieb:
> Es ist so das anscheinend der Rx Uart Interrupt nicht so läuft wie er
> soll.

Wie erkennst du das?

> Kann das sein?

Möglich, vielleicht habe ich einen Fehler gemacht.

Falk B. schrieb:
> Möglich, vielleicht habe ich einen Fehler gemacht.

Er könnte die Interruptvektortabelle jetzt ja auch einfach nochmal 
nachprüfen.

Mein_erstes_Mal schrieb:
> Habe jetzt das Angepasste File ausprobiert.
> Es ist so das anscheinend der Rx Uart Interrupt nicht so läuft wie er
> soll.
>
> Kann das sein?

Hast mal in die App Note reingeschaut?

Oliver S. schrieb:
> Wers offiziell nachlesen will, Microchip Appnote AVR089
>
> https://ww1.microchip.com/downloads/en/Appnotes/doc2538.pdf

Da siehst du in der Tabelle, dass die UART RX Vektoren an anderer Stelle 
sind.

Falk B. schrieb:
> Wie erkennst du das?
>
>> Kann das sein?
>
> Möglich, vielleicht habe ich einen Fehler gemacht.

Hallo Falk,
ich gehe davon aus das es mit dem Empfang an der Uart ein Problem gibt.
Sobald ich daten vom Pc zum Display sende macht das Display nichts mehr.

Deshalb meine Mutmaßung das es am Rx Uart liegen könnte.
Danke für die Hilfe

Ben B. schrieb:
> Flash doch aus Spaß mal die unveränderte Datei. Mich und bestimmt noch
> andere mit dem gleichen Problem würde interessieren, ob das funktioniert
> oder nicht.

Habe ich bereits vor ich hier geschrieben habe.
Beitrag "Re: Hex File von Atmega16 in Atmega32 verwandeln"

Mein_erstes_Mal schrieb:
> ich gehe davon aus das es mit dem Empfang an der Uart ein Problem gibt.
> Sobald ich daten vom Pc zum Display sende macht das Display nichts mehr.
>
> Deshalb meine Mutmaßung das es am Rx Uart liegen könnte.

Falls RX mit Interrupt läuft. Hast das mal geprüft (siehe Bild)?

> Deshalb meine Mutmaßung das es am Rx Uart liegen könnte.

Wundert mich - wenn ich es richtig sehe, wurde lediglich versehentlich 
'SPI STC' zusätzlich belegt.

Adam P. schrieb:
> Oliver S. schrieb:
>> Wers offiziell nachlesen will, Microchip Appnote AVR089
>>
>> https://ww1.microchip.com/downloads/en/Appnotes/doc2538.pdf
>
> Da siehst du in der Tabelle, dass die UART RX Vektoren an anderer Stelle
> sind.

Und was glaubst du, was hier gemacht wurde?

Beitrag "Re: Hex File von Atmega16 in Atmega32 verwandeln"

Mein_erstes_Mal schrieb:
>> Möglich, vielleicht habe ich einen Fehler gemacht.
>
> Hallo Falk,
> ich gehe davon aus das es mit dem Empfang an der Uart ein Problem gibt.
> Sobald ich daten vom Pc zum Display sende macht das Display nichts mehr.

Und was macht es vorher?

> Deshalb meine Mutmaßung das es am Rx Uart liegen könnte.

Scheint so. Hast du die AVR Fuses richtig eingestellt? Die stehen 
nämlich nicht im HEXfile.

Adam P. schrieb:
>> Deshalb meine Mutmaßung das es am Rx Uart liegen könnte.
>
> Falls RX mit Interrupt läuft. Hast das mal geprüft (siehe Bild)?

Ja, haben wir!

Beitrag "Re: Hex File von Atmega16 in Atmega32 verwandeln"

OK, Fehler gefunden, ich war bei den UART Vektoren um eine Nummer 
verrutscht!

Falk B. schrieb:
> OK, Fehler gefunden, ich war bei den UART Vektoren um eine Nummer
> verrutscht!

Jetzt rennt es wie es soll👏🏾👏🏾👏🏾👏🏾👏🏾👏🏾
Wow ich staune mega fettes Danke!!!
kann ich dir ein Bier spendieren??

Oliver S. schrieb:
> Wers offiziell nachlesen will, Microchip Appnote AVR089
>
> https://ww1.microchip.com/downloads/en/Appnotes/doc2538.pdf

Sind die bei Atmel betrunken gewesen? Warum verwürfelt man die 
Interrupttabelle, wenn die Anzahl und Art der Interrupts gleich bleibt? 
Nur wegen der Pseudo-Priorität, wenn zwei Interrupts gleichzeitg aktiv 
werden? Cmon! Ebenso die beiden Bits in MCUSR? Wir werden es nie 
erfahren . . .

Falk B. schrieb:
> Ein RJMP ist relativ, [...] Die gibt es aber nur bei kleinen
> AVRs mit max. 8k Flash. Z.B. ATmega88

Nö, RJMP / RCALL wird von allen AVR cores unterstützt.

Bei Flash > 8KiB gibt's dann zusätzlich noch JMP / CALL, wobei diese 
Instruktionen bei manchen neueren Devices (zB 0-Series) auch schon bei 
Flash <= 8KiB unterstützt werden.

Das Problem mit RJMP / RCALL im Kontext der Frage ist, dass diese bein 
Setzen des neuen PC einen Wrap-Around machen.  Negativ erscheinende 
Zieladressen sind also ok, landen beim ATmega16 aber an einer anderen 
Stelle als beim ATmega32.

Johann L. schrieb:
> Falk B. schrieb:
>> Ein RJMP ist relativ, [...] Die gibt es aber nur bei kleinen
>> AVRs mit max. 8k Flash. Z.B. ATmega88
>
> Nö, RJMP / RCALL wird von allen AVR cores unterstützt.

Ja, ich meinte aber was anderes. Nur bei AVRs mit <=8kB Flash besteht 
die Vektortabelle aus RJMPs.

Falk B. schrieb:

> Ja, ich meinte aber was anderes. Nur bei AVRs mit <=8kB Flash besteht
> die Vektortabelle aus RJMPs.

Das ist falsch. Bei diesen Teilen muss sie zwingend aus RJMPs bestehen, 
weil halt die Vektoren dort nur ein Wort groß sind. Bei den größeren 
sind sie zwei Worte groß. Dort hat man die Wahl, ob man JMPs oder RJMPs 
verwendet, naja, natürlich nur, wenn das Sprungziel im per RJMP 
erreichbaren Teilbereich des Flash liegt.

Genau genommen, müssen nichtmal zwingend überhaupt Sprungbefehle auf den 
Vektoren liegen. Es ist nur in den meisten Fällen sinnvoll.

C-hater schrieb:
> Bei diesen Teilen muss sie zwingend aus RJMPs bestehen,
> weil halt die Vektoren dort nur ein Wort groß sind. Bei den größeren
> sind sie zwei Worte groß.

Da verwechselt der der große c-hater dann doch Ursache und Wirkung. Der 
eigentliche Grund, warum die bei den Teilen aus rjmps bestehen MUSS, ist 
einfach der, daß es kein jmp gibt. Und daher ist dann auch die 
Sprungtabelle passend aufgebaut.

Oliver

Oliver S. schrieb:

> Da verwechselt der der große c-hater dann doch Ursache und Wirkung.

Nein. Die Behauptung von Falk B. war:

> Ja, ich meinte aber was anderes. Nur bei AVRs mit <=8kB Flash besteht
> die Vektortabelle aus RJMPs.

Und das ist schlicht falsch. Man beachte das Wörtchen "nur".

Tatsache ist, dass sie eben auch bei größeren AVR8 durchaus aus RJMPs 
bestehen kann. Darauf wollte ich im Kern nur hinweisen.

C-hater schrieb:
> Nein. Die Behauptung von Falk B. war:
>
>> Ja, ich meinte aber was anderes. Nur bei AVRs mit <=8kB Flash besteht
>> die Vektortabelle aus RJMPs.
>
> Und das ist schlicht falsch. Man beachte das Wörtchen "nur".
>
> Tatsache ist, dass sie eben auch bei größeren AVR8 durchaus aus RJMPs
> bestehen kann. Darauf wollte ich im Kern nur hinweisen.

Nein, du verstehst das nicht richtig.

AVR8 mit grösser als 8kb Flash haben eine Vektortabelle mit 32 Bit pro 
Eintrag.
Alles kleinere hat eine Tabelle mit 16 Bit pro Eintrag.
Ergo kann alles was 8k oder kleiner ist NUR RJMP, die anderen JMP oder 
wenn man möchte auch RJMP, falls die relative Reichweite +2k -2k reicht. 
Dann bleiben die beiden letzten Bytes ebend unbenutzt.

Björn W. schrieb:

> AVR8 mit grösser als 8kb Flash haben eine Vektortabelle mit 32 Bit pro
> Eintrag.
> Alles kleinere hat eine Tabelle mit 16 Bit pro Eintrag.
> Ergo kann alles was 8k oder kleiner ist NUR RJMP, die anderen JMP oder
> wenn man möchte auch RJMP, falls die relative Reichweite +2k -2k reicht.
> Dann bleiben die beiden letzten Bytes ebend unbenutzt.

Ja, genau so ist das.

Interessant ist wäre nur, wie du zu der Aussage kommst, dass ich da 
etwas nicht verstanden hätte...

Denn genau das hatte Falk B. geleugnet und ich richtig gestellt.

Wenn also irgendwer etwas nicht verstanden hat, dann du...

C-hater schrieb:
>> Ja, ich meinte aber was anderes. Nur bei AVRs mit <=8kB Flash besteht
>> die Vektortabelle aus RJMPs.
>
> Und das ist schlicht falsch. Man beachte das Wörtchen "nur".

Du zweifelst an dieser Aussage.

Björn W. schrieb:
> C-hater schrieb:
>>> Ja, ich meinte aber was anderes. Nur bei AVRs mit <=8kB Flash besteht
>>> die Vektortabelle aus RJMPs.
>>
>> Und das ist schlicht falsch. Man beachte das Wörtchen "nur".
>
> Du zweifelst an dieser Aussage.

Natürlich. Die offensichtliche und unbestreitbare Tatsache, dass halt 
auch bei einem größeren AVR8 die Vektortabelle aus lauter RJMPs bestehen 
kann, beweist nach den Gesetzen der Logik, dass die Aussage von Falk B. 
schlicht falsch sein muss.

C-hater schrieb:
> Tatsache ist, dass sie eben auch bei größeren AVR8 durchaus aus RJMPs
> bestehen kann. Darauf wollte ich im Kern nur hinweisen.

Geht dir jetzt besser? Ist dir einer abgegangen? Bravo! Was wäre die 
Welt ohne Menschen wie du?

In den ersten Datenblättern des ATmega8 waren JMP und CALL noch 
aufgeführt und wurden korrekt ausgeführt. Quasi der CPU-Core des 
ATmega16.

Peter D. schrieb:
> In den ersten Datenblättern des ATmega8 waren JMP und CALL noch
> aufgeführt und wurden korrekt ausgeführt. Quasi der CPU-Core des
> ATmega16.

Ich konnte das kaum glauben, ist aber tatsächlich so (siehe Anhang). 
Tja, man lernt immer noch dazu.