mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Atmel 32Bit/ARM mit FPU


Autor: Ano Nym (oorim)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Servus

Ich bin derzeit dabei ein AHRS (also eine Art künstlicher Horizont) zu 
entwickeln/bauen.
Da ich mit der Mathematischen Seite recht weit bin möchte ich parallel 
Anfangen mir um die praktische realisierung Gedanken zu machen. Was 
dabei noch fehlt ist eine passende CPU.

Nun war meine Überlegung, dass eine Leistungsfähige CPU mit FPU für die 
Matrixberechnungen und die Signalverarbeitung (Kalman- und ggf. FIR 
Filter) nicht schlecht wäre. Oder liege ich dabei falsch? Eine FPU 
sollte doch in diesem Kontext die genauigkeit erhöhen.

Aber welche nehm ich da? Ich hab mich bei Atmel ein wenig umgesehen (ich 
bin ein wenig Atmel addicted ...) und habe gesehen das es durchaus 32Bit 
mit FPU gibt. Allerdings finde ich bei denen bei den 32bitern keine 
Datenblätter mehr Oo.
Würde ich denn mit einem 32Bit Typ L oder B glücklich werden? Oder gibt 
es einen noch löt- und leistbaren ARM mit FPU von Atmel (ich hab bei den 
ARM nichts zum Thema FPU gesehen).

Ich bin für Ratschläge Dankbar :)

Grüße

Autor: Tropenhitze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um Deine Frage nicht wie gewünscht zu beantworten, es gibt den SH7216 
und den R32C und den RX610. Zwar alle nicht ARM und nicht Atmel sondern 
Renesas, aber mit FPU + Flash + RAM +++ :-)

Autor: Ano Nym (oorim)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erzähl mir mehr davon. Ich mein, ich kann ja auch mal über den 
Tellerrand hinweg sehen.

Was ich vielleicht noch erwähnen sollte: Das Teil sollte gut erhältlich, 
leicht Programmierbar (also ich möchte kein Entwicklungsgerät für 
mehrere 100€ kaufen müssen) und eine günstige und gute Toolchain haben. 
JTAG wäre natürlich Zauberhaft ...

Autor: Tropenhitze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://www.msc-toolguide.com/renesas/tool-family/r...

Das wäre das günstigste Paket. Dazu gibt es einen GCC bei www.kpit.com 
für kostenlos.
Zu höheren Kosten gibt es auch ein SH7216 RSK mit E10A. Der rechnet 
sogar mit double Genauigkeit (64 bit). Bevor Du über die Kosten 
grübelst, warte ab, ob es überhaupt günstigere Alternativen gibt.

Soweit ich weiß, gibt es keinen 'embedded' ARM mit Flash, RAM, IO und 
FPU. Aber ich lerne gerne dazu.

Autor: Ano Nym (oorim)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anders rum gefragt: Welche möglichkeit hab ich denn 
Matrix-Multiplikationen mit besserer Leistung und genauigkeit zu machen 
(auser FPGA und DSP)? Sollte eben noch Löt- und Layoutbar sein. Der 
Renesas sieht noch lötbar aus. Den schau ich mir mal an.
Ein EvalKit kommt halt eigentlich nicht in Frage weil ich ein eigenes, 
kleines Target am zaubern bin.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Anders rum gefragt: Welche möglichkeit hab ich denn
>Matrix-Multiplikationen mit besserer Leistung und genauigkeit zu machen
>(auser FPGA und DSP)? Sollte eben noch Löt- und Layoutbar sein. Der
>Renesas sieht noch lötbar aus. Den schau ich mir mal an.
>Ein EvalKit kommt halt eigentlich nicht in Frage weil ich ein eigenes,
>kleines Target am zaubern bin.

Was muss der uC denn noch so nebenbei machen? Ein Flugzeug
steuern? Oder "nur" das AHRS durchrechnen?
Wie oft muss das pro Sekunde durchgerechnet werden?
Wie gross sind die Matrizen? Sind 32bit ausreichend? Kommt sonst
noch etwas ausser Multiplikationen(Anzahl/s?) und Additionen (Anzahl/s?)
pro Durchlauf dazu?

Wenn ich das Problem pragmatisch angehen müsste, würde ich mir
(als Entwicklungsumgebung) einen günstigen (ARM) NSLU2 auf Ebay
schiessen und mittels einer  Linux-basierten i386-Cross-
entwicklungsumgebung einen Prototypen machen; dann hätte man
wenigstens Durchsatzzahlen an der Hand, über die
man diskutieren könnte.... :-) Ein Ausgangspunkt wie "ich brauche
pro Durchlauf mit a Multiplikationen und b Additionen mit der
Technologie XY und Taktrate Z mit/ohne FPU (z.B.) 100ms und
muss auf 1ms runter", macht die Abschätzung einfach(er).

VG,
Hans

PS: Ein "eigenes Target zaubern" ohne Test in einer vorgelagerten
architekturkongruenten Entwicklungsumgebung ist sehr mutig!

Autor: Ano Nym (oorim)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PS: Ein "eigenes Target zaubern" ohne Test in einer vorgelagerten
architekturkongruenten Entwicklungsumgebung ist sehr mutig!

Wie meinst du das? Mit Target mein ich entsprechend die Platine mit 
Sensorik, µP und kram. Falls das nicht 100% klar war.


Ich kann noch gar nicht richtig abschätzen wieviel ich brauch und 
wieviel nicht. Ich probier aber gerne neues -> deshalb such ich eine 
32Bit CPU ("Datendurchsatz") mit FPU um vergleiche ziehen zu können 
zwischen 8Bit (mega128 zB) und einem 32bit mit/ohne FPU :D

Klingt alles ein bisschen dämlich aber ... ist halt so. Ich möchte das 
sehr viel später irgendwann auch mal auf einen FPGA mit Softcore braten, 
das ist aber Zukunftsmusik.

Die CPU selbst soll in diesem Kontext nur das AHRS berechnen und einen 
Kompass sowie eben die Lage ausgeben. Berechnen tu ich - bis jetzt sieht 
der Plan so aus, die Algorithmik ist noch nicht fertig - über 
Quaternionen und Kalman-Filter.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ano Nym schrieb:
> Nun war meine Überlegung, dass eine Leistungsfähige CPU mit FPU für die
> Matrixberechnungen und die Signalverarbeitung (Kalman- und ggf. FIR
> Filter) nicht schlecht wäre. Oder liege ich dabei falsch? Eine FPU
> sollte doch in diesem Kontext die genauigkeit erhöhen.

Die FPU erhöht nicht die Genauigkeit, sie erhöht nur die Geschwindigkeit 
deutlich bei Floatingpoint-Operationen. Wenn du keine FPU hast, wird die 
Berechnung in SW gemacht, genauso genau, aber eben langsamer.

Es gibt da eine Ausnahme, da du oben irgendwo den Atmega128 angesprochen 
hast. Bei denen wird bei double floating point trotzdem mit single 
precision gerechnet jedenfalls wenn man die Standard AVR Library nutzt. 
Dort würdest du eine höhere Genauigkeit mittels FPU bekommen, da dann 
double presision möglich ist. Allerdings kenn ich keine FPU, die du an 
den AVR klemmen kannst.

Da du die Rechenleistung nicht genau kennst, die du benötigst, würde ich 
mir erstmal ein kleines günstiges ARM-Evalboard kaufen (20€) und da die 
Algorithmen implementieren. Dann kannst du Messungen machen, ob die 
Rechenleistung ausreicht. Wenn nicht, dann nimmst du etwas mit einer 
FPU.
Du kannst z.B ein Cortex-M3 Board (ca. 20€) nehmen. Die haben meistens 
einen Bootloader für die serielle Schnittstelle auf dem Chip. Dazu eine 
kostenlose GNU-Toolchain. Dann kannst du für 20€ alles probieren.
Diese z.B.: http://www.futurlec.com/ET-STM32_Stamp.shtml
Achtung: Preis in $ dort.
Ich habe das Board hier, es ist prima. Der Shop ist auch OK.

Autor: Ano Nym (oorim)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke. Wieder was gelernt. Ich denke mal die Performance von dem STM32 
reicht aus, der wird in dem Kontext auch öfter benutzt. 20€ für das Eval 
Board sind auch cool - seh ich das richtig das ich den dann über RS232 
Programmieren kann? Wenn ja wäre das natürlich noch cooler. Dann werd 
ich das zum Testen nehmen auch wenn ich nicht der Fan von Eval Boards 
bin. 90 MIPS klingt eigentlich so als wenn das kein Problem mit der 
Berechnung haben sollte.

Bezüglich FPU: Wieder was gelernt. Dankeschön! Hatte mich mit der 
Thematik noch nicht richtig befasst und bin jetzt auch schlauer :D

Dann werde ich die Sachen wohl damit Testen.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ano Nym schrieb:
> Danke. Wieder was gelernt. Ich denke mal die Performance von dem STM32
> reicht aus, der wird in dem Kontext auch öfter benutzt. 20€ für das Eval
> Board sind auch cool - seh ich das richtig das ich den dann über RS232
> Programmieren kann? Wenn ja wäre das natürlich noch cooler.

Ja, bei dem Board kannst du über die RS232 Programme flashen.
Hier findest du das Datenblatt, was auf dem Board (oben) verbaut ist.
http://www.st.com/mcu/devicedocs-STM32F103RE-110.html

Das Programm, um vom PC aus Porgramme auf das Ding zu laden, gibt es 
dort auch irgendwo (Stichwort Bootloader).

Ich verwende als Toolchain Codesourcery-Lite, kost nix. Yagarto sollte 
es auch tun, habe aber hier ein paarmal von Problemen bei floating point 
gelesen, weiß aber nicht mehr genau, womit die zusammenhingen. Also ich 
kann grad nicht sagen, ob das Problem bei Yagarto oder zwischen den 
beiden Ohren vor dem Bildschirm bestand ;-)
Du solltest dich dann auch etwas mit Make, GNU-Toolchain u.s.w 
auskennen. Eine "Rundum-Sorglos-IDE" gibt es nämlich nicht dabei. Wenn 
du Geld dafür ausgibst, dann sicher.

Beispiele zum Starten findest du bei Martin Thomas:
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/

Der ist auch immer sehr hilfsbereit, wenn es Probleme gibt (das ist 
jetzt ein verstecktes 'danke schön' an Thomas). Ich bin mit seinen 
Beispielen auch mit dem ARM angefangen. Dann irgendwann Cortex-M3.

Wenn du noch etwas mehr in die Entwicklungsumgebung investieren 
möchtest, dann kostet ein Debug-I/F auch nicht viel. Ca. 60 Euro 
(private none commercial license) für den J-Link von Segger, da ist dann 
auch die SW dabei. Du kannst auch einen Olimex-ARM-JTAG-Key in 
Verbindung mit OpenOCD nutzen (oder auch den Armontec-Key). Ich 
persönlich habe den J-Link hier da er meines Erachtens mehr Freude 
macht. Ein Armontec kostet auch schon 50 Euro (meine ich) und man hat 
die Konfiguration von OpenOCD am Hals, was kein Zuckerschlecken ist.

Edit: Ergänzung... Ein kleines Manko hat das Board. Das JTAG-I/F ist bei 
dem Board nicht auf eine spezielle "JTAG-Stiftleiste" geführt, sondern 
die notwendigen Signale liegen an den langen Stiftleisten. Du mußt dir 
dann einen kleinen Adapter bauen, dann kann man auch über JTAG debuggen 
mit dem Board (hab ich so gemacht)..

Autor: Ano Nym (oorim)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Durch die Stiftleisten brauch ich ja sowieso einen Adapter aber das ist 
kein Problem.

Makfiles versteh ich solangsam, im Moment bin ich auch in einem Projekt 
wo die Makefiles sehr zickig sind. Nervt wie die Sau aber soviel 
versteckte Geheimnisse stecken da scheinbar nicht drin.

Ahm ja. Ich würds erstmal mit dem 20€ Teil probieren und wenn ich merk 
das ist cool setz ich auf JTAG und mehr ;) Dankeschön. Das hilft schon 
mal sehr weiter.

Und ich glaub mit den 90MIPS hab ich auch keine Geschwindigkeitsprobleme 
(hab ich auhc so nicht glaub ich ...)

Dankeschön!

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ano Nym schrieb:
> Dankeschön!

Bitte schön :-)

Als Alternative, weil höherer CPU Takt. Auch schön klein, aber teurer:
http://mbed.org/

Gibt z.B. hier:
http://elmicro.com/de/mbed-nxp-lpc1768.html

Autor: Tropenhitze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Du noch garnicht weißt, was Du letzlich brauchst, erstelle doch ein 
Programm für einen AVR. Das sollte schnell und einfach gehen, wenn erst 
einmal die Rechenroutinen reichen.
Dann kannst Du sehen, ob Dir das reicht oder ob es schneller gehen soll. 
Brauchen Deine Berechnungen eine Beschleunigung um den Faktor 10, dann 
nimm einen ARM.
Wird der Beschleunigungsfaktor 100 benötigt, nimm einen SH7216 :-)

Autor: Ano Nym (oorim)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Zahlreichen antworten.

Ich werde mir erstmal einen Matlab Code erstellen, daraus einen C Code 
und aus dem entstehenden ASM Code berechne ich mir die theoretische Zeit 
die ich zur berechnung brauche. Dann brat ich das vll mal auf einen 
Atmega128 und schau was passiert und mess mit einem Oszilloskop. Unter 
der Vorraussetzung das ich dann noch Student bin oder in meinem 
Praktikum messen darf ...

Dann weiß ich ja was ich brauch und wo es noch klemmt und dann schau ich 
mir die Prozessoren die hier genant wurden noch einmal an. Dankeschön!

Autor: Stefan Kunz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
eine FPU ist bei Berechnungen immernoch langsamer als Berechnungen mit 
ganzen Zahlen (Fix Kommar) ebenso haben floats auch nicht mehr 
Informationsgehalt. Float Zahlen sind einfach nur da um für den Menschen 
vor der Maschine "einfacher" zu rechnen.

Und zu Matlab und C-Code.
Matlab C-Code ist zwar schön aber defenetiv unperformant. Er kann 
höchstens kleinen Anhaltspunkt nehmen.

Ich würd die Berechnungen ohne floats machen, selbst mit FPU bekommt man 
so min. einen Geschwindigkeitsgewinn um Faktor 4.

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Abhaengig von den Anzahl Messungen pro Sekunde koennt ich mir sogar 
vorstellen, einen Mega32 zu verwenden.

Autor: Ano Nym (oorim)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja den C Code tipp ich logischerweise selbst und verwende nicht den 
der aus Matlab kommt ;)

Ich erhöhe aber doch mit Float die Genauigkeit (es ist ja ein 
unterschied zB bei 2*pi ob ich 2*3 oder 2*3,14 oder 2*3,14159 rechne). 
Die FPU macht dann immer noch einen Unterschied in der Geschwindigkeit. 
Int oder gleich Binär rechnen macht das ganze natürlich schneller. (Ja 
man könnte die Float auch Binär zusammenbauen)

Autor: guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zumindest der Zahlenbereich ist bei float größer.
32 bit float erstreckt sich über +-10^38, 32 bit int über +-2^31 und das 
ist schon ein gewaltiger Unterschied. Erst mit 128 bit int kommt man in 
den Bereich von 10^38.
Wenn man viel rechnen muss, wartungsfreundlich programmieren möchte und 
eine FPU hat macht es auch Sinn sie auch zu nutzen weil sie einem ganz 
einfach Arbeit abnehmen kann.

P.S.: Von Atmel sind AVR32 MCs mit FPU angekündigt. Wann die kommen ist 
noch nicht raus, MC mit DSP Befehlen UND FPU klingt aber gut.

Autor: Tropenhitze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>eine FPU ist bei Berechnungen immernoch langsamer als Berechnungen mit
>ganzen Zahlen (Fix Kommar) ebenso haben floats auch nicht mehr
>Informationsgehalt. Float Zahlen sind einfach nur da um für den Menschen
>vor der Maschine "einfacher" zu rechnen.


Eine interessante Aussage, der ich gerne widersprechen möchte. Erzähl 
das einmal einem Physiker :-)

Es geht hier nicht um einen AMD9511 sondern um hochwertige 
Feinelektronik im Jahre 2010. Eine FPU läßt Festkommaschiebereien alt 
aussehen.

Autor: Stefan Kunz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
floats haben trotzdem keinen Mehrwert an Information, der Zahlenbereich 
ist augenwischerei. Daneben sind FPUs trotzdem langsamer in ihren 
Berechnungen.

Auch ein Physiker wird sich davor hüten zusehr auf das Format zu 
vertrauen. Denn was passiert wenn man eine mittelgroße(wertmässig) 
Floatzahl mit einer kleinen (wertmässig) Floatzahl addiert? Grade bei 
sehr kleinen Zahlen sind floats trügerisch.

Autor: Tropenhitze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja ja, die Welt ist böse.
Ich bringe gerade meinem Elefanten das Fliegen bei, damit werde ich dann 
wohl eher Erfolg haben ;-)

Autor: Ano Nym (oorim)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Lage deines Elefanten kannste dann mit meinem AHRS regeln :D

Autor: Stefan Kunz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du verkennst, das 32bit float nur 32bit Informationsgehalt hat. 32bit 
int hat auch nur 32bit Informationsgehalt. Daher bringt float keinen 
Informationsgewinn.
Wie gesagt floats macht die Betrachtungsweise einfacher bringt aber mehr 
Rechenaufwand mit sich. Aber diese Thematik wurde hier schon öfters 
besprochen.

Autor: Ano Nym (oorim)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber es ist doch ein unterschied ob ich 3,14 oder 3 verwende auch wenn 
der Informationsgehalt in Bit der selbe is ...

Autor: Tropenhitze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Die Lage deines Elefanten kannste dann mit meinem AHRS regeln :D

Ich seh' schon, wir kommen ins Geschäft ;-)
Mein Elefant schafft schon 3,14798 mm mit einem Rüsselschlag!

Autor: Ano Nym (oorim)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
xD

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meiner schafft 314798 100000stel.
Passt doch wunderbar in 32 Bit ohne Float.

Autor: Ano Nym (oorim)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es geht doch nicht darumob es reinpasst sondern darum das 3*3,1479 
genauer ist als 3*3 ...

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ano Nym schrieb:
> Danke. Wieder was gelernt. Ich denke mal die Performance von dem STM32
> reicht aus, der wird in dem Kontext auch öfter benutzt. 20€ für das Eval
> Board sind auch cool - seh ich das richtig das ich den dann über RS232
> Programmieren kann? Wenn ja wäre das natürlich noch cooler. Dann werd
> ich das zum Testen nehmen auch wenn ich nicht der Fan von Eval Boards
> bin. 90 MIPS klingt eigentlich so als wenn das kein Problem mit der
> Berechnung haben sollte.

Wenn's zum Testen auf den Preis ankommt, LPCXPRESSO LPC1114 ~20€ von 
NXP.
Vorteil: Wenn man das Target nicht braucht, kann man die Platine teilen 
und benutzt nur den JTAG/SWD-Teil für eigene Targets.
Entwicklungsumgebung ist Eclipse, GCC (inkl optimierter C-Lib)
http://www.embeddedartists.com/products/lpcxpresso...
http://www.embeddedartists.com/products/lpcxpresso...

>
> Bezüglich FPU: Wieder was gelernt. Dankeschön! Hatte mich mit der
> Thematik noch nicht richtig befasst und bin jetzt auch schlauer :D
>
> Dann werde ich die Sachen wohl damit Testen.

Autor: Tropenhitze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und um das mit der Rechengeschwindigkeit zu verdeutlichen, habe ich mal 
die Ausführungszeiten aus dem Datenblatt zum 7216 bei 200MHz Takt 
rausgesucht. Angaben in ns für (float32/double64)

FMUL (5/30), FDIV (50/115), FSQRT (45/110)

Wenn FMUL mit float32 gerechnet einen Takt braucht, wird es mit 
Festkomma Tricksereien nicht schneller gehen können.
Zum Vergleich braucht ein ATmega bei 16MHz ca. 20000ns für FMUL. Um 
wieviel die FPU schneller ist, kann man gerne mit Integer rechnen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.