I2C mit FreeRTOS auf STM32F103

[Vorname N. (mcu32)]

Hi,

ich versuche derzeit ein wenig in die Materie von FreeRTOS einzutauchen. 
Das klappt soweit auch ganz gut, das Prinzip hab ich verstanden und 
nicht kommunikative Dinge funktionieren soweit auch nachvollziehbar.

Jetzt habe ich gestern versucht, einen BME280 (Umweltsensor von Bosch) 
der I2C unterstüzt zu integrieren und bin dabei nach der Empfehlung des 
entsprechenden GitHub Repos vorgegangen (Pointer des BME280 Device auf 
entsprechende Funktionen für I2C).

Dafür verwendete ich folgende API die offiziell von Bosch stammt:
https://github.com/BoschSensortec/BME280_driver

Was soll ich sagen,  kompilieren tut es, allerdings hänge ich kurz nach 
dem starten des Debuggings in einer Schleife fest wo er den Systemtick 
erwartet.

Ich nutze die HAL von ST sowie FreeRTOS. Falls jemand helfen kann stelle 
ich auch gerne meinen (relevanten) Code ein. Ich bin mir relativ sicher 
dass es nichts mit der API von Bosch zu tun hat, sondern eher das mir 
das entsprechende Wissen fehlt wie man Kommunikation wie I2C o.ä 
vernünftig in FreeRTOS umsetzt :/.

Das ganze passiert auf einem BluePill Board (mit echtem STM32^^ liegt 
schon ne Weile hier herum). Verkabelung sollte soweit stimmen.

Schonmal vielen Dank.

[hard werker (Gast)]

Vorname N. schrieb:
> Pointer des BME280 Device auf
> entsprechende Funktionen für I2C

Das ruft nach Klärungsbedarf. Da müsstest du schon etwas
genauer und verbindlicher werden.

"Pointer des BME280 Device" klingt schon sehr nach Geschwurbel.
Die Sprache die hier zur Kommunikation verwendet wird ist
der Quellcode ....

[Vorname N. (mcu32)]

Hallo nochmal,
wie bereits erwähnt poste ich den Code gerne wenn jemand Helfen mag :)

//Associate BME280 with I2C HAL
    //Typecast of I2C HAL receive/write function ptr to the suitable format for bme280 driver
    bme280.read =  (bme280_read_fptr_t)HAL_I2C_Master_Receive;
    bme280.write = (bme280_write_fptr_t)HAL_I2C_Master_Transmit;
    bme280.delay_us = (bme280_delay_us_fptr_t)HAL_Delay;

Ich habe das so verstanden, dass die API von Bosch die I2C Funktionen 
der Hal selbstständig aufruft in dem ich die entsprechenden Pointer des 
structs bme280 auf diese zeigen lasse.

struct bme280_dev
{
    /*< Chip Id */
    uint8_t chip_id;

    /*< Interface function pointer used to enable the device address for I2C and chip selection for SPI */
    void *intf_ptr;

    /*< Interface Selection
     * For SPI, intf = BME280_SPI_INTF
     * For I2C, intf = BME280_I2C_INTF
     * */
    enum bme280_intf intf;

    /*< Read function pointer */
    bme280_read_fptr_t read;

    /*< Write function pointer */
    bme280_write_fptr_t write;

    /*< Delay function pointer */
    bme280_delay_us_fptr_t delay_us;

    /*< Trim data */
    struct bme280_calib_data calib_data;

    /*< Sensor settings */
    struct bme280_settings settings;

    /*< Variable to store result of read/write function */
    BME280_INTF_RET_TYPE intf_rslt;
};

Das gesamte SetUp sieht dann so aus:

struct bme280_dev dev;
int8_t rslt = BME280_OK;
uint8_t dev_addr = BME280_I2C_ADDR_PRIM;

dev.intf_ptr = &dev_addr;
dev.intf = BME280_I2C_INTF;
dev.read = user_i2c_read;
dev.write = user_i2c_write;
dev.delay_ms = user_delay_ms;

rslt = bme280_init(&dev);

Wenn ich beim Debuggen durch das Programm skippe funktioniert auch alles 
problemlos bis ich diese Funktion aufrufe:

int8_t stream_sensor_data_normal_mode(struct bme280_dev *dev)
{
  int8_t rslt;
  uint8_t settings_sel;
  struct bme280_data comp_data;

  /* Recommended mode of operation: Indoor navigation */
  dev->settings.osr_h = BME280_OVERSAMPLING_1X;
  dev->settings.osr_p = BME280_OVERSAMPLING_16X;
  dev->settings.osr_t = BME280_OVERSAMPLING_2X;
  dev->settings.filter = BME280_FILTER_COEFF_16;
  dev->settings.standby_time = BME280_STANDBY_TIME_62_5_MS;

  settings_sel = BME280_OSR_PRESS_SEL;
  settings_sel |= BME280_OSR_TEMP_SEL;
  settings_sel |= BME280_OSR_HUM_SEL;
  settings_sel |= BME280_STANDBY_SEL;
  settings_sel |= BME280_FILTER_SEL;
  rslt = bme280_set_sensor_settings(settings_sel, dev);
  rslt = bme280_set_sensor_mode(BME280_NORMAL_MODE, dev);

  printf("Temperature, Pressure, Humidity\r\n");
  while (1) {
    /* Delay while the sensor completes a measurement */
    dev->delay_us(5, dev->intf_ptr);
    rslt = bme280_get_sensor_data(BME280_ALL, &comp_data, dev);
    print_sensor_data(&comp_data);
  }

  return rslt;
}

Er springt auch problemlos in die I2C HAL Funktion, landet dann aber 
einen Takt später in der SysTick Funktion und kommt da nicht mehr raus. 
Eine Ausgabe erhalte ich auch nicht obwohl das durch die implementierte 
print Funktion in der oben geschriebenen Funktion eigentlich passieren 
sollte (Wenn das Device was gesendet hat und das empfangen wurde).

[Johannes S. (Gast)]

das kann ja nur funktionieren wenn die HAL mit der erwarteten Signatur 
der I2C Funktionen kompatibel sind, und das sieht nicht so aus.
https://github.com/BoschSensortec/BME280_driver/blob/c47f06eb44fc96970f0abfcc941ec16425b2a9e6/bme280_defs.h#L272

Da sind also Wrapper nötig die diese Argumente nehmen und dann die 
entsprechende HAL Funktion aufrufen.

[Vorname N. (mcu32)]

Johannes S. schrieb:
> Da sind also Wrapper nötig die diese Argumente nehmen und dann die
> entsprechende HAL Funktion aufrufen.

Ok, ergibt Sinn. Leider hab ich sowas noch nie gemacht :/ Wie wäre hier 
jetzt das vorgehen? Grundsätzlich verstehe ich glaube ich schon was das 
Problem ist, allerdings frage ich mich grade wie ich das umsetzen soll.

Auf jeden Fall schonmal vielen Dank :)

[Vorname N. (mcu32)]

Ich glaube ich habs jetzt verstanden. Ich zeige quasi auf eine Funktion 
mit den entsprechenden ÜBergabeparametern wie in der oben genannten 
Definition und rufe dann IN dieser Funktion die eigentliche HAL Funktion 
mit den Parametern auf, richtig?

[Vorname N. (mcu32)]

Ok, also irgendwie klappt das noch nicht so ganz.

Ich habe jetzt folgendes versucht:

bme280.read =  (bme280_read_fptr_t)user_i2c_read;

int8_t user_i2c_read(uint8_t reg_addr, uint16_t len)
{
  int8_t err;
  err = HAL_I2C_Master_Receive(&hi2c2, dev_addr, &reg_addr, len, 50);
  return err;
}

Allerdings KANN das nicht funktionieren. Irgendwie muss ich ja alle 
Parameter aus

typedef BME280_INTF_RET_TYPE (*bme280_read_fptr_t)(uint8_t reg_addr, uint8_t *reg_data, uint32_t len, void *intf_ptr);

and die HAL übergeben. Allerdings hab ich keine Ahnung wie ich das 
machen soll, denn die HAL nimmt nur

HAL_I2C_Master_Receive(I2C_HandleTypeDef *hi2c, uint16_t DevAddress, uint8_t *pData, uint16_t Size, uint32_t Timeout)

Wie soll ich denn die ganzen Parameter da rein bringen ? Die DevAddress 
brauche ich ja weil sich sonst das Slave nicht angesprochen fühlt :/.

[Vorname N. (mcu32)]

Falls irgend jemand hier nochmal drüber stolpern sollte und das selbe 
Problem hat: Ich hab es tatsächlich gelöst :)

Für eine direkte Registeradressierung innerhalb des Slave muss man die 
MemRead /Write Funktionen nehmen. Die Wrapper können dann z.B. so 
ausschauen:

int8_t user_i2c_read(uint8_t reg_addr, uint8_t *reg_data, uint32_t len)
{

    HAL_StatusTypeDef status = HAL_OK;

    //initial value is usually zero
  int32_t iError = BME280_INIT_VALUE;

  uint8_t tempbuff[I2C_BUFFER_LEN] = {BME280_INIT_VALUE};
  uint8_t index = BME280_INIT_VALUE;
  tempbuff[BME280_INIT_VALUE] = reg_addr;

  uint8_t trials = 3;
  uint8_t timeout = 20;

  //check if I2C is ready to use, use the generated i2c instance
  while (HAL_I2C_IsDeviceReady(&hi2c2, dev_addr, trials, timeout) != HAL_OK) {}

    status = HAL_I2C_Mem_Read(&hi2c2,            // i2c handle
                  (uint16_t)(dev_addr<<1),    // i2c address, left aligned
                (uint16_t)reg_addr,      // register address
                (uint16_t)I2C_MEMADD_SIZE_8BIT,      // bme280 uses 8bit register addresses
                tempbuff,      // write returned data to this variable
                (uint16_t)len,              // how many bytes to expect returned
                10);              // timeout

    if (status != HAL_OK)
    {
      // The BME280 API calls for 0 return value as a success, and -1 returned as failure
      iError = (-1);
    }
  for (index = BME280_INIT_VALUE; index < len; index++) {
    *(reg_data + index) = tempbuff[index];
  }

  return (int8_t)iError;
}


int8_t user_i2c_write(uint8_t reg_addr, uint8_t *reg_data, uint32_t len)
{
  HAL_StatusTypeDef status = HAL_OK;

  //initial value is usually zero
  int32_t iError = BME280_INIT_VALUE;

  uint8_t trials = 3;
  uint8_t timeout = 20;


  while (HAL_I2C_IsDeviceReady(&hi2c2, dev_addr, trials, timeout) != HAL_OK) {}

  status = HAL_I2C_Mem_Write(&hi2c2,            // i2c handle
                  (uint16_t)(dev_addr<<1),    // i2c address, left aligned
                (uint16_t)reg_addr,      // register address
                (uint16_t)I2C_MEMADD_SIZE_8BIT,      // bme280 uses 8bit register addresses
                reg_data,    // write returned data to reg_data
                (uint16_t)len,              // write how many bytes
                10);              // timeout

    if (status != HAL_OK)
      {
          // The BME280 API calls for 0 return value as a success, and -1 returned as failure
        iError = (-1);
      }
    return (int8_t)iError;
}

void user_delay(uint32_t us)
{
  HAL_Delay(us);
}

[Harry L. (mysth)]

Warum nutzt du nicht HAL_I2C_Mem_Read_IT & Co?

Macht das Leben sehr viel einfacher...

[hard werker (Gast)]

Harry L. schrieb:
> Macht das Leben sehr viel einfacher...

Mir erschliesst sich bis heute nicht warum man auf einem F103
ein wie auch immer gestaltetes RTOS verwendet um einen popeligen
Sensor zu steuern oder auszulesen. Auch nicht gezeigte Zusatz-
Funktionalität macht es noch nicht plausibel sich den Overhead
eines Betriebssystems auf einen mini kleinen Controller anzutun.

[Hans (Gast)]

hard werker schrieb:
> Mir erschliesst sich bis heute nicht warum man auf einem F103
> ein wie auch immer gestaltetes RTOS verwendet um einen popeligen
> Sensor zu steuern oder auszulesen. Auch nicht gezeigte Zusatz-
> Funktionalität macht es noch nicht plausibel sich den Overhead
> eines Betriebssystems auf einen mini kleinen Controller anzutun.

Vielleicht um wie der TO schrieb

Vorname N. schrieb:
> derzeit ein wenig in die Materie von FreeRTOS einzutauchen

Muss ja nicht immer den "grossen" Sinn machen aber lernen kann man 
daraus und darum geht es anscheinend dem TO.

Ciao Hans

[Vorname N. (mcu32)]

Hans schrieb:
> Muss ja nicht immer den "grossen" Sinn machen aber lernen kann man
> daraus und darum geht es anscheinend dem TO.

Genau so ist es. Das BluePill Board lag hier noch rum und das Thema RTOS 
interessierte mich schon länger :)

[Johnny B. (johnnyb)]

hard werker schrieb:
> Mir erschliesst sich bis heute nicht warum man auf einem F103
> ein wie auch immer gestaltetes RTOS verwendet

Also im Vergleich zu vielen 8-Bit oder 16-Bit Mikrocontroller ist selbst 
ein "popeliger" und steinalter STM32F103 ein Monster und steckt wegen 
des grossen RAM's, Flash und hoher CPU Taktfrequenz den Overhead für 
FreeRTOS locker weg, auch wenn man nur ein paar LED's blinken lassen 
will.

[deutschleera (Gast)]

Johnny B. schrieb:
> des grossen RAM's

Johnny B. schrieb:
> ein paar LED's

Johnny B. schrieb:
> steckt ......... den Overhead für FreeRTOS locker weg

Aber ich steck die Deppenapostrophen nich wech.

http://www.deppenapostroph.info