LL-Treiber I2C STM32L4

[Moot S. (mootseeker)]

Hallo Zusammen,

ich arbeite auf einem STM32L4 Mikrokontroller mit FreeRTOS. Bis anhin 
habe ich für die I2C-Schnittstelle die HAL Library verwendet. Nun musste 
ich aber feststellen, wenn ich viele Daten auslesen will z.B. von einem 
EEPROM werden nicht alle Daten korrekt geladen und die HAL-Funktion 
ergibt 1 zurück für HAL_ERROR.

Nun habe ich in mehreren Foren gelesen, dass dies der HAL-Library 
geschuldet ist, da diese nicht thread tauglich ist.

Nun habe ich versucht, die I2C Schnittstelle in LL-Library zu 
programmieren. Leider ohne Erfolg, ich habe nur Beispiele und 
Anleitungen für den STM32F4 gefunden. Da ST sich natürlich gedacht hat, 
beim STM32L4 soll alles besser gemacht werden, heissen gewisse Register 
anderst, Flags die es beim F4 gibt heissen beim L4 anderst und sind in 
anderen Registern...

Natürlich habe ich es auch selbst mit dem Datenblatt versucht aber da 
habe ich das Problem, dass beim Transmit keine Daten gesendet werden, 
die Funktion hängt beim Check start Bit flag.

// Example for transmit function
int8_t LL_I2C1_Master_Transmit( uint8_t devAddr, uint8_t* buffer, uint16_t len, uint16_t ms )
{
  // Local variables
  uint16_t timeout = 0;

  // Create start condition
  LL_I2C_GenerateStartCondition( I2C1 );

  // Check start Bit flag
  while( !( READ_BIT( I2C1->ISR, I2C_ISR_BUSY )))
  {
    vTaskDelay( 1 );
    if(timeout++ > ms) return -1;
  }

  // Write device Address
  LL_I2C_TransmitData8( I2C1, ( devAddr << 1 | 0x00 ));

  // Wait for address written
  while( !LL_I2C_IsActiveFlag_ADDR( I2C1 ))
  {
    vTaskDelay( 1 );
    if( timeout++ > ms ) return -1;
  }

  // Clear Address flag
  LL_I2C_ClearFlag_ADDR( I2C1 );

  // Check TXE flag & write data
  for( int i = 0; i < len; i++ )
  {
    while( !LL_I2C_IsActiveFlag_TXE( I2C1 ) )
    {
      vTaskDelay( 1 );
      if( timeout++ > ms ) return -1;
    }

    LL_I2C_TransmitData8( I2C1, buffer[ i ] );
  }

  // wait TC flag (TXE flag set & empty DR condition)
  while( !LL_I2C_IsActiveFlag_TC( I2C1 ) )
  {
    vTaskDelay( 1 );
    if( timeout++ > ms ) return -1;
  }

  // stop condition
  LL_I2C_GenerateStopCondition( I2C1 );

  return 0;
}

Bei der Receive Funktion das selbe

// Example for receive function
int8_t LL_I2C1_Master_Receive( uint8_t devAddr, uint8_t *buffer, uint8_t len, uint16_t ms )
{
  // Local varables
  uint16_t timeout;

  // fast NACK configuration when receiving single byte.
  if( len == 1 )
  {
    LL_I2C_AcknowledgeNextData( I2C1, LL_I2C_NACK );
  }
  else
  {
    LL_I2C_AcknowledgeNextData( I2C1, LL_I2C_ACK );
  }

  // start condition
  LL_I2C_GenerateStartCondition( I2C1 );

  // check start bit flag
  while( !( READ_BIT( I2C1->ISR, I2C_ISR_BUSY ) ) )
  {
    vTaskDelay( 1 );
    if( timeout++ > ms ) return -1;
  }

  // write device address (READ)
  LL_I2C_TransmitData8( I2C1, ( devAddr << 1 ) | 0x01 );

  // wait address sent
  while( !LL_I2C_IsActiveFlag_ADDR( I2C1 ) )
  {
    vTaskDelay( 1 );
    if( timeout++ > ms ) return -1;
  }

  // clear ADDR flag
  LL_I2C_ClearFlag_ADDR( I2C1 );

  // check RXNE flag & read data
  for( int i = 0; i < len; i++ )
  {
    // NACK at last byte
    if( i == len - 1 )
    {
      LL_I2C_AcknowledgeNextData( I2C1, LL_I2C_NACK );
    }

    while( !LL_I2C_IsActiveFlag_RXNE( I2C1 ) )
    {
      vTaskDelay( 1 );
      if( timeout++ > ms ) return -1;
    }

    buffer[ i ] = LL_I2C_ReceiveData8( I2C1 );
  }

  // stop condition
  LL_I2C_GenerateStopCondition( I2C1 );

  return 0;
}

Hat jemand ein Beispiel, dass ich mir mal anschauen könnte, oder sieht 
den Fehler in meinen Funktionen?

[Harry L. (mysth)]

Moot S. schrieb:
> Bis anhin
> habe ich für die I2C-Schnittstelle die HAL Library verwendet. Nun musste
> ich aber feststellen, wenn ich viele Daten auslesen will z.B. von einem
> EEPROM werden nicht alle Daten korrekt geladen und die HAL-Funktion
> ergibt 1 zurück für HAL_ERROR.

Da speziell die I²C-Master-Funktionen zu den meist genutzten und best 
erprobten Funktionen in HAL gehören, denke ich, daß das Problem mit an 
Sicherheit grenzender  Wahrscheinlichkeit in deinem Code liegt.

Moot S. schrieb:
> Nun habe ich in mehreren Foren gelesen, dass dies der HAL-Library
> geschuldet ist, da diese nicht thread tauglich ist.

Sorry, aber das ist vollkommener Blödsinn!
Wenn verschiedene Tasks die selbe I²C-Schnitstelle für unterschiedliche 
Peripherie nutzen, musst du die natürlich gegeneinander verriegeln.
Das hat aber rein gar nichts mit "Thread-safe" zu tun.

[Moot S. (mootseeker)]

Die HAL-Library ist mit ihren unendlichen HAL Delays überhaupt nicht 
RTOS tauglich.

Natürlich habe ich die Schnittstelle mit einem Mutex geschützt, auch 
wenn nur ein Task mit dieser Schnittstelle arbeitet.

Mit den übertriebenen asserts ist die Library auch sehr langsam und 
benötigt unnötig viel Speicher.

Naja genug HAL-Hate...

Ich möchte die LL-Libray verwenden beim L4.

[Harry L. (mysth)]

Moot S. schrieb:
> Die HAL-Library ist mit ihren unendlichen HAL Delays überhaupt nicht
> RTOS tauglich.

Unfug!
In den HAL-Funktionen wird HAL_Delay praktisch nirgendwo verwendet.
Bei preemptiven FreeRTOS ist es zudem egal, und bei kooperativen RTOS 
nutzt man eben osDelay.

Moot S. schrieb:
> Mit den übertriebenen asserts ist die Library auch sehr langsam und
> benötigt unnötig viel Speicher.

Wieder so eine Aussage die von völliger Unkenntnis zeugt...

Moot S. schrieb:
> Ich möchte die LL-Libray verwenden beim L4.

Dann musst du das eben lernen!

[Moot S. (mootseeker)]

Harry L. schrieb:
> Unfug!
> In den HAL-Funktionen wird HAL_Delay praktisch nirgendwo verwendet.
> Bei preemptiven FreeRTOS ist es zudem egal, und bei kooperativen RTOS
> nutzt man eben osDelay.

Ich glaube du hast dich noch nie mit der HAL-Library tiefer beschäftigt.

Nur schon die Init Funktion von I2C in HAL hat 8 Asserts, jedes assert 
braucht unnötig Speicher und Zeit. Hier ein Aussschnitt:

/**
  * @brief  Initializes the I2C according to the specified parameters
  *         in the I2C_InitTypeDef and initialize the associated handle.
  * @param  hi2c Pointer to a I2C_HandleTypeDef structure that contains
  *                the configuration information for the specified I2C.
  * @retval HAL status
  */
HAL_StatusTypeDef HAL_I2C_Init(I2C_HandleTypeDef *hi2c)
{
  /* Check the I2C handle allocation */
  if (hi2c == NULL)
  {
    return HAL_ERROR;
  }

  /* Check the parameters */
  assert_param(IS_I2C_ALL_INSTANCE(hi2c->Instance));
  assert_param(IS_I2C_OWN_ADDRESS1(hi2c->Init.OwnAddress1));
  assert_param(IS_I2C_ADDRESSING_MODE(hi2c->Init.AddressingMode));
  assert_param(IS_I2C_DUAL_ADDRESS(hi2c->Init.DualAddressMode));
  assert_param(IS_I2C_OWN_ADDRESS2(hi2c->Init.OwnAddress2));
  assert_param(IS_I2C_OWN_ADDRESS2_MASK(hi2c->Init.OwnAddress2Masks));
  assert_param(IS_I2C_GENERAL_CALL(hi2c->Init.GeneralCallMode));
  assert_param(IS_I2C_NO_STRETCH(hi2c->Init.NoStretchMode));

Harry L. schrieb:
> Dann musst du das eben lernen!

Was für eine blöde aussage... genau deswegen schriebe ich ja diesen 
Beitrag!

[Harry L. (mysth)]

Moot S. schrieb:
> Ich glaube du hast dich noch nie mit der HAL-Library tiefer beschäftigt.

"Glauben" ist nicht "wissen" ;-)

Ich arbeite seit Jahren mit HAL und hab so machen Code zu dem Thema hier 
im Forum veröffentlicht. (Suchen kannst du sicher selber)

Moot S. schrieb:
> Nur schon die Init Funktion von I2C in HAL hat 8 Asserts, jedes assert
> braucht unnötig Speicher und Zeit.

Ja und?
Zeit (wenige µs) braucht das genau 1 mal während der Initialisierung, 
und, wenn du die wenigen Byte Flash nicht hast, hast du eben den 
falschen Chip gewählt.
Ich möchte auf diese Tests jedenfalls nicht verzichten.

Moot S. schrieb:
> Was für eine blöde aussage... genau deswegen schriebe ich ja diesen
> Beitrag!

Achso....und so glaubst du, das zu lernen?
Dazu gibts reichlich Doku von ST, aber, da du dich ja hier als absoluter 
"überflieger" präsentierst, gehe ich davon aus, daß du die auch selbst 
findest.

Ich hab jedenfalls keine Lust mehr, dir zu helfen.

[J. S. (jojos)]

Zeige doch mal wieviel Code die asserts erzeugen. Wieviel Zeit an 
Fehlersuche du damit sparen kannst hast du nicht verstanden.

[Moot S. (mootseeker)]

Harry L. schrieb:
> Ja und?
> Zeit (wenige µs) braucht das genau 1 mal während der Initialisierung,
> und, wenn du die wenigen Byte Flash nicht hast, hast du eben den
> falschen Chip gewählt.
> Ich möchte auf diese Tests jedenfalls nicht verzichten.

Ja das ist im Init irrelevant das stimmt, aber nicht z.B. in der 
Transmit Funktion. Da werden aus diesen us schnell ms bis s die reichen 
das Timeouts überschritten werden. Wenn man die Funktion immer wieder 
aufrufen muss.

Wenn man im Speicher begrenzt ist, muss man halt sparen wo man kann. 
Gerade bei Bastel-Projekten wo man nicht einfach auf den nächst 
grösseren 256KB MCU wechseln kann.

Das schweift aber auch vom eigentlichen Problem ab...

Harry L. schrieb:
> Achso....und so glaubst du, das zu lernen?
> Dazu gibts reichlich Doku von ST, aber, da du dich ja hier als absoluter
> "überflieger" präsentierst, gehe ich davon aus, daß du die auch selbst
> findest.

Als Überflieger würde ich mich nicht bezeichnen, aber +/- verstehe ich 
schon was ich machen möchte. Ich arbeite auch nicht seit gestern mit 
diesen Kontrollern. In 98 von 100 Projekten arbeite ich auch mit HAL. 
Hin und wieder gibt es aber Projekte wo es nicht passt wie hier mit dem 
RTOS.

Harry L. schrieb:
> Ich hab jedenfalls keine Lust mehr, dir zu helfen.

Geholfen hast du ja eh nicht, somit ist mir das eigentlich egal.


Meine Frage war ja eigentlich... Ich habe einen Code geschrieben mit 
Hilfe der Doku von ST, aber aus irgend einem Grund wird das BUSY Flag 
nicht gesetzt, bzw. ich habe nicht verstanden ob das BUSY flag das 
richtige ist, das ausgelesen werden muss nach dem erstellen der Start 
Condition...

[Harry L. (mysth)]

Moot S. schrieb:
> aber nicht z.B. in der
> Transmit Funktion. Da werden aus diesen us schnell ms bis s die reichen
> das Timeouts überschritten werden. Wenn man die Funktion immer wieder
> aufrufen muss.

Offenbar hast du dir stm32f4xx_hal_i2c.c noch nie im Detail angeschaut.
Deine Aussage ist einfach nicht wahr.
Und, wenn du die Funktion ständig aufrufen musst, so, daß sowas 
überhaupt einen nachweisbaren Effekt hätte, ist dein Konzept eben 
vollkommener Murks.

Dabei Sekunnden zusammen zu fantasieren zeugt nur von totalem 
Unverständnis dieses Codes.

Moot S. schrieb:
> Wenn man im Speicher begrenzt ist, muss man halt sparen wo man kann.
> Gerade bei Bastel-Projekten wo man nicht einfach auf den nächst
> grösseren 256KB MCU wechseln kann.

Wieder so eine typische Anfänger-Fehleinschätzung!
Wenn der Code aller Assert-Funktionen zusammen 200-300Byte belegt ist 
das bereits viel, und das fällt bei den Speichergrößen der üblichen 
L4-Chips absolut nicht ins Gewicht.

Für nicht genutzten Speicher gibts eben kein Geld zurück.