Marco's Affenbox Fork

Danke für die Hinweise.
Dann muss ich das abfangen.
Verstehe ich das Richtig, dass ab einer Addressierung von über 1024 der Bootloader überschrieben wird?
Wäre sicherlich auch nicht verkehrt das im Original Sketch ab zu fangen.

Du kannst ja im Moment gar nicht auf Adressen über 512 zugreifen. Was ja überhaupt erstmal der Bug ist. Siehe die Tests die da hinterlegt sind. Die Bootloader Probleme bekommst du, so versteh ich das, wenn du das eeprom vergrösserst. Was wir ja eh nich tun (weil frisst ja flash).

Okay Danke, dann les ich mich erst mal ein.

So ich habe den Pullrequest in meine kopie eingefügt und kann jetzt auch über die Adresse 512, Daten lesen und schreiben.

Ich habe auf GitHub auch mein Feedback hinterlassen.

Einen Programmer hab ich hier, deswegen konnte ich bedenkenlos an die Sache ran.

Leider ist der Bugfix nichts für die breite Masse hier, deshalb muss ich meinen Fork erstmal auf die 512Byte beschneiden…
Hoffentlich wird der Pullrequest schnell übernommen.

An alle Forknutzer, in dem erweiterten Hörbuchspeicher gab es einen Bug, der den EEPROM falsch befüllt hat.
Bitte aktualisiert eure Forkversion.

Hallo @stephan
Ich habe mir mal den Pullrequest angesehen. Verstehe ich das richtig, dass die Vergrößerung des EEPROM zu lasten des Programmspeichers geht?
Ich werde mich aber erst mal nicht an diese Sache wagen und warte ab bist eine fertige Aktualisierung der Bibiothek veröffentlicht ist.
Gruß Thomas

Da der LGT kein EEPROM hat geht die Emulation immer zu Lasten des Programmspeichers und das doppelt (wegen paging). Der PR geht auch nicht (primär) um das vergrößern sondern um einen Bug der momentan nur den Zugriff auf 512 byte statt der default mässigen 1024 (1022 eigentlich) erlaubt.

Das heißt, mit dem Bug sind die 510 Byte auf die nicht zugegriffen werden kann quasi gar nicht nutzbar. Auch nicht für den Programmspeicher?

Richtig. (20 Zeichen)

ok.verstanden. Danke für die Auskunft.

Hallo zusammen,
ich habe mir Marcos letzten Sketch gezogen um einen Poti aus diesem Set als Lautstärkeregler zu nutzen. Wenn ich nun in die Config schaue, liegt der ROTARY_ENCODER auf 5. Muss ich hier auf 7 switchen? Reichen mir 3,3V oder muss ich auf 5V gehen?
Gruß,
Jens

Hallo Jens,
ein Poti funktioniert leider nicht, du musst einen Rotary Encoder kaufen.

Der dreht Endlos und bietet Vorteilenin der Software Anpassung.

Schade. Kann ich nicht über map den PotiValue abgreifen?

Ich habe in meinem Fork nur diesen Encoder vorgesehen.
Potis find ich nicht so geeignet, da sie immer fest sind.
Man kann so keine Lautstärken über Software festlegen. Die Initiallautstärke entfällt somit.

Achso, klar - Denkfehler. Danke!

Lässt sich der Tonuino komplett über den Rotary-Encoder steuern? Also Play/Pause/Aufwecken per Druck, Lautstärke durch Drehen und ggf. Vor/Zurück durch Drücken und Drehen gleichzeitig? Fürs Admin-Menü kann man ja eine Karte machen.

Nein es wird nur die Lautstärke gesteuert.

Die Idee der Gesamtsteuerung hatte ich auch schon, aber ich finde das nicht so Kindertauglich, deswegenbhab ich da keine weiteren Mühen hinein gesteckt.

Ich versuche gerade deinen Fork für die AiO-Platine zu kompilieren. Das klappt leider nicht. Ich habe das Gefühl, dass ich irgendeine Bibliothek aktualisieren muss, weiß aber nicht was genau …

Der Fehler ist 'class EEPROMClass' has no member named 'size':

Tonuino/Tonuino.ino: In function 'void setup()':
Tonuino:1802:30: error: 'class EEPROMClass' has no member named 'size'
   for (int i = 0; i < EEPROM.size(); i++) {
                              ^~~~
Tonuino/Tonuino.ino: In function 'void adminMenu(bool)':
Tonuino:2611:30: error: 'class EEPROMClass' has no member named 'size'
   for (int i = 0; i < EEPROM.size(); i++) {
                              ^~~~
exit status 1
'class EEPROMClass' has no member named 'size'

Das scheint mit der Diskussion, die ihr in dem Pull Request zu diesem Thema geführt habt, zusammenzuhängen. Der PR beinhaltet die Implementierung der neuen EEPROM API und ist ja noch nicht gemerged. Könnt ihr mir Sagen wie ich auf die richtige Version aktualisieren und den Sketch kompilieren kann? Danke

Ist angepasst, bitte nochmal herunter laden.

Das ging ja fix :slight_smile:
Danke!

(kleiner Tipp am Rande: Solche „magic numbers“ machen sich ganz gut als definierte Konstanten. Während du geantwortet hast habe ich selber das Problem mit einem #define EEPROM_size 512 gelöst.)

Da fällt mir ein: Sollte das wirklich 1020 sein? Sind die 1020 Bytes nicht der unterliegende physische Flashspeicher der gebraucht wird um 512 Byte abbilden zu können?