stm32f4 Probleme mit Sinus funktion

[Oliver F. (ollif)]

Hallo Forum,

ich versuche gerade eine Lookuptable mit Sinuswerten zu füllen.

Benutze System Workbench un ein STM 32F4 Discovery board.

Wenn ich den Folgenden Code aufrufe
...

int sinustable_init(){

  int  i = 0;
  for ( i = 0; i < 255; ++i) {
    sinustable[i] = sin(i);   //geht nicht
    
      }
return i;
}

bricht das Programm ab.

Zum Test habe ich einmal

int sinustable_init(){

  int  i = 0;
  for ( i = 0; i < 255; ++i) {
    sinustable[i] = sin(i);   //geht nicht
    //sinustable[i] = sin(10);      //funktioniert  
      }
return i;
}

probiert und dann wurde das Array mit -0.54402111088936977 gefüllt.


Was mach ich denn hierbei falsch bzw. wie kann ich hier ermitteln an was 
es liegt.
Dies sin(Double) Funktion scheint ja zu funktionieren und alle libs sind 
dann wohl richtig.



Hier nochmal der komplette Code:

#include "stm32f4xx.h"

#include "stm32f4_discovery.h"

#include "stm32f4xx_gpio.h"
#include "stm32f4xx_rcc.h"

#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <float.h>

int sinustable_init();

double sinustable[256];

void Delay(volatile uint32_t nCount)
{
  while(nCount--)
  {
  }
}

int sinustable_init(){

  int  i = 0;
  for ( i = 0; i < 255; ++i) {
    sinustable[i] = sin(i);   //geht nicht
    //sinustable[i] = sin(10);      //funktioniert -0.54402111088936977
      }
return i;
}

void init(void) {
  GPIO_InitTypeDef  GPIO_InitStructure;


  RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOD, ENABLE);


  GPIO_InitStructure.GPIO_Pin = GPIO_Pin_12;
  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT;
  GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
  GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_UP;
  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
  GPIO_Init(GPIOD, &GPIO_InitStructure);
}

int main(void)
{
  SystemInit();
  init();
  sinustable_init();
  while(1) {
    Delay(500000);
    GPIOD->ODR ^= GPIO_Pin_12;
  }
}

Vielen Dank im Voraus.

Gruß

Oliver

[Pd G. (pdg)]

Du denkst schon dran, dass du hier mit Radian rechnest?
Die Sinustabelle hätte also bei 0...255 ca 40.5 Perioden (eine Periode = 
2*Pi).
Eigentlich berechnet man auch nur eine halbe Periode oder sogar nur eine 
viertel Periode und spiegelt diese Teil-Tabellen per Pointer, um 
Speicherplatz zu sparen.

Dann noch das Pre-Increment ++i, das man gelegentlich in Java nimmt. 
Hier hast du es aber mit einer for-Loop in C zu tun und da wird i.d.R. 
Post-Increment i++ verwendet (mach mal eine Grenzwertbetrachtung mit 
i={0|254|255}).

[Embedder (Gast)]

Hi,

wegen dem ++i, mach dir mal keinen Stress. Ganz im Gegenteil soweit ich 
wieß bringt das sogar Performance Vorteile (den genauen Hintergrund 
bekomme ich jetzt nicht mehr hin ohne selbst zu googeln). Grob hat es 
etwas damit zu tun, dass ein Postinkrement den Wert länger vorhalten 
muss als der Präinkrement. Auf keinen Fall entsteht dadurch in diesem 
Kontext aber ein nachteiliges Verhalten.

Ansonsten hat PdG natürlich recht, was möchtest Du denn mit sin(255) 
ausdrücken? Das gäbe ja noch nichtmal als Gradwert einen Sinn...

Rechne mit 2 * PI bzw. wie vorgeschlagen sogar mit Spiegelungen (ich 
denke aber 2 * PI ist in diesem Fall zielführender...).

Viele Grüße!

[Dr. Sommer (Gast)]

Pd G. schrieb:
> Hier hast du es aber mit einer for-Loop in C zu tun und da wird i.d.R.
> Post-Increment i++ verwendet

In C++ ist pre de/in-krement etwas sinnvoller, da uU. effizienter falls 
es kein einfacher Integer Typ ist.

Oliver F. schrieb:
> bricht das Programm ab.

Spezifiziere das mal genauer. Hast du vielleicht einfach nur die FPU 
nicht aktiviert, Code für die falsche FPU generiert (Compiler Optionen), 
oder die falsche C Library gelinkt?

[Dr. Sommer (Gast)]

PS: siehe hier:

https://www.mikrocontroller.net/articles/ARM_GCC#FPU_der_Cortex-M4F_nutzen

[Oliver F. (ollif)]

Hallo,

Inhaltlich habt ihr recht dass die Berechnung über diesen Wertebereich 
keinen Sinn macht. Der Tipp mit

SCB->CPACR |= ((3UL << 10*2)|(3UL << 11*2)); /* set CP10 and CP11 Full Access */

war gold richtig.

Vielen Dank.

Gruß

Oliver

[Optimiert schlechter als gar nicht (Gast)]

Bei billigen Integern und Floats sind selbst bei -O0 die Binarys absolut 
identisch, egal ob Post- oder Preinkrement.(getestet mit gcc 5.3.0 x86 
und ARM)
Mit diesen Pseudooptimierungen verschwendet ihr nur eure Zeit