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...
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
>Beitrag "Re: STM32F4Discovery I2C-Kommunikation" Besser: http://eliaselectronics.com/stm32f4-tutorials/stm32f4-i2c-master-tutorial/
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:
1 | int I2C_ReadTransfer (dev_addr, *buffer, cnt, ptr, ptrlen); |
2 | int I2C_WriteTransfer(dev_addr, *buffer, cnt, ptr, ptrlen); |
- Check-Funktion um zu prüfen, ob ein Baustein "antwortet"
1 | 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!
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.
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.
@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;
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.