Problem mit I²C (CubeMX)

[Harry L. (mysth)]

Hallo,
ich hab ein sehr seltsames Problem mit den I²C-Funktionen des 
HAL-Library.
Ich nutze den DMA-Mode für die I²C-Schnittstelle.
An der Schnittstelle hängt ein 0,96" Oled-Display mit einem SSD1306.
Pullup-Widerstände (1k2 bei 3,3V) sind auch bestückt.
Das Board ist ein MapleMini mit ST32F103C8-CPU.

Der Transfer selbst ist auch gar kein Problem, und bevor ich ein neues 
Datenpaket absende, überprüf ich zunächst mit "HAL_I2C_GetState (&hi2c1) 
== HAL_I2C_STATE_READY" ob der Buffer frei ist.

Das funktioniert so auch, und die Initialisierung läuft auch wie 
erwartet.

In der Initialisierung läuft das noch geblockt, und ich warte vor jedem 
Transfer darauf, daß der Treiber READY liefert.

Die Funktion void oled_worker() wird bei jedem Durchlauf der main-loop 
einmal aufgerufen, und bei jedem Aufruf wird für eine Row im Display 
(128 Byte entspr. 8 Zeilen zu 128Pixel) geprüft, ob sich was am 
Pufferinhalt geändert hat, und ggf. der Transfer über I²C angestossen 
(max 128 Byte + 7 Befehlsbyte).

Vor dem eigentlichen Senden prüfe ich wieder ob der Puffer frei ist.
Wenn das nicht der Fall ist, wird die Funktion beendet, (non-blocking) 
und beim nächsten Aufruf wiederholt sich das Spiel bis der Puffer frei 
ist.

Jetzt wirds allerdings spannend:
Wenn ich mir bei dem diesem Transfer-Kommando (ziemlich am Ende der 
Datei) einen Breakpoint setze, und dann manuell fortsetze, läuft es wie 
erwartet, aber wenn ich das Programm einfach starte, wird Müll auf dem 
Display ausgegeben.

Es hat etwas Mühe gekostet, das Problem auf genau diesern Punkt 
einzugrenzen.

Wenn ich -testweise- nach dem Send-Command ein HAL_delay() einfüge muß 
das Delay min. 4 sein (zw. 3 und 4ms) damit das Programm fehlerfrei 
läuft.
Wenn ich das Delay auf 3 stelle (zw. 2 und 3ms), kommen wieder falsche 
Zeichen.
Der Transfer einer Zeile dauert ca. 2,7ms, was sich mit dieser Wartezeit 
deckt.

Ich vermute also, daß das Send-Kommand bereits aufgerufen wird, obwohl 
noch ein Transfer läuft.

Ist es möglich, daß HAL_I2C_GetState() mir falsche Daten liefert, oder 
hab ich irgendwas übersehen?

Harry

/*
 * oled_worker.c
 *
 *  Created on: 17.04.2016
 *      Author: harry
 */

#include <string.h>
#include <stdlib.h>
#include "stm32f1xx_hal.h"
#include "oled.h"
#include "needle.h"

#define  OLED_IDLE  0
#define  OLED_UPD_PAGE  1
#define  OLED_UPD_LINE  2
#define  OLED_NEEDLE_MOV  3
#define  OLED_VAL_CHG  4
#define OLED_LINE_PREF  5

#define NEEDLE_IDLE  0
#define NEEDLE_UPDATE  1
#define NEEDLE_
//#define  OLED_
//#define  OLED_

#define WRK_STAT_IDLE  0
#define WRK_STAT_UPDATE  1
#define WRK_STAT_UPD_LINE  2
#define WRK_STAT_UPD_COL 3
//#define WRK_STAT_
//#define WRK_STAT_

static const uint8_t OledInit[] =
  { 0x80, 0xae,    // turn off oled-display
      0x80, 0xd5,0x90,  // set display clock divide ratio/oscillator frequency
      0x80, 0xa8,0x3f,  // set multiplex ratio(1 to 64)
          // 1/64 duty
      0x80, 0xd3,0,00,  // set display offset
      // not offset
      0x80, 0x8d,0x14,  // set Charge Pump enable/disable
      0x80, 0x40,  // set start line address
      0x80, 0xa6,  // set normal display
      0x80, 0xa4,  // Disable Entire Display On
      0x80, 0xa1,  // set segment re-map 128 to 1
      0x80, 0xc8,  // Set COM Output Scan Direction 64 to 1
      0x80, 0xda,0x12,  // set com pins hardware configuration
      0x80, 0x81,0xf1,  // set contrast control register
      0x80, 0xdb,0x40,  // set vcomh
      0x80, 0xaf  // turn on oled panel

    };

uint8_t oled_state;
uint8_t oled_page;
uint8_t needle_last_val;
uint8_t needle_val;
uint8_t needle_state;
uint8_t worker_state;
uint8_t update_request;
uint8_t needle_pos = 0;


uint8_t cmd_buf[6];


#define MAX_CMD_LEN  7
#define PREFIX_LEN  7
#define SET_OLED_ADR(page,col)  oline_buf.cmd[1]= 0xb0 | page; \
        oline_buf.cmd[3] = (col >> 4) | 0x10; \
        oline_buf.cmd[5] = col & 0x0f;

uint8_t oled_buf[8][0x80];


struct
{
  uint8_t cmd[MAX_CMD_LEN];
  uint8_t line[0x80];
  uint8_t l;
  uint8_t r;
  uint8_t size;
} oline_buf;

void
oled_init (void)
{
  uint8_t i, j;
  HAL_Delay (1000);
  while (HAL_I2C_GetState (&hi2c1) != HAL_I2C_STATE_READY)
    ;
  HAL_I2C_Master_Transmit_DMA (&hi2c1, OLED_ADR, OledInit, sizeof(OledInit));
  oline_buf.cmd[0] = oline_buf.cmd[2] = oline_buf.cmd[4] = 0x80;
  oline_buf.cmd[6] = 0x40;
worker_state = WRK_STAT_IDLE;

  // clear PicBuf
  for (j = 0; j < 0x80; j++)
    {
      oline_buf.line[j] = 0x00;
    }

  for (i = 0; i < 8; i++)
    {
      for (j = 0; j < 0x80; j++)
  {
    oled_buf[i][j] = 0x00;
  }
      while (HAL_I2C_GetState (&hi2c1) != HAL_I2C_STATE_READY)
  ;
      SET_OLED_ADR(i, 0);
      HAL_I2C_Master_Transmit_DMA (&hi2c1, OLED_ADR, oline_buf.cmd, 128 + PREFIX_LEN);
   }
}

void
oled_worker (void)
{
  uint8_t i, j, q;
  static uint8_t lc;

  switch (worker_state)
    {
    case WRK_STAT_IDLE:
      if (lc > 7)
  {
    lc = 0;
  }

      oline_buf.l = 0x80;
      oline_buf.r = 0;
      oline_buf.size = 0;

      q = 0;
      for (j = 0; j < 128; j++)
  {
    if (q == 0)
      {
        if (lc < 6)  // Needle only in top 6 rows!
    {
      if (oled_buf[lc][j]
          != (PicBuf[lc][j] & needle_buf[lc][j]))
        {
          oline_buf.l = j;
          q = 1;
          i = 0;
        }
    }
        else
    {
      if (oled_buf[lc][j] != PicBuf[lc][j])
        {
          oline_buf.l = j;
          q = 1;
          i = 0;
        }
    }
      }
    if (q == 1)
      {
        if (lc < 6)  // with meter-mask
    {
      if (oled_buf[lc][j]
          != (PicBuf[lc][j] & needle_buf[lc][j]))
        {
          if (j > oline_buf.r)
      {
        oline_buf.r = j;
      }
        }
          oled_buf[lc][j] = oline_buf.line[i++] = PicBuf[lc][j]
        & needle_buf[lc][j];
    }
        else
    {
      if (oled_buf[lc][j] != PicBuf[lc][j])
        {
          if (j > oline_buf.r)
      {
        oline_buf.r = j;
      }
        }
          oled_buf[lc][j] = oline_buf.line[i++] = PicBuf[lc][j];
    }
      }
  }

      if (oline_buf.l != 0x80)  // line needs some update
  {
    oline_buf.size = oline_buf.r - oline_buf.l + 1;
    worker_state = WRK_STAT_UPD_LINE;
  }
      else  // advance to next line
  {
    lc++;
  }

      break;

      /*
       *
       */

    case WRK_STAT_UPD_LINE:
      if (HAL_I2C_GetState (&hi2c1) == HAL_I2C_STATE_READY)
  {
    SET_OLED_ADR(lc,oline_buf.l);
    HAL_I2C_Master_Transmit_DMA (&hi2c1, OLED_ADR, oline_buf.cmd,
               oline_buf.size + PREFIX_LEN);

/*
 * Wenn ich hier 4ms Delay einfüge, läuft alles
 */
    HAL_Delay(4);
    oline_buf.l = 128;
    oline_buf.r = 0;
    lc++;    // advance to next line
    worker_state = WRK_STAT_IDLE;

  }
      break;
    }
}

[NACK (Gast)]

Kann es sein, dass du dem DMA über seine Daten trampelst wärend er noch 
läuft und deshalb das delay einen heilenden Effekt hat?

Entweder sehe ich es nicht, aber für mich schaut es so aus, als ob 
oline_buf... beim nächsten Aufruf von oled_worker geschrieben wird bevor 
getested wird ob der DMA noch aktiv ist.

Gruß

[fop (Gast)]

Dazu müsste man die Daten auf dem Bus mal sehen. Was ich auch schon 
hatte, sind IC's deren Schnittstelle schneller ist als ihre interne 
Logik. Sprich es kann auch sein, dass das Display 0,3 ms benötigt, um 
die Daten, die vom I2C herein kamen zu verdauen.

[Harry L. (mysth)]

NACK schrieb:
> Kann es sein, dass du dem DMA über seine Daten trampelst wärend er noch
> läuft und deshalb das delay einen heilenden Effekt hat?

Ja, danach sieht es aus, aber es gibt keine weiteren I²C-Aufrufe im 
übrigen Programm.

Ich hab das Programm bereits auf die oben gezeigten Funktionen 
reduziert.
Es wird garantiert an keiner anderen Stelle geschrieben.

fop schrieb:
> Dazu müsste man die Daten auf dem Bus mal sehen. Was ich auch schon
> hatte, sind IC's deren Schnittstelle schneller ist als ihre interne
> Logik. Sprich es kann auch sein, dass das Display 0,3 ms benötigt, um
> die Daten, die vom I2C herein kamen zu verdauen.

Das hab ich mir angeschaut, und ja, es ist so, daß zu früh gesendet 
wird.
Aber warum?
Das würde bedeuten, daß die HAL_I2C_GetState nicht richtig funktioniert.
Es geht auch nicht um 0,3ms, sondern um min. 3 ms, was darauf hindeutet, 
daß ich bereits sende, während die Schnitstelle noch aktiv ist.
Harry

[NACK (Gast)]

Harry L. schrieb:
> Ja, danach sieht es aus, aber es gibt keine weiteren I²C-Aufrufe im
> übrigen Programm.

Ja schon, aber oled_worker selbst könnte im nächsten Zyklus über die 
Daten schreiben die noch nicht komplett gesendet wurden. Probier doch 
mal
"if (HAL_I2C_GetState (&hi2c1) == HAL_I2C_STATE_READY)" direkt am Anfang 
zu testen bevor du irgendwas in oled_worker machst.

[Harry L. (mysth)]

oled_worker() -am Ende- ist aber der einzige Ort, an dem ich auf das 
I²C-Subsystem zugreife.
Natürlich könnte ich direkt am Anfang prüfen, aber genau da wollte ich 
das ja nicht, da an der Stelle die meiste Rechenzeit gebraucht wird (der 
Vergleich der Puffer) und das kann wunderbar geschehen, während bereits 
ein Transfer läuft.

Harry

[NACK (Gast)]

Harry L. schrieb:
> oled_buf[lc][j] = oline_buf.line[i++] = PicBuf[lc][j]
>         & needle_buf[lc][j];

Ich habe jetzt nicht versucht die ganze Logik nachzuvollziehen, aber 
kann es sein, dass du den Puffer hier schon "wieder" beschreibst, 
während noch ein Transfer läuft?

Ansonsten, probier doch einfach mal den Test an den Anfang zu schieben 
und schau obs dann ohne delay geht.

Nur so

[Harry L. (mysth)]

NACK schrieb:
> Ich habe jetzt nicht versucht die ganze Logik nachzuvollziehen, aber
> kann es sein, dass du den Puffer hier schon "wieder" beschreibst,
> während noch ein Transfer läuft?


Oh Mann!


Das wars!


Manchmal ist man einfach betriebsblind

Herzlichen Dank!

Da muss ich wohl mit 2 alternierenden Puffern arbeiten.

Harry

[NACK (Gast)]

Prost! :)