Forum: Mikrocontroller und Digitale Elektronik Atmega2560 Verhält sich komisch bei zu vielen Daten


von M. M. (mrmcchicken)


Lesenswert?

Hallo zusammen, ich bin Aktuell dabei eine kleinigkeit zu Basteln und 
benutze dazu einen Arduino Mega2560 abklatsch aus China (Schande über 
mich).
Das hat den Hintergrund, dass ich recht viele Daten im Flash 
abspeichere, die ich dann nachher auslese. Außerdem hat die Platine 
direkt alles was ich brauche ohne SMD löten zu müssen.
Heute war ich ein paar Stunden munter am Programmieren, bis mir ein 
komsicher Fehler aufgefallen ist. Sobald ich mehr als ca. 60kB in den 
Flash schreibe, sind alle nachfolgenden Daten futsch.
Das heist, dass bis ca 60kB alle Daten noch Problemlos ausgelesen und 
ausgegeben werden können, danach jedoch nur wirre zusammenschnite aus 
den Daten davor auftreten.
Schreibe ich die Daten einzeln in den Flash klappt alles super. 
Verschiebe ich mit .org alle Daten weiter nach hinten, sind alle Daten 
betroffen.

Ich vermute also stark, dass es ein Hardwarebug ist. Kann es sein, dass 
der Speicher einen Schaden hat? Schließlich war die ganze Platine 
billiger als ein Controller hier vom Fahhändler. Könnte es sein, dass 
der Controller ein gefälschter ist? Habe mal gehört, dass es sowas gibt.

von Karl M. (Gast)


Lesenswert?

Wie beschreibst Du einen Mega2560 ?

Per ISP dann ist es ein Problem von Avrdude, sonst von einem Bootloader.
Dann installiert man sich einen funktionierenden.

von Magnus M. (magnetus) Benutzerseite


Lesenswert?

M. M. schrieb:
> Ich vermute also stark, ...
> Kann es sein, dass...
> Könnte es sein, dass...

Ich vermute, dass es sein kann, dass sich in deinem Programm ein Fehler 
verstecken könnte.

> Habe mal gehört, dass es sowas gibt.

Siehe oben.

von M. M. (mrmcchicken)


Lesenswert?

Karl M. schrieb:
> Wie beschreibst Du einen Mega2560 ?

Mit einem STK500. Stecke das ISP Kabel einfach drauf.
Habe BOOTRST deaktiviert.

Ich möchte keinen Bootloader drauf haben. Die Platine ist mit dem 
Arduino Bootloader gekommen. Habe ich den so nicht beseitigt?

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

M. M. schrieb:
> Sobald ich mehr als ca. 60kB in den Flash schreibe,
> sind alle nachfolgenden Daten futsch.
> Das heist, dass bis ca 60kB alle Daten noch Problemlos ausgelesen und
> ausgegeben werden können, danach jedoch nur wirre zusammenschnite aus
> den Daten davor auftreten.

Was sagt denn das Mapfile über die Belegung von .progmem ?

Wenn das über die 64KiB-Grenze geht genügt __flash nicht mehr, dann 
kannst du entweder __memx nehmen (etwas bequeer aber ineffizient) oder 
Daten auf andere Flash-Bänke legen mit __flash1 etc.

von Magnus M. (magnetus) Benutzerseite


Lesenswert?

M. M. schrieb:
> Habe BOOTRST deaktiviert.
>
> Ich möchte keinen Bootloader drauf haben. Die Platine ist mit dem
> Arduino Bootloader gekommen. Habe ich den so nicht beseitigt?

Mach nen Chip Erase.

von Chris F. (chfreund) Benutzerseite


Lesenswert?

Mal generell eine Frage:
Kann das sein, dass die bei dem Clone zwar "2560" draufschreiben, aber 
ein "6450" drin ist? Wenn man das mit Atmel-Tools verwendet, würde ich 
sowas erkennen?

von Karl M. (Gast)


Lesenswert?

M. M. schrieb:
> Ich möchte keinen Bootloader drauf haben. Die Platine ist mit dem
> Arduino Bootloader gekommen. Habe ich den so nicht beseitigt?

Nein, denn da gibt es noch so einige Fuse-Bits, die wollen auch 
angepasst werden.

von AVR (Gast)


Lesenswert?

Wenn die Device Signature passt, ist es schon der richtige Chip. Und 
China Nachbauten derartig komplexer Controller sind "noch" extrem 
unwahrscheinlich.

von Arduinohater (Gast)


Lesenswert?

Das Problem liegt garantiert in der Zeile 42.

Außerdem was ist das für ein bescheurter Titel...verhält sich 
komisch....das einzige was komisch ist, bist Du

von Joachim B. (jar)


Lesenswert?

komisch hat sich mein 2560 auch benommen, habe ich bis 64kB(oder waren 
es 128kB egal) feste statische Daten geschrieben vom Prommer lief das, 
aber als ich über 64/128k kam lief nix mehr

Ich wüsste nicht wo mein Programmierfehler liegen sollte, es ist zwar 
ein 8-Bitter und alles was über den 64K Adressbereich geht sollte doch 
mit dem dritten Adressbyte das AVR Studio richten, egal ich habe 
aufgegeben zu suchen.

Evtl mache ich das mal.

Übrigens spannend, bei meinen 1284p habe ich den Code noch knapp unter 
64K, mal sehen was passiert wenn ich die 64K Grenze übersteige, schon 
mit der FastLED LIB gab es ja "Berechnungsprobleme" im Timing weil 3 
Adressbytes den Code um 10% verlangsamen im Gegensatz zu einem 328p.

hilft zwar nicht, aber vielleicht interessant zu lesen wo es beim 
Überschreiten der 64K-Grenze Probleme geben kann.

von Falk B. (falk)


Lesenswert?

@Joachim B. (jar)

>komisch hat sich mein 2560 auch benommen, habe ich bis 64kB(oder waren
>es 128kB egal) feste statische Daten geschrieben vom Prommer lief das,
>aber als ich über 64/128k kam lief nix mehr

>Ich wüsste nicht wo mein Programmierfehler liegen sollte, es ist zwar
>ein 8-Bitter und alles was über den 64K Adressbereich geht sollte doch
>mit dem dritten Adressbyte das AVR Studio richten,

Das muss man aber "manuell" machen.

>Übrigens spannend, bei meinen 1284p habe ich den Code noch knapp unter
>64K, mal sehen was passiert wenn ich die 64K Grenze übersteige, schon
>mit der FastLED LIB gab es ja "Berechnungsprobleme" im Timing weil 3
>Adressbytes den Code um 10% verlangsamen im Gegensatz zu einem 328p.

Code geht bis 128kB problemlos mit den Standardmethoden, denn der Flash 
wird wortweise adressiert.

>hilft zwar nicht, aber vielleicht interessant zu lesen wo es beim
>Überschreiten der 64K-Grenze Probleme geben kann.

Daten werden byteweise adressiert, da muss man ab 64kB auf "Tricks" 
ausweichen. Jetzt müsste man nur wissen, ob der avr gcc in den 
Standardeinstellungen die Daten in die die unteren 64kB legt. Ich glaube 
aber schon.

von Joachim B. (jar)


Lesenswert?

Falk B. schrieb:
> Code geht bis 128kB problemlos mit den Standardmethoden, denn der Flash
> wird wortweise adressiert.

ne das lag an der Arduino LIB, wie soll das auch anders sein?
Es ist eben nicht egal ob eine Adresse mit 2 Byte zu erreichen ist oder 
mit 3 Byte, das kannst du nicht wegreden, also muss das Timing 
verschieden sein.

dort wurden das Timing für WS2812b gemacht, am 328p eine RGB LED 30µs 
für die Datenbits, passt, mit dem 1284p 33µs nachgemessen, es MUSS an 
den Adressprüngen liegen weil nun ein drittes Adressbyte hinzu kommt.

Beitrag "Arduino FastLED LIB vs. WS28xx LIB"

von c-hater (Gast)


Lesenswert?

Joachim B. schrieb:

> Es ist eben nicht egal ob eine Adresse mit 2 Byte zu erreichen ist oder
> mit 3 Byte, das kannst du nicht wegreden, also muss das Timing
> verschieden sein.

Du begreifst nicht den Unterschied zwischen Code und konstanten Daten.

Beides kann im Flash liegen, aber da der Code wortweise addressiert 
wird, ist bis 128kB alles wie immer, denn man braucht so lange für 
Codeadressen eben keine drei Bytes für die Adresse, sondern nur zwei. 
Das Problem tritt also, bezogen auf den Code beim Mega1284P nicht auf. 
Beim Mega2560 hingegen schon. Da kostet ein call und ein ret je einen 
Takt mehr, ein minimaler Interruptframe ist zwei Takte länger und für 
indirekte Sprünge oder Unterprogrammeaufrufe muss zusätzlich sogar ein 
Hilfregister (EIND) befüllt werden, um das Ziel erreichen zu können.

Beim Zugriff auf konstante Daten sieht die Sache anders aus, dabei 
erfolgt die Adressierung nämlich byteweise und deswegen tritt das 
Problem schon ab 64kB auf. Wenn allerdings die konstanten Daten komplett 
in die ersten 64kB passen (und dann auch tatsächlich dort abgelegt 
werden), ist das kein Problem, dann ändert sich erst einmal nichts. Nur 
wenn die Daten nicht komplett in die ersten 64kB passen, muss wieder ein 
Hilfsregister beschäftigt werden (RAMPZ), was natürlich extra Takte 
kostet.

> dort wurden das Timing für WS2812b gemacht

Beim Timing können zusätzlich auch noch andere Sachen eine Rolle 
spielen, die nichts mit der Größe des Flash-Speichers zu schaffen haben. 
Das betrifft insbesondere Zugriffe auf Peripherie-Register. AVRs, die 
besonders viele davon haben, können auf einen Teil davon nicht mit 
schnellen IO-Befehlen zugreifen, weil halt nicht alle in den IO-Bereich 
passen. Diese müssen dann wie RAM angesprochen werden (memory mapped 
IO), was deutlich langsamer geht. Ausserdem gibt es auch noch spezielle 
Instruktionen, mit denen nicht einmal der gesamte IO-Bereich abgedeckt 
wird. Die sind je nach Target auf bestimmte Register mal anwendbar und 
mal nicht, je nachdem ob das anzusprechende Register nun in dem Bereich 
liegt oder nicht, der mit diesen Instruktionen erreicht werden kann.
Ach ja, fast vergessen: bei Devices mit externem RAM spielt auch noch 
eine Rolle, ob man auf dieses zugreift oder auf das interne. Zugriffe 
auf das externe RAM sind mindestens einen Takt langsamer, u.U. sogar 
noch mehr.

Fazit: Überall, wo ein exaktes Timing wichtig ist, hilft nur sachkundige 
Programmierung in Assembler, um es zuverlässig garantieren zu können.

von Falk B. (falk)


Lesenswert?

@Joachim B. (jar)

>> Code geht bis 128kB problemlos mit den Standardmethoden, denn der Flash
>> wird wortweise adressiert.

>ne das lag an der Arduino LIB, wie soll das auch anders sein?

Ach Jo, du und deine Logik. ;-)

Du hast selber gesagt daß du den Fehler NICHT eindeutlig finden 
konntest, und tus jetzt so, als ob du den Durchblick hättest.

>Es ist eben nicht egal ob eine Adresse mit 2 Byte zu erreichen ist oder
>mit 3 Byte, das kannst du nicht wegreden,

Das will ich doch gar nicht.

>dort wurden das Timing für WS2812b gemacht, am 328p eine RGB LED 30µs
>für die Datenbits, passt, mit dem 1284p 33µs nachgemessen, es MUSS an
>den Adressprüngen liegen weil nun ein drittes Adressbyte hinzu kommt.

Ohne einen Blick hinter die Kulissen (= Assemblercode) ist das alles 
reine Spekulation. Aber davon gibt es hier ja reichlich.

von Falk B. (falk)


Lesenswert?

@c-hater (Gast)

>Du begreifst nicht den Unterschied zwischen Code und konstanten Daten.

In der Tat.

>Fazit: Überall, wo ein exaktes Timing wichtig ist, hilft nur sachkundige
>Programmierung in Assembler, um es zuverlässig garantieren zu können.

Da hast du ausnahmsweise mal Recht. Gar keine Ausraster heute? Was ist 
los? Wirkt die Theapie? Neue Freundin? Neuer Compiler? Ähhh, Assembler 
;-)

von Paul B. (paul_baumann)


Lesenswert?

Falk B. schrieb:
> Was ist
> los? Wirkt die Theapie? Neue Freundin? Neuer Compiler? Ähhh, Assembler

:-)))

MfG Paul

von Joachim B. (jar)


Lesenswert?

Falk B. schrieb:
> Ach Jo, du und deine Logik. ;-)
>
> Du hast selber gesagt daß du den Fehler NICHT eindeutlig finden
> konntest, und tus jetzt so, als ob du den Durchblick hättest.

zumindest habe ich im Gegensatz zum Autor eine Lösung für mich gefunden,
ist der Code um 10% zu langsam beim 1284p weil dort das Timing von mehr 
Adressbytes oder anderen Registerzugriffen bestimmt wird dann benutzt 
man eben eine um 10% langsamere F_CPU dann passen die Zugriffe wieder:
1
#if defined(__AVR_ATmega1284P__) && (F_CPU==16000000)
2
  #define NS(_NS) ( (_NS * ( (F_CPU-1600000) / 1000000L))) / 1000
3
  #define CLKS_TO_MICROS(_CLKS) ((long)(_CLKS)) / ((F_CPU-1600000) / 1000000L)
4
#else

Falk B. schrieb:
> Ohne einen Blick hinter die Kulissen (= Assemblercode) ist das alles
> reine Spekulation. Aber davon gibt es hier ja reichlich.

wer hindert dich?
fastLED ist quellcode offen, aber wenn nicht mal der Autor eine Lösung 
wusste oder verweigerte dann bleibe ich halt auf meiner 
Umgehungstrategie die schon Jahre funktioniert.
Gut Reden können ja viele,
Lösungen bringen nur wenige.

: Bearbeitet durch User
von M. M. (mrmcchicken)


Lesenswert?

Hallo nochmal. Juhuu es funktioniert nun! Bei nachträglichen 
überlegungen ist es recht einleuchtend, dass mit 16 Bit nicht der ganze 
Speicher Adressiert werden kann.
Ich habe es nun mit RAMPZ und elpm gelöst. Danke c-hater für diese 
ausführliche Erklärung!

von Carl D. (jcw2)


Lesenswert?

> für indirekte Sprünge oder Unterprogrammeaufrufe muss zusätzlich sogar ein
> Hilfsregister (EIND) befüllt werden, um das Ziel erreichen zu können.

Oder die avr-gcc Variante:
alle Zeiger haben 16bit. Funktionen, die indirekt angesprochen werden, 
bekommen eine garantierte Adresse innerhalb der ersten 64k-Worte, die 
aus einem Sprung zur echten Funktion auch jenseits der magischen 
128kB-Grenze.
Diese "Trampolines" werden nach den Int-Vektoren gelinkt. FLASH-Daten 
kommen danach. Deshalb wie oben "ab ca. 60kB FLASH-Daten spinnt das 
Programm".
Dann wird es so unbequem, daß man 32bit-Pointer auf alles als Erlösung 
ansieht.
 Oder eben __flash1 und Erfahrung im .lss-File lesen.

von Joachim B. (jar)


Lesenswert?

c-hater schrieb:
> Beides kann im Flash liegen, aber da der Code wortweise addressiert
> wird, ist bis 128kB alles wie immer, denn man braucht so lange für
> Codeadressen eben keine drei Bytes für die Adresse, sondern nur zwei.

wäre mir neu, ich programmiere ja nicht erst seit Arduino,

jede 8-Bit CPU mit 64K Adressraum brauchte 16 Bit Adressregister und die 
reichen nun mal nur bis 64K -> 2^16 von 6502 bis z80 und LH5803

bei der erweiterten z80 wurde mir Banking gearbeitet.

mit 128K Adressraum braucht man auch schon ein Byte mehr! genau wie beim 
256K Adressraum.

Ich bin gespannt wie du das erklärst:

c-hater schrieb:
> ist bis 128kB alles wie immer, denn man braucht so lange für
> Codeadressen eben keine drei Bytes für die Adresse, sondern nur zwei

??? mein Rechner sagt 2^16 = 65536

: Bearbeitet durch User
von Falk B. (falk)


Lesenswert?

@Joachim B. (jar)

>c-hater schrieb:
>> Beides kann im Flash liegen, aber da der Code wortweise addressiert
>> wird, ist bis 128kB alles wie immer, denn man braucht so lange für
>> Codeadressen eben keine drei Bytes für die Adresse, sondern nur zwei.

>wäre mir neu, ich programmiere ja nicht erst seit Arduino,

Tja, man lernt eben nie aus! Lange dabei sein heißt noch lange nicht 
Wissen zu haben ;-)

>jede 8-Bit CPU mit 64K Adressraum brauchte 16 Bit Adressregister und die
>reichen nun mal nur bis 64K -> 2^16

Ja, aber der AVR adressiert seine Befehle in 16 Bit Wortbreite. Schrieb 
ich bereits. Also 64kWORTE (a 16 Bit) = 128kByte!

>mit 128K Adressraum braucht man auch schon ein Byte mehr!

Nö.

>Ich bin gespannt wie du das erklärst:

Nützt nix, du liest die Antworten ja nicht, geschweige denn, daß du sie 
verstehen WILLST!

: Bearbeitet durch User
von Joachim B. (jar)


Lesenswert?

Falk B. schrieb:
> Nützt nix, du liest die Antworten ja nicht, geschweige denn, daß du sie
> verstehen WILLST!

das liegt immer nur an dem Erklären wenn einer nicht versteht!

Falk B. schrieb:
> Ja, aber der AVR adressiert seine Befehle in 16 Bit Wortbreite. Schrieb
> ich bereits.

und auch das gibt nur 64K Adressraum wobei Wortbreite .....saudoof ist

es gibt die Wortbreite nicht mehr short normal long?

16 Bit ist bei dir also größer als 64K?

: Bearbeitet durch User
von Marc V. (Firma: Vescomp) (logarithmus)


Lesenswert?

Joachim B. schrieb:
> jede 8-Bit CPU mit 64K Adressraum brauchte 16 Bit Adressregister und die
> reichen nun mal nur bis 64K -> 2^16 von 6502 bis z80 und LH5803

 Das ist reines Marketing bei ATMEL.
 AVR Befehle sind 16bit, es gibt keine 8bit Befehle und auch Flash ist
 nur 16bitweise nutzbar.
 Also sollte M328 normallerweise M168 heissen, da sie nur 16K x 16bit
 Flash hat. Folglich hat M128 nur 64KB Worte und die kann man mit
 16bit adressieren.

Joachim B. schrieb:
> und auch das gibt nur 64K Adressraum wobei Wortbreite .....saudoof ist
>
> es gibt die Wortbreite nicht mehr short normal long?
>
> 16 Bit ist bei dir also größer als 64K?

 Nein, aber mit 16bit kann man 64K Byt oder 64K Word oder 64K Long
 adressieren.
 Deswegen gibt es auf der Flashadresse Low- und Highbyte und deswegen
 gibt es auch Padding bei Constanten im Flash - diese können nicht eine
 ungerade Länge haben.
 Auch deswegen werden beim ASM programmieren die Adressen der Konstanten
 mit 2 multipliziert.

von Frickelfritze (Gast)


Lesenswert?

Marc V. schrieb:
> Nein, aber mit 16bit kann man 64K Byt oder 64K Word oder 64K Long
> adressieren.

Das scheint ja bei manchen Leuten gar nicht in den Kopf zu gehen.

von c-hater (Gast)


Lesenswert?

Joachim B. schrieb:

> ??? mein Rechner sagt 2^16 = 65536

Tja, so ist das mit der Computerei. Shit in -> shit out.

Die korrekte Rechnung ist nämlich:

2^16 Addressen * 2 Byte Codewortbreite = 131072 Byte

von Marc V. (Firma: Vescomp) (logarithmus)


Lesenswert?

Frickelfritze schrieb:
> scheint ja bei manchen Leuten gar nicht in den Kopf zu gehen.

 Die Schuld liegt beim ATMEL.
 Microchip hätte bei 14bit PIC auch  14336 oder 16384 Byt Flash angeben
 können, anstatt (wie auch richtig) 8Kword Flash.

von Frickelfritze (Gast)


Lesenswert?

Marc V. schrieb:
> Die Schuld liegt beim ATMEL.

Neeee, die Schuld liegt in der Beschränkung im Kopf:

Marc V. schrieb:
> mit 16bit kann man 64K Byt oder 64K Word oder 64K Long
> adressieren.

Denn man kann mit 16 Bit auch 64K Apfelbäume oder
64K Kernkraftwerke adressieren.

von Joachim B. (jar)


Lesenswert?

Falk B. schrieb:
> Nützt nix, du liest die Antworten ja nicht, geschweige denn, daß du sie
> verstehen WILLST!

Doch wenn sie richtig erklärt werden, das hier habe ich bei Atmel noch 
nie gelesen:

https://www.uni-koblenz.de/~physik/informatik/MCU/core.pdf
"Da alle AVR-Instruktionen entweder 16 oder 32 Bit lang sind, ist dieser 
Speicher in 8192 Zellen von jeweils 16Bit aufgeteilt."

na endlich, doof halt wenn sie den 8-Bitter nennen!

Marc V. schrieb:
> Das ist reines Marketing bei ATMEL.
>  AVR Befehle sind 16bit, es gibt keine 8bit Befehle und auch Flash ist
>  nur 16bitweise nutzbar.
>  Also sollte M328 normallerweise M168 heissen, da sie nur 16K x 16bit
>  Flash hat. Folglich hat M128 nur 64KB Worte und die kann man mit
>  16bit adressieren.

Worte ist in heutigen Zeiten eh eine ungünstige Bezeichnung, da finde 
ich int8_t bis uint64_t verständlicher.

Frickelfritze schrieb:
> Neeee, die Schuld liegt in der Beschränkung im Kopf

ne nicht daran, sondern an der bewussten Verschleierung die 8-Bitter zu 
nennen!

c-hater schrieb:
> Tja, so ist das mit der Computerei. Shit in -> shit out.
>
> Die korrekte Rechnung ist nämlich:
>
> 2^16 Addressen * 2 Byte Codewortbreite = 131072 Byte

Da gebe ich dir absolut Recht! bei dem Satz besonders:

c-hater schrieb:
> Tja, so ist das mit der Computerei. Shit in -> shit out

http://www.atmel.com/devices/ATMEGA1284P.aspx
"The high-performance Atmel 8-bit AVR RISC-based microcontroller"

war es nicht mal so eine 8-Bit CPU ein "Wort" aus 8 Bits hatte und eine 
16-Bit CPU ein "Wort" aus 16-Bits? Wobei Wort auch gerne gemixt genutzt 
wurde und mal 8-Bit, 16-Bit bis 64-Bit bedeuten konnte?

Egal ich habe jetzt, die Beschränkung in meinem Kopf ist aufgehoben, es 
mit dem erweiterten PC programm counter mit drittem Byte muss mir also 
bei dem atmega 2560 begegnet sein, nur ich ehemals Unwissender habe das 
auf den atmega 1284p übertragen.

DANKE c-hater DU hast es als Einziger deutlicher gemacht, aber nicht so 
deutlich wie in diesen PDF 
https://www.uni-koblenz.de/~physik/informatik/MCU/core.pdf

Ich hatte auch noch mal gegoogelt, abgesehen von der Atmel Bezeichnung 
8-Bit CPU gab es nicht viele Fundstellen die es deutlicher machten.

Falk B. schrieb:
> Code geht bis 128kB problemlos mit den Standardmethoden, denn der Flash
> wird wortweise adressiert.

ja aber beim MC68000 war Bytezugriff immer irgendwie krampfig wenn man 
nicht den MC68008 hatte, von daher habe ich beim "8-Bit AVR" nie was von 
16-Bit Organisation bemerkt.

Falk B. schrieb:
> Ja, aber der AVR adressiert seine Befehle in 16 Bit Wortbreite. Schrieb
> ich bereits. Also 64kWORTE (a 16 Bit) = 128kByte!

wenn das so war dann sorry, musst du gut versteckt haben oder ging im 
Grundrauschen unter!
Dann auch dir ein verspätetes DANKE

: Bearbeitet durch User
von Joachim B. (jar)


Lesenswert?


von Falk B. (falk)


Lesenswert?

@Joachim B. (jar)

>> Nützt nix, du liest die Antworten ja nicht, geschweige denn, daß du sie
>> verstehen WILLST!

>Doch wenn sie richtig erklärt werden, das hier habe ich bei Atmel noch
>nie gelesen:

Weil dir aus sonst diverse Grundlagen fehlen, u.a. Verständnis von 
technischem Englisch.

>https://www.uni-koblenz.de/~physik/informatik/MCU/core.pdf
>"Da alle AVR-Instruktionen entweder 16 oder 32 Bit lang sind, ist dieser
>Speicher in 8192 Zellen von jeweils 16Bit aufgeteilt."

Siehe Anhang!!!

>na endlich, doof halt wenn sie den 8-Bitter nennen!

Doof ist jemand ganz anderes . . .

Denn die Bezeichung 8-Bit bezieht sich in den allermeisten Fällen auf 
die Bitbreite der CPU-Register!

>Worte ist in heutigen Zeiten eh eine ungünstige Bezeichnung,

Das war sie auch früher schon, denn die Wortbreite war und ist immer von 
der betrachteten CPU abhängig.

>ne nicht daran, sondern an der bewussten Verschleierung die 8-Bitter zu
>nennen!

Unfug! Auch der 8051 ist ein 8-Bitter. Nach deiner "Logik" darf der dann 
auch keinen 16 Bit Programm counter in der CPU haben ;-)

>http://www.atmel.com/devices/ATMEGA1284P.aspx
>"The high-performance Atmel 8-bit AVR RISC-based microcontroller"

>war es nicht mal so eine 8-Bit CPU ein "Wort" aus 8 Bits hatte

Die CPU-Register. Wobei sich auch das nur auf die "normalen" 
Arbeitsregister bezieht. Auch der 8015, 6811 etc. haben 
(zusammengesetzte) 16 Bit Arbeitsregister.

>> Code geht bis 128kB problemlos mit den Standardmethoden, denn der Flash
>> wird wortweise adressiert.

>ja aber beim MC68000 war Bytezugriff immer irgendwie krampfig wenn man
>nicht den MC68008 hatte,

Das interessiert den AVR aber nicht.

Der 68000er ist auch ein 32 Bit Prozessor, der aber nur einen 16 Bit 
Datenbus hat (zumindest war das beim Amiga so)

von Falk B. (falk)


Angehängte Dateien:

Lesenswert?

Siehe Anhang.

von Joachim B. (jar)


Lesenswert?

Falk B. schrieb:
> Doof ist jemand ganz anderes . . .

warum wirst du öfter beleidigend? (hast du nur schlechten Sex?)

mehr als Danke sagen kann ich doch nicht und ich habs ja jetzt 
verstanden.

Falk B. schrieb:
> Die CPU-Register. Wobei sich auch das nur auf die "normalen"
> Arbeitsregister bezieht. Auch der 8015, 6811 etc. haben
> (zusammengesetzte) 16 Bit Arbeitsregister.

ja der LH5803 und die z80 auch, der MC68008 sogar 32-Bit, das ist noch 
keine Erklärung, also Dozent oder Lehrer wirst DU nie.

Falk B. schrieb:
> Der 68000er ist auch ein 32 Bit Prozessor, der aber nur einen 16 Bit
> Datenbus hat (zumindest war das beim Amiga so)

auch beim Atari und der mc68008 sogar nur mit 8-bit Datenbus, wo ist nun 
die neue Erkenntnis?

von Marc V. (Firma: Vescomp) (logarithmus)


Lesenswert?

Joachim B. schrieb:
> ne nicht daran, sondern an der bewussten Verschleierung die 8-Bitter zu
> nennen!

 Nein, nur hört sich 32KByt besser an als 16K Words.
 Und solange du an der Byt und Word Bezeichnungen herumreitest, wirst
 du Probleme haben.

 Es sind 64K * Befehlsbreite.
 Punkt.

von Joachim B. (jar)


Lesenswert?

Marc V. schrieb:
> Nein, nur hört sich 32KByt besser an als 16K Words.
>  Und solange du an der Byt und Word Bezeichnungen herumreitest, wirst
>  du Probleme haben.

ne ne ne

ich habs ja schon verstanden, es fehlte mir nur dieser Satz:

Joachim B. schrieb:
> https://www.uni-koblenz.de/~physik/informatik/MCU/core.pdf
> "Da alle AVR-Instruktionen entweder 16 oder 32 Bit lang sind, ist dieser
> Speicher in 8192 Zellen von jeweils 16Bit aufgeteilt."

von Marc V. (Firma: Vescomp) (logarithmus)


Lesenswert?

Joachim B. schrieb:
> ich habs ja schon verstanden, es fehlte mir nur dieser Satz:
>
> Joachim B. schrieb:
>> https://www.uni-koblenz.de/~physik/informatik/MCU/core.pdf
>> "Da alle AVR-Instruktionen entweder 16 oder 32 Bit lang sind, ist dieser
>> Speicher in 8192 Zellen von jeweils 16Bit aufgeteilt."

Falk B. schrieb:
> Ja, aber der AVR adressiert seine Befehle in 16 Bit Wortbreite. Schrieb
> ich bereits. Also 64kWORTE (a 16 Bit) = 128kByte!

Marc V. schrieb:
> AVR Befehle sind 16bit, es gibt keine 8bit Befehle und auch Flash ist
>  nur 16bitweise nutzbar.
>  Also sollte M328 normallerweise M168 heissen, da sie nur 16K x 16bit
>  Flash hat. Folglich hat M128 nur 64KB Worte und die kann man mit

c-hater schrieb:
> 2^16 Addressen * 2 Byte Codewortbreite = 131072 Byte

 Was ist da besser erklärt ?

 Oder ist es die uni-koblenz die Hochachtung hervorruft ?

von Joachim B. (jar)


Lesenswert?

Marc V. schrieb:
> Was ist da besser erklärt ?

wie oft denn noch?
ich habe mich bei c-hater & Falk bedankt, warum ich das nun noch mal für 
dich wiederholen muss verstehe ich nicht

Joachim B. schrieb:
> DANKE c-hater DU hast es als Einziger deutlicher gemacht

Joachim B. schrieb:
> Falk B. schrieb:
>> Ja, aber der AVR adressiert seine Befehle in 16 Bit Wortbreite. Schrieb
>> ich bereits. Also 64kWORTE (a 16 Bit) = 128kByte!
>
> wenn das so war dann sorry, musst du gut versteckt haben oder ging im
> Grundrauschen unter!
> Dann auch dir ein verspätetes DANKE

Bitte 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
Noch kein Account? Hier anmelden.