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
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 +++ :-)
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 ...
http://www.msc-toolguide.com/renesas/tool-family/rsk/renesas-starter-kit-plus-for-rx610.html 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.
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.
>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!
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.
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.
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.
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)..
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!
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
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 :-)
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!
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.
Abhaengig von den Anzahl Messungen pro Sekunde koennt ich mir sogar vorstellen, einen Mega32 zu verwenden.
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)
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.
>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.
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.
ja ja, die Welt ist böse. Ich bringe gerade meinem Elefanten das Fliegen bei, damit werde ich dann wohl eher Erfolg haben ;-)
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.
Aber es ist doch ein unterschied ob ich 3,14 oder 3 verwende auch wenn der Informationsgehalt in Bit der selbe is ...
>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!
Meiner schafft 314798 100000stel. Passt doch wunderbar in 32 Bit ohne Float.
Es geht doch nicht darumob es reinpasst sondern darum das 3*3,1479 genauer ist als 3*3 ...
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/lpc1114_xpr.php http://www.embeddedartists.com/products/lpcxpresso/lpc1343_xpr.php > > 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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.