Hallo zusammen, ich habe mal eine Frage zur Leistungsfähigkeit von FPGAs! Also ich habe bisher mit AVRs rum gespielt und das hat auch alles sehr gut geklappt! Eigentlich wollte ich als nächstes mal mit ARM anfangen nur was immer mehr mein Interesse weckt sind halt FPGAS. Was für mich sehr schwer abzuschätzen ist und was ich auch nirgends finde ist wieviel man in so ein Ding reinkriegt! Also um es konkret zu machen überlege ich einem FPGA das fliegen bei zubringen ;) also wie das http://www.mikrokopter.de/ Projekt. Reicht da ein Pluto Board aus??? Von Atmel gibt es ja auch die AVR mit integriertem FPGA, dazu finde ich nix an Projekten etc an denen man lernen kann. Dazu dann noch die Frage wer hat schon mal ein AVR Software Core in den FPGA gesteckt (gibt es bei Opencores), und mal wieder wie groß (Logik gatter) muss das Ding dann sein. Bin für alle Infos dankbar und auch links wo ich mich dann selbst schlauer mach sind willkommen! :) Gruß Jan
Warum willst Du unbedingt einen FPGA benutzen, wenn ein kleiner Mikrocontroller bereits ausreicht? Das macht das Ganze nur komplizierter und anfälliger, nicht besser. Es gibt genügend Anwendungsfälle, wo man quasi zwingend einen FPGA braucht. Such Dir doch sowas aus, das macht dann sicher mehr Spaß. Markus
Für mich ist das ganze Thema Elektronik mehr oder weniger nur Hobby, und daher wäre es für mich sehr interessant halt mal mit nem FPGA zu arbeiten! Und da die bei dem beschriebene Projekt ja insgesamt 5 µC benutzen halte ich ein FPGA für ne alternative. Den Anspruch das es besser werden soll habe ich gar nicht, mir geht es einzig und allein darum was zulernen und spaß dabei zuhaben. Was ist denn deiner Meinung nach etwas wo man eine FPGA zwingend braucht? Jan
@ Jan (Gast) >Und da die bei dem beschriebene Projekt ja insgesamt 5 µC benutzen halte >ich ein FPGA für ne alternative. Den Anspruch das es besser werden soll Was soll das den werden? 5uC? >Was ist denn deiner Meinung nach etwas wo man eine FPGA zwingend >braucht? Wo grosse Datenmengen möglichst fix verarbeitet werden müssen. Mbytes bis Gbyts/s. Oder dutzende PWMs. Irgendwelche SDRAM Controller, graphische LCD Controller, SPI-Parallel Wandler etc. MFG Falk
Jan wrote: > Für mich ist das ganze Thema Elektronik mehr oder weniger nur Hobby, und > daher wäre es für mich sehr interessant halt mal mit nem FPGA zu > arbeiten! Klar, das ist hier bei vielen so. Aber dann macht es nicht so viel Sinn, in den FPGA einen MC zu packen. Da lernst Du nicht so viel über FPGAs. > Und da die bei dem beschriebene Projekt ja insgesamt 5 µC benutzen halte > ich ein FPGA für ne alternative. Den Anspruch das es besser werden soll > habe ich gar nicht, mir geht es einzig und allein darum was zulernen und > spaß dabei zuhaben. Aber dafür fehlen Dir die A/D-Wandler. > Was ist denn deiner Meinung nach etwas wo man eine FPGA zwingend > braucht? Mein Favorit ist Oversampling: Man hat eine verrauschte Messung, die man oft wiederholen kann und z.B. 1000 Messwerte vom A/D-Wandler benötigt. Zur Verbesserung des Rauschabstandes macht man die Messung 256x hintereinander und addiert die Werte. Wenn der A/D-Wandler 50MSPS hat, dann sind das 50 Millionen Additionen und noch mehr Speicherzugriffe pro Sekunde. Mit sowas kann man auch relativ große Mikrocontroller schnell plätten. Es ist von der Logik her aber eher primitiv und damit ideal für einen FPGA geeignet. Anwendungsfall sind z.B. Laserentfernungsmesser. Ansonsten bietet sich z.B. Videosignalerzeugung (z.B. VGA) an. Das ist auch eher primitiv, aber man hat hohe Datenraten und es muss die ganze Zeit etwas getan werden. Auch Bildverarbeitung/-erkennung kann man auf FPGAs ganz gut machen, allerdings werden da auch gerne DSPs genommen, weil die leichter und schneller zu programmieren sind. Markus
FPGAs braucht man bei wirklich zeitkritischen Anwendungen, wo es um ns geht. Für alles Andere gibt es µC oder DSP.. FPGAs kommen von der Gesamtkomplexität nicht an die Möglichkeiten mit einer CPU heran...
Von den FPGAs gibt es auch beliebig viele Ausfuehrungen. Die kleineren nennen sich CPLD und sind mit EEPROMzellen versehen. Dh sie arbeiten ab powerup so wie sie programmiert sind. Die FPGA sind SRAM Basier und haben heute eine flash. Das bedeutet in einem bootprozess wird die Flash information vom flash in das SRAM geladen. Das kann bis 400ms dauern. Erst dann arbeitet das Device wie es programmiert wurde. Ein vernuenftiges CPLD hat bis 256 makrozellen mehr wird sehr teuer. Eine Makrozelle ist ein Flipflop plus eine Lookup table fuer logische operationen. Mit einem CPLD hat man im Wesentlichen einen Satz Zaehler und Register. Damit kann man beliebig schnelle Timings erzeugen resp. bearbeiten. Ei FPGA startet ab einigen Tausend Makrozellen, hat also viel mehr Moeglichkeiten. Zu beachten sind die Definitionen, auch beim Strombverbrauch. Ein Haupthersteller, zB geht von 15% benutzter Gatter aus. Schreibt das auch so fuer die, die's auch lesen. Wenn dann 100mA bei XX MHz spezifiziert sind, bedeutet das, dass es auch 700mA bei Vollauslastung sein koennen. Toll, wenn die Speisung gerade mal auf 150mA designt wurde. Ein AVR und ein CPLD/FPGA ergaenzen sich sehr gut.
>>FPGAs kommen von der Gesamtkomplexität nicht an die Möglichkeiten mit >>einer CPU heran... Kannst du das bitte erläutern, was du damit sagen willst? Ich finde super, dass du freiwillig FPGAs lernen willst. Es ist ein Interessantes Thema. Und wenn du dich einließt, fallen die all die Möglichkeiten auf. Aber klar, viele Projekte sind vom Aufwand her mit einem µC schneller gemacht. Außer es geht um viel Leistung, die parallel erbracht werden muss.... Dafür gibt es keine µCs. FPGAs senden mittlerweile 10G Daten, die µCs fühlen sich mit 9600 Baud wohl, wenn du weißt, was ich meine.
Damit meine ich, wenn man die GESAMTkomplexität einer Baugruppe betrachtet, also Hardware und Software, kann man mit CPUs mehr erreichen, als mit einem FPGA... oder würdest Du einen PC komplett mit OS und Applikationen in einem FPGA realisieren? FPGAs haben ihre Berechtigung bei harten Realtime-Anforderungen.
Für ein Flugobjekt ist ein FPGA nicht zu gebrauchen. Er frisst zu viel Strom. Alle Zellen auch unbenutzt Gater vergeuden Energie. Da ist ein ARM schon stromsparender. Ich habe den Sprung vom AVR auch zum ARM gemacht, und es war schon ein ganzer Sprung. Man muss sich daran gewöhnen, dass es nicht mehr ein umfassendes Datenblatt gibt. Die Datenblätter für die AVRs sind sehr übersichtlich. Beim ARM gibt es für den CORE das Datenblatt. Beim Chip Hersteller das Datenblatt für die Peripherie. Und dann hat man noch ein Einsteigerboard, wo die Dokumentation auch nicht ganz vollständig ist. an Markus Kaufmann, du benutzt Oversampling in FPGAs zur Laserentfernungsmessung. Hast du dazu ein paar Infos? Welche Größe wird gemessen? Um eine Entferungsmessung im cm Bereich durch Laufzeit zu erfassen, muss man in den ps Bereich. Mit 50MHz wird es da sicher noch sehr knapp. Oder hasst du eine sehr hohe ADC Auflösung?
Hallo, also schon mal danke an alle für die antworten! Was ich jetzt das erstmal höre ist das die FPGAs so viel Strom brauchen! Dann macht es wirklich keinen Sinn ein Softcore zu benutzen. Aber die Verbindung von µC und FPGA wird dann immer wahrscheinlicher. Kann mir jemand bei der Abschätzung der große helfen, wenn ich folgendes machen möchte. (Nur noch mal kurz, es soll ja ein flugobjekt wie http://www.mikrokopter.de/ werden) @ Falk Brunner Die benutzen 5 µC: 1 macht die ganze flugsteuerung und 4 stück sind ein gesetzt als motorcontroller für die bldc motoren. Ich würde mir die Aufteilung jetzt so vorstellen: Der AVR (vielleicht auch ARM) übernimmt die flugsteuerung und der fpga soll dann die Motorsteuerung aller 4 motoren übernehmen. Sowie die Messwertaufnahme und Vorverarbeitung. Im einzelnen bedeutet das: Motorsteuerung: Erkennung der Umschaltpunkt der 3 phasen der motoren und die Regelung der PWM für die Leistung. Ganz schick wäre wenn ich dem FPGA eine soll Drehzahl vorgebe, die er dann selbst einregelt. (Sollte ja ein Problem sein, oder?) Messsignale: Also man braucht wenigstens schon mal 6 "relativ" schnelle Analogkanäle für die Gierraten und die Beschleunigen in allen Raum-Axen. Die sollen dann auch schon gefiltert etc werden (so wie vorgeschlagen Einsatz eines FPGA :) ). Muss ich nochmal den Ordner für Digital Filter hervorkramen. ;) Ich habe mal etwas rum geschaut und das hier gefunden: http://www.knjn.com/board_Xylo.html wäre beides schon drauf ;), aber welche ausbau stufe muss ich nehmen, ich hätte jetzt mal auf "Saxo-L FPGA + ARM board" getippt. Was für ein A/D Wandler gibt es denn der leicht an ein FPGA zu hängen ist, ich wollte ja nicht einen per SPI dran hängen das macht für mich keinen Sinn! (Ich schau gleich mal wenn jemand aber schon was weiß .... ;) Gruß Jan
Die analogen Messkanaele fuer die Positionsmessung sind nicht ganz so schnell. Ein Beschleunigungssensor macht hechstens 100Hz, dh man ist mit einem kilosample locker dabei. Der Einsatz eines FPGA bringt wahrscheinlich nichts.
@René: Ein ARM ist eine full-fledged RISC-CPU, ein AVR ein µC... das ist Äpfel mit Birnen vergleichen. @Jan: Ich sehe immer noch nicht die Notwendigkeit für ein FPGA... es sei denn, man will unbedingt ein FPGA einsetzen.
@ Jan (Gast) >Was ich jetzt das erstmal höre ist das die FPGAs so viel Strom brauchen! Was heisst viel? Ein kleineres FPGA, in das schon ne MENGE reingeht braucht vielleicht 20-50mA. Jaja, ein AVR braucht einen Bruchteil davon. Dafür kann das FPGA den hundertfachen Datendurchsatz verarbeiten, wenn es nötig sein sollte. >http://www.mikrokopter.de/ werden) Coole Sache ;-) >Ich würde mir die Aufteilung jetzt so vorstellen: >Der AVR (vielleicht auch ARM) übernimmt die flugsteuerung und der fpga >soll dann die Motorsteuerung aller 4 motoren übernehmen. Sowie die >Messwertaufnahme und Vorverarbeitung. Kann man machen. >Motorsteuerung: Erkennung der Umschaltpunkt der 3 phasen der motoren und >die Regelung der PWM für die Leistung. Ganz schick wäre wenn ich dem >FPGA eine soll Drehzahl vorgebe, die er dann selbst einregelt. (Sollte >ja ein Problem sein, oder?) Yep. >Also man braucht wenigstens schon mal 6 "relativ" schnelle Analogkanäle >für die Gierraten und die Beschleunigen in allen Raum-Axen. Die sollen ADC mit 6 Kanälen. >welche ausbau stufe muss ich nehmen, ich hätte jetzt mal auf "Saxo-L >FPGA + ARM board" getippt. Sieht gut aus. >Was für ein A/D Wandler gibt es denn der leicht an ein FPGA zu hängen >ist, ich wollte ja nicht einen per SPI dran hängen das macht für mich >keinen Sinn! (Ich schau gleich mal wenn jemand aber schon was weiß .... ??? Warum macht das keinen Sinn? SPI ist schnell und einfach handhabbar. Der FPGA kann problemlos 50 MHZ SPI-Takt verarbeiten. MFG Falk
Vorneweg: Ich bin auch ein FPGA Fan. Die Dinger sind einfach nur geil. Aber: In dieser Anwendung einfach fehl am Platz. 1. Preis: 4x Mega8 = 4x 1.39 Euro (CSD), dazu minimales Hühnerfutter. FPGA > 10 Euro + verschiedene Spannungsversorgungen + ADC Allerdings zählt das im Hobbybereich nicht unbedingt viel. Ist mir klar. 2. Lokalität: Die Controller können mit Leistungsteil direkt bei den Motoren platziert werden. Der FPGA müsste wohl irgendwo in die Mitte. 3. Flexibilität: Hört sich jetz blöd an, aber ein Regler für ein derartig nichtlineares System (krasse Stellgrößenbegrenzung) kann schon mal Strukturumschaltungen nötig machen. Das müsste im FPGA ohne Softcore parallel implementiert werden, was die Effizienz wieder verschlechtert. 4. Entwicklungsaufwand: Bis man ein sauberes Design in VHDL zu Stande bringt, braucht man schon einiges Hintergrundwissen bezüglich Digitalelektronik. Wenn man sich dann doch mal nen Baustein schießt, ists bei einem µC weit weniger tragisch. Also für dieses Projekt würde ich bei µC bleiben. Für andere sind FPGAs geeigneter. Und interessant sind sie sowieso.
Nochmal kurz zum Stromverbrauch: Wenn ich mir vorstelle, dass die Flugzeit eines RC-Fliegers maximal 20 Minuten ist, kann ich dieses Argument einfach nicht nachvollziehen.
tcfkat wrote: > @René: Ein ARM ist eine full-fledged RISC-CPU, ein AVR ein µC... das ist > Äpfel mit Birnen vergleichen. Ein ARM ist erstmal nur ein Prozessorkern. Mikrocontroller mit ARM-Kern sind inzwischen für viele Anwendungen eine Alternative zum AVR.
René D. wrote: > an Markus Kaufmann, > Um eine > Entferungsmessung im cm Bereich durch Laufzeit zu erfassen, muss man in > den ps Bereich. Mit 50MHz wird es da sicher noch sehr knapp. Oder hasst > du eine sehr hohe ADC Auflösung? Wenn man die Pulsform kennt, dann kann man ja zwischen den Samples interpolieren und damit die Genauigkeit erhöhen. Wenn der A/D-Wandler 8 Bit hat und man 256x Oversampling macht, dann hat man hinterher im Idealfall 16 Bit. Wobei man diese vielen Bits hauptsächlich wegen der Dynamik braucht, im Nahbereich reichen die 8 Bits durchaus aus. Markus
Heiner D. wrote: >>Wenn man die Pulsform kennt, dann kann man ja zwischen den Samples >>interpolieren und damit die Genauigkeit erhöhen. > > Witzbold. Wenn man die Pulsform kennt, braucht man nicht mehr messen und > interpolieren, weil man dann alle Samples vorhersagen kann. Man hat den Laserpuls ja selber weggeschickt. Deswegen kennt man seine Form. Was man nicht kennt, ist die genaue Position, weil die ja von der Entfernung des Ziels abhängt. > Ansonsten > gilt das Abtasttheorem und da kommst du auch mit noch soviel Phantasie > nicht herum. Das Eingangssignal muss natürlich bandbreitenbegrenzt sein. Dann kann man es z.B. mit sinc interpolieren und bekommt ein besser aufgelöstes Signal und kann anhand dessen die Entfernung des Zieles genauer ermitteln. > Wenn du das ernst meintest, solltest du dir etwas Grundlagenwissen > aneignen, bevor du weitere Ratschläge gibst. Das habe ich mir nicht ausgedacht, das funktioniert so. Markus
Heiner D. wrote: >>Man hat den Laserpuls ja selber weggeschickt. Deswegen kennt man seine >>Form. Was man nicht kennt, ist die genaue Position, weil die ja von der >>Entfernung des Ziels abhängt. > > Na klar. Und wenn es mal ein bißchen mehr rauscht als erwartet, geht auf > einmal gar nichts mehr. Wenn es stärker als erwartet rauscht, dann ist es halt falsch designed. Bis jetzt hatten wir aber in einer relativ stark gestörten Umgebung noch keine Probleme. > Wenn du bloß auf die Flanke eines wie auch immer gefilterten Pulses > triggern willst, bist du eigentlich mit ein bißchen schneller > Analogelektronik weitaus besser bedient. Ich will ja nicht einfach triggern. Denn dann bräuchte ich ja noch einen Zähler im GHz-Bereich. > Aber heutzutage, wo ein simples > RC-Glied vorzugsweise in einem FPGA simuliert wird, Die Bandbreitenbegrenzung geschieht natürlich analog, nicht im FPGA. > da es fertige > Programme fürs Design digitaler Filter gibt, Warum sollten handberechnete Filter besser sein? > aber nicht zum Löten einer Platine, Warum sollte ich 200polige Käfer von Hand löten wollen? > Wieso predigst du, keine FPGAs einzusetzen, wo Mikrocontroller besser > geeignet sind, aber du quälst Analogelektronikersatz in einen FPGA? Weil das analog nicht einfacher ist. Das Eingangssignal hat in meinem Fall eine Dynamik von etwa 170dB. Ohne Oversampling (und ein paar anderen Dingen) wäre wohl das Rauschen deutlich stärker als die schwächsten Ziele. Wie sollte man da überhaupt analog triggern?
Das ist ein guter Punkt! Bei meinem Letzten Projekt musste ich auch richtig ordentlich Glättung in einen DAC-ALOG einbauen (2 Wochen Arbeit!) nur weil einer die Anti-Aliasing-Problematik nicht kapiert hat und am Analogteil / Ausgang des DACs das AA-Filter fehlte ...
Jan Was ideal wäre für so einen Mikrokopter ist ein Propeller Chip (nur schon wegen dem Namen). Der hat 8 Prozessoren auf einem Chip mit gemeinsamem RAM. Stromverbrauch wie uCs und Leistungsfähig wie ein kleines FPGA. Erhältlich im DIL40 der TQFP44. Und sehr einfach programmierbar. http://www.parallax.com/propeller/index.asp
Ein FPGA ist für so eine Anwendung völliger Overkill. Daran kannst du wieder denken wenn deine Regelkreise bei 50 MHz oder mehr arbeiten müssen. Ansonsten gibt es wenn der AVR nicht reicht noch genügend andere Mikrocontroller auf die man umsteigen kann, z.B. ARM-basierte, oder, wenn man das Multicore-Konzept mag, der Propeller.
Bitte 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.