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?
>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
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:
- Check-Funktion um zu prüfen, ob ein Baustein "antwortet"
1
intI2C_CheckDevice(dev_addr);
- und eine kleine Demo-Applikation dazugepackt:
(siehe beigefügtes CooCox-Projekt)
Feedbacks, Verbesserungsvorschläge und allfällige Korrekturen sind sehr
willkommen!
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.
@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.
@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...)
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!
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 ...
>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"
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
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...
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...
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
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;
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang