Sinusfunktion mit FPU

[HalliGalli (Gast)]

Hi,
muss ich für einen Mikrocontroller mit FPU etwas berücksichtigen, wenn 
ich einfach nur den Sinus berechnen möchte? Verwende einen 
Cross-Compiler.

Leider liegt keine Math-Library vor. Mehr weiss ich im Moment nicht.

Danke.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

HalliGalli schrieb:
> muss ich für einen Mikrocontroller mit FPU etwas berücksichtigen

Bloss nicht sagen, was es für einer ist - das gibt immer viel Spass beim 
Raten.

[Jacko (Gast)]

Haste dem Cross-Compiler auch nicht gesagt, von welchem
System (mit/ohne FPU) auf welches System mit FPU du was
basteln willst?

Dann freu dich auf die Fehlermeldungen...

[C. A. Rotwang (Gast)]

Matthias S. schrieb:
> HalliGalli schrieb:
>> muss ich für einen Mikrocontroller mit FPU etwas berücksichtigen
>
> Bloss nicht sagen, was es für einer ist - das gibt immer viel Spass beim
> Raten.

Hm, gibt es soviele µC mit Floating Point?
Es ist ja nicht von DSP die Rede, und von den üblichen Verdächtigen 
fällt mir grad nur der ARM ein in Bezug auf FPU.

[A.. P. (arnonym)]

C. A. Rotwang schrieb:
> Hm, gibt es soviele µC mit Floating Point?
> Es ist ja nicht von DSP die Rede, und von den üblichen Verdächtigen
> fällt mir grad nur der ARM ein in Bezug auf FPU.

Und alle hier im Forum haben immer den aktuellsten Marktüberblick über 
Controller mit FPU oder was? Selbst wenn's nur zwei gäbe: soll man 
rumraten, welchen dieser beiden der TO wohl vor sich liegen hat oder 
sollen hier zwei Lösungsansätze parallel gefahren werden? Und wenn er 
nun einen der unüblichen Unverdächtigen im Einsatz hat? Mach doch mal 
den Anfang…

[asdfasd (Gast)]

Man braucht man keine FPU, um nen Sinus zu berechnen. Mit geht es 
höchstens schneller.

[C. A. Rotwang (Gast)]

A.. P. schrieb:
> C. A. Rotwang schrieb:
>> Hm, gibt es soviele µC mit Floating Point?
>> Es ist ja nicht von DSP die Rede, und von den üblichen Verdächtigen
>> fällt mir grad nur der ARM ein in Bezug auf FPU.
>
> Und alle hier im Forum haben immer den aktuellsten Marktüberblick über
> Controller mit FPU oder was?

Wer keinen aktuellen Blick über die FPU's hat sollte bei diesem Thread 
die Klappe halten.

[Hmm (Gast)]

C. A. Rotwang schrieb:
> Matthias S. schrieb:
>> HalliGalli schrieb:
>>> muss ich für einen Mikrocontroller mit FPU etwas berücksichtigen
>>
>> Bloss nicht sagen, was es für einer ist - das gibt immer viel Spass beim
>> Raten.
>
> Hm, gibt es soviele µC mit Floating Point?
> Es ist ja nicht von DSP die Rede, und von den üblichen Verdächtigen
> fällt mir grad nur der ARM ein in Bezug auf FPU.

Mir eigentlich nur der PIC32MZ.
Also das derivat mit Floating point unit:
http://ww1.microchip.com/downloads/en/DeviceDoc/60001358C.pdf

Was das Problem angeht, kann man dazu nur sagen:
Es kommt auf die Auflösung an, die du brauchst. Ich bin bisher mit 8bit 
ausgekommen, und dafür tut es eine in Excel berechnete Tabelle. Man muss 
nur von 0-90° berechnen, der Rest ist eh immer das gleiche (nur 
gedreht).

[Guest (Gast)]

HalliGalli schrieb:
> muss ich für einen Mikrocontroller mit FPU etwas berücksichtigen, wenn
> ich einfach nur den Sinus berechnen möchte?

Ja, schon. Du musst auch etwas beruecksichtigen wenn du eine Strasse 
ueberqueren oder dir ein Butterbrot schmieren willst. Was genau brauchst 
du?

HalliGalli schrieb:
> Leider liegt keine Math-Library vor. Mehr weiss ich im Moment nicht.

Dann ist es vielleicht ein wenig frueh fuer die Frage hier. Nichts desto 
trotz, soviel sei gesagt:

Ohne math lib gubt es keine sin(.) Funktion die du aufrufen kannst. Das 
ist schlecht fuer dich. Musst also selber schreiben, unter verwendung 
nur der einfachen Operatoren +,-,*. Ueblicherweise macht man dafuer eine 
Tailorapproximation um die 0. Dabei faellt jeder zweite term weg (cos(0) 
= 0) und du kannst mit wenigen Koeffiziennten sehr genau rechnen. Du 
musst dann noch deine Eingabeparameter ins Intervall (-pi/2, pi/2] 
wrappen und den rest ueber die entsprechenden Transformationen 
ausrechnen. Denk daran, die FPU calls fuer die Rechnungen zu nutzen.

[PittyJ (Gast)]

Ich verwende auch einen Cross-Compiler. Under der Sinus wird korrekt 
berechnet. Du mußt gar nichts beachten.

[Guest (Gast)]

Guest schrieb:
> (cos(0) = 0)

Der Rest vom Post sollte mehr wahrheiten enthalten ;)

[C. A. Rotwang (Gast)]

Hmm schrieb:
> C. A. Rotwang schrieb:
>> Matthias S. schrieb:
>>> HalliGalli schrieb:
>>>> muss ich für einen Mikrocontroller mit FPU etwas berücksichtigen
>>>
>>> Bloss nicht sagen, was es für einer ist - das gibt immer viel Spass beim
>>> Raten.
>>
>> Hm, gibt es soviele µC mit Floating Point?
>> Es ist ja nicht von DSP die Rede, und von den üblichen Verdächtigen
>> fällt mir grad nur der ARM ein in Bezug auf FPU.
>
> Mir eigentlich nur der PIC32MZ.
> Also das derivat mit Floating point unit:

Da ja diese FPU wie die von ARM dem selben Standard IEEE 754 ist Frage 
nach dem Hersteller m.E. völlig überflüssig. Und die Frage nach single 
oder double Precision ist nicht gestellt.
--
> Ueblicherweise macht man dafuer eine Tailorapproximation um die 0.
Ich bezweifle das man bei Mikrocontrollern gleich von üblich in Bezug 
auf Taylorreihenentwicklung sprechen kann. LUT sollte in der Verbreitung 
Taylor mindestens ebenbürtig sein und CORDIC wird auch oft gegenüber 
Taylor wegen der schnelleren Konvergenz bevorzugt.

[Rene. K (Gast)]

Hmm schrieb:
> Mir eigentlich nur der PIC32MZ.

Nunja, eigentlich auch sämtliche anderen Cortex-M4 / M7  etc...

[Axel S. (a-za-z0-9)]

C. A. Rotwang schrieb:
> Hmm schrieb:
>> C. A. Rotwang schrieb:
>>> Matthias S. schrieb:
>>>> HalliGalli schrieb:
>>>>> muss ich für einen Mikrocontroller mit FPU etwas berücksichtigen
>>>>
>>>> Bloss nicht sagen, was es für einer ist - das gibt immer viel Spass
>>>> beim Raten.
>>>
>>> Hm, gibt es soviele µC mit Floating Point?
>>> Es ist ja nicht von DSP die Rede, und von den üblichen Verdächtigen
>>> fällt mir grad nur der ARM ein in Bezug auf FPU.
>>
>> Mir eigentlich nur der PIC32MZ.
>> Also das derivat mit Floating point unit:
>
> Da ja diese FPU wie die von ARM dem selben Standard IEEE 754 ist Frage
> nach dem Hersteller m.E. völlig überflüssig.

Keineswegs. Bei den Cortex-M kann die FPU z.B. den Sinus direkt 
berechnen, aber nur für float. Wenn man jetzt dieses unschuldige 
Progrämmchen betrachtet:

float r= 1.234;
float s= sin(r);

dann wird man erstaunt feststellen, daß der Compiler nicht die FPU 
verwendet, sondern r zu einem double casted, die Sinus-Funktion aus 
der libm aufruft und das Ergebnis von double wieder zurück nach 
float casted. Und das alles deswegen, weil sin() double erwartet (und 
liefert) die FPU aber nun mal nur float kann [1]. Bei einer anderen 
Architektur hätte das womöglich anders ausgesehen. Sogar schon bei einem 
anderen ARM Prozessor wie Cortex-A oder -R.

Korrekt hätte man für obiges Programm besser sinf() verwendet.


> Ich bezweifle das man bei Mikrocontrollern gleich von üblich in Bezug
> auf Taylorreihenentwicklung sprechen kann. LUT sollte in der Verbreitung
> Taylor mindestens ebenbürtig sein und CORDIC wird auch oft gegenüber
> Taylor wegen der schnelleren Konvergenz bevorzugt.

Für den reinen Anwender ist das Wurst. Die Funktionen sin() & Co. sind 
ebenso wie die libm ein standardisierter Bestandteil der Sprache C. 
Deswegen wird man sie auch benutzen. Was der Lieferant der C-Toolchain 
dann implementiert hat, ist in den wenigsten Fällen von Belang. Und wenn 
doch, dann schaut man genau dann erst nach.


[1] 
http://support.raisonance.com/content/how-should-i-use-floating-point-unit-fpu-cortex 
(und an anderen Orten)

[Mampf F. (mampf)]

Axel S. schrieb:
> Und das alles deswegen, weil sin() double erwartet (und
> liefert) die FPU aber nun mal nur float kann [1].

Ja stimmt ... Das ist mir beim arbeiten mit der FPU auch schon 
aufgefallen.

Es gibt eine einfache Lösung: sinf() zu verwenden :)

Aber daran muss man erstmal denken^^

[A.. P. (arnonym)]

C. A. Rotwang schrieb:
> Wer keinen aktuellen Blick über die FPU's hat sollte bei diesem Thread
> die Klappe halten.

Und wer anderen nur zeigen möchte, was für ein Held er in diesem Bereich 
sein möchte, hat trotzdem nicht das Recht, anderen die Meinung zu 
verbieten. Man kann in einem Thread auch helfen, OHNE "den aktuellen 
Blick über die FPU's zu haben".

[HalliGalli (Gast)]

...nur mal angenommen es wäre IEEE754 single precision. Sind dafür 
public Libs verfügbar?

[W.S. (Gast)]

HalliGalli schrieb:
> Leider liegt keine Math-Library vor. Mehr weiss ich im Moment nicht.

Da bist du aber arm dran.

Hättest du hier im Forum mal nach ner Sinusberechnung gesucht, wärest du 
auch fündig geworden. Entweder du suchst mal nach CORDIC oder nach 
Pedersen.

W.S.

[Axel S. (a-za-z0-9)]

HalliGalli schrieb:
> ...nur mal angenommen es wäre IEEE754 single precision. Sind dafür
> public Libs verfügbar?

Was gefällt dir nicht an der Lib, die bei deinem Compiler sowieso
dabei ist? Denn einen C-Compiler wirst du ja wohl haben ...

[HalliGalli (Gast)]

Axel S. schrieb:
> Was gefällt dir nicht an der Lib, die bei deinem Compiler sowieso
> dabei ist? Denn einen C-Compiler wirst du ja wohl haben ...

das weiss ich jetzt noch nicht ehrlich gesagt. Sind die denn alle 
unterschiedlich und hw spezifisch?

[Johann L. (gjlayde)]

HalliGalli schrieb:
> Axel S. schrieb:
>> Was gefällt dir nicht an der Lib, die bei deinem Compiler sowieso
>> dabei ist? Denn einen C-Compiler wirst du ja wohl haben ...
>
> das weiss ich jetzt noch nicht ehrlich gesagt.

Wenn du einen Compiler hast, aber nich nichma weisst ob es ein 
C-Compiler ist...

> Sind die denn alle unterschiedlich und hw spezifisch?

Ja, unterschiedliche Compiler sind unterschiedlich, und wenn die 
unterschiedliche Zielplattformen haben ist das Resultat HW-spezifisch.

ABer wenn es ein C/C++ Compiler ist, dann hält er sich an den 
Sprachstandard.  Und da gehört sin() dazu.

[Hoppla (Gast)]

HalliGalli schrieb:
> das weiss ich jetzt noch nicht ehrlich gesagt. Sind die denn alle
> unterschiedlich und hw spezifisch?

... jetzt wird's langsam trollig obwohl der Freitag
schon vorbei ist.

[HalliGalli (Gast)]

klar sind compiler hw spezifisch, jetzt sprechen wir von libs.

Johann L. schrieb:
> ABer wenn es ein C/C++ Compiler ist, dann hält er sich an den
> Sprachstandard.  Und da gehört sin() dazu.

...bezogen auf makronamen math.h oder auch implementierung sin.c?

[Axel S. (a-za-z0-9)]

HalliGalli schrieb:
> klar sind compiler hw spezifisch, jetzt sprechen wir von libs.

Libs enthalten Maschinencode (ja gut, Objectcode; für unsere Zwecke das 
gleiche). Wie sollen die nicht hardwarespezifisch sein?

> Johann L. schrieb:
>> ABer wenn es ein C/C++ Compiler ist, dann hält er sich an den
>> Sprachstandard.  Und da gehört sin() dazu.
>
> ...bezogen auf makronamen math.h

HÄH? "math.h" ist der Name eines Includefiles. Hast du schon jemals eine 
einzige Zeile C geschrieben?

> oder auch implementierung sin.c?

Standardisiert sind der Funktionsname sowie Anzahl und Typ der Parameter 
und Typ des Returnwerts. Die Implementierung kann jeder Hersteller eines 
C-Compilers (respektive der dazugehörigen Libs) nach Gusto machen.

$ man 3 sin

SIN(3)            Linux Programmer's Manual           SIN(3)

NAME
       sin, sinf, sinl - sine function

SYNOPSIS
       #include <math.h>

       double sin(double x);
       float sinf(float x);
       long double sinl(long double x);

       Link with -lm.
...

CONFORMING TO
       C99, POSIX.1-2001.  The variant returning double also
       conforms to SVr4, 4.3BSD, C89.