STM32F4: Datenübertragung extrem langsam

[Daniel V. (voda)]

Guten Abend liebes Forum,

seit einiger Zeit habe ich Probleme mit einem ADNS3090.

Dieser IC ist normalerweise ein Maussensor und ich möchte diesen für 
eine Optical-Flow-Messung einsetzen. Der Sensor hat folgende 
bildtechnische Merkmale:

Pixelanzahl:  30 x 30 x 8 Bit CMOS (7200 Bit = 900 Byte)
Framerate:    max. 6469 fps
eingestellt:  2000 fps

Laut Datenblatt (S.20, Figure 4) müssen folgende Register eingestellt 
werden um die Pixeldaten auszulesen:

Schreibe im Register 0x13 (ADNS3090_FRAME_CAPTURE) den Wert 0x83
Warte 3 Frames + 10 ms (2000 fps/s -> 500 µs * 3 + 10ms  = 1510 ms)

Folgendes habe ich ebenfalls eingestellt:

SPI-Takt: 1,25 MHz
USART: 256000 Baud

Diese Funktion sieht so aus:

void adns3090_FrameCapure_Config(void)
{
  ADNS3090_NSS_LOW;
    delay_ns(121);
    adns3090_Write(SPI2,ADNS3090_FRAME_CAPTURE|0x80);
    delay_ns(1);
    adns3090_Write(SPI2,0x83);
    delay_ns(1); 
   ADNS3090_NSS_HIGH;
   delay_nms(1510);
}

Die Bilddaten (insgesamt 1536 Werte) können nun über das 
Pixel_Burst-Register 0x40 ausgelesen werden. Hier meine 
Funktionsimplementierung, zu Figure 24 auf Seite 20 des Datenblattes:

uint8_t adns3090_Pixel_Burst(uint8_t *image)
{
  adns3090_FrameCapure_Config();
  
  ADNS3090_NSS_LOW;
  adns3090_Read(SPI2, ADNS3090_PIXEL_BURST);
  delay_nms(50/1000);
  
  for (i=0; i<900;)
  {
    register_val = adns3090_Read(SPI2,0xFF);
    delay_nms(10/1000);
   
    if(start==0)
    {
     if (register_val&0x40)
     {
      start = 1;
     }
      else
      {
       TimeOut++;
       if(TimeOut==100)
       {
        reset = -1;
        break; 
       }   
     }
    }
    
    if(start==1)
    {
     image[i++] = (register_val<<2);
    }
  }
  ADNS3090_NSS_HIGH;
  delay_nms(14/1000);
  return reset;
}

In der Main rufe ich dann folgendes auf:

int main (void)
{
 uint8_t picture[1536];
 int image_data;
 
 startUp();                  /*Controllerinitialisierung*/
 USART_config();             /*Usart*/
 bma020_SPI_SETTINGS();      /*Beschleunigungssensor*/
 adns3090_STARTUP();         /*ADNS3090-Inititialisierung*/
 SysTick_Init();   
 
  while(1)
    {    
      SystemCoreClockUpdate();
      adns3090_Pixel_Burst(picture);
      
      for (int n=0; n<900; n++)
      {
       image_data = picture[n];
       USART_SendData(USART3,image_data);
      }
    }
}

Der Sensor und somit auch die Datenübertragung über die USART ist jedoch 
extrem langsam (16 Byte/s). Normalerweise habe ich eine viel höhere 
Geschwindigkeit erwartet. Warum tröpfeln die Daten vor sich hin?

Kann mir jemand einen Tipp geben?

Vielen Dank und Gruß
Daniel

[Stefan K. (stefan64)]

Was ist das für ein Uart und wie ist der eingestellt:
USART_SendData(USART3,image_data);

256000 Baud ist ja nicht so die Standard-Baudrate, ist das ein CDC-USB?
Ist wirklich (16 Byte/s) gemeint oder eher picture/s?

Mit welchem Programm empfängst Du?

Gruß, Stefan

[Rufus Τ. F. (rufus)]

Daniel V. schrieb:
> delay_nms(14/1000);

Was macht diese Funktion, und was macht sie, wenn ihr 0 übergeben wird?

Denn genau das machst Du hier: 14 / 1000 ist 0.

[holger (Gast)]

SystemCoreClockUpdate();

Es reicht wenn du das einmal machst.

    delay_nms(10/1000);

10/1000 ergibt 0!

Was macht deine Funktion wenn du 0 übergibst?

[Daniel V. (voda)]

Hi Stefan,

Stefan K. schrieb:
> Was ist das für ein Uart und wie ist der eingestellt:
> USART_SendData(USART3,image_data);

/*USART-Schnittstelle */
USART_InitTypeDef USART_InitStructure;    
USART_InitStructure.USART_BaudRate            = 256000;
USART_InitStructure.USART_WordLength          = USART_WordLength_8b;
USART_InitStructure.USART_StopBits            = USART_StopBits_1;
USART_InitStructure.USART_Parity              = USART_Parity_No;
USART_InitStructure.USART_HardwareFlowControl = USART_HardwareFlowControl_None;
USART_InitStructure.USART_Mode        = USART_Mode_Rx | USART_Mode_Tx;
USART_Init(USART3, &USART_InitStructure);
USART_Cmd(USART3,ENABLE);

Stefan K. schrieb:
> 256000 Baud ist ja nicht so die Standard-baudrate, ist das ein CDC-USB?
> Ist wirklich (16 Byte/s) gemeint oder eher picture/s?

Auf der Platine habe ich einen FTDI verbaut.

Stefan K. schrieb:
> Mit welchem Programm empfängst Du?

In HTerm tröpfeln die Daten herein.

Rufus Τ. F. schrieb:
> Was macht diese Funktion, und was macht sie, wenn ihr 0 übergeben wird?

delay_nms(10/1000);

Dies ist meine Wartefunktion in ms (10/1000) = 0,001 ms.

Ich habe W.S.s- Konzept noch nicht implementiert:
Beitrag "STM32F4: SysTick etwas ungenau"

Danke und Gruß
Daniel

[Rufus Τ. F. (rufus)]

Daniel V. schrieb:
> Dies ist meine Wartefunktion in ms (10/1000) = 0,001 ms.

Das ist einerseits eine interessante Rechnung (ich würde ja 0.010 ms 
erwarten), aber trotzdem 0.
Deine Wartefunktion bekommt tatsächlich einen float -Wert übergeben?

Das ist ... gelinde gesagt ineffizient.

Und 10 / 1000 ist ein int - Ausdruck, der ist konstant 0.

Wolltest Du 0.001 erzeugen, müsstest Du eine float -Division 
durchführen,

also "wait_nms(10.0 / 1000.0)" verwenden.

Auch wenn das 'ne Konstante ist: Keine gute Idee. Benenne die Funktion 
um in wait_microsec() und übergebe ihr einen int, also hier 10.

[Uhrmacher (Gast)]

> Dies ist meine Wartefunktion in ms (10/1000) = 0,001 ms.

Wenn (und falls) ich annehme, dass die Division, egal aus welchem 
Zahlenbereich Dividend und Divisor kommen, eine reale Zahl oder auch 
rationale Zahl ergeben, dann stimmt das im Bereich der Mathematik.

Allerdings stimmt das auch in C nicht grundsätzlich. Analog zu Werte- 
und Bildmenge in der Mathematik gibt es hier "Datentypen". Auch wenn in 
der Mathematik häufig vorkommende Werte- und Bildmengen oft nicht 
angegeben werden, so ist das weder in der Mathematik noch in C, - und 
dort schon gar nicht -, formal richtig.

Das steht alles in den C-Büchern bzw. spätestens in den Standards.

Wenn Du ein C-Integer durch ein C-Integer dividierst, dann ist das 
Ergebnis wieder ein Integer (übrigens eines mit Vorzeichen und nicht 
implizit grösser oder gleich Null).
Selbst wenn nicht, - es gibt da gewisse Mittel, zu denen vor allem 
eine korrekte Datentyp-Angabe zählt, eine Fliesskomma-Division zu 
erzwingen -, dann würde ein dem Sinne nach erwartetes float oder double 
Ergebnis spätestens durch den Funktionsparametertyp auf ein Integer 
implizit gecasted .

Du musst Dich also entscheiden, in welchem Zahlenbereich (Datentyp) Du 
das delay angeben willst und die Entscheidung muss zu der Auflösung und 
den Grenzen passen, in denen Du die Dauer der Verzögerung nennen willst.

[Daniel V. (voda)]

Du hast vollkommen recht. Ich habe gerade die Quick&Dirty-Lösung 
"wait_nms(10.0 / 1000.0" implementiert. Leider keine Besserung, Ich 
triggere mit meinem Oscar am Clock-Signal. Auch hier aktualisiert sich 
das Oscarbild alle 1 s und läuft synchron so der Aktualisierung bei 
HTerm.

Sende ich in der while-Schleife einen Teststring auf die USART:

sendText("Es tut mir Leid, Dave, aber das kann ich nicht tun. \n");

rennt alles.

[holger (Gast)]

>Ich habe gerade die Quick&Dirty-Lösung
>"wait_nms(10.0 / 1000.0" implementiert.

Dann zeig den Kram doch mal. Ist das denn so schwer?

[Rufus Τ. F. (rufus)]

Daniel V. schrieb:
> Ich habe gerade die Quick&Dirty-Lösung "wait_nms(10.0 / 1000.0"
> implementiert.

Zeig doch bitte mal den Quelltext von wait_nms.

[Uhrmacher (Gast)]

Oscar in der Tonne, vielleicht.

[Uhrmacher (Gast)]

Meine Glaskugel sagt: wait_nms(<integer type>)

"Oscar" - meine Güte.

[Daniel V. (voda)]

Rufus Τ. F. schrieb:
> Daniel V. schrieb:
>> Ich habe gerade die Quick&Dirty-Lösung "wait_nms(10.0 / 1000.0"
>> implementiert.
>
> Zeig doch bitte mal den Quelltext von wait_nms.

Gerne:

delay.c

#include <delay.h>

static __IO uint32_t sysTick_zaehler;

void SysTick_Init(void)
{
 while (SysTick_Config(SystemCoreClock/1000000) != 0)
 {
 }
}

void timer_Decrement(void)
{
  if (sysTick_zaehler != 0x00)
  {
   sysTick_zaehler--;
  }
}

void delay_ns(uint32_t n)
{
 sysTick_zaehler = n;
  while (sysTick_zaehler != 0) 
  {
  }
}

void delay_ms(void)
{
 sysTick_zaehler = 1000;
  while (sysTick_zaehler != 0) 
  {
  }
}

void delay_nms(uint32_t n)
{
  while (n--)
  {
   delay_ms();
  }  
}

und die dazugehörige Header:

#ifndef DELAY_H
 #define DELAY_H
  
#include <stm32f4xx.h>  

extern void SysTick_Init(void);
extern void timer_Decrement(void);
extern void delay_ns(uint32_t n);
extern void delay_ms(void);
extern void delay_nms(uint32_t n);
#endif

[Uhrmacher (Gast)]

Schön. Und zeigst Du uns jetzt BITTESCHÖN die Implementierung von 
wait_nms? DANKESCHÖN.

[Daniel V. (voda)]

Die wait_nms() heißt delay_nms() daher habe ich einfach

delay_nms(10.0/1000.0);

ausprobiert. Die Funktion siehe oben.

Auch habe ich die Funktion delay_ns(5000) für 5 µs ausprobiert. Selbes 
Fehlerbild.

Danke und Gruß
Daniel

[Rufus Τ. F. (rufus)]

Daniel V. schrieb:
> void delay_nms(uint32_t n)
> {
>   while (n--)
>   {
>    delay_ms();
>   }
> }

Diese Funktion wartet die Anzahl der übergebenen millisekunden, 
vorausgesetzt, daß delay_ms funktioniert.

Der Wert ist ein Ganzzahlwert. Ein Integer. Da kann man keine Brüche, 
keine Nachkommastellen etc. angeben.

> static __IO uint32_t sysTick_zaehler;

Der scheint wohl irgendwo in einem Interrupthandler verändert zu werden. 
Da Du darauf auch von außerhalb des Interrupthandlers zugreifen willst, 
musst Du diese Variable als volatile deklarieren, weil sonst der 
Compiler beim Übersetzen Deiner Funktionen davon ausgeht, daß die 
Variable sich nie ändert - und damit die Zugriffe wegoptimiert.

[holger (Gast)]

__IO entspricht volatile.
Da wollte ein ganz schlauer bei STM nur wieder was neues erfinden.

[Uhrmacher (Gast)]

[MOD: unsachliches Lamento gelöscht]

WAS ERGIBT 10.0 durch 1000.0 gecasted auf eine Integer-Typ? Das kann 
doch nicht so schwer sein.

Ich bin raus.

[Daniel V. (voda)]

So, ich habe mal den LA drangehängt und die im Datenblatt geforderten 
Zeiten stimmen überein.

Es sind ja pro Frame 900 Werte. Diese sind ja auch da, man kann diese 
auch sehen, nur das innerhalb der Zeit werden nur 16 Byte/s übertragen. 
Der Rest wandert ins Datennirwana. Die Division habe ich nun 
herausgenommen und habe mit der ns-Delayfunktion die entsprechende Zeit 
eingegeben.

Kann das sein, das ich irgendwas übersehen habe in der Figure 28?

Danke euch und Gruß
Daniel

[aSma>> (Gast)]

Daniel V. schrieb:
> while (SysTick_Config(SystemCoreClock/1000000) != 0)

Ich habe dir schon in den anderen Thread gesagt, dass das Unfug ist!
Dafür dass man delay_us selten braucht, verbraucht das bei dir sehr viel 
an Leistung.

[Nop (Gast)]

holger schrieb:
> __IO entspricht volatile.
> Da wollte ein ganz schlauer bei STM nur wieder was neues erfinden.

nein, es gibt auch noch __I, welches im Unterschied zu __IO nämlich 
"const volatile" entspricht. Das ist schon nicht blöd, daß man den 
Schreibzugriff auf reine Leseregister schon per Compiler abwehrt. 
Außerdem ist das auch nicht von ST, sondern das entstammt dem CMSIS von 
ARM.

Der Rest stimmt aber.

[Nop (Gast)]

Daniel V. schrieb:

void adns3090_FrameCapure_Config(void)
{
  ADNS3090_NSS_LOW;
    delay_ns(121);
    adns3090_Write(SPI2,ADNS3090_FRAME_CAPTURE|0x80);
    delay_ns(1);
    adns3090_Write(SPI2,0x83);
    delay_ns(1);
   ADNS3090_NSS_HIGH;
   delay_nms(1510);
}

Also außer dem Tipfehler im Funktionsnamen fällt mir auf, daß Deine 
ganzen Delays dort offenbar in ns sind - außer das letzt, das ist in ms. 
1500ms wären aber immerhin schon 1.5 Sekunden. Sicher, daß das so sein 
soll?

[holger (Gast)]

>ganzen Delays dort offenbar in ns sind

Nein, es sind n x µs;) Der Name der Funktion ist nur
schlecht gewählt.

[Daniel V. (voda)]

aSma>> schrieb:
> Ich habe dir schon in den anderen Thread gesagt, dass das Unfug ist!

Hab ich gelesen und ich schrieb auch im Thread, das ich diese Lösung 
implementieren muss. Den Thread habe ich hier ja auch verlinkt und nicht 
aus den Augen verloren.

Nop schrieb:
> Also außer dem Tipfehler im Funktionsnamen fällt mir auf, daß Deine
> ganzen Delays dort offenbar in ns sind - außer das letzt, das ist in ms.
> 1500ms wären aber immerhin schon 1.5 Sekunden. Sicher, daß das so sein
> soll?

Das ist komplett richtig. Heute Morgen beim Aufwachen ist mir dies auch 
als erstes eingefallen. Laut Datenblatt soll t_Capture die Länge von 
drei Frames + 10 µs betragen. Ich habe 2000 fps eingestellt, also 
beträgt die Zeit für ein Frame 0,0005 s was 500 µs also 1510 µs 
entsrpicht. Hier sind es 1,51 s, was man im LA auch sehen kann.

Was mich auch stutzig macht, die Daten liegen ja komplett im Register 
und auch auf den Bus.

Ich werde mir erstmal eine neue Delayfunktion schreiben müssen. Bin halt 
selber noch ein (Berufs-)Anfänger.

[EDIT]
aSma>> schrieb:
> Ich habe dir schon in den anderen Thread gesagt, dass das Unfug ist!

Jau, im anderen Thread hast Du es schon geschrieben. Durch die Zählung 
ist der Controller bereits ausgelastet, so kann er die Daten zwar noch 
lesen und auf den Bus legen, aber er schafft es nicht weiter auf die 
USART, weil die Kapazitäten fehlen. Richtig?

[aSma>> (Gast)]

Daniel V. schrieb:
> Jau, im anderen Thread hast Du es schon geschrieben. Durch die Zählung
> ist der Controller bereits ausgelastet, so kann er die Daten zwar noch
> lesen und auf den Bus legen, aber er schafft es nicht weiter auf die
> USART, weil die Kapazitäten fehlen. Richtig?

Mit Verlaub, ja freilich. Eine ISR mit 1Mhz bei ca. 80Mhz Takt ist 
unschlau. Register sichern, Waitstates & Co da bleibt nicht viel übrig.

Dies klärt man aber besser im anderen Thread.

[Rufus Τ. F. (rufus)]

holger schrieb:
> Nein, es sind n x µs;) Der Name der Funktion ist nur
> schlecht gewählt.

Das ist neu.

Daniel V. schrieb:
> void delay_nms(uint32_t n)
> {
>   while (n--)
>   {
>    delay_ms();
>   }
> }

Da wird delay_ms aufgerufen.

Oder sollen das etwa Microsekunden sein?

Dann tu Dir und uns einen Gefallen und hör' mit dem Blödsinn auf, 
solche irreführenden Funktionsnamen zu verwenden.

[Daniel V. (voda)]

Rufus Τ. F. schrieb:
> Dann tu Dir und uns einen Gefallen und hör' mit dem Blödsinn auf,
> solche irreführenden Funktionsnamen zu verwenden.

Du hast zu 100% Recht. Ich habe diese Timergeschichte aus irgendeinem 
belgischen Blog "geklaut". Im Nachbarthread werde ich morgen die Idee 
von WS und den anderen versuchen zu verstehen, zu bearbeiten und zu 
implementieren.

Rufus Τ. F. schrieb:
> Da wird delay_ms aufgerufen.
>
> Oder sollen das etwa Microsekunden sein?

Millisekunden.

[holger (Gast)]

>Da wird delay_ms aufgerufen.
>Oder sollen das etwa Microsekunden sein?

Nein, delay_ms ist schon ok, aber delay_ns macht nicht
was man anhand des Namens erst einmal denkt.