Arduino Uno R4: Besonderheiten und Abhilfen

[Kai (ksb)]

Hallo geehrte Experten,

für mein nächstes Hobby-Projekt bin ich auf das o. g. Board umgestiegen 
und habe zur Einarbeitung mein letztes Projekt angepasst.

Nachdem mir Nemopuk zielsicher die Lösung eines Problem der 
Datenübertragung genannt hat, stellten sich nach und nach weitere 
Besonderheiten des Uno R4 heraus, über welche zum Großteil auch andere 
Benutzer im Netz berichten:

1. Speicherbedarf:  Ein Programm welches auf dem Mega 52kB gross ist, 
benötigt auf dem R4 mehr als den doppelten Speicher.
                        Abhilfe: keine bekannt

2. Compilier-Dauer:  Das Compilieren dauert beim R4 mit ca. 30s deutlich 
länger als beim Mega mit ca. 11s. 
Abhilfe: keine bekannt

3. random():     Diese Funktion arbeitet beim R4 extrem langsam, da die 
Routine bei jedem Aufruf den True Random Number Generator (TRNG) neu 
initialisiert.

Abhilfe: Wert einmal pro Sekunde abfragen und in einem Ringpuffer 
speichern. Den Wert aus dem Ringpuffer abfragen.


4. tone:         Diese Funktion scheint beim R4 nicht zum Abspielen von 
Melodien geeignet zu sein - es treten diverse störende Effekte auf.
Abhilfe: Verwendung einer alternativen Bibliothek (z. B. TimerFreeTone)


5. EEPROM:    um exakt zu sein, gibt es beim R4 kein EEPROM, dieses wird 
im Flash simuliert - bei jedem Schreiben muss die gesamte Page gelöscht 
werden.
Abhilfe: Verwendung eines externen EEPROM

6. Datenübertragung:    Einbrechen der Übertragungsgeschwindigkeit bei 
längeren Übertragungen.
Abhilfe: keine bekannt

Sind euch Abhilfen zu den genannten Besonderheiten bekannt?

Viele Grüße
Kai

[Nemopuk (nemopuk)]

Kai schrieb:
> Speicherbedarf:  Ein Programm welches auf dem Mega 52kB gross ist,
> benötigt auf dem R4 mehr als den doppelten Speicher.
> Abhilfe: keine bekannt

Das ist allerdings kein Fehler, sondern der 32 Bit ARM Architektur 
geschuldet.

[Kai (ksb)]

Hallo Nemompuk

vielen Dank für deine Antwort, hatte ich bereits vermutet - deshalb habe 
ich auch Besonderheit geschrieben.
Wenn aber jemand mit einem grösseren Projekt vom Mega auf den Uno R4 
umziehen möchte, wird er Schiffbruch erleiden...

Weitere Besonderheiten:

6. LED-Matrix:       recht dunkel, wird diese mit matrix.play(true) 
gestartet kommt es zu zyklischer Laufzeiterhöhung (was zu erwarten war)
    Abhilfe: für Helligkeit keine bekannt, Matrix.next an geeigneter 
Stelle einsetzen.


7. Interrupts:          einige Funktionen werden vermutlich durch 
unerwartete Interrupts beeinflusst.
      Abhilfe: keine bekannt

Viele Grüße

Kai

[Nemopuk (nemopuk)]

Meiner Meinung nach hätte dieses neue Board nicht "Uno" heissen sollen.

[Arduino F. (Firma: Gast) (arduinof)]

Nemopuk schrieb:
> Meiner Meinung nach hätte dieses neue Board nicht "Uno" heissen
> sollen.

Offensichtlich scheint deine Meinung da nicht sonderlich relevant zu 
sein.


So wie auch Nano nur die Bauform beschreibt und nicht den montierten µC, 
ist es auch mittlerweile auch beim UNO.

[Jens M. (schuchkleisser)]

Kai schrieb:
> Ein Programm welches auf dem Mega 52kB gross ist,
> benötigt auf dem R4 mehr als den doppelten Speicher.

Ist egal, du bekommst kein Geld zurück für ungenutzten Speicher. Passt 
das Programm rein? Dann ist alles gut.

Kai schrieb:
> Das Compilieren dauert beim R4 mit ca. 30s deutlich
> länger als beim Mega mit ca. 11s.

Da ist eine wesentlich fettere Architektur dahinter, von 8 auf 32 bit 
und natürlich ist ARM auch unheimlich aufgeblasen, so stark, das es nur 
mit C zu ertragen ist. In Assembler ein kurzes einfaches Blinkprogramm 
zum testen geht nicht, weil das nicht oder nur sehr umständlich 
dokumentiert ist wie man den Chip anspricht.

Kai schrieb:
> Diese Funktion arbeitet beim R4 extrem langsam, da die
> Routine bei jedem Aufruf den True Random Number Generator (TRNG) neu
> initialisiert.

Dafür isses echter Zufall und kein PRNG. Eins willste, eins kriegste.

Kai schrieb:
> Diese Funktion scheint beim R4 nicht zum Abspielen von
> Melodien geeignet zu sein - es treten diverse störende Effekte auf.

Vollkommen andere Architektur der CPU, die solcherlei Hardwarenahen 
Krempel halt nicht erlaubt. Daher kann man C-Programme ja auch nie auf 
eine andere Hardware übertragen, obwohl das ja eins der Hauptargumente 
für C ist. Aber irgendwann nutzt man eben doch Hardwareeigenheiten, und 
dann kommt das dabei raus.

Kai schrieb:
> um exakt zu sein, gibt es beim R4 kein EEPROM, dieses wird
> im Flash simuliert - bei jedem Schreiben muss die gesamte Page gelöscht
> werden.

Auch hier: Hardwarenaher Kram, der emuliert werden muss, das geht halt 
oder eben nicht.

Kai schrieb:
> Einbrechen der Übertragungsgeschwindigkeit bei
> längeren Übertragungen.

Das liegt nicht an der Firmware, niemals nicht...

Kai schrieb:
> Wenn aber jemand mit einem grösseren Projekt vom Mega auf den Uno R4
> umziehen möchte, wird er Schiffbruch erleiden...

Wenn ein doppelt so großes Programm von 32kB auf 256kB nicht passt, 
stimmt was mit deinem Taschenrechner nicht.

Kai schrieb:
> recht dunkel

Falsche Hardware für sowas. Du meckerst auch, weil deine Ape nur noch 
kriechen kann wenn da 7,5 Tonnen dranhängen.

Kai schrieb:
> einige Funktionen werden vermutlich durch
> unerwartete Interrupts beeinflusst.

Nochmal: Falsche Hardware.

Du erwartest ernsthaft, das ein nicht mal im entferntesten ähnlicher 
Controller hardwarenah identisch funktioniert?
Wie läuft den C64 mit Windows 11? Wo hast du das Userport-TPM und den 
USB3.2-1541-Adapter gekauft, und wie kann man im C64-Bios Secureboot 
aktivieren?

[Arduino F. (Firma: Gast) (arduinof)]

Jens M. schrieb:
> von 32kB auf 256kB nicht passt,

Der Arduino Mega hat 256k Flash.

[Jens M. (schuchkleisser)]

Oh stimmt ich hatte nach dem Uno R3 gekuckt.
Das ist ja auch der "Vorvater" des Uno R4, nicht der Mega.
Vielleicht muss man vom Mega (mit ATmega2560) auf einen ESP gehen, der 
hat 4MByte Flash. Und WLAN. Aber halt wenig RAM. Irgendwas ist ja immer.

[Falk B. (falk)]

Arduino F. schrieb:
> Der Arduino Mega hat 256k Flash.

Die nicht mal 1% der Anwender jemals ausgenutzt haben!

[Johann L. (gjlayde)]

Kai schrieb:
> Das Compilieren dauert beim R4 mit ca. 30s deutlich
> länger als beim Mega mit ca. 11s.

Damit nicht Äpfel mit Birnen verglichen werden: Für die gleiche GCC 
Version und die gleichen Optimierungseinstellungen?

C++ Programme mit DWARF-3 Debug-Info sind teilweise riesig, und das kann 
Linken spürbar langsamer machen.  Ändert sich was wenn mit -g0 übersetzt 
wird?

[Falk B. (falk)]

Kai schrieb:

> Nachdem mir Nemopuk zielsicher die Lösung eines Problem der
> Datenübertragung genannt hat,

Wenn die Person hinter Nepomuk die ist, welche ich vermute, denn würde 
ich das Wort "zielsicher" nicht verwenden wollen ;-)

> 1. Speicherbedarf:  Ein Programm welches auf dem Mega 52kB gross ist,
> benötigt auf dem R4 mehr als den doppelten Speicher.
>                         Abhilfe: keine bekannt

Ignorieren. Denn der R4 hat genügend Flash-Speicher (256k). Wie es 
scheint, beherrscht die CPU auch keinen Thumb Mode, welcher weniger 
Speicher braucht.

> 2. Compilier-Dauer:  Das Compilieren dauert beim R4 mit ca. 30s deutlich
> länger als beim Mega mit ca. 11s.
> Abhilfe: keine bekannt

Ist halt so. Damit kann und muss man leben.

> 3. random():     Diese Funktion arbeitet beim R4 extrem langsam, da die
> Routine bei jedem Aufruf den True Random Number Generator (TRNG) neu
> initialisiert.

Glaub ich nicht. Wie hast du das gemessen? Was ist "extrem langsam"?

> 5. EEPROM:    um exakt zu sein, gibt es beim R4 kein EEPROM, dieses wird
> im Flash simuliert - bei jedem Schreiben muss die gesamte Page gelöscht
> werden.
> Abhilfe: Verwendung eines externen EEPROM

Oder Schreibzugriffe minimieren.

https://www.mikrocontroller.net/articles/Speicher#EEPROM-Schreibzugriffe_minimieren

> 6. Datenübertragung:    Einbrechen der Übertragungsgeschwindigkeit bei
> längeren Übertragungen.
> Abhilfe: keine bekannt

Unsinn! Ohne genauere Beschreibung der Übertragung und des Quellcodes 
kann man da rein GAR NICHTS sagen!

[Harald K. (kirnbichler)]

Jens M. schrieb:
> auf einen ESP gehen, der
> hat 4MByte Flash. Und WLAN. Aber halt wenig RAM.

"Der" ESP kann auch mehr Flash-ROM haben, aber wie kommst Du auf "wenig" 
RAM? Welchen "ESP" meinst Du überhaupt? Es gibt viele Varianten, die 
alle unterschiedlich ausgestattet sind. Und obendrein kann da PSRAM 
angeschlossen werden, und ist es auf den besseren Modulen auch 
standardmäßig.

[Kai (ksb)]

Johann L. schrieb:
> Kai schrieb:
>> Das Compilieren dauert beim R4 mit ca. 30s deutlich
>> länger als beim Mega mit ca. 11s.
>
> Damit nicht Äpfel mit Birnen verglichen werden: Für die gleiche GCC
> Version und die gleichen Optimierungseinstellungen?
>
> C++ Programme mit DWARF-3 Debug-Info sind teilweise riesig, und das kann
> Linken spürbar langsamer machen.  Ändert sich was wenn mit -g0 übersetzt
> wird?

Hallo Johann,

klingt logisch aber wo kann ich diese Option in der Arduino-Ide 
einstellen?

Vielen Dank und viele Grüße
Kai

[Kai (ksb)]

Falk B. schrieb:
>> 3. random():     Diese Funktion arbeitet beim R4 extrem langsam, da die
>> Routine bei jedem Aufruf den True Random Number Generator (TRNG) neu
>> initialisiert.
>
> Glaub ich nicht. Wie hast du das gemessen? Was ist "extrem langsam"?

Hallo Falk,

ich habe die Zeit nicht exakt bestimmt - wahrscheinlich um 100ms pro 
Aufruf, jedoch ist dieses Problem bekannt:
https://forum.arduino.cc/t/random-function-on-r4-terribly-slow/1342877
Wird random() einer Routine intensiv verwendet, scheint der Controller 
stehen zu bleiben.

Viele Grüße
Kai

[Arduino F. (Firma: Gast) (arduinof)]

Kai schrieb:
> klingt logisch aber wo kann ich diese Option in der Arduino-Ide
> einstellen?
Du legst neben der vorhandenen, genutzten,  platform.txt eine 
platform.local.txt.
In dieser bringst du deine Änderungen unter.

[Kai (ksb)]

Hallo Arduino F,

vielen Dank für deine Antwort - versuche ich morgen.

Viele Grüße
Kai

[Falk B. (falk)]

Kai schrieb:
> ich habe die Zeit nicht exakt bestimmt - wahrscheinlich um 100ms pro
> Aufruf, jedoch ist dieses Problem bekannt:
> https://forum.arduino.cc/t/random-function-on-r4-terribly-slow/1342877
> Wird random() einer Routine intensiv verwendet, scheint der Controller
> stehen zu bleiben.

Hier gibt es die Lösung. Lesen bildet.

https://forum.arduino.cc/t/random-function-on-r4-terribly-slow/1342877/12?_gl=1*1mw7hsl*_up*MQ..*_ga*OTYxMTM3NzcxLjE3NTg3Mzg2MzM.*_ga_NEXN8H46L5*czE3NTg3Mzg2MjckbzEkZzEkdDE3NTg3Mzg5NjMkajYwJGwwJGg3MTk0MjU5MjM.

[Kai (ksb)]

Falk B. schrieb:
> Hier gibt es die Lösung. Lesen bildet.
>
> 
https://forum.arduino.cc/t/random-function-on-r4-terribly-slow/1342877/12?_gl=1*1mw7hsl*_up*MQ..*_ga*OTYxMTM3NzcxLjE3NTg3Mzg2MzM.*_ga_NEXN8H46L5*czE3NTg3Mzg2MjckbzEkZzEkdDE3NTg3Mzg5NjMkajYwJGwwJGg3MTk0MjU5MjM.

Hallo Falk,

Vielen Dank - super - funktioniert!

Jens M. schrieb:
> Vollkommen andere Architektur der CPU, die solcherlei Hardwarenahen
> Krempel halt nicht erlaubt. Daher kann man C-Programme ja auch nie auf
> eine andere Hardware übertragen, obwohl das ja eins der Hauptargumente
> für C ist. Aber irgendwann nutzt man eben doch Hardwareeigenheiten, und
> dann kommt das dabei raus.

Hallo Jens,

es geht um die Funktion tone(), welche kein hardwarenaher Krempel ist.

Jens M. schrieb:
> Du erwartest ernsthaft, das ein nicht mal im entferntesten ähnlicher
> Controller hardwarenah identisch funktioniert?
> Wie läuft den C64 mit Windows 11? Wo hast du das Userport-TPM und den
> USB3.2-1541-Adapter gekauft, und wie kann man im C64-Bios Secureboot
> aktivieren?

Nein das erwarte ich gar nicht sondern frage hier, ob ihr Abhilfen zu 
den aufgetretenen Besonderheiten kennt.

Jens M. schrieb:
> Das liegt nicht an der Firmware, niemals nicht...

Falk B. schrieb:
>> 6. Datenübertragung:    Einbrechen der Übertragungsgeschwindigkeit bei
>> längeren Übertragungen.
>> Abhilfe: keine bekannt

> Unsinn! Ohne genauere Beschreibung der Übertragung und des Quellcodes
> kann man da rein GAR NICHTS sagen!

Hallo Jens und Falk,

die Ursache dieses Problemes muss ich noch genauer analysieren - zurzeit 
ist es so, dass die Übertragung längerer Dateien an Mega und Uno R3 
störungsfrei funktioniert und bei R4 nicht.

Jetzt suche ich erstmal den richtigen Ordner für:

Arduino F. schrieb:
>> klingt logisch aber wo kann ich diese Option in der Arduino-Ide
>> einstellen?
> Du legst neben der vorhandenen, genutzten,  platform.txt eine
> platform.local.txt.
> In dieser bringst du deine Änderungen unter.

Vielen Dank für alle Antworten bisher!

Viele Grüße
Kai

[Arduino F. (Firma: Gast) (arduinof)]

Kai schrieb:
> Jetzt suche ich erstmal den richtigen Ordner für:

Zeigt Arduino dir wenn du die ausführlichen Ausgaben aktivierst.

[Cyblord -. (cyblord)]

Nemopuk schrieb:
> Meiner Meinung nach hätte dieses neue Board nicht "Uno" heissen sollen.

Geht es dir auch so dass sich quasi niemand für deine Meinung 
interessiert? Das ist bei mir sehr oft der Fall. Eigentlich durchgehend.

[Arduino F. (Firma: Gast) (arduinof)]

Cyblord -. schrieb:
> ...

Du hast mein volles Mitgefühl!
(hihi)

Schaut euch einfach mal den VW Golf Revision 1 und Revision 7 an.
Was haben die gemeinsam?
Nicht viel!
OK, die Räder sind weiterhin unten, und das Dach meist oben, aber sonst?

Kein relevantes Teil passt.
Nichts, außer vielleicht die ein oder andere M6er Schraube.

[Kai (ksb)]

Arduino F. schrieb:
> Kai schrieb:
>> Jetzt suche ich erstmal den richtigen Ordner für:
>
> Zeigt Arduino dir wenn du die ausführlichen Ausgaben aktivierst.

Hallo Arduino F,

vielen Dank - das war dank deiner Hilfe sehr einfach - aber welche ist 
die richtige Stelle?

Viele Grüße
Kai

[Arduino F. (Firma: Gast) (arduinof)]

Kai schrieb:
> aber welche ist
> die richtige Stelle?

Wofür?
Wolltest du nicht -g3 in -g0 ändern?

Dann nimmst du alle Zeilen, aus der platform.txt welche -g3 beinhalten 
und kopierst diese in die platform.local.txt.
Dann darin alle -g3 in -g0 ändern

Denn:
Die platform.txt wird nur einmal geladen. Die platform.local.txt bei 
jedem Compilerlauf.
Einträge in der platform.local.txt überdecken Einträge aus der 
platform.txt

[Kai (ksb)]

Hallo Arduino F,

ich habe an 2 Stellen -G3 gefunden und diese auf -G0 geändert:

compiler.c.flags=-c {compiler.warning_flags} 
{compiler.optimization_flags} -g0 -nostdlib {build.defines} -MMD 
-std=gnu11 -mcpu={build.mcu} {build.float-abi} {build.fpu} 
-fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections 
-fmessage-

compiler.cpp.flags=-c {compiler.warning_flags} 
{compiler.optimization_flags} -g0 -fno-use-cxa-atexit -fno-rtti 
-fno-exceptions -MMD -nostdlib {build.defines} -MMD -std=gnu++17 
-mcpu={build.mcu} {build.float-abi} {build.fpu} -fsigned-char 
-ffunction-sections -fdata-sections -fmessage-length=0 -fno-builtin

Als Ergebnis kein großer Unterschied - immer noch ca. 30 s mit Upload.

Gibt es eine Möglichkeit, das Erzeugen der Dateien für den Debugger 
abzuschalten?

Viele Grüße

Kai

[Arduino F. (Firma: Gast) (arduinof)]

Kai schrieb:
> ich habe an 2 Stellen -G3 gefunden und diese auf -G0 geändert:

Nicht -G0 sondern -g0.
Das mag für dich keinen Unterschied machen.....

Nach 1 Minute suchen:
Lesestoff: https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html

[Jens M. (schuchkleisser)]

Kai schrieb:
> es geht um die Funktion tone(), welche kein hardwarenaher Krempel ist.

Falsch gedacht.
Tone frickelt an einem Timer rum, um eine Frequenz zu erzeugen. Dazu 
sind Timer nicht da, d.h. das ist eine sehr hardwarenahe Funktion.
Wenn die Timer des anderen Prozessors anders funktionieren, gibt's halt 
Stress.

Kai schrieb:
> Nein das erwarte ich gar nicht sondern frage hier, ob ihr Abhilfen zu
> den aufgetretenen Besonderheiten kennt.

Es gibt zwei Abhilfen: Einen Chip nehmen, der die gewünschten Funktionen 
nativ unterstützt, oder auf die nicht möglichen Funktionen verzichten.
Eine Emulation kann niemals zu 100% identisch funktionieren.

[Kai (ksb)]

Entschuldigung: ich habe natürlich von -g3 auf -g0 geändert

[Kai (ksb)]

Arduino F. schrieb:
> Nach 1 Minute suchen:
> Lesestoff: https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html

super - vielen Dank - wird etwas dauern, bis ich das alles verstanden 
habe....

[Kai (ksb)]

Jens M. schrieb:
> Kai schrieb:
>> es geht um die Funktion tone(), welche kein hardwarenaher Krempel ist.
>
> Falsch gedacht.
> Tone frickelt an einem Timer rum, um eine Frequenz zu erzeugen. Dazu
> sind Timer nicht da, d.h. das ist eine sehr hardwarenahe Funktion.
> Wenn die Timer des anderen Prozessors anders funktionieren, gibt's halt
> Stress.

Hallo Jens,

danke für deine Antwort - wahrscheinlich habe ich es falsch formuliert:

die Funktion tone() ist klar definiert und sollte daher auf allen 
Plattformen das selbe Ergebnis produzieren:

    tone(pin, frequency)

    tone(pin, frequency, duration)

Viele Grüße
Kai

[Arduino F. (Firma: Gast) (arduinof)]

Kai schrieb:
> Als Ergebnis kein großer Unterschied - immer noch ca. 30 s mit Upload.

Ähmm, mit -g0 dreht es sich nicht so sehr um die Compilezeit, sondern 
eher um die Codegröße.

[Arduino F. (Firma: Gast) (arduinof)]

Kai schrieb:
> die Funktion tone() ist klar definiert und sollte daher auf allen
> Plattformen das selbe Ergebnis produzieren
Reparieren und die Verbesserung der Gemeinschaft melden.

[Jens M. (schuchkleisser)]

Kai schrieb:
> die Funktion tone() ist klar definiert und sollte daher auf allen
> Plattformen das selbe Ergebnis produzieren:

Das kann sie nicht.
Sie funktioniert, weil Arduino nunmal dazu da ist simpel und kurz zu 
einem Ergebnis zu kommen.
Was völlig unüblich ist.
Also ist es gerade so ein "geht so", identisch kann es gar nicht sein.
Wenn du da tatsächlich von ausgehst bist du seeehr blauäugig.

[Arduino F. (Firma: Gast) (arduinof)]

Jens M. schrieb:
> identisch

Die Implementierungen von tone() sowohl AVR, als auch R4 liegen auf 
Github offen aus.
Da ist nichts identisch!
Bis auf die Funktionsdeklarationen.
Sonst: Komplett unterschiedlich.

Was auch kein Wunder ist.

[Nemopuk (nemopuk)]

Ersetze Mundharmonika durch Clarinette und spiele den gleichen Ton. Es 
sind sogar beides Blasinstrumente.

[Kai (ksb)]

Hallo,

nach einigen Experimenten bezüglich tone() kann ich folgendes berichten:

1. Die Originalversion aller Melodien 
(https://github.com/robsoncouto/arduino-songs) funktioniert sowohl auf 
dem Uno R4 als auch R3 störungsfrei.
   Der Sketch-Datei beinhaltet sowohl die Defines der Tonhöhen (pitches) 
als auch die Noten in Form eines Integer-Arrays für jeweils ein Lied.

2. Zusammen mit anderen Programmteilen wird bei der Verwendung von 
tone() anstelle bestimmter Noten (= Frequenzen) ein merkwürdiger Ton 
ausgegeben - könnte man als Tschilpen beschreiben.
   (Der Sketch beinhaltet nur die Abspielroutine. Tonhöhen und Noten 
sind in Header ausgelagert. Die Noten befinden sich im PROGMEM int 
melody[].

3. Wird tone() durch TimerFreeTone() ersetzt, so werden fast alle 
Melodien korrekt abgespielt. Bei 2 von 25 Melodien gibt es Probleme, 
diese sind durcheinander und zwar sowohl beim Lesen aus dem PROGMEM als 
auch aus dem EEPROM.

4. Werden die Melodien vom Uno R4 EEPROM als Datei ausgelesen und in das 
EEPROM des Uno R3 eingelesen, so ist die Wiedergabe aller Melodien 
korrekt. In beiden Controllern befinden sich identische Programmteile.

Ich habe das Programm, als auch die Noten schon mehrfach verglichen bzw. 
kontrolliert, komme aber nicht auf die Fehlerursache. Daher werde ich 
jetzt eine Pause einlegen....

Viele Grüße
Kai

[Arduino F. (Firma: Gast) (arduinof)]

Kai schrieb:
> PROGMEM

Das ganze PROGMEM Gedönse kannste auf ARM vergessen

[Kai (ksb)]

Hallo Arduino F,

vielen Dank für deine Antwort - was bedeutet es exakt, dass ich PROGMEM 
auf dem ARM vergessen kann?

Die meisten Verwendungen des PROGMEM funktionieren ohne erkennbare 
Fehler, die Fehler treten in Zusammenhang mit den Melodien auf.

Eventuell habe ich in der Adressberechnung auch einen Fehler? Aber 
weshalb dann nur für Uno R4 bzw. ARM?

Anbei ein minimierter Sketch, welcher auf dem Uno R3 fehlerfrei 
funktioniert und auf dem R4 die Melodien mehr oder weniger stark 
verfremdet.
Am stärksten durcheinander sind Melodie 8. Heilige Nacht und 9. Happy 
Birthday.

Vielen Dank für jede Hilfe im Voraus.

Ein schönes Wochenende und viele Grüße

Kai

[Kai (ksb)]

Nachtrag: das weiter oben beschriebene Störgeräusch (Zwitschern bzw. 
Tschilpen) tritt in diesem Minimal-Sketch nicht auf - hier muss ich noch 
finden, welche Funktion oder  Bibliothek ursächlich ist.

[Arduino F. (Firma: Gast) (arduinof)]

Kai schrieb:
> Aber weshalb dann nur für Uno R4 bzw. ARM?
Die alten AVR haben getrennte Adressbusse für RAM+Register und Flash. 
Bei diesen ist das Progmem Gedönse notwendig.

Bei dem ARM ist das Flash und Ram im gleichen Adressraum. Also nix 
Progmem nötig.

Kai schrieb:
> Die meisten Verwendungen des PROGMEM funktionieren ohne erkennbare
> Fehler,

Das sind alles mehr oder weniger leere Stummel.

Beispiel, die Definition von PROGMEM auf dem R4 ist:
#define PROGMEM
Also leer. Nur aus Kompatibilitätsgründen da.

[Nemopuk (nemopuk)]

Kai schrieb:
> was bedeutet es exakt, dass ich PROGMEM auf dem ARM vergessen kann?

Bei 8 Bit AVR wird der Programmspeicher mit anderen Befehlen 
angesprochen, als RAM. Adresse 1234 ist nicht eideutig. Damit kann RAM 
oder Flash gemeint sein.

Bei 32 Bit ARM Controllern ist das anders. Dort werden beide Speicher 
durch die selben Befehle angesprochen. Die Unterscheidung wird durch 
eindeutige Adress-Bereiche gemacht. Deswegen hat PROGMEM dort keinen 
Sinn. Beim STM32 Core ist Progmem einfach als gar nichts definiert, 
PGM_P ist ein normaler const char* und PSTR(von x) ist auch ein dummy, 
nämlich x.

[Johann L. (gjlayde)]

Kai schrieb:
> was bedeutet es exakt, dass ich PROGMEM
> auf dem ARM vergessen kann?

Vor allem bedeutet es, dass du das ganze pgm_read_xxx Geraffel nicht 
brauchst.  Anstatt

tempo = pgm_read_word_near(tempis+(snd-1));

kannst also einfach:

tempo = tempis[snd - 1];

Und warum nimmst du eigentlich globale Variablen, zum Beispiel für 
tempo???

Der Code sollte eigentlich eher so aussehen:

void setup()                                        // put your setup 
code here, to run once:
{
   Serial.begin(19200);                                // opens serial

   ...

   for (byte snd = 1; snd < 28; ++snd)                 // Play melody 1 - 27
   {
       int tempo = tempis[snd - 1];                    // Melody tempo
       Serial.print("Title: ");
       Serial.print(snd);
       Serial.print(" ");                              // Blank
       for (uint8_t byte x = 0; x < 14; ++x)
       { 
          ...

Und was sind eigentlich diese magischen Zahlen 14 und 28? Arraylängen?
Und warum wird das alles in setup() gemacht?

[Norbert (der_norbert)]

Kai schrieb:
> was bedeutet es exakt, dass ich PROGMEM
> auf dem ARM vergessen kann?

* Harvard Architektur
gegenüber
* Von-Neumann Architektur

[Kai (ksb)]

Hallo Arduino F, Nemopuk, Johann und Norbert,

vielen Dank für eure Antworten.

Arduino F. schrieb:
> Die alten AVR haben getrennte Adressbusse für RAM+Register und Flash.
> Bei diesen ist das Progmem Gedönse notwendig.

Arduino F. schrieb:
> Bei dem ARM ist das Flash und Ram im gleichen Adressraum. Also nix
> Progmem nötig.

OK - verstanden - vielen Dank

Nemopuk schrieb:
> Bei 8 Bit AVR wird der Programmspeicher mit anderen Befehlen
> angesprochen, als RAM. Adresse 1234 ist nicht eideutig. Damit kann RAM
> oder Flash gemeint sein.
>
> Bei 32 Bit ARM Controllern ist das anders. Dort werden beide Speicher
> durch die selben Befehle angesprochen.

ebenfalls verstanden

Johann L. schrieb:
> Vor allem bedeutet es, dass du das ganze pgm_read_xxx Geraffel nicht
> brauchst.  Anstatttempo = pgm_read_word_near(tempis+(snd-1));
> kannst also einfach:tempo = tempis[snd - 1];

Super - das verkürzt diese Zeilen deutlich

Johann L. schrieb:
> Und warum nimmst du eigentlich globale Variablen, zum Beispiel für
> tempo???

Weil tempo und snd in meinem Sketch auf dem LCD angezeigt werden.

Johann L. schrieb:
> Und warum wird das alles in setup() gemacht?

Weil es im Original (https://github.com/robsoncouto/arduino-songs) 
genauso ist und ich sicher gehen wollte, das dies nicht die Ursache ist.

Johann L. schrieb:
> Und was sind eigentlich diese magischen Zahlen 14 und 28? Arraylängen?

14 ist die Länge der Titel und 28 die Anzahl der vorhandenen Melodien.

Mal sehen, ob sich das Verhalten nach Änderung verbessert.....

Viele Grüße
Kai

[Kai (ksb)]

Hallo,

nach Anpassung des oben angehangenen Minimal-Sketches werden alle 
Melodien auch auf dem Uno R4 richtig wiedergegeben. Somit war hier die 
Verwendung von PROGMEM die Ursache.

Was ich aber noch nicht verstehe ist, dass auch die Wiedergabe aus dem 
externen EEPROM in meinem Gesamt-Sketch an identischen Stellen wie bei 
Verwendung von PROGMEM fehlerhaft ist. Klar ist, dass wenn ich das 
EEPROM mit dem Uno R4 beschreibe die Daten deshalb durcheinander sind, 
weil die Routine die Melodien mittels PROGMEM ausliest und ins EEPROM 
schreibt.

Der Fehler tritt aber ebenfalls auf, wenn ich ein mit dem Arduino Mega 
beschriebenes EEPROM einsetze, welches auf Uno R3 und Mega fehlerfreie 
Melodien ausgibt.

Viele Grüße
Kai

[Joachim B. (jar)]

Arduino F. schrieb:
> Jens M. schrieb:
>> von 32kB auf 256kB nicht passt,
>
> Der Arduino Mega hat 256k Flash.

und der ATmega1284p hat 128k Flash
Gibt es nicht mehr die Compilerinfo wo man unterschiedliche 
Compileroptionen setzen kann?

sollte sich auch anpassen lassen auf Arm Architektur.

#if defined(__AVR__)
  const uint8_t PROGMEM pwmtable_11C[] = {255,  253,  251,  248,  244,  236,  223,  201,  165,  103,  0};
#elif defined(ESP32)
  const uint8_t PROGMEM pwmtable_11C[] = {0,    2,    4,    7,    11,   19,   32,   54,   90,   152,  255};
  const int freq = 5000;
  const int resolution = 8;
#endif

oder

#if defined(__AVR_ATmega1284P__)
  Serial.println(F(", auf migthy ATmega1284p"));
#elif defined(__AVR_ATmega328P__)
  Serial.println(F(", auf ATmega328p"));
#elif defined(ESP32)
  Serial.println(F(", auf ESP32 WEMOS LOLIN32"));
#endif

[Niklas G. (erlkoenig)]

Kai schrieb:
> 1. Speicherbedarf:  Ein Programm welches auf dem Mega 52kB gross ist,
> benötigt auf dem R4 mehr als den doppelten Speicher.

Wahrscheinlich sind die Arduino-Libraries für den Peripheriezugriff beim 
ARM einfach komplexer, eben weil die Peripherie komplexer ist. Dafür 
kann sie auch mehr. Der eigene Code der Anwendung könnte sogar durchaus 
kleiner sein, hängt vom Einzelfall ab.

Kai schrieb:
> ich habe an 2 Stellen -G3 gefunden und diese auf -G0 geändert:

Das bringt gar nichts. Die Debug-Informationen landen nur in der 
ELF-Datei, welche sich ausschließlich auf dem PC befindet. Der 
eigentliche Maschinencode der auf dem Controller landet ist durch die -g 
Option vollkommen unverändert. Wenn also die Festplatte im PC fast voll 
ist und du auf dem PC jedes einzelne KB sparen musst, kannst du auf -g0 
gehen, sonst würde ich Mikrocontroler-Projekte grundsätzlich immer mit 
-g3 kompilieren, denn für den Controller macht es keinen Unterschied 
(auch nicht bei der Übertragungszeit). Dies vereinfacht die Fehlersuche 
dramatisch - wobei die Arduino-Hardware alleine ja sowieso nicht 
in-circuit debuggen kann, aber für Crash-Dumps oder Disassembly o.ä. 
kann es trotzdem nützlich sein.

Um den Programmspeicher zu reduzieren musst du i.W. die 
Arduino-Libraries modifizieren und "entschlacken". Das ist viel Arbeit. 
Arduino kompiliert anscheinend standardmäßig schon mit "-Os", man kann 
noch mit LTO und ein paar anderen Optionen experimentieren. Das ist aber 
was für Leute die sich damit auskennen.

Kai schrieb:
> 2. Compilier-Dauer:  Das Compilieren dauert beim R4 mit ca. 30s deutlich
> länger als beim Mega mit ca. 11s.
> Abhilfe: keine bekannt

Die Arduino-IDE ist da nicht besonders clever, und kompiliert immer 
alles/vieles neu. Wenn du auf eine andere IDE (z.B. VS Code) umsteigst 
und ninja als Build-Tool nutzt, geht es viel schneller. Aber auch hier 
gilt dass die komplexere Library eben etwas Zeit braucht, auch beim 
Linken.

Kai schrieb:
> 6. Datenübertragung:    Einbrechen der Übertragungsgeschwindigkeit bei
> längeren Übertragungen.
> Abhilfe: keine bekannt

Was für eine Übertragungskanal? Benutze DMA, dann geht's noch viel 
schneller als beim AVR.

Jens M. schrieb:
> so stark, das es nur
> mit C zu ertragen ist. In Assembler ein kurzes einfaches Blinkprogramm
> zum testen geht nicht, weil das nicht oder nur sehr umständlich
> dokumentiert ist wie man den Chip anspricht.

Die Dokumentation von ARM ist exzellent, wenn Renesas die Peripherie 
nicht gut dokumentiert liegt das nicht an ARM. Und selbstverständlich 
kann man problemlos in Assembler für ARM Cortex-M ein einfaches 
Blinkprogramm hinschreiben, das macht nur normalerweise keiner. 
Tatsächlich programmiert es sich im ARM-Assembler ziemlich angenehm, 
dank Offset-Adressierung (gerade auch auf dem Stack), der vielen als 
Pointer nutzbaren Register, vielfältigen Arithmetik-Instructions inkl. 
Multiplikation, Barrel-Shifting und FPU, effizienten 
Load/Store-Multi-Instructions, integrierten Shifts bei diversen 
Instructions (bei Speicherzugriffen und auch Arithmetik), automatischer 
Kontext-Sicherung bei Interrupts, und natürlich linearem Adressraums. 
Etwas nervig ist dass auf Peripherieregister immer als Read-Modify-Write 
zugegriffen werden muss, aber das ist erträglich (kann man z.B. auch in 
ein Makro stecken).

Jens M. schrieb:
> Daher kann man C-Programme ja auch nie auf
> eine andere Hardware übertragen

Komisch dass eine Unmenge an C-Software super auf 
ARM-Smartphones/Laptops/Servern, x86- und x86_64 -PCs, MIPS-Routern 
läuft, sogar ohne Massen an "#ifdef __arm__" etc.

[Arduino F. (Firma: Gast) (arduinof)]

Niklas G. schrieb:
> wobei die Arduino-Hardware alleine ja sowieso nicht
> in-circuit debuggen kann,

Das ist nicht mehr richtig!
Die Arduino IDE 2.X kann das, zumindest für einige µC
z.B. STM32

[Niklas G. (erlkoenig)]

Arduino F. schrieb:
> Das ist nicht mehr richtig!
> Die Arduino IDE 2.X kann das, zumindest für einige µC
> z.B. STM32

m.W. hat aber keines der Original-Arduino-Boards einen Debugger 
integriert, und ich schrieb ja auch "Arduino-Hardware _alleine_".

[Kai (ksb)]

Hallo Joachim und Niklas,

Vielen Dank auch für eure Antworten.

Joachim B. schrieb:
> Gibt es nicht mehr die Compilerinfo wo man unterschiedliche
> Compileroptionen setzen kann?

Damit bin ich überfragt....

Niklas G. schrieb:
> Die Arduino-IDE ist da nicht besonders clever, und kompiliert immer
> alles/vieles neu. Wenn du auf eine andere IDE (z.B. VS Code) umsteigst
> und ninja als Build-Tool nutzt, geht es viel schneller. Aber auch hier
> gilt dass die komplexere Library eben etwas Zeit braucht, auch beim
> Linken.

Mir ging es nicht um das Sparen von Arbeitsspeicher, sonden um das 
Verkürzen der Compilierdauer.

Viele Grüße
Kai

[Kai (ksb)]

Niklas G. schrieb:
> Kai schrieb:
>> 6. Datenübertragung:    Einbrechen der Übertragungsgeschwindigkeit bei
>> längeren Übertragungen.
>> Abhilfe: keine bekannt
>
> Was für eine Übertragungskanal? Benutze DMA, dann geht's noch viel
> schneller als beim AVR.

Hallo Niklas,

es geht um die serielle Schnittstelle.

Viele Grüße
Kai

[Nemopuk (nemopuk)]

Niklas G. schrieb:
> m.W. hat aber keines der Original-Arduino-Boards einen Debugger
> integriert

Dieses hat einen:
https://store.arduino.cc/products/arduino-zero

[Niklas G. (erlkoenig)]

Kai schrieb:
> Mir ging es nicht um das Sparen von Arbeitsspeicher, sonden um das
> Verkürzen der Compilierdauer.

Das hatte ich verstanden. Du kannst wie gesagt die Compilierdauer 
drastisch reduzieren indem du nicht mit der Arduino-IDE kompilierst, 
sondern über ein Tool das immer nur genau das neu baut, das auch 
wirklich geändert wurde. Wie eben über Ninja.

Beispielsweise hat ST für die STM32 jetzt Plugins für VS Code welche 
Ninja nutzen, und damit geht's dann sehr flott. z.B. 1-2 Sekunden wenn 
nur eine nicht allzu komplexe Datei geändert wurde. Das ist die gleiche 
Architektur und gleicher Compiler wie für den RA4M1.

i.A. geht kompilieren übrigens unter Linux schneller als unter Windows.

Kai schrieb:
> es geht um die serielle Schnittstelle.

Angeblich kann der RA4M1 bis zu 6.6 MHz auf der seriellen Schnittstelle, 
die lässt sich mit dem ARM-Prozessorkern auf jeden Fall kontinuierlich 
bedienen, gerade auch wenn man DMA nutzt. Die Verbindung zum PC wird 
über USB hergestellt, mit einer theoretischen maximalen Datenrate von 12 
Mbps, auch die sollte erzielbar sein. Also wieder eine Frage der 
Software. Kann natürlich sein dass das Arduino-Framework das nicht 
schafft, da muss man dann ggf. von Hand ran.

Nemopuk schrieb:
> Dieses hat einen:

Cool, na dafür sollte man dann definitiv immer mit -g3 kompilieren.

[Kai (ksb)]

Hallo Niklas,

die Übertragung kürzerer Dateien (aktuell 605 Zeichen) funktioniert auch 
beim Arduino R4 ohne Probleme.

Meine erste Analyse zeigt, dass bei grösseren Dateien die Übertragung 
zwischendurch stockt (ich lasse mir das Erreichen einer bestimmten 
Anzahl von Daten über die serielle Schnittstelle ausgeben). Der serielle 
Puffer verschluckt dann scheinbar Zeichen. Am Ende der Übertragung 
wurden deutlich weniger Zeichen übertragen, als in der Datei vorhanden 
sind.

Viele Grüße
Kai

[Niklas G. (erlkoenig)]

Kai schrieb:
> Der serielle
> Puffer verschluckt dann scheinbar Zeichen. Am Ende der Übertragung
> wurden deutlich weniger Zeichen übertragen, als in der Datei vorhanden
> sind.

Was ist das Zielgerät? Hast du mal per Oszilloskop oder Logic-Analyzer 
geprüft was gesendet wird? Sendest du immer nur einzelne Bytes? Mal per 
USB-Serial-Adapter den Datenstrom mitgeschnitten? Wie ist die Baudrate? 
Klingt doch stark nach Software-Problem.

[Jens M. (schuchkleisser)]

Da das Flashen der Firmware (die ja deutlich über 605 Bytes hat) 
ebenfalls über exakt die selbe Schnittstelle geht und problemlos klappt 
(sonst würde das Programm nicht laufen) ist das 100% ein Problem des 
Codes.

[Niklas G. (erlkoenig)]

Jens M. schrieb:
> Da das Flashen der Firmware (die ja deutlich über 605 Bytes hat)
> ebenfalls über exakt die selbe Schnittstelle geht

Das Flashen geht über natives USB, keine serielle Schnittstelle. Das 
Board hat keinen USB-Serial-Adapter. Kai nutzt vermutlich die 
"sekundäre" serielle Schnittstelle zur Kommunikation mit einem anderen 
Gerät.

[Kai (ksb)]

Niklas G. schrieb:
> Das Flashen geht über natives USB, keine serielle Schnittstelle. Das
> Board hat keinen USB-Serial-Adapter. Kai nutzt vermutlich die
> "sekundäre" serielle Schnittstelle zur Kommunikation mit einem anderen
> Gerät.

Hallo Niklas,

richtig - die Datenübertragung zwischen PC und Arduino erfolgt über die 
"sekundäre" serielle Schnittstelle (19200 Baud).

Viele Grüße
Kai

[Niklas G. (erlkoenig)]

Kai schrieb:
> richtig - die Datenübertragung zwischen PC und Arduino erfolgt über die
> "sekundäre" serielle Schnittstelle (19200 Baud).

Warum nicht über USB? Wie hast du die sekundäre Schnittstelle am PC 
angebunden? Mit was für einer Software empfängst du die Daten?

19200 Baud sind jedenfalls so gut wie nix, das kann jeder Controller 
unter der Sonne zu 100% abhandeln.

[Kai (ksb)]

Hallo Niklas,

entschuldige - da habe ich nicht aufgepasst - die Übertragung erfolgt 
über USB - im Falle Uno R4 über COM7 und im Falle Uno R3 COM4.

Das Senden von beiden Controllern an den PC ist weiterhin problemlos, 
jedoch tritt beim Empfangen mit Uno R4 das o. g. Problem auf.

Evtl. liegt das Problem an der höheren Arbeitsfrequenz des Uno R4?

Zurzeit übertrage ich die Daten mittels des seriellen Monitors, habe 
aber auch eine Visual Studio App dafür geschrieben.

Muss ich beim R4 evtl. Serial1 nutzen?

Ich habe schon überlegt, wie ich das Problem mittels Scope darstellen 
kann, bin aber bisher auf keine Lösung gekommen.

Viele Grüße
Kai

[Niklas G. (erlkoenig)]

Kai schrieb:
> jedoch tritt beim Empfangen mit Uno R4 das o. g. Problem auf.

Theoretisch könnte es ein Fehler in der Arduino Library für den R4 sein, 
aber ich kann mir nicht vorstellen dass so ein elementarer Fall nicht 
korrekt abgedeckt wird.

Das USB Protokoll enthält eine Prüfung und Flusskontrolle für die 
Nutzdaten, somit kann auf dem Controller kein Puffer überlaufen und 
Daten verloren gehen.

Daher ist es höchst wahrscheinlich ein Problem in deinem Code.

Kai schrieb:
> Evtl. liegt das Problem an der höheren Arbeitsfrequenz des Uno R4?

Nein.

Kai schrieb:
> Zurzeit übertrage ich die Daten mittels des seriellen Monitors,

Und damit tritt das Problem auch auf?

Kai schrieb:
> Muss ich beim R4 evtl. Serial1 nutzen?

Nein.

Kai schrieb:
> Ich habe schon überlegt, wie ich das Problem mittels Scope darstellen
> kann, bin aber bisher auf keine Lösung gekommen.

Bei USB geht das nicht wirklich und ist auch kaum sinnvoll.

Die Baudrate spielt übrigens bei reiner USB-Übertragung keine Rolle, 
weil nirgendwo eine physische serielle Schnittstelle im Spiel ist.

[Kai (ksb)]

Niklas G. schrieb:
>> Zurzeit übertrage ich die Daten mittels des seriellen Monitors,
> Und damit tritt das Problem auch auf?

ja - beim Uno R4 und
nein - beim Uno R3

[Niklas G. (erlkoenig)]

Kai schrieb:
> ja - beim Uno R4 und

Dann liegt es so gut wie sicher an deinem Sketch. Insbesondere weil du 
schreibst:

> Der serielle Puffer verschluckt dann scheinbar Zeichen. Am Ende der Übertragung 
wurden deutlich weniger Zeichen übertragen

Bei USB-Serial kann eigentlich nichts verschluckt werden.

[Nemopuk (nemopuk)]

Dieses Thema hatten wir schon mal, da lag es 100% an schlechtem Code. 
Nur wolltest du das bis zum Schluss nicht einsehen.

Beitrag "Arduino: page-write in I2C eeprom verliert sporadisch ein Byte"

[Kai (ksb)]

Hallo Nemopuk,

naja - der schlechte Code läuft aber auf Mega und Uno R3 seit gut 2 
Monaten problemlos....

Viele Grüße
Kai

[Nemopuk (nemopuk)]

Kai schrieb:
> naja - der schlechte Code läuft aber auf Mega und Uno R3 seit gut 2
> Monaten problemlos....

Dann bleibe halt beim Uno R3 und akzeptiere die Schuld, anstatt über den 
Uno R4 zu schimpfen. Wenn du die Ratschläge damals angenommen hättest, 
dann hättest du jetzt kein Problem.

Oder nutze dies als zweite Gelegenheit und Grund, es richtig zu machen. 
Neue Ratschläge braucht es dazu nicht.

[Kai (ksb)]

Hallo Nemopuk,

ich habe nicht über den Uno R4 geschimpft, sondern Besonderheiten 
geschildert und nach Abhilfe gefragt. Aus meiner Sicht können alle 
Punkte auch für andere Uno R4 Umsteiger hilfreich sein - sei es, um eine 
Entscheidung für oder gegen Arduino Uno R4 zu treffen oder um nicht mit 
den selben Besonderheiten kämpfen zu müssen.

1. Übertragung PC an seriellen Monitor funktioniert nicht - Ursache dank 
deines Tipps gefunden Abhilfe: DTR + RTS müssen gesetzt werden
2. Doppelter Speicherbedarf - Ursache dank deines Tipps: ARM-Architektur 
Abhilfe: keine
3. random() sehr langsam - Ursache Routine initialisiert TRNG bei jedem 
Aufruf neu initialisiert (100ms) - Abhilfe dank eines Tipps von Falk 
gefunden
4. tone() Melodien fehlerhaft - Ursache PROGMEM Abhilfe: dank Tipps von 
Arduino F, Johann und dir ist PROGMEM nicht nötig. *)
5. EEPROM: ggf. schnell verschlissen - Ursache: wird im Flash simuliert 
Abhilfe: wahrscheinlich besser externes EEPROM verwenden
6. Datenübertragung: Einbrechen der Übertragungsgeschwindigkeit - 
Ursache: ggf. mein schlechter Code Abhilfe bisher unklar
7. LED-Matrix: recht dunkel - Ursache: Charlieplexing Abhilfe: keine 
bekannt - ist aber auch nicht so wichtig.
8. Interrupts: unerwartete Interrupts - Ursache: ggf. weitere von mir 
eingebundene Bibliotheken bzw. Funktionen Abhilfe: keine bekannt.

Nur bei Punkt 6. ist eventuell mein Code ursächlich - die Ursache muss 
ich noch finden - evtl. schlägt ein Timeout zu, da das Programm ja 
schneller abgearbeitet wird.

Als weitere Besonderheiten wäre noch zu nennen:

9. Bluetooth: nur BLE

Viele Grüße
Kai

*) Offen ist noch herauszufinden, welche Bibliotheken oder Funktionen 
den Ton selber stören.

[Kai (ksb)]

Hallo,

anbei ein Minimal-Sketch bei dem die oben beschriebenen Störungen 
auftreten. Dieser schreibt die Daten in ein externes 32k-EEPROM und 
liest diese anschliessend wieder aus.
Bei allen Melodien treten mehr oder weniger starke Störungen auf. Die 
meisten sind aber noch erkennbar. Nur 8 und 9 sind vollkommen 
durcheinander.

Ohne das Einbinden des LCD werden keine I2C-Adressen gefunden. Was 
könnte dafür die Ursache sein?

Viele Grüße
Kai

[Nemopuk (nemopuk)]

Kai schrieb:
> Ohne das Einbinden des LCD werden keine I2C-Adressen gefunden. Was
> könnte dafür die Ursache sein?

Fehlende Pull-Up Widerstände an SCL und SDA.

[Arduino F. (Firma: Gast) (arduinof)]

Kai schrieb:
> Ohne das Einbinden des LCD werden keine I2C-Adressen gefunden. Was
> könnte dafür die Ursache sein?

fehlende Pullup

[Nemopuk (nemopuk)]

Die Pull-Up Widerstände auf den gängigen Display Boards sind außerdem 
recht hochohmig. Das könnte deine Kommunikation zum EEPROM 
beeinträchtigen. Ich würde sie immer auf 1-3 mA auslegen, wenn die 
Leitungen kurz sind.

[Kai (ksb)]

Hallo Arduino F und Nemopuk,

vielen Dank für Eure Antworten.

ich messe 1k6.
LCD und RTC sind auch ohne Einbinden montiert und somit deren Pull-Up 
aktiv.
Jedoch bekomme ich erst nach dem Einbinden des LCD Adressen angezeigt.

Viele Grüße
Kai

[Nemopuk (nemopuk)]

Kai schrieb:
> Jedoch bekomme ich erst nach dem Einbinden des LCD Adressen angezeigt.

Was genau meinst du mit "einbinden"?

[Kai (ksb)]

Die includes einfügen:

#include <LiquidCrystal_I2C.h>     // I2C-Display
LiquidCrystal_I2C lcd(0x27,20,4);  // set the LCD address to 0x27 for a 
16 chars and 2 line display

und das LCD initialisieren:
lcd.init();                        // Initialize the lcd

[Nemopuk (nemopuk)]

Hmm, darauf kann ich mir keinen Reim machen. Das Display sollte auch 
ohne Initialisierung nicht den Bus blockieren.

Hast du eventuell noch andere Stellen im Code, die auf das nicht 
initialisierte Display zuzugreifen versuchen? Wahrscheinlich nicht, das 
würde wohl nicht compilieren.

[Kai (ksb)]

Nein - ich habe alle Befehle für das Display erst eingefügt, als ich 
keine Adressen fand. Zuerst habe ich mit dem LCD angefangen. Sobald ich 
nur diese 3 Zeilen einfüge:

#include <LiquidCrystal_I2C.h>     // I2C-Display
LiquidCrystal_I2C lcd(0x27,20,4);  // set the LCD address to 0x27
lcd.init();

finde ich die Adressen (siehe Screenshot).

[Kai (ksb)]

Ah - mein Fehler: Wire.begin(); fehlte