Hallo, das hier ist eine totale Anfängerfrage, aber eher eine "Wie fange ich an?"-Frage. Ich arbeite seit einigen Jahren in der Entwicklung im Bereich Bildverarbeitung und optische Messtechnik und habe einiges an Erfahrung mit C, C++, teilweise auch (16bit)-Mikrocontrollern,.. In der Regel arbeiten wir auf (möglichst guten) Industrie-PCs, aber eine Softcore-Demo hat mich davon überzeugt, dass FPGAs, wenn auch vielleciht nicht für alle Algorithmen, auch im Bereich Preprocessing/einfaches Processing interessant sind. Konkret will ich erst mal einen CMOS-Sensor (oder Camerainterface oder auch USB, ist mir eigentlich egal) an einen FPGA anschließen, eine einfache Operation ausführen und vielleciht auf einer Schnittstelle etwas ausgeben. Progammieren möchte ich idealerweise in C (Wir haben MATLAB und LabVIEW, mit denen ich beide vertraut bin, aber ich will ein bisschen mehr low-level anfangen). Ich suche dazu ein Evalboard + Toolchain (Spartan gefällt mir recht gut), idealerweise gleich mit Möglichkeit zum Sensor-Anbinden/oä; und vielleicht ein paar Hinweise, wie ich weitermachen kann.. DAnke, kk.
kk schrieb: > Progammieren möchte ich idealerweise in C Dann vergiss FPGAs. kk schrieb: > Konkret will ich erst mal einen CMOS-Sensor (oder Camerainterface oder > auch USB, ist mir eigentlich egal) an einen FPGA anschließen, eine > einfache Operation ausführen und vielleciht auf einer Schnittstelle > etwas ausgeben. Sinnvoller wäre erst mal einen Taster auf einem Evalboard nehmen, eine einfache Operation damit ausführen (Entprellen, etc) und damit eine LED ein- und ausschalten. Wenn du das geschafft hast, was insgesamt mit Besorgen eines beliebigen Spartan Boards(z.b. Digilent) so um die 1-2 Wochen dauert, dann können wir nochmal sprechen.
Mike schrieb: > FPGA und C?????? System-C? Das war der Traum, den Personalbüros Ende am Anfang dieses Jahrtausends hatten, als wegen des Platzens der Internet-Blase viele billige Software-Entwickler auf der Straße saßen... Und auch Schulen waren sehr interessiert, weil sie sich eine billige(re) Hardwaresimulation mit System-C versprachen... Ähnliches passiert gerade mit MATLAB und FPGAs: man klickt/tippt sich ein Modell zusammen, danach ein Druck auf "Run" und fertig ist das Design. So einfach ist das. Da kann jeder theoretische Mathematiker "FPGA", dafür ist kein Hardwareentwickler nötig... ;-)
Moin, kk schrieb: > Konkret will ich erst mal einen CMOS-Sensor (oder Camerainterface oder > auch USB, ist mir eigentlich egal) an einen FPGA anschließen, eine > einfache Operation ausführen und vielleciht auf einer Schnittstelle > etwas ausgeben. Progammieren möchte ich idealerweise in C (Wir haben > MATLAB und LabVIEW, mit denen ich beide vertraut bin, aber ich will ein > bisschen mehr low-level anfangen). Von Klicki-Kram wie Labview, Simulink, usw. kann ich auch nur eher abraten. Damit kann man nicht wirklich robust entwickeln. Fürs Prototyping ist es ok. Zum Thema Softcore auf FPGA: Ich habe jetzt einige Monate an spezifischer FPGA-HW für Bildverarbeitung entwickelt, dabei kristallisiert sich heraus, dass die für Leute aus der Software-Ecke folgende Vorgehensweise empfiehlt: - Design der Verarbeitungs-Pipeline für die 'dummen', aber aufwendigen Algorithmen in VHDL (Filter Kernel, o.ä.) - Erledigen sequentieller Aufgaben per simplen, resourcengünstigen softcore. Die Verarbeitungsgeschichte fungiert dabei eher als Coprozessor und wird durch den softcore nur per Register "angeschmissen". Aufgrund seiner Einfachheit, aber einer robusten Toolchain (Gnu compiler), kann ich die ZPU (Zealot) empfehlen. Schnell ist so ein Softcore nie, wenn man seine Algorithmen komplett in C (ohne VHDL-Auslagerung) schreiben will, ist der ARM oder DSP immer die bessere Wahl. Aber: Trotz Beschleunigung mittels einiger Debugging-Tricks ist man da einige Mannmonate dabei. Konkret zur Plattform: Ich habe hier einen Kameraprototypen auf Spartan6-LX45/Blackfin-Basis, wenn's Dich interessiert, schick mir ne PM. Wir haben auf die Schnelle ein paar Coremodule eingesetzt. Der Sp6 ist aufgrund seiner stattlichen Anzahl Multiplikatoren gut geeignet für BV. Grüsse, - Strubi
Hallo, danke erst mal für die Rückmeldung. Filter etc. in VHDL ist auch der Plan, nur unsere Algorithmen sind leider nicht ausschließlich für so was ausgelegt (größere Differntialgleichungssolver und so Geschichten - wir haben da viele Filterops, aber..). Aber was du da geschrieben hast, klingt relativ gut. Dann eben Preprocessing auf FPGA. Einige Mannmonate haben wir - nur ist die Frage, ob es sich auszahlt.. Und was Klicki-Bunti betrifft: Jedem das seine, aber solange hier im Forum Entprellen als wichtiger Schritt der Programmierung gefeiert wird, nehme ich solche Urteile nur begrenzt ernst. Nach 10 Jahren LabVIEW kann ich damit verdammt viel - und auch robust - entwickeln. Aber das ist nicht das Thema. Gruß, kk
Niemand bestreitet, dass man mit LabView auch robuste Sachen machen kann. Nur kann man eben mit LabView und Matlab nicht gescheit eine völlig andere Domäne, nämlich Hardware, entwickeln. Es gibt für schnelle Prototyping-Sachen da einiges, aber das ist kaum anpassbar, nicht optimiert und passt meist nicht wirklich zur Außenwelt. Solche Überlegungen kommen bei uns auch immer mal hoch.
Das Entprellen war nicht als wichtiger Schritt gedacht, sondern eher um ein Gefühl dafür zu geben was man alles beachten muss. kk schrieb: > Nach 10 Jahren LabVIEW kann > ich damit verdammt viel - und auch robust - entwickeln. Aber das ist > nicht das Thema. Genau, das hilft dir leider bei den FPGAs nicht viel weiter. Sicherlich ist es sinnvoll sich die Algorithmen gut zurechtlegen zu können, aber man muss die auch sinnvoll einbauen. Zwischen einem Guten, einem Mittelmäßigem, einem Schlechtem und einem automatisch erzeugten Design gibt es massive Unterschiede, mMn wesentlich größer als bei jeder konventionellen Software. Aber es ist müßig darüber zu debattieren mit jemandem der nie mit FPGAs angefangen hat. Ein bischen Grundverständnis muss da sein und dafür muss man die Arbeitsweisen kennen. Selbst wenn jemand später mal Teile mit C programmiert (sei das konvertierter Code oder Softcores), so muss man zwingend die Grundlagen beherrschen. Und, ja das klingt komisch, aber bei deinem derzeitigemn Wissensstand ist es zweifelhaft ob du ohne google überhaupt ein Lauflicht zustande bekommst. Das soll keine Kritik sein, aber jemand der noch nichtmal ein "Hello World" programmiert hat, mit dem kannst du nunmal auch nicht diskutieren wie er nun Funktion xy in Photoshop implementiert, auch wenn er seit 10 Jahren erstklassig auf dem Papier zeichnet.
Symbole plazieren, Klick auf "Generate" und fertig ist das FPGA. So bescheibt es Mathworks. Was sie verschweigen: 1. "Fertig" ist damit nur der rechnende Code, nicht die Elektronik 2. Man muss dennoch alle Instanzen setzen, nur eben per Grafik 3. Was an IO, DDR, RAM benötigt wird, muss ebenfalls rein, HW Knowhow ist also dennoch nötig. 4. Die Eingabe ist unflexibler, als in TXT 5. Die Ganze Geschichte ist langwieriger und dauert 6. Die Tool Chain ist noch sher buggy und alles ist anfälliger
Probier mal folgendes dann Verstehst du was wir meinen ! Wirklich ! 1. Programmier mal eine LCD Bildschirmausgabe auf nem µC in C++. (1 tag) 2. Mach das ganze mal mit diskreter Logik (mit 74xx TTL Gatern odes CMOS) (1 Woche) 3. Mach das ganze mal mit nem FPGA in VHDL (wenn du 1 und 2 kannst 1/2 Tag) 4. Mach das mal mit MatLab (Hmmm kiene Ahnung) Schreibe hier mal deine Erfahrung. Dann wirst du schon Verstehen was wir meinen. Das ganze kann man auch einfach mal auf Papier machen (sollte für die Entscheidenede Erkenntnis ausreichen).
Nur so als Anmerkung: Ein Punkt den viele vergessen: Die Resultate der diversen Klickitools sind oft nur mit aufwendigen Lowlevel-Tools im Feld zu debuggen, wenn sie dann komplett sporadisch Mist bauen, oder irgendwo Overflows generieren, etc. Die Zeit, die man beim Zusammenklicken gespart hat, investiert man beim Debuggen aus Erfahrung 3-10fach und ärgert sich grün und blau, oder schreibt alles nochmal von Grund auf neu. Beim gewissen Zertifizierungen kommt das gottseidank von Anfang an nicht in die Tüte. Deswegen führt bei letzerem auch kaum ein Weg an VHDL, Testbenches und Coverage-Tests vorbei (oder man möge mich 'updaten') Über Robustheit kann man diskutieren, aber manche Kunden würden mir graphisch generierte 'embedded' Executables um die Ohren hauen. Ich glaube der Kommentar von Herrn "abc" betr. Entprellen war eine eher vorschnelle minderkonstruktive Antwort auf eine legitime Frage. Es gibt immer noch eine Menge Leute auf Messen, die einem ihre geniale C->Hardware-Lösung verkaufen wollen, leider ist diese meist entweder nicht bezahlbar, oder gerade für eine Referenzanwendung gut. Ich glaube aber, dass Du mit einem Mittelweg aus knietief-im-Dreck-VHDL und einigen generierten Modulen (Filter) solche Entwicklung durchaus "rentabel" angehen kannst, aber das hängt halt von der Komplexität der Anwendung und den Anforderungen ab.
kk schrieb: > Ich suche dazu ein Evalboard + Toolchain (Spartan gefällt mir recht > gut), idealerweise gleich mit Möglichkeit zum Sensor-Anbinden/oä; und > vielleicht ein paar Hinweise, wie ich weitermachen kann.. Es gibt Hersteller von Kameras für die industrielle Bildverarbeitung, die einen frei programmierbaren FPGA enthalten. Von diesen Herstellern bekommst du ein Beispiel-Design, das du deinen Wünschen (und den Möglichkeiten der Kamera) entsprechend anpassen kannst. Nicht desto Trotz wird es für die als Programmierer schwer werden. Tom
Thomas Reinemann schrieb: > Es gibt Hersteller von Kameras für die industrielle Bildverarbeitung, Beispiele?
Mark schrieb: > Thomas Reinemann schrieb: >> Es gibt Hersteller von Kameras für die industrielle Bildverarbeitung, > Beispiele? Für was, Kameras oder Kameras mit FPGA Für letzteres Matrix Vision und VisioSens Tom
Lothar Miller schrieb: > Mike schrieb: > >> FPGA und C?????? > > System-C? > Das war der Traum, den Personalbüros Ende am Anfang dieses Jahrtausends > hatten, als wegen des Platzens der Internet-Blase viele billige > Software-Entwickler auf der Straße saßen... System-C ist gut geeignet umd Testbenches zu treiben > Und auch Schulen waren sehr interessiert, weil sie sich eine billige(re) > Hardwaresimulation mit System-C versprachen... ... und um Modelle zu entwickeln, die man ausserhalb von FPGAs testen kann .. > Ähnliches passiert gerade mit MATLAB und FPGAs: man klickt/tippt sich > ein Modell zusammen, danach ein Druck auf "Run" und fertig ist das > Design. So einfach ist das. Da kann jeder theoretische Mathematiker > "FPGA", dafür ist kein Hardwareentwickler nötig... ;-) ... funktionieren tut das schon, nur hat man damit viel Redundanz im Gepäck. Schau sich einer die stark virtualiserten Funktionen in C++ an: Dort wird arger Aufwand getrieben, um Sequenzielles parallel arbeiten lassen zu können, was komplett wegfällt, wenn man schon parallel Arbeitendes (Silicon) hat. Oftmals wird die Software ja nur genutzt, um Hardware umständlich zu emulieren, wobei dann die Hardware durch die Übersetzung ihrerseits gestrickt wird, den Ablauf zu vollziehen, den die Software vorgibt. Doppeltes Wrapping sozusagen.
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.