ich habe heute die USART meines AVR64DD20 programmiert und mit ein paar Änderungen von der Bibliothek von Microchip selbst ( https://github.com/microchip-pic-avr-examples/avr64dd32-getting-started-with-i2c-mplabx , lediglich anderer Pin) verwendet. Die ganz gewöhnliche printf-Funktion, die jetzt den USART-stream verwendet, funktioniert für einzelne Werte und Texte tadellos. Jedoch ist mir aufgefallen, dass wenn ich:
int main(void) {
1
USART0_Init();
2
3
PORTA.DIR |= DSCK_PIN;
4
5
char testbuffer2[1000];
6
_delay_ms(10000);
7
for (int i = 0; i< 1000; i++)
8
{
9
testbuffer2[i] = i;
10
}
11
testbuffer2[999] = '\0';
12
while(1)
13
{
14
printf("%s", testbuffer2);
15
_delay_ms(1000);
16
}
}
nutze, ich nur noch garbage-data empfange ohne Grenzen. Der Delay wird nicht mehr erreicht und es kommt nur ein Stream an "0xFF" am Terminal an. Weiß jemand, was ich falsch mache? Sobald die Arraygröße von testbuffer2 größer als 100 ist, scheinen die Probleme zu beginnen. Es ist genug SRAM auf dem Controller vorhanden, da bis auf die USART und I2C-Inits nichts ausgeführt wird.
testbuffer2 größer als 100 ist, scheinen die Probleme zu beginnen. Es
ist genug SRAM auf dem Controller vorhanden, da bis auf die USART und
I2C-Inits nichts ausgeführt wird.
Mag sein, aber dein testbuffer2 ist eine lokale Variable in main(), die wird auf dem Stack angelegt. Mach aus der mal eine globale Variable.
testbuffer2 größer als 100 ist, scheinen die Probleme zu beginnen. Es
ist genug SRAM auf dem Controller vorhanden, da bis auf die USART und
I2C-Inits nichts ausgeführt wird.
Mag sein, aber dein testbuffer2 ist eine lokale Variable in main(), die
wird auf dem Stack angelegt. Mach aus der mal eine globale Variable.
Lieben Dank für die schnelle Antwort. Hab's getestet und leider das selbe Resultat. Hier Mal ein Bild vom Output. Baudrate und sonstiges stimmt, die Daten schicken ohne Pause.
Das ist nicht C&P Deines Codes, stimmts?
Du schreibst als erstes in testbuffer2[0] = 0; d.h. erzeugst einen leeren String und printf("%s" gibt gar nichts aus.
Warum wird hier wohl immer wieder gebetsmühlenartig gefordert, benutzte C&P oder den Dateianhang!
Lieben Dank für die schnelle Antwort. Hab's getestet und leider das
selbe Resultat. Hier Mal ein Bild vom Output.
Sehr sinnvoll! Wenn schon, dann die HEX-Darstellung!
Außerdem ist es keine gute Idee, Binärzahlen von 0-32 mittels printf() zu senden, denn das sind Steuerzeichen, die weiß was machen. Auch eine Schleife von 0-1000 ist hier fragwürdig, weil da beim Speichern von i im Array ein Überlauf passiert. Dann kommen wieder Steuerzeichen.
Woher willst Du wissen ob Du genug Platz für so eine Variable auf dem Stack hast? Es kommt nicht nur auf die Menge des verfügbaren RAMs an, sondern auch darauf wie er genutzt wird. Dazu müsste man ins MAP file oder Linkerscript schauen. Wer weiß schon wie viel RAM alleine durch die Microchip Library belegt wird. Dazu noch printf(). Wenn es sich um das printf() aus der newlib in Standard config handelt dann genehmigt sich das gerne mal mehrere kB.
Lieben Dank für die schnelle Antwort. Hab's getestet und leider das
selbe Resultat. Hier Mal ein Bild vom Output.
Sehr sinnvoll! Wenn schon, dann die HEX-Darstellung!
Außerdem ist es keine gute Idee, Binärzahlen von 0-32 mittels printf()
zu senden, denn das sind Steuerzeichen, die weiß was machen. Auch eine
Schleife von 0-1000 ist hier fragwürdig, weil da beim Speichern von i im
Array ein Überlauf passiert. Dann kommen wieder Steuerzeichen.
Nun, das Problem war ursprünglich, dass es mit Sensordaten bereits nicht funktionierte, sobald der Buffer größer gewählt wurde als 100, unabhängig davon ob die übertragene Länge 100 übersteigt oder nicht.
Die Steuerzeichen sollten bei hterm oder printf nicht zu Problemen führen, immerhin schicke ich auch float-bytes byteweise raus und da kann ich nicht garantieren, dass kein Steuerzeichen ankommt.
Die ASCII-Darstellung ist natürlich vollkommener Quatsch. Falls Bedarf besteht, kann ich den Output wieder als HEX abspeichern.
Ich habe Mal die Main hochgeladen, das Projekt ist an einem anderen Computer. Da sieht man die anderen Versuche zu printen. Der ewiglange printf-Text hat funktioniert.
Woher willst Du wissen ob Du genug Platz für so eine Variable auf dem
Stack hast? Es kommt nicht nur auf die Menge des verfügbaren RAMs an,
sondern auch darauf wie er genutzt wird. Dazu müsste man ins MAP file
oder Linkerscript schauen. Wer weiß schon wie viel RAM alleine durch die
Microchip Library belegt wird. Dazu noch printf(). Wenn es sich um das
printf() aus der newlib in Standard config handelt dann genehmigt sich
das gerne mal mehrere kB.
Gut zu wissen, danke für den Hinweis! Als globale Variable funktioniert es leider auch nicht.
Sehr sinnvoll! Wenn schon, dann die HEX-Darstellung!
Außerdem ist es keine gute Idee, Binärzahlen von 0-32 mittels printf()
zu senden, denn das sind Steuerzeichen, die weiß was machen.
Das ist beim verwendeten Terminalprogramm schon so OK, das macht nicht "wer weiß was".
Auch eine Schleife von 0-1000 ist hier fragwürdig
Die Schleife geht bis 999
Dann kommen wieder Steuerzeichen.
Selbst wenn es so wäre, würde das die Ausgabe nicht beeinträchtigen, denn er schließt die Zeichenkette deppensicher ab:
Sehr sinnvoll! Wenn schon, dann die HEX-Darstellung!
Außerdem ist es keine gute Idee, Binärzahlen von 0-32 mittels printf()
zu senden, denn das sind Steuerzeichen, die weiß was machen.
Das ist beim verwendeten Terminalprogramm schon so OK, das macht nicht
"wer weiß was".
Ich rede von der printf() Funktion im Controller! Im Idealfall sendet die einfach ALLES bis zum Nullterminator.
Auch eine Schleife von 0-1000 ist hier fragwürdig
Die Schleife geht bis 999
Ja und? Aber wenn testbuffer2[0]=0 von der Schleife beschrieben wird, gibt printf() nie was aus!
Selbst wenn es so wäre, würde das die Ausgabe nicht beeinträchtigen,
denn er schließt die Zeichenkette deppensicher ab:
Das sieht sehr nach falscher Baudrate aus.
Da steht ja 115,2kBaud. Welchen Quarz hast Du denn angeschlossen, damit
der Fehler klein genug (<1%) ist?
Gar keinen, ich benutze die interne Clock. Es funktioniert ja für alles andere, dieser Output ist "random" und hört nie auf. Also stoppt auch nicht kurz für eine Sekunde. Und wenn ich eine while(1); dranhänge, wird diese nie erreicht. Irgendwas passiert mit der USART, dass da alles schief läuft.
Ist der Buffer klein genug oder printe ich (wie in der angehängenten main_1_.c) einen sehr langen const String aus, funktionierts ohne Probleme. Aber verwende ich ein 1 kB großes Array geht alles den Bach runter.
Unabhängig davon ob ich
zu oft nullterminiere oder das Array mit einem fixen char-Wert fülle,
das zweite 1 kB Array rauslösche und das erste Array als globale Variable deklariere,
Welche genau und wie konfiguriert? Das Teil hat verschiedene interne
Taktquellen und sind obendrein recht vielfältig konfigurierbar.
Ich nutze den internen "high-frequency oscillator". Die Taktfrequenz ist dabei default 4 MHz und sonst wird auch nichts an der Clock gedreht. AVR ist für mich relativ neu und ich hatte schon genug Problem, dass "CPU_CCP"-Register zu finden, dass im Datenblatt und teilweise in den Header noch als "CPU.CCP" in den Kommentaren erwähnt wird.
Es funktioniert ja für alles
andere, dieser Output ist "random" und hört nie auf.
Poste einfach mal das fertige Programm, bevorzugt als Hex-File. Dann
kann man reinschauen und sehen, was wirklich passieren sollte.
Was tut printf("%s",testbuffer2) genau? Streamt die Bibliothek an dieser Stelle testbuffer2 direkt an die UART, oder wird ein temporärer Speicher alloziert, der Inhalt von testbuffer2 dorthin kopiert, und dann der temporäre Speicher an die UART gestreamt?
Gab es da nicht vor kurzem einen ahnlichen Fall - irgendwas mit String
mal als Variable, mal als Konstante?
Kann ich mich nicht erinnern. Kannst du das genauer spezifizieren?
Wenn nicht, warten wir halt bis Montag. Dann kommen die belastbaren Fakten vom TO, so hat er zumindest versprochen.
Ich bin wirklich gespannt. Die DD sind ja wirklich noch sehr frisch. Ein Erratum wäre also durchaus möglich. Aber auch ein Fehler in den MC-Libs ist nicht ausgeschlossen.
Für mehr reicht es aber heute morgen nicht, und ob es wirklich etwas mit
dem Fall hier zu tun hat ...?
Kann man wohl nicht völlig ausschließen, auch wenn das Problem zunächst ein anderes zu sein scheint. Es könnte trotzdem sein, das beides im Kern auf denselben Fehler zurückzuführen ist, wo auch immer der genau angesiedelt sein mag.
Deswegen wollte ich auf Binärebene schauen, was da die MCU tatsächlich als Programm erreicht. Wenn da schon klar wird, dass es fehlerhaft ist, dann kann der Fehler nur irgendwo in der gcc-Toolchain (oder natürlich beim Programmierer des jeweiligen Codebestandteils selber) liegen.
Interessant für mich persönlich wird es aber eher dann, wenn sich herausstellt, dass das Programm auf Binärebene formal OK ist und funktionieren müsste, aber trotzdem Mist passiert.
Das ist sicher so, aber das wissen inzwischen auch alle, die es interessiert. Und den Fetischisten ist eh' nicht zu helfen. Die bleiben bei ihrer Bibel.
Ich nutze den internen "high-frequency oscillator". Die Taktfrequenz ist
dabei default 4 MHz und sonst wird auch nichts an der Clock gedreht.
Die Frage ist aber, ob Deine Lib 115.2kBaud bei 4MHz auch unterstützt.
Sende doch einfach mal erst einen konstanten String "Hallo Test\n", erstmal ohne haufenweise Arrays im RAM zu reservieren.
Debuggen heißt nicht, ein Programm als unteilbaren Brocken zu testen, sondern erstmal jede Teilfunktion für sich.
Ist der Buffer klein genug oder printe ich (wie in der angehängenten
main_1_.c) einen sehr langen const String aus, funktionierts ohne
Probleme. Aber verwende ich ein 1 kB großes Array geht alles den Bach
runter.
Und der genannte String besteht ja ausschließlich aus Kleinbuchstaben.
hier ist Mal das Main-Programm, dass bei mir äußerst komischen Output gibt. Baudrate ist auf 115200, der TX-Pin ist Pin 4 Port D. Verwendet wurde der AVR64DD20.
#define ARRAY_LEN 100
char rxBuf[ARRAY_LEN] = {0x65};
int main(void) {
1
USART0_Init();
2
configureClock();
3
4
_delay_ms(1000);
5
6
for (int i = 0; i < ARRAY_LEN; i++)
7
{
8
rxBuf[i]= 0x65;
9
}
10
11
rxBuf[ARRAY_LEN-1] = '\0';
12
13
printf("%s", rxBuf);
14
15
while(1);
}
Der Output führt bei mir zu dem selben, wie in dem Bild oben gezeigt.
Und hier sind noch die einzelnen Dateien. Ich wusste nicht was lieber
ist, ein paar main/USART-Files oder das ganze Projekt hochzuladen.
Dieses "Werk" kann unmöglich Quelle für das gepostetete Hexfile gewesen sein. Weil: es läßt sich auf Grund eines Tippfehlers und eines nicht vorhandenen Includefiles schonmal garnicht übersetzen.
Weiteren Kram, der unglücklich bis falsch ist, schenke ich mir hier. Da sollen die C-Fetischisten sich die Mäuler drüber zerreissen, das macht denen Spaß.
Nach der Korrektur der gröbsten Fehler kommt jedenfalls tatsächlich erstmal was raus.
Was da rauskommt, hat allerdings schon strukturell kaum etwas mit dem Hexfile zu tun, was du geposted hast. Das Hexfile stammt mit an Sicherheit grenzender Wahrscheinlichkeit von einem völlig anderen Target und wurde obendrein mit einiger Wahscheinlichkeit "post-build"-manipuliert.
Ich würde mal sagen: Troll. Für einen Troll immerhin deutlich über dem üblichen Niveau, aber trotzdem verdammenswert.
Wie magst du deine Rednerei
Nur gleich so hitzig übertreiben?
an Max W.:
Zwar habe ich gewisse Zweifel, dass Ihnen das weiterhilft, denn a) habe ich eine zusammengestoppelte C-Umgebung (nicht fragen!) und b) nur einen AVR128DB28, trotzdem: das zuletzt Gezeigte läuft hier, mutatis mutandis, es kommen 99 'e' an.
Es kommen auch z.B. 999, mit ARRAY_LEN = 1000.
Nee, das ist alt: das wurde von Microchip irgendwann mal geändert, und ich hatte das von Hand nachgezogen. War vor ein paar Wochen hier erwähnt worden.
Nee, das ist alt: das wurde von Microchip irgendwann mal geändert, und
ich hatte das von Hand nachgezogen. War vor ein paar Wochen hier erwähnt
worden.
Was ist alt? Das mit dem "FREQ" oder das mit dem "FRQ"? Ich habe testweise gerade mal das Pack aktualisiert, aber das ist immer noch auf "FREQ" geeicht. Also dürfte "FRQ" alt bis bis längst begraben sein sein. Sprich: falls es so eine Änderung tatsächlich mal gegeben hat, muß das vor sehr viel längerer Zeit als nur "ein paar Wochen" passiert sein.
Die Änderung muss vor ein oder zwei Jahren erfolgt sein, aktuell ist 'FRQSEL'; dass es hier im Forum erwähnt wurde, liegt einige Wochen zurück (aber ich finde es jetzt nicht mehr).
Schauen Sie mal in die diversen Datenblätter unter CLKCTRL-OSCHFCTRLA.
Nein, sicher nicht. Aktuell ist das Pack AVR-Dx_DFP in der Version 2.2.253. Und das heißt der Kram "FREQSEL". Und so hieß er auch schon in der Version 1.8.95 (das war die bei mir installierte vor dem heutigen Upgrade). Und die weist sich mit dem Datum 2021-04-29 aus.
Also: mindestens seit zwei vollen Jahren heißt diese Scheiße "FREQSEL".
Also: mindestens seit zwei vollen Jahren heißt diese Scheiße "FREQSEL".
Was übrigens bedeutet: für den DD hieß sie wohl schon immer so. Ich hatte jetzt keine Lust, die ollen Packs runterzuladen, aber der DD ist sicher nicht viel älter als 2021-04-29. D.h.: mit einiger Wahrscheinlichkeit hat das bei dem niemals anders geheißen.
Also ich weiß ja nicht, wo bzw. was Sie herunterladen, aber in meinem Microchip.AVR-Dx_DFP.2.3.272 mit '2022-12-16' steht es sowohl in AVR64DD20def.inc als auch in ioavr64dd20.h mit 'FRQSEL'.
Ist doch aber nur eine Petitesse, da stehen wir drüber, so fehlertolerant sind wir allemal, und zumindest bei mir kommt noch die Altersmilde hinzu.
Zurück zum eigentlichen Thema, Max W. wird sicher schon ungeduldig.
Also ich weiß ja nicht, wo bzw. was Sie herunterladen
Von MC, denke ich doch.
aber in meinem
Microchip.AVR-Dx_DFP.2.3.272 mit '2022-12-16'
Das bietet er mir auch mit explizitem "Update" überhaupt nicht an. Da haben die MC-Wichser wohl was gegen Windows7...
Naja, stört natürlich die "Telemetrie" ein wenig. Werde ich also mal mit dem dienstlichen Windows10 weiter durchexerzieren müssen. Da läuft die "Telemetrie" ja vermutlich ungestört und obendrein massiv gepimpt. Muss ich mir privat aber nicht antun...
Ich muß die Diskussion über dieses Thema also erst einmal vertagen.
Ist doch aber nur eine Petitesse, da stehen wir drüber, so
fehlertolerant sind wir allemal
Ja klar. Es bleibt der Fakt, dass das Hexfile niemals durch einen einfachen Compilerlauf aus den geposteten Quellen entstanden sein kann. Weder mit einer aktuellen noch mit einer rezenten Version der AVR64DD20-Includes.
Und hier sind noch die einzelnen Dateien. Ich wusste nicht was lieber
ist, ein paar main/USART-Files oder das ganze Projekt hochzuladen.
Dieses "Werk" kann unmöglich Quelle für das gepostetete Hexfile gewesen
sein. Weil: es läßt sich auf Grund eines Tippfehlers und eines nicht
vorhandenen Includefiles schonmal garnicht übersetzen.
Weiteren Kram, der unglücklich bis falsch ist, schenke ich mir hier. Da
sollen die C-Fetischisten sich die Mäuler drüber zerreissen, das macht
denen Spaß.
Hi,
ich bin kein Troll, wirklich nicht. Ich habe nicht gemerkt, dass der Student die testfunctions.h inkludiert hat, die man für die usart gar nicht braucht. Er dachte sich wohl, viel hilft viel und hat alles überall inkludiert.
Nach der Korrektur der gröbsten Fehler kommt jedenfalls tatsächlich
erstmal was raus.
Was da rauskommt, hat allerdings schon strukturell kaum etwas mit dem
Hexfile zu tun, was du geposted hast. Das Hexfile stammt mit an
Sicherheit grenzender Wahrscheinlichkeit von einem völlig anderen Target
und wurde obendrein mit einiger Wahscheinlichkeit
"post-build"-manipuliert.
Ich würde mal sagen: Troll. Für einen Troll immerhin deutlich über dem
üblichen Niveau, aber trotzdem verdammenswert.
Welche grobe Fehler? Das mit der nicht inkludierten .h ist nun eben Quatsch, ich wollte sie nicht mitschicken, weil sie nun eben nicht von mir ist.
Nun ja, dieses '#include "testfunctions.h"' habe ich auskommentiert, und
den Ausgabepin für USART0 auf mein A0 gelegt. Mehr aber nicht.
Ernsthaft? Also mein Includefile für den AVR64DD20 kennt jedenfalls kein
Symbol "CLKCTRL_FRQSEL_24M_gc". Das heißt da: "CLKCTRL_FREQSEL_24M_gc".
Und genau so heißt es auch in meinem Includefile für den von dir
verwendeten AVR128DB28.
Also zumindest das mußt du ebenfalls noch geändert haben...
Wie gesagt, ich bin neu in der Programmierung von AVR und habe keine Ahnung, was sich über die Jahre geändert hat. Die Zeile Code, die in configureClock() verwendet wird, ist 1:1 aus dem Thread der zuvor gepostet wurde.
Ja klar. Es bleibt der Fakt, dass das Hexfile niemals durch einen
einfachen Compilerlauf aus den geposteten Quellen entstanden sein kann.
Weder mit einer aktuellen noch mit einer rezenten Version der
AVR64DD20-Includes.
Das ist und bleibt natürlich der Punkt.
Ganz ehrlich: Ich habe dann einen Fehler beim Auswählen der Datei gemacht. Ich habe die einzige .hex-File, die ich im Projekt gefunden habe, hochgeladen, nachdem ich vorher das Projekt compiliert habe.
an Max W.:
Zwar habe ich gewisse Zweifel, dass Ihnen das weiterhilft, denn a) habe
ich eine zusammengestoppelte C-Umgebung (nicht fragen!) und b) nur einen
AVR128DB28, trotzdem: das zuletzt Gezeigte läuft hier, mutatis mutandis,
es kommen 99 'e' an.
Es kommen auch z.B. 999, mit ARRAY_LEN = 1000.
Danke schön fürs Ausprobieren! Auf meinem AVR64DD28 funktioniert der Code leider auch.
Verstehe ich das richtig: Sie haben einen AVR64DD28 und einen AVR64DD20, und nur bei Letzterem gibt es Probleme? Falls ja, so sei c-haters Frage nach den Fuses wiederholt, für beide Controller. Mehr fällt mir erstmal nicht ein.
Verstehe ich das richtig: Sie haben einen AVR64DD28 und einen
AVR64DD20,
und nur bei Letzterem gibt es Probleme? Falls ja, so sei c-haters Frage
nach den Fuses wiederholt, für beide Controller. Mehr fällt mir erstmal
nicht ein.
Hier ein Video, wie es aussieht und hoffentlich zeigt, dass das kein
Getrolle ist.
Naja, wir haben schon deutlich schlimmere Sachen gesehen. Aber du musst an deiner Kommunikation arbeiten, siehe Netiquette. Dazu gehört hier im Speziellen
vollständigen, fehlerfrei compilierbaren Code als Anhang einfügen
eine klare, explizite Fehlerbeschreibung
Du hast nie gesagt, daß dauerhaft Zeichen empfangen werden! Das sieht erst auf deinem Video.
Wir stellen fest. Dein UART funktioniert. Ein konstanter String wird fehlerfrei ausgegeben. Das Array, auch wenn es mit 0x65 gefüllt und mit 0 terminiert ist, gibt erst viele 0x20 (Leerzeichen) und dann 0xFF aus. Sehr merkwürdig. Das sieht fast so aus, als ob der Pointer auf den Flash zeigen würde. Das sollte er aber nicht. Printf der libc vom AVR gcc kennt zwei Strings
%s (kleines s) Pointer auf RAM
%S (großes S) Pointer auf Flash
Aber in deinem Video ist es ein kleines s. Das sollte funktionieren.
Ich hoffe ich hab die Einstellung richtig kopiert, habe aber auch nichts
aktiv daran verändert.
Bleibt die Frage, ob und wie die Fuse-Einstellungen in die echten Fuses kommen? Es gibt das Wege. Aber funktionieren die bei dir WIRKLICH?
Sollte aber egal sein, der UART funktioniert.
Noch ein Tipp zum CCP-Register. Das sollte man NICHT naiv so in C hinschreiben! Denn je nach Compilereinstellung kann das auch mal nicht so optimal umgesetzt werden und dann funktioniert es nicht. Man sollte das IMMER mit einem Inline-ASM-Makro machen.
Du hast nie gesagt, daß dauerhaft Zeichen empfangen werden!
Doch, doch, hat er, im Verlauf der Diskussion:
dieser Output ist "random" und hört nie auf. Also stoppt auch
nicht kurz für eine Sekunde. Und wenn ich eine while(1);
dranhänge, wird diese nie erreicht.
Fuses: das sind die Default-Werte, folglich unauffällig.
Dann wäre jetzt die nächste Frage nach dem Assemblerlisting und den Optionen beim Build-Prozess, aber da kenne ich mich kaum aus, überlasse ich lieber Spezialisten.
Zum eigentlichen Problem. Im Video funktioniert es auch nicht mit einem 100er Array! Sehr merkwürdig! Also mit Größe 10 testen! Wenn auch das nicht geht, eine Schleife schreiben und die einzelnen Zeichen manuell per printf() ausgeben. Da ist nur zum testen! Nicht als Workaround.
Verstehe ich das richtig: Sie haben einen AVR64DD28 und einen
AVR64DD20,
und nur bei Letzterem gibt es Probleme?
Kann es sein, daß bei dem IC, wo es nicht geht, der falsche Controller in der IDE eingestellt ist und dadurch irgendwas mit den Speicherbereichen nicht stimmt? Vor allem mit dem RAM?
Ich habe von C fast keine Ahnung, also: in dem Filmchen läuft das printf bei 00:35 zum erstenmal in den Flash (übrigens bei 00:41 wieder, also ganz grob nach 6 s entsprechend 64 KiB bei 115200 kBd) und findet dort 0x0C 0x94 0x51 0x00 - warum stoppt es nicht an dieser Stelle, ich dachte immer, in C seien Strings mit 0x00 terminiert?
Vermutlich zeigt der SP in den Wald und daher geht das RET nicht zurück, sondern woanders hin.
Es sieht also nur so aus, als würde printf nicht beendet.
Für eine genauere Untersuchung wären die beiden HEX Dateien interessat: diejenige, die auf dem AVR64DD28 funktioniert und die, die auf dem AVR64DD20 nicht funktioniert.
Idealerweise auch die beiden ELF Dateien (unter der Annahme daß die Toolchain auch eine ELF Datei erzeugt), alternativ die MAP Dateien.
Ich habe von C fast keine Ahnung, also: in dem Filmchen läuft das printf
bei 00:35 zum erstenmal in den Flash
Das scheint so, sollte aber nicht sein. Der Pointer rxBuf zeigt auf RAM!
(übrigens bei 00:41 wieder, also
ganz grob nach 6 s entsprechend 64 KiB bei 115200 kBd) und findet dort
0x0C 0x94 0x51 0x00 - warum stoppt es nicht an dieser Stelle, ich dachte
immer, in C seien Strings mit 0x00 terminiert?
Das heißt, dass bereits im Vorfeld etwas schiefgeht, denn die Ausgabe
beginnt ja nicht mit den 'e's, sondern mit Blanks.
IN der Tat. Darum auch mehrfach mein Hinweis, mal mit einem sehr kleinen Array mit 10 Elementen zu testen. Und mit Einzelausgabe. Man sollte die Hinweise auch mal lesen und umsetzen, das dauert nur wenige Minuten.
Ich würde trotz allem immer noch gerne den Sourcecode vom hier verwendeten printf() sehen. Ich kann mir vorstellen, dass die Implementierung bei der Verwendung von %s eine Längenobergrenze der Zeichenkette voraussetzt.
