STM32F4 Discovery mit I2C-Bus EEPROM

[Peter S. (psavr)]

Hab mein Discovery Board mit einem 4 kB I2C-Bus EEPROM aufgemotzt, anbei 
zwei Fotos zur Inspiration für für allfällige Nachahmer...

- R21 und R22 => auf C16 + C27 umbestücken
- X3 (Pin 2 und Pin 3) Lötpads mit Skalpell aufteilen (aus 2 mach 4)
- EEPROM (z.B. Atmel AT24C32 4k x 8) auf Pads des X3 bestücken
- Pin 1..4 (A0,A1,A2,GND) verbinden (=> Device Addr 0xA0)
- Pin 5 auf SDA/PB8 @ R29
- Pin 6 auf SCL/PB6 @ R33
- Pin 7 (WP) bleibt "not connected" (interner Pulldown)
- Pin 8 auf VDD (+3V)

Past so...

[Thomas W. (diddl)]

Genial, da ich vorher AVR gewohnt war, ist das genau was mir gefehlt 
hat.

Spendierst du uns auch noch ein Code Schnipsel dazu?



AT24C32? Ist das nicht ein 5V Typ? 4,5V bis 5,5V?

[Peter S. (psavr)]

>Spendierst du uns auch noch ein Code Schnipsel dazu?
Kann ich machen, aber passenden Code muss ich erst noch proggen, es sei 
denn ein anderer spendiert was fix-fertiges? (Ich fürchte, dass ich 
selber über dieses WE nicht dazukommen werde.)

>AT24C32? Ist das nicht ein 5V Typ? 4,5V bis 5,5V?
Nein, der verwendete Typ ist der 24C32N-SI27, (Industrial 
Temperatur-Bereich, 2.7V - 5.5V, es gibt auch noch den -SI18 bzw -PI18 
Typ, für 1.8V - 5.5V

[vampire (Gast)]

Beitrag "Re: STM32F4Discovery I2C-Kommunikation"

[Peter S. (psavr)]

>Beitrag "Re: STM32F4Discovery I2C-Kommunikation"

Besser: 
http://eliaselectronics.com/stm32f4-tutorials/stm32f4-i2c-master-tutorial/

[Peter S. (psavr)]

Ich habe den Code von http://eliaselectronics.com ausgebaut:
 - Erweiterungen mit Timout- und Error-Handling
 - Universelle I2C-R/W Funktionen, passend für alle Bausteine:

   int I2C_ReadTransfer (dev_addr, *buffer, cnt, ptr, ptrlen);
   int I2C_WriteTransfer(dev_addr, *buffer, cnt, ptr, ptrlen);

 - Check-Funktion um zu prüfen, ob ein Baustein "antwortet"

   int I2C_CheckDevice(dev_addr);

 - und eine kleine Demo-Applikation dazugepackt:
   (siehe beigefügtes CooCox-Projekt)

Feedbacks, Verbesserungsvorschläge und allfällige Korrekturen sind sehr 
willkommen!

[m.n. (Gast)]

Eine Kleinigkeit fällt mir auf.
Es wäre schön, wenn der page-mode unterstützt würde. Der beschleunigt 
das Schreiben größerer Blöcke erheblich. U.U. könnte ich Dir 
Beispielcode eines anderen µC dafür anbieten. CooCox selbst verwende ich 
nicht.

[Thomas W. (diddl)]

Danke für den Code, noch dazu CooCox, perfekt!  :-)


Ich bekomme demnächst einen Flash Baustein und ein I2C Display (12864), 
da werde ich das testen.

[m.n. (Gast)]

@Peter
Ich habe versucht, die Schreibroutinen fürs EEPROM 24C32 
nachzuvollziehen. Irgendetwas scheint nicht zu stimmen.

Die Teststrings werden immer an 'runde' Adressen 0x20, 0x40, ... 
geschrieben und das 24C32 hat eine Seitengröße von 32. Das funktioniert 
hier zufällig.
Aber schreibe mal nach 0x31, 0x4e, ... dann kann der page-mode nicht 
mehr funktionieren.
Wenn ich mich nicht völlig falsch erinnere, werden einzelne Bytes 
geschrieben, indem die komplette Adressierung + Datenbyte + STOP 
ausgegeben werden. Wird kein STOP ausgegeben landen die Daten im 
page-buffer bis STOP kommt. Werden zu viele Bytes (oder unausgerichtet) 
geschrieben, landen die überschüssigen Daten ganz vorne im Puffer. Beim 
sequentiellen Lesen tauchen sie dann nicht mehr auf, da der Lesezeiger 
keine Seitengröße beachtet.

[Peter (Gast)]

@m.n. (Gast)
>Es wäre schön, wenn der page-mode unterstützt würde.
Selbstverständlich geht das mit den vorhandenen Funktionen!

>Aber schreibe mal nach 0x31, 0x4e, ... dann kann der page-mode nicht
>mehr funktionieren....
Die Funktionen sind absichtlich universell gehalten und nicht auf 
spezifische I2C-Bus Bausteine zugeschnitten. Aber es sollte mit den 
vorhanden Funktionen recht einfach sein, Device-spezifische Treiber zu 
schreiben. (z.B. für EEPROMs, IO-Expander A/D- und D/A-Wandler, 
Temp.-Sensoren, RTC-Module, Displays etc...)

[m.n. (Gast)]

Peter S. schrieb:
> Feedbacks, Verbesserungsvorschläge und allfällige Korrekturen sind sehr
> willkommen!

Wie gesagt, ich habe kein CooCox, kein EEPROM 24C32 angeschlossen und 
weiß auch nicht, was in der Routine I2C_SendData() passiert.
Da nehme ich Deinen obigen Aufruf ernst, schlag Dir einen Test mit 
anderen Adresseinstellungen vor und höre anschließend nur von 
'universell gehaltenen Funktionen'. Weiterhin viel Glück!

[bösewicht (Gast)]

Die Teststrings werden immer an 'runde' Adressen 0x20, 0x40, ...
geschrieben und das 24C32 hat eine Seitengröße von 32.

Es macht schon einen Unterschied, ob ich mit Adresse die I2C-Adr. des 
Chips meine oder die Adresse 0x20, 0x40, ... im z.B. dem 
EEprom-Speicher;

Da reden 2 aneinander vorbei ...

[Peter S. (psavr)]

>Die Teststrings werden immer an 'runde' Adressen 0x20, 0x40 geschrieben...
Ja, das ist bloss ein rudimentäres Beispiel für Test-Zwecke. Natürlich 
fehlen noch die I2C-Device spezifischen Funktionen welche z.B. die 
Page-Struktur eines EEPROMs korrekt berücksichtigen.

>U.U. könnte ich Dir Beispielcode eines anderen µC dafür anbieten.
Bitte, lass sehen!

Erweiterungen siehe: Beitrag "Re: STM32F4Discovery mit CooCox CoOS-RTOS und printf"

[Peter S. (psavr)]

I2C-Bus Code...

[Peter S. (psavr)]

Update.. ;o)

[Elia (Gast)]

Schön zu sehen, dass mein Code wirklich jemandem was nützt :)

Gerne integriere ich das Timout/Error-Handling in den Code auf meiner 
Website wie von dir vorgeschlagen!

MfG
Elia

[Markus K. (markus_k64)]

Klasse Code, hat mir sehr geholfen!

Noch ein wichtiger Hinweis, der mich Wochen an Zeit gekostet hat (lag 
aber eher an meinem Unverständnis):

Mein I2C-Bauteil (Temperature / Drucksensor Bosch BMP085) hat die 
Adresse 0x77.

Der obige Sourcecode lief einwandfrei, nachdem ich die Geräteadresse des 
Sensors im Code von 0x77 auf 0xEE änderte (0x77 um ein bit nach links 
verschoben (bit shifting)).

Wie ich die Hinweise im Netz und in der Doku von ST verstand, liegt es 
daran, dass meine Geräteadresse 0x77 eine 7-Bit-Adresse ist, der STM32 
bei I2C Daten und Adressen aber als 8-Bit-Bytes überträgt.

Nur als Hinweis, falls es mal noch jemandem so geht...

[veryBo (Gast)]

Markus K. schrieb:
> Klasse Code, hat mir sehr geholfen!
>
> Noch ein wichtiger Hinweis, der mich Wochen an Zeit gekostet hat (lag
> aber eher an meinem Unverständnis):
>
> Mein I2C-Bauteil (Temperature / Drucksensor Bosch BMP085) hat die
> Adresse 0x77.
>
> Der obige Sourcecode lief einwandfrei, nachdem ich die Geräteadresse des
> Sensors im Code von 0x77 auf 0xEE änderte (0x77 um ein bit nach links
> verschoben (bit shifting)).
>
> Wie ich die Hinweise im Netz und in der Doku von ST verstand, liegt es
> daran, dass meine Geräteadresse 0x77 eine 7-Bit-Adresse ist, der STM32
> bei I2C Daten und Adressen aber als 8-Bit-Bytes überträgt.
>

Das LSB wird bei I2C zur Unterscheidung zwischen Lesen und Schreiben
benutzt. Manche geben 2 Adressen als 8 bits an und beziehen das LSB mit 
ein,
andere wiederum nur 7 und überlassen den Rest dem Leser...

[Thomas (Gast)]

Soweit ich mich erinnern kann war das jetzt das erste Mal, dass ich 
einen Code ohne irgendwelche Änderungen vornehmen zu müssen, wieder 
verwenden konnte:

VIELEN DANKE Peter und http://eliaselectronics.com

Wirklich Super!

LG Thomas

[Tobias (Gast)]

Der Code funktioniert toll. Vielen Dank auch von mir.

Es fehlen noch zwei Defindes, wie bereits auf der Seite von Elia 
angemerkt wurde:

#define OK (0)
#define ERROR (-1)

Diese beißen sich aber mit dieser Zeile in der stm32f4xx.h?

typedef enum {ERROR = 0, SUCCESS = !ERROR} ErrorStatus;