Hej Leute, Ich möchte mir ein Evaluationsboard mit einem FPGA holen. Leider kenne ich mich nicht gut genug aus, um zu Wissen welches für mein Problem in Frage kommt. Mein Ziel ist es, mit Hilfe eines FPGAs eine Bilddatei aus einem Speicher zu lesen. Diese Bilddatei ist eine veränderte TIFF-Struktur, was heißen soll ich hab in der TIFF-Datei direkt Steuersignale zum drucken untergebracht. Das Format ist soweit fertig konzipiert. Nun zu meiner Frage, welches Entwicklungsboard würde denn in Frage kommen? Vor allem im Hinblick auf den Speicher. Einige von den Xilinx Evaluationboards haben DDR-Speicher, aber dieser soll schwer zu programmieren sein, also müsste ja ein SRAM sinnvoller sein? Ich bin auch für Ideen offen, falls ich noch einen Denkfehler in meinem Konzept habe und es vlt leichter zu realisierende Möglichkeiten gibt. Viele Grüße Patrick
Bilddatei... Speicher... Drucken... Warum nimmst Du nicht einen Raspi? Duke
Duke Scarring schrieb: > Bilddatei... Speicher... Drucken... > Warum nimmst Du nicht einen Raspi? > > Duke Weil der mind. 30s zum Booten braucht?
Darüber hab ich auch schon einmal nachgedacht. Mein Ziel ist es aber mir den FPGA näher zu bringen, da ich diesen auch für weitere Projekte nutzen möchte. Und mit einem gut fordernden Einstiegsprojekt, hab ich auch die Motivation dahinter zu steigen.
Frank E. schrieb: > Duke Scarring schrieb: >> Bilddatei... Speicher... Drucken... >> Warum nimmst Du nicht einen Raspi? >> >> Duke > > Weil der mind. 30s zum Booten braucht? Stimmt und das auch noch ;-)
Frank E. schrieb: > Duke Scarring schrieb: >> Bilddatei... Speicher... Drucken... >> Warum nimmst Du nicht einen Raspi? >> >> Duke > > Weil der mind. 30s zum Booten braucht? braucht der nicht, wenn man: -arch Linux verwendet -auf ne Gui verzichtet -kernel mit statisch verlinkten II-Treiber verwendet 10 s boot time sind locker machbar
Ich geh mal noch ein bisschen ins Detail: Also der FPGA soll noch ein paar Eingangssignale vom Drucker bekommen und außerdem verschiedene Druckparameter sowie die Bild-Daten auf einen Bus legen. Also in großem Ganzen brauch ich Schätzungsweise 24 I/O Ports (noch über konzipiert, da erste Überlegungen) + zusätzlich Ports zum Anschluss an den Speicher. gibt es da ein Evaluationsboard welches ausreicht und sehr empfehlenswert ist, weil es gewisse Vorteile hat, guten Support usw. ?
Du weisst schon, dass man die Bilddaten noch in ein passendes Protkoll bzw. Dateiformat verpacken muss, wie z.B. Postscript, ESC/P oder PCL ... ?
Patrick S. schrieb: > falls ich noch einen Denkfehler in meinem Konzept habe und es vlt > leichter zu realisierende Möglichkeiten gibt. Nimm einen uC. Da gibt es hübsche potente Burschen die jeden FPGA Prozessor in die Tasche stecken für mickriges Geld. Du willst alles in ein FPGA packen? Das ganze Processing? Wie willst du die FPGA-Funktionen beschreiben? Mit VHDL? Das braucht ein paar Mannjahre. Oder willst du einen Prozessor aufs FPGA basteln und den dann in C programmieren? Dann wirst du schon beim Kauf der Toolchain arm... Ein Vorschlag: zeichne einfach mal ein Blockschaltbild von deinem Gerät und schreib dazu, was was ist und was was machen soll. Dann hat man was zu diskutieren...
Lothar M. schrieb: > Oder willst du einen Prozessor aufs FPGA basteln und den dann in C > programmieren? Dann wirst du schon beim Kauf der Toolchain arm... Och, es gibt da ein paar nette Cores, z.B. PicoRV32 (https://github.com/cliffordwolf/picorv32), seit gcc 7.1 ist der RISC-V-Support auch Upstream.
Genau. Gute Idee... Packen wir uns nen µC in nen FPGA und machen dann alles in SW... Nimm für das einen Raspberry Pi! Kauf dir trotzdem nen FPGA und fang ganz einfach an - Blinky - UART Core (RX/TX) - ...
ui schrieb: > Kauf dir trotzdem nen FPGA und fang ganz einfach an > - Blinky > - UART Core (RX/TX) Aber nicht für das Projekt"Drucker", sondern um mal grob zu erfassen, was ein FPGA ist und kann. Dann sieht nämlich der Ansatz für den "Drucker" ganz anders aus... Patrick S. schrieb: > Und mit einem gut fordernden Einstiegsprojekt, hab ich auch die > Motivation dahinter zu steigen. Du unterschätzt den Aufwand für FPGAs. Und zudem überschätzt du die Leistungsfähigkeit eines Systems, wie du es willst, wenn es auf einem FPGA basiert. Oder andersrum: ich mache gerne in FPGAs. Aber für die Aufgabenstellung hier würde ich einen uC nehmen. Allein schon wegen der Schnittstellen, die dabei FPGA alle selber implementieren oder kaufen (oder kopieren und kapieren) musst. BTW: du willst schnell rechnen, gleichzeitig aber ein schnarchlangsames SRAM anschließen? Das ist sehr ambivalent...
:
Bearbeitet durch Moderator
Angehängte Dateien:
-
FPGA-erste_Schritte.png
67 KB
In den letzten Tagen, hab ich mich ein wenig mehr mit der Hardware beschäftigt und welche Ein/Ausgangssignale ich benötige. Das Bild im Anhang enthält jetzt eine ungefähre Vorstellung was da passieren soll. Zu der Kritik von Lothar, ich bin keineswegs auf einen Speicher festgelegt. Das steckt erst mal nur in der Überlegung welchen ich denn eigentlich verwenden könnte. Wichtiger als der Speicher, ist aber die Ansteuerung der bis zu 24x 9 adrigen Busse, dass hat sich leider jetzt erst heraus gestellt wie viele das sind. Ich hatte anfänglich auch an einen µC gedacht, jedoch denk ich, dass das mit dem Timing für die 24 Busse eine hohe Herausforderung wird. Vorschlag vom Chef war an dieser Stelle ein FPGA zu verwenden, damit der Bus parallel angesteuert werden kann. Würde eine Variante zu realisieren sein mit integriertem Softcore? Die 24 Busse müssen jeweils mit einem Bustakt von 104 kHz angesteuert werden. Also ich hatte auf jeden Fall an einen internen Core gedacht. Ist das Projekt zu realisieren mit zum Beispiel einem Altera Nios II Eval Kit? oder weiß jemand von Vornherein, dass das Quatsch ist und kann gleichzeitig eine bessere Lösung empfehlen. Vielen Dank für konstruktive Kritik und Empfehlungen.
Willst du einen Stoffbahnen- oder Parkettdrucker bauen? Klingt nach 24 parallel arbeitenden Druckköpfen und einem Ding mit harten Echtzeitanforderungen. Dafür dürfte ein FPGA in der Sparte die beste Option sein, aber 9*24 ist eine hohe Anzahl I/O. Einen Soft-core solltest du bei der Komplexität eh einsetzen, aber die Probleme liegen wohl eher im Design der Peripherie, die mit dem Rest optimal harmoniert. Für das Front-End mit USB-Stick usw. nimmst du allerdings besser einen uC von der Stange, das auf dem FPGA zu machen ist schwer teuer. So umgehst du auch das Problem mit der RAM-Anbindung. Mach doch erst mal einen Simulator, um den kommst du sowieso kaum herum. Dann kannst du anfangen, dir die passende EvalHW zu suchen.
Strubi schrieb: > Willst du einen Stoffbahnen- oder Parkettdrucker bauen? > Klingt nach 24 parallel arbeitenden Druckköpfen und einem Ding mit > harten Echtzeitanforderungen. Dafür dürfte ein FPGA in der Sparte die > beste Option sein, aber 9*24 ist eine hohe Anzahl I/O. > Einen Soft-core solltest du bei der Komplexität eh einsetzen, aber die > Probleme liegen wohl eher im Design der Peripherie, die mit dem Rest > optimal harmoniert. Für das Front-End mit USB-Stick usw. nimmst du > allerdings besser einen uC von der Stange, das auf dem FPGA zu machen > ist schwer teuer. So umgehst du auch das Problem mit der RAM-Anbindung. > Mach doch erst mal einen Simulator, um den kommst du sowieso kaum herum. > Dann kannst du anfangen, dir die passende EvalHW zu suchen. Das klingt doch mal sehr konstruktiv. Also empfiehlst du einen separaten µC für die Verwaltung von Speicher und der Kommunikation mit USB-Stick und LAN. Kannst du mir noch empfehlen, wie ich bei der Simulation voranschreite? Also welche Software da empfehlenswert ist?
Ich werfe mal Zynq in den Raum. Und Software, naja, die des FPGA Herstellers.
:
Bearbeitet durch User
> > Das klingt doch mal sehr konstruktiv. Also empfiehlst du einen separaten > µC für die Verwaltung von Speicher und der Kommunikation mit USB-Stick > und LAN. Jau, du musst dich dann nur noch auf das Interface zwischen "Lieblings-Coremodul" und FPGA-Steuerung konzentrieren. Manche erledigen das dann auch als Einchip-Lösung in einem Zynq, das sollte man sich aber jeweils gut überlegen/nochmal durchrechnen. > Kannst du mir noch empfehlen, wie ich bei der Simulation voranschreite? > Also welche Software da empfehlenswert ist? Für ein funktionales Modell setze ich auf Python/MyHDL.
Jetz doch nochmal nachgefragt: Soll das eine kommerzielle Anwendung sein oder von akademischem Interesse?
Strubi schrieb: > Jetz doch nochmal nachgefragt: Soll das eine kommerzielle Anwendung sein > oder von akademischem Interesse? Quasi beides! Ist das wichtig?
Gustl B. schrieb: > Ich werfe mal Zynq in den Raum. > > Und Software, naja, die des FPGA Herstellers. Über Zynq werde ich mich noch informieren. Ich schau mir nebenbei noch Quartus Prime an.
Patrick S. schrieb: > Strubi schrieb: >> Jetz doch nochmal nachgefragt: Soll das eine kommerzielle Anwendung sein >> oder von akademischem Interesse? > > Quasi beides! Ist das wichtig? Naja, bei mir gilt quid pro quo, wer Ideen haben will, muss auch ein bisschen erzählen.
Strubi schrieb: > Patrick S. schrieb: >> Strubi schrieb: >>> Jetz doch nochmal nachgefragt: Soll das eine kommerzielle Anwendung sein >>> oder von akademischem Interesse? >> >> Quasi beides! Ist das wichtig? > > Naja, bei mir gilt quid pro quo, wer Ideen haben will, muss auch ein > bisschen erzählen. Sind ja nur die ersten Schritte. Es ist ein größeres Uni-Projekt, mit der Aussicht das jmd. auf den Zug aufspringt. Will ja erst einmal schauen wie das Ganze realisierbar ist und ob es sich lohnt da viel Kraft und Zeit hinein zu investieren.
Ahoi, es ist jetzt eine Weile ins Land gezogen und ich hab das Thema weiter vertieft. Ich hatte mich jetzt erst einmal für eine Raspberry Lösung entschieden und kann die Bilder umwandeln und die Busse ansteuern vom Prinzip her. Hab dazu einige Programmierfortschritte gemacht und es funktioniert so weit auch. Jedoch ist der Raspberry mit den Threads und dem Timing komplett überfordert. Um das Timing von den Bussen hinzubekommen, brauch ich jetzt dafür einen 2ten Controller der das Bus Timing und die Verteilung auf den richtigen Port übernimmt. Weswegen ich den Raspberry gut finde, ist weil er einen vergleichsweiße großen Speicher hat und ich die ganzen Daten (Informationen für die einzelnen Druckköpfe) vorberechnen lassen kann und die Daten nur noch auslesen muss. Meine Frage ist jetzt wie kann ich vorgehen um an die Daten auf den Raspberry ranzukommen? Meine erste Idee war im Takt des Busses nen Interrupt auszulösen und die Daten durch zu schleusen. Leider hatt es der Raspberry nicht so genau mit Interrupts und er braucht mal länger und mal kürzer, was wahrscheinlich auf die neben Tasks zurück zu führen ist. An der Stelle häng ich jetzt komplett. Wäre es vlt sinnvoll die Daten in einen externen Speicher zu speichern? (welchen? min 10 Mb) auf welchen der µC direkt zugreifen kann. oder wäre es sinnvoll, ein neues Konzept mit einem oder zwei Leistungsfähigen Controllern zu realisieren bei dem nichts vorberechnet wird, so dass die Daten direkt vorher berechnet werden? Ich steh gerade auf dem Schlauch. Falls es andere Ideen gibt was ich noch versuchen könnte oder was ich vlt übersehen hab, weil es eine leichtere Lösung gibt, immer raus damit?!
Patrick S. schrieb: > Leider hatt es der Raspberry nicht so genau mit Interrupts > und er braucht mal länger und mal kürzer, was wahrscheinlich auf die > neben Tasks zurück zu führen ist. Das hat schlicht mit der Default-Linux-Architektur zu tun, die ist für harte Echtzeit nicht gemacht. Optionen: - RT Preempt - Xenomai-Erweiterung (aufwendiger, aber höchste Kontrolle) Mit Xenomai habe ich hier auf einem System z.B. garantierte Latenzen unter 40 us, auch bei Prozess-Volllast. Das auf einem Raspi hinzukriegen dürfte aber einiges an Aufwand hermachen, du musst da tief in die Treiber und DMA-Modelle deines Chips einsteigen. Da macht der Broadcom ne schlechte Nummer. Würde mir in deinem Fall eher ein FIFO-Interface ranbasteln, was für einen Druckdurchlauf die Daten synchron raushaut - möglichst mit garantierter Vermeidung eines Underruns, sonst passiert dasselbe wie bei einer gebrannten CD :-) Auch da hast du leider bei standard-Linux keine Garantie, aber gute Karten unter 10ms Prozessantwort zu bleiben, wenn du das System nicht anderweitig belastest und schön mit DMA arbeitest.
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.