I2C EEPROM Erfahrungsbericht

Hallo Arduino Gemeinde,
Ich will mit euch meine Erfahrungen teilen zu diesem Bauteil.

Bestellt habe ich: AT24C256
Erhalten habe ich einen IC in SMD-Bauform mit folgendem Aufdruck: ATMLH713 2EC L Y 3X5347A

Testbedingungen:
Arduino IDE 1.8.3
Erweiterung arduino-esp32
ESP 32 Board
mit Internen Pullup
VCC 3,3V

Quellcode: https://www.robot-r-us.com/vmchk/components/i2c-eeprom-module-at24c256.html

Erster Test:
Anpassungen Demo Programm:
#include Wire.h geändert in #include <Wire.h>
Wire.begin(); geändert in Wire.begin(mySDA, mySCL);
delay(10); eingefügt nach Serial.begin(9600); (Löst ein bestehendes Reset Problem vom ESP nicht dauerhaft!)

Mein Test:
Schreibtest:
Testdaten sind unsigned long (4 Byte je Wert)
Ist der Testwert größer als 32764 läuft der Speicher über (entspricht 0b1000.0000.0000.0000)

Berechnung:
4 Byte je Wert * 32764 Werte = 131056 Byte = 131kByte
131056 Byte * 8 = 1048448 bit = 1Mbit Speichergröße

Fazit:
Besser als erwartet :slight_smile:

Gruß an alle Arduino begeisterten

4 Byte je Wert * 32764 Werte = 131056 Byte = 131kByte

:wink: Witzige Berechnung

Ich fürchte, ein AT24C256 - Chip mit 256kBit wird leider nur 32 kByte Daten speichern können.
Das sind immerhin 8192 uint32_t Variable.
Du kannst natürlich auf die Adressbytes 0 .. 32787 schreiben.
Wenn du jeweils 4 Bytes schreiben willst, darf die letzte Startadresse nur 32764 sein, mit der dann
die 4 Bytes 32764 .. 32767 beschrieben werden. (Was drei Bytes der vorigen Operation ( 32763.. 32766 ) wieder überschreibt)

Anpassungen Demo Programm:
#include Wire.h geändert in #include <Wire.h>

Ist schon ein bisschen peinlich für robot-r-us.com
Der Rest ( Wire.begin(); ) geht auf "ESP32 ist nun mal kein Arduino".

Ja stimmt, da habe ich einen Denkfehler.
Heute geht es nicht so schnell bei mir.

Hoffe es ist trotzdem hilfreich für jemanden :slight_smile:

Hallo,

michael_x:
Der Rest ( Wire.begin(); ) geht auf "ESP32 ist nun mal kein Arduino".

vielleicht mache ich mich auch unbeliebt...
Was ist ein "Arduino"?
Ein Mega328, 32U4, Mega2560, eine SAM, ein ARM M4auf dem Board?
Bei jeder version muß man Unterschiede beachten.

Ein ESP8266 und ein ESP32, der aus der Arduino-IDE programmiert wird und deren Lib-Unterstüzung nutzt, ist für mich ein "Arduino". Gänsefüßchen bei Arduino, weil ich nicht dauern Arduino-compatibel schreiben wollte.
Darüber kann man sich gern mit den Herstellern berechtigt um die Namensrechte zanken.

Für übliche User (auch für mich) sind aus der IDE ESP8266/ESP32 durchaus "Arduions".
Und oh Wunder: Wire.begin() ohne Parameter geht da wie auch bei anderen "Arduions".
Werden eben die Default-Pins benutzt.
Beim ESP8266 GPIO4 SDA, GPIO5 SCK, beim ESP32 GPIO21 SDA und GPIO22 SCK.

Gruß aus Berlin
Michael

Bei jeder version muß man Unterschiede beachten

Genau deshalb versuche ich hier auch eine Kleinigkeit bei zu tragen

#include Wire.h geändert in #include <Wire.h>

Diese Kleinigkeit hätte mich zum Beispiel noch vor ein paar Jahren dazu veranlasst das Notebook zu zu machen und dann hätte ich gesagt da funktioniert ja gar nichts.

Wire.begin()

Ja, das stimmt, aus meiner Beschreibung geht nicht hervor dass ich das gemacht habe da ich andere Pins verwende und auf diese Weise können sie manuell ausgewählt werden.

Ich wollte nur darauf hinweisen das wohl noch ein Fehler im Programmablauf sein dürfte, denn beim ersten Test wurde nicht einmal das erste „Serial.println“ ausgeführt, nach dem einfügen von „delay(10);“ ging es eine Zeit, nach dem ich das Demo Programm erweitert habe ging es nicht mehr,
wie gesagt, ESP32.

Gruß an alle die sich von einem vergessenen Semikolon nicht den Spaß nehmen lassen.

Hallo,

Fan1000:
Ich wollte nur darauf hinweisen das wohl noch ein Fehler im Programmablauf sein dürfte, denn beim ersten Test wurde nicht einmal das erste „Serial.println“ ausgeführt, nach dem einfügen von „delay(10);“ ging es eine Zeit, nach dem ich das Demo Programm erweitert habe ging es nicht mehr,
wie gesagt, ESP32.

ein Reset-Problem beim ESP32 ist mir bisher nicht aufgefallen. Was auf manchen ESP32-Boards hier gern passiert: er startet nach dem Flashen nicht sauber, da drücke ich aber dann schon aus Gewohnhiet den Resetknopf...
Ich habe auch 2 verschiedene ESP32 hier (NodeMCU.ähnlich), die aus der IDE nicht in den Programmiermode kommen. Ist eben ein Druck auf Prog nötig. Ursache ist mir noch unklar, Beschaltung auf den Boards für RTS/DTR ist eigentlich ok.

Gruß aus Berlin
Michael

2 verschiedene ESP32 hier (NodeMCU.ähnlich),

Das „NodeMCU.ähnliche“ automatisch in den Programmiermode gehen bin ich auch vor kurzem draufgekommen (so geil ist Geiz dann auch wieder nicht).

So, jetzt habe ich mir das noch einmal angeschaut und bin etwas klüger geworden:
Versuch 1:
Arduino IDE 1.8.3
Serial.begin(115200);
Programm bleibt stehen bei

ets Jun 8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0x00
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0008,len:8
load:0x3fff0010,len:160
load:0x40078000,len:10632
load:0x40080000,len:252
entry 0x40080034

Versuch 2:
Arduino IDE 1.8.5 (heruntergeladen)
Serial.begin(115200);
Programm läuft :slight_smile:

ets Jun 8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:956
load:0x40078000,len:0
load:0x40078000,len:13256
entry 0x40078a90
Writing Test:
. . . . . . . . . . . . . . . . . . . .
Reading Test:
A B C D E F G H I J K L M N O P Q R S T
Writing Page Test:
Reading Page Test:
! " # $ % & ' ( ) * + , - . / 0 1 2 3 4 5 6 7 8 9 : ; <

Habe so das Gefühl dass er innerhalb „Wire.begin();“ stehen bleibt, das ist mir schon öfters passiert, schuld war eine wackliger Verdrahtung, das kann ich hier aber ausschließen denn hier ist der I2C ausnahmsweise mal wirklich als Platinenbus ausgeführt mit nur dem einen IC.

Und was mir unabhängig davon aufgefallen ist, das mein ESP32 den ich üblicherweise verwende, schon einiges mit mir mitgemacht den der zeigt folgendes an:

ets Jun 8 2016 00:22:57 ⸮HH⸮t:0x10 (RTCWDT_RTC_RESQU⸮I⸮⸮⸮⸮0x13 (SPI_FAST_FLP*⸮%==Q⸮
configsip: 0, S⸮]A⸮0x00
clk_drv:0x00,q_⸮⸮⸮0x00,d_drv:0x00,cs0_drv'⸮⸮0,hd_drv:0x00,wp_drv:0⸮0
mode:DIO, clock div:1 !⸮+⸮:0x3fff0008,len:8
loX⸮⸮⸮⸮fff0010,len:160
load'⸮⸮0078000,len:10632
loa⸮⸮⸮⸮0080000,len:252
entry⸮⸮⸮0080034

Hallo,

wie groß sind die PullUp-Widerständen am I2C? 3,3k wäre ein sinnvoller Wert.

Das untere sieht auf wie etwas falsche Bitrate oder angeschossenem TX-Pin oder USB-Converter.
Habe ich bisher noch nicht geschafft, auch nicht mit diversen ESP8266.

Gruß aus Berlin
Michael

wie groß sind die PullUp-Widerständen

zum testen habe ich an dem NodeMCU.ähnlich Board die Internen PullUp verwendet,
wie gesagt mit der IDE 1.8.5 läuft der EEPROM soweit fehlerfrei.

Das untere sieht aus wie etwas falsche Bitrate

Ja, aber das Programm lädt er momentan immer einwandfrei hoch und die Debugausgaben sind auch in Ordnung.
Ich muss aber auch dazusagen dass ich an besagten Board normalerweis mit Baud 250000 arbeite, ich momentan einen CH340 USB-Adapter (Welcher mir schon viele Probleme gemacht hat) verwende und dazwischen ist eine Schaltung mit 6N137 mit galvanicher Trennung, könnte ich mir alles sparen mit dem NodeMCU.ähnlich Board, werde ich wahrscheinlich auch, aber bis dahin gilt „never touch a running system“

Anmerkung: Ich glaube mich erinnern zu können dass ich mit 230400 Baud upload-speed vor langer Zeit mal ein sehr zeitraubendes Problem hatte.

Hallo,

mit dem CH340 auf den ESP8266-Boards hatte ich noch keine wirklichen Probleme, Debug-seriell 115200, Flashen mit 921600. Reine USB-Adapter habe ich mit FTDI und CP2102, auch da keine wirklichen Probleme, lange Dupont-Strippen und Steckbrett können natürlich die 921k Baud schonmal stören, dann flashe ich eben etwas langsamer.
Galvanische Trennung nutze ich keine, falls doch mal nötig sein sollte, liegt ein Adapter mit einem ADUM1201 rum, der kommt dann eben dazwischen. Bisher gab es keinen Grund dafür.

Probleme bei bestimmten Baudraten gab es beim ESP8266 und vielleicht auch beim ESP32 durchaus mal, da wurde die Baudrate im SDK schon falsch berechnet...

Gruß aus Berlin
Michael

zum testen habe ich an dem NodeMCU.ähnlich Board die Internen PullUp verwendet,

  • Wie willste denn das gemacht haben?
  • Wenn überhaupt möglich, dann sind sie immer noch zu groß.

Hallo,

combie:

  • Wie willste denn das gemacht haben?
  • Wenn überhaupt möglich, dann sind sie immer noch zu groß.

habe ich doch glatt übersehen in seiner Antwort...

Ja, ist wie beim AVR möglich und ja, sie sind zu hochohmig.

Gruß aus Berlin
Michael

EDIT:

Entfernt, weil ich den hohen Ansprüchen nicht gerecht werden kann.

combie:
So mancher AVR hat eine Hardware TWI Einheit.
Diese übergeht alle vorherigen pinMode() Einstellungen auf den Pins.

Das ist nicht korrekt.

Aus dem 328p Datasheet:

26.5.1. SCL and SDA Pins
These pins interface the AVR TWI with the rest of the MCU system. The output drivers contain a slewrate
limiter in order to conform to the TWI specification. The input stages contain a spike suppression unit
removing spikes shorter than 50ns. Note that the internal pull-ups in the AVR pads can be enabled by
setting the PORT bits corresponding to the SCL and SDA pins, as explained in the I/O Port section. The
internal pull-ups can in some systems eliminate the need for external ones.

EDIT:

Beitrag entfernt, weil ich den hohen Ansprüchen nicht gerecht werden kann.

combie:
So mancher AVR hat eine Hardware TWI Einheit.

Stimmt, so mancher ist eher fast jeder, aber warum erwähnst du das?

combie:
Die Wire Library übergeht/überschreibt die vorherigen Pullup Einstellungen auf den Pins.

Nein zu übergeht, ja zu überschreibt, tw_init (aufgerufen von TwoWire.begin) schaltet die Pullups ein (auf AVRs).

// activate internal pullups for twi.
  digitalWrite(SDA, 1);
  digitalWrite(SCL, 1);

combie:
In der Hardware TWI Einheit kann man nichts zu den Pullups einstellen.

Das ist wahr, aber völlig ohne Relevanz.
Hardware Einheiten sind so weit als möglich getrennt, Einstellungen über mehrere Einheiten
(TWI und I/O Pins) werden normalerweise durch Software vorgenommen.

Hallo,

gerade nochmal beim ESP8266 geschaut: auch hier werden die PullUp in twi_init() eingeschaltet:
pinMode(twi_sda, INPUT_PULLUP);
pinMode(twi_scl, INPUT_PULLUP);

Die internen PullUp (PullDown hat der ESP8266 auch) sind ca. 27k, also höchstens mal zum Test mit einem einzelnen I2C-Device brauchbar.

Gruß aus Berlin
Michael