Bildverarbeitung

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.

FPGA und C??????

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

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.

Thomas Reinemann schrieb:
> Es gibt Hersteller von Kameras für die industrielle Bildverarbeitung,
Beispiele?

Helion Vision hat auch ein nettes Baukastensystem..

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.