I2C Kommunikation zwischen Nucleo STM32F103RBT6 und Sensor Honeywell HIH9120

[Wsk8]

Bau dir doch mal einen I2C Scanner (Arduino Beispiel):

void loop()
{
  byte error, address;
  int nDevices;
  Serial.println("Scanning...");
  nDevices = 0;
  for(address = 1; address < 127; address++ )
  {
    // The i2c_scanner uses the return value of
    // the Write.endTransmisstion to see if
    // a device did acknowledge to the address.
    Wire.beginTransmission(address);
    error = Wire.endTransmission();
    if (error == 0)
    {
      Serial.print("I2C device found at address 0x");
      if (address<16)
        Serial.print("0");
      Serial.print(address,HEX);
      Serial.println("  !");
      nDevices++;
    }
    else if (error==4)
    {
      Serial.print("Unknow error at address 0x");
      if (address<16)
        Serial.print("0");
      Serial.println(address,HEX);
    }
  }
  if (nDevices == 0)
    Serial.println("No I2C devices found\n");
  else
    Serial.println("done\n");
  delay(5000);           // wait 5 seconds for next scan
}

mfg

[fredred]

Hallo Wsk8,

Ein Scanner wie du schreibst ist okay. Mein Hinweis sollte nur Vermitteln, ist die Hardware „Dumm“, kann eine Software, nicht den Fehler eindeutig erkennen. Die vielen guten Softwarelösungen gehen ja immer davon aus, es ist ein Fehler im Programm. Oft sind es aber nur kleine Fehler, wenn ein neues Modul nicht korrekt angeschlossen wird.

Gruß fredred

[Klacknack]

Danke für beide Vorschläge.

Zur Hardware: Ich habe auch neben 100kHz andere Frequenzen ausgetestet, jedoch stelle ich da kein Unterschied fest. Datenblatt des Sensors sagt aus, dass alles zwischen 100kHz und 400kHz in Ordnung ist. Die Pull-Up Widerstände betragen 1,8kOhm, nach Datenblatt sollten es 2,2kOhm sein. Da hab ich auch schon variiert. Jedoch wiederum kein Unterschied. Die Entstör-Kondensatoren betragen den verlangten Wert und ich kann mir wirklich nicht vorstellen, dass es daran liegt. Der Aufbau ist auf einem Breadboard und ich überlege momentan ob ich den Testaufbau auf eine Lochrasterplatine löten soll. Mir fällt kein präziser Grund ein, denn beim Kontrollieren mit Multimeter oder Logic Analyzer waren alle Pegel auf dem Breadboard richtig, nur aus Erfahrung weiß ich, dass die Dinger nicht immer 100% zuverlässig sind. Als letztes fällt mir noch ein, einen anderen Sensor auszutesten. Vllt habe ich diesen beim Testen in irgendeiner Weise zerstört.

Dann werde ich mich als nächstes mal mit der Software befassen und mir den I2C Scanner ansehen. Zurzeit programmiere ich das Nucleo Board online mit dem mbed Compiler, weil ich eine recht kleine Aufgabe zu implementieren habe und ich keine Lust hatte mir eine IDE auf dem PC einzurichten. Vielleicht sollte ich dann doch dazu übergehen.

Ich halte euch auf dem laufenden was die Ergebnisse der nächsten Tage ergeben.

Danke, Gruß!

[Mxt]

An sich funktioniert I2C mit mbed ziemlich gut. Ich habe zwar nicht genau den Nucleo aus dem Titel, sondern einen F401, aber da sollte kein großer Unterschied sein.

Mit der normalen 400 kHz Einstellung habe ich verschiedene Sensoren und auch EEPROMs an verschiedenen mbed im Einsatz.

[fredred]

Hallo Klacknack,

wie geschrieben, ist die Hardware (Busleitungen okay), kannst Du deine Sensoren kaum zerschießen.
Mein Vorschlag ist.
Teste den I²C erst mal mit einem Digital- IC z B. PCF 8574. Der muss ja nicht erst Messdaten aufbereiten um Status „ich bin fertig“ zu generieren damit es weiter geht. Wenn sich IC meldet weist du erst mal, der Bus funktioniert. Rest ist die Softwareanpassung für die unterschiedlichen Teilnehmer.
Viele Sensoren sind meist für ein bestimmtes System entwickelt wurden. Somit sind Laufzeiten und Flanken zu beachten.
Das I²C Prodokoll ist zwar kaum noch in der Industrie im Einsatz, aber für Amateure wie ich es bin, leicht zu handhaben.
Beispiel: Meine Testplatine hat 40 Sockel für Test der I²C IC’s.
Bei voller Bestückung..

1. 16x Digital IC 64 Ports zum Schreiben und 64 zum Lesen ein IC ist Master für LCD-Anzeige 20x4 eingestellt.(Hat keinen I²C Anschluss). Also Modus abbilden
2. 8x Analog IC gleich 32 Ports
3. 8x Digital Poti 16 mal analog Out
4. 4x EEprom (256 k) für Datenlogger.

Werden alle Ereignisse mit ATmega 644P (Prozessortakt 16 MHz) generiert, ist die Laufzeit < 1 Sekunde.
Muss sagen für viele Anwendungen ist dies ausreichend.
Natürlich sind in der Software die Auswertungen, Anzeigen und Berechnungen für Laufzeiten zu beachten.

Gruß
fredred

[Mxt]

Hallo,

ich habe in meiner Sammlung ein kleines Beispiel für einen 24LC256 EEPROM, ist allerdings für den LPC1768 konfiguriert. Man muss die Pin Bezeichnungen für einen Nucleo anpassen, auch hat der nur eine LED. Aber es ist das schöne an mbed, dass die Programme mit so wenigen Änderungen auf Cortex-M verschiedener Hersteller laufen.

Headerdatei

#ifndef I2C_EEPROM_H
#define I2C_EEPROM_H

#include <vector>

//
// Klasse für 24LC256 usw.
//
class I2C_Memory {
private:
    int m_Address;
    I2C m_i2c;
    bool m_Ok;    
    
    //
    // Übertragungsfehler merken
    //
    void DoWrite(int value) {
        if (!m_i2c.write(value))
            m_Ok = false;
    }
    
public:

    //
    // Konstruktor
    //
    I2C_Memory(int address, PinName sda, PinName scl) : m_Address(address), m_i2c(sda, scl), m_Ok(true) 
    {}   
    
    //
    // Schreiben
    //
    bool Write(unsigned short start_address, const std::vector<uint8_t>& data) {
        m_Ok = true;
        
        char hb = (start_address & 0xff00) >> 8;
        char lb = start_address & 0xff;
        
        m_i2c.start();
        
        DoWrite(m_Address);
        DoWrite(hb);
        DoWrite(lb);
        
        for(unsigned int i = 0; i < data.size(); i++) {
            DoWrite(data[i]);
        }
        
        m_i2c.stop();
        
        return m_Ok;
    }
    
    //
    // Lesen
    //
    bool Read(unsigned int start_address, unsigned int count, std::vector<uint8_t>& data) {
        m_Ok = true;
        data.clear();
        
        char hb = (start_address & 0xff00) >> 8;
        char lb = start_address & 0xff;
        
        m_i2c.start();
        
        DoWrite(m_Address);
        DoWrite(hb);
        DoWrite(lb); 
        
        m_i2c.start();
        
        DoWrite(m_Address + 1);   
        
        for(unsigned int i = 0; i < count - 1; i++) {
            data.push_back(m_i2c.read(1));
        }
        if ( count > 0 ) {
            data.push_back(m_i2c.read(0));   // Letztes Lesen mit NACK quittieren
        }      
        
        m_i2c.stop();                      
        
        return m_Ok;
    } 
};
    
#endif

Beispielprogramm

#include "mbed.h"
#include "I2C_EEPROM.h"

I2C i2c(p9, p10);

DigitalOut led1(LED1);
DigitalOut led2(LED2);
DigitalOut led3(LED3);

int main() {
    I2C_Memory memory(0xa0, p9, p10);
    
    while(1) {
        led1 = 0;
        led2 = 0;
        led3 = 0;
        
        wait(1.0);
        
        std::vector<uint8_t> data;
        
        if ( memory.Read(0, 256, data) ) {
            led1 = 1;
            
            for(int i = 0; i < data.size(); i++) {
                printf("%0.2x ", data[i]);
            }
            printf("\r\n\r\n");
        }
        else {
            led2 = 1;
        }
        
        wait(5.0);
    }
}

[Klacknack]

Hallo,

also nachdem ich mich nochmal sehr intensiv daran gesetzt habe und wieder keine Kommunikation zustande gekommen ist. Habe ich mir meine Schaltung und Bauteilliste zum 100sten mal angesehen und den Fehler gefunden. Und der ist wirklich peinlich! Ich habe in der Bestellnummer die letzte Zahl falsch eingegeben und den Sensor anstatt mit I2C Kommunikation einen mit SPI-Kommunikation bestellt. Die Schaltung ist geändert und die Software zu SPI Kommunikation geschrieben und es funktioniert einwandfrei.

Weiß noch nicht ob ich mich über den gefundenen Fehler freuen oder ärgern soll Jedenfalls bedanke ich mich bei allen für die mithilfe. Ich denke die I2C Kommunikation meines µC hat funktioniert und weswegen die Antwort des Sensors ausblieb weiß ich nun.

Gruß und Danke