Forum: FPGA, VHDL & Co. Welches Zynq-Board für Mess-Applikationen ?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Felix K. (pfiffiger_pfelix)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ich versuche im Moment ein passendes FPGA-µC-Board zu finden nach 
folgenden Kriterien:
- Im Rahmen meiner Hiwi-Stelle sollen damit kleine Prototypen von 
Messgeräten bzw. kleine Teil-Applikationen davon zu Testzwecken 
realisiert werden.
- Bsp.: Es wird eine analoge Wechselspannung auf einen angeschlossenen 
Elektromagneten gegeben der ein Objekt mit einem Magnetfeld 
beaufschlagt. Das resultierende Magnetfeld des Objektes wird mit einem 
Hall-Sensor gemessen und das Sensorsignal eingelesen. Danach erfolgt mit 
Hilfe der Algorithmen im FPGA eine Transformation in den Frequenzbereich 
und weitere Analysen, aus denen dann Informationen z.B. über das 
Material des untersuchten Objektes gewonnen werden können. Das 
Einstellen der Parameter für die Messung erfolgt über eine provisorische 
GUI. Das wäre mal so grob eine Beispiel-Applikation.
- Ich persönlich würde mich gerne im Hinblick auf zukünftige Bewerbungen 
im Bereich Hard- und Softwareentwicklung in System-On-Chip-Systeme 
(FPGA+µC+DSP) und entsprechende Entwicklungsumgebungen einarbeiten und 
insbesondere in Vivado und den Zynq, da Xilinx momentan Marktführer im 
Bereich FPGA und Embedded-Systems ist.
- Zunächst hoffte ich noch, dass es in Bezug auf Info-Material, Büchern 
und Tutorials da vllt. ein System mit einer zur Arduino und Raspberry-Pi 
vergleichbaren Community gibt jedoch gibt es das leider nicht.
- Hier im Forum wird oft das Red-Pitaya-Board erwähnt, das für meine 
Anforderungen prädestiniert zu sein scheint, jedoch kommt mir das Teil 
im vergleich zu anderen Zynq-Boards z.B. dem Arty-Board total überteuert 
vor und es hat auch nur eine sehr kleine Community.

Meine Frage wäre jetzt, ob es vllt. noch eine kostengünstige Alternative 
zum Redpitaya gibt, die ebenfalls einen Zynq, gute AD- und DA-Wandler, 
Schnittstellen zur Anbidung einer GUI und zumindest ansatzweise eine 
Community und Tutorials bietet.
Oder befinde ich mich da auf einem Holzweg und sollte mich eher nach 
Nicht-Zynq-Alternativen umschauen ?
(Das mit dem Zynq wäre halt eher, weil ich mich dafür interessiere und 
nicht, weil das von meiner Hiwi-Stelle her notwendig wäre).

Gruß
pfiffiger_pfelix

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Felix K. schrieb:
> - Hier im Forum wird oft das Red-Pitaya-Board erwähnt, das für meine
> Anforderungen prädestiniert zu sein scheint, jedoch kommt mir das Teil
> im vergleich zu anderen Zynq-Boards z.B. dem Arty-Board total überteuert
> vor und es hat auch nur eine sehr kleine Community.

Genau das mit dem ADC und DAC kostet schon auch gut Geld. Ausserdem 
kaufst du auch die Umgebung, da gibt es eben schon ein schönes Linux mit 
Anpassungen die du verwenden kannst.

Felix K. schrieb:
> Oder befinde ich mich da auf einem Holzweg und sollte mich eher nach
> Nicht-Zynq-Alternativen umschauen ?
> (Das mit dem Zynq wäre halt eher, weil ich mich dafür interessiere und
> nicht, weil das von meiner Hiwi-Stelle her notwendig wäre).

Einfach sind eben schöne Fertiglösungen. Z. B. Fertiglösungen von NI die 
dann mit Labview zusammenspielen.

: Bearbeitet durch User
von egonotto (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Red Pitaya --- oh weia :)

Also meine Meinung dazu. Ich finde die Hardware ziemlich gut (STEMlab 
125-14). Allerdings ist die Oscilloscope, Signal Generator und Spectrum 
Analyzer Software sehr sehr sehr frugal.

Wie man es gut machen kann zeigt die Software vom Analog Discovery.

Mittlerweile gibt es mehr Hardware Versionen. Die 16 Bit Version mit 
Zynq 7020 ist wohl nur für HF-Anwendung gedacht.

Aber ich denke als Plattform für eigene Projekte ist es sehr gut.
Die Entwicklungsumgebung sollte aber Linux sein.
https://forum.redpitaya.com/

Vermutlich sind tiefere Kenntnisse bzgl. Red Pitaya schon sehr nützlich.

Wenn man ein geeignetes Problem mit dem Red Pitaya schnell realisieren 
kann sind die Kosten für einen Red Pitaya nebensächlich.

MfG
egonotto

von Felix K. (pfiffiger_pfelix)


Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Einfach sind eben schöne Fertiglösungen. Z. B. Fertiglösungen von NI die
> dann mit Labview zusammenspielen.

Ja die "Remote control (Matlab, Labview, Scilab or 
Python)"-Unterstützung des RP ist auf jeden Fall etwas, das ich nutzen 
wollte um immer eine kleine GUI (warscheinlich mit Labview) für die 
Applikation zu erstellen, die ich implementieren möchte.
Jetzt wäre halt die Frage ob es da noch Alternativen gibt also z.B. 
Boards von NI selber oder von Digilent, die ebenfalls eine solche 
Unterstützung bieten. Ich habe bisher leider nichts vergleichbares 
gefunden.

egonotto schrieb:
> Allerdings ist die Oscilloscope, Signal Generator und Spectrum
> Analyzer Software sehr sehr sehr frugal.

Genau solche Dinge wären es, die ich dann selber implementieren würde 
(zumindest Teilfunktionen davon) und eher nicht auf vorgefertigtes 
zurückgreifen würde.

mit dem Arty-Board z.B. bekäme man den Zynq Z7-20 schon für ca. 200€ und 
es gibt einen 24bit AD- und einen 16bit DA- Wandler als P-Mod.
Aber leider würden dann immer noch alle Software-Features des RP fehlen 
und eben auch der LabView-Support.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Felix K. schrieb:
> mit dem Arty-Board z.B. bekäme man den Zynq Z7-20 schon für ca. 200€ und
> es gibt einen 24bit AD- und einen 16bit DA- Wandler als P-Mod.
> Aber leider würden dann immer noch alle Software-Features des RP fehlen
> und eben auch der LabView-Support.

Dann schreibe doch mal was du konkret brauchst. Zynq alleine ist recht 
ungenau. Bei einem AD- oder DA-Wandler gibt es auch weitere Kennzahlen 
als nur die Anzahl der Bits.

Ja Zynq ist jetzt klar, du willst also CPU Kerne und vermutlich auch 
schnellen externen RAM um ein Linux laufen zu lassen. Welche 
Schnittstellen brauchst du noch? Ethernet, UART, ...

von Felix K. (pfiffiger_pfelix)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Gustl B. schrieb:
> Bei einem AD- oder DA-Wandler gibt es auch weitere Kennzahlen
> als nur die Anzahl der Bits.

In diesem Fall wäre tatsächlich nur eine möglichst hohe Auflösung 
relevant, alles andere eher "nice to have".

Gustl B. schrieb:
> Welche
> Schnittstellen brauchst du noch? Ethernet, UART, ...

Eine JTAG-Programmierschnittstelle und Ethernet wären wünschenswert, der 
Rest erstmal zweitrangig.
Audio-Video-Schnittstellen wie Klinkenbuchsen, HDMI oder ähnliches sind 
nicht erforderlich.
Auch sowas wie S-ATA (was der RP bietet) ist nicht nötig.

Gruß

: Bearbeitet durch User
von -gb- (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Irgendeine minimale Abtastrate sollte der ADC doch haben?
Wofür denn Ethernet bei einer geringen Datenrate und was soll der 
Zynq/FPGA machen?
Hochauflösende ADCs und DACs kannst du auch an einen Raspberry oder so 
anschließen. Das würde vieles einfacher machen.

von Felix K. (pfiffiger_pfelix)


Bewertung
0 lesenswert
nicht lesenswert
Hallo, schonmal danke an alle für die Antworten bisher.

-gb- schrieb:
> Irgendeine minimale Abtastrate sollte der ADC doch haben?

Die meisten Messsignale, mit denen ich arbeiten werde, sind eher 
niederfrequent, also max 2-stelliger kHz-Bereich. Eine Abtastrate von 
125Ms/s wie beim RP, wäre daher eher ein Bonus aber kein Must-Have.

-gb- schrieb:
> Wofür denn Ethernet bei einer geringen Datenrate und was soll der
> Zynq/FPGA machen?

Das Ethernet wäre weniger für die schnelle Übertragung, sondern eher für 
die Kompatibilität, also z.B. zum anschließen des Boards an einen 
Laptop, auf dem dann eine GUI für die Messapplikation laufen könnte.

Der FPGA soll hauptsächlich in Echtzeit eine Auswertung der Messsignale 
durchführen, also FFT, Fensterfunktionen, FIR/IIR-Filter etc.
Der Zynq ist sicher kein Must-have, aber ich will im Thema SoCs 
weiterkommen, da es meiner meinung nach ein recht aktuelles Thema auf 
dem Arbeitsmarkt ist, kann mich aber auch täuschen.

Schönes Wochenende

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
OK, du machst das also als Lernprojekt, ja, das ist gut. Sonst fürde ich 
die Filterung und FFT bei der geringen Datenrate nicht im FPGA, sondern 
am PC machen. Das hast du in z. B. Python sehr viel schneller 
hingeschrieben als in den FPGA eingebaut.
Bei zweistellig kHz würde ich auch nicht allzu schnell abtasten, das 
bringt keinen Mehrwert und du musst dann nur das hochfrequente Zeug 
rausfiltern.

von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
Zum Lernen/Weiterbilden ist das ZynQ-Zeug IMHO nur bedingt geeignet, da 
man da sehr schnell den Fokus in einer Menge Probleme verlieren kann.
Mehr punkten kann man mit gut gestrickten Bare-Metal-SoCs, da umgeht man 
einige Echtzeitprobleme und eine Menge Linux-Overhead, den man u.U. gar 
nicht will (ansonsten koennte man auch einen fertigen ARM SoC nehmen).

In dem 'niederfrequenten' Bereich kannst du auch einen RISC-V deiner 
Wahl nehmen und erst noch den Komplett-SoC durchsimulieren, wenn die 
Bugs auftauchen (und das werden sie..). Das mit einem ZynQ zu tun ist 
von der Komplexitaet und den Kosten her ziemlich erschlagend, 
dementsprechend ist das RedPitaya auch eigentlich nicht zu teuer, der 
Softwareaufwand wurde halt deutlich unterschaetzt.

von zynq (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hier lernen Generationen an Studenten mit einem Zynq wie das mit diesem 
FPGA-ARM Soc Zeugs funktioniert, scheinbar ist die Plattform zum Lernen 
gar net mal so blöd.

Ich weiss nicht von welchen Echtzeitproblemen oder Linux-Overhead du 
redest, die Erfassung machst du eh im FPGA und das Linux darf sich die 
Daten aus einem gemeinsam genutzen Speicherbereich rausfischen

Der Verweis auf risc-v liest sich für mich eher so wie Schleichwerbung, 
ich sehe keinen einzigen Vorteil gegenüber einer Zynq Lösung.

von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Mehr punkten kann man mit gut gestrickten Bare-Metal-SoCs, da umgeht man
> einige Echtzeitprobleme und eine Menge Linux-Overhead, den man u.U. gar
> nicht will

Wenn das nötige Linux Wissen (also bis zu Treiberprogrammierung, die hab 
ich auch nicht) fehlt und dieses Fass auch nicht gleich aufgemacht 
werden soll, dann lohnt es sich, auf dem Zynq nicht mit Linux sondern 
mit FreeRTOS zu arbeiten. Wird bei Vivado auch direkt unterstützt und 
ergibt schnell etwas kleines das mal rennt. Netzwerk kann FreeRTOS auch, 
für Webserver, Datenbanken und GUI ist es natürlich nicht die richtige 
Wahl.

von Martin S. (strubi)


Bewertung
-1 lesenswert
nicht lesenswert
@anonymer Troll:

zynq schrieb:
> Hier lernen Generationen an Studenten mit einem Zynq wie das mit diesem
> FPGA-ARM Soc Zeugs funktioniert, scheinbar ist die Plattform zum Lernen
> gar net mal so blöd.
>

Wenn das Lernziel sein sollte, wie man sich beim Debuggen verzetteln 
kann, oder wie man's nicht machen sollte: Merkwuerdiger Ansatz.

> Ich weiss nicht von welchen Echtzeitproblemen oder Linux-Overhead du
> redest, die Erfassung machst du eh im FPGA und das Linux darf sich die
> Daten aus einem gemeinsam genutzen Speicherbereich rausfischen
>

Wenn damit fuer dich der Datentransfer fertig sein sollte, wirst du bei 
einer realen Implementierung noch auf ganz viele Probleme stossen und 
mit Sicherheit an der Komplexitaet scheitern.

> Der Verweis auf risc-v liest sich für mich eher so wie Schleichwerbung,
> ich sehe keinen einzigen Vorteil gegenüber einer Zynq Lösung.

Normalerweise antworte ich auf solches Zynq-Fanboy-Getrolle kaum, aber 
vielleicht machst du noch mal eine Internet-Recherche zum Thema RISC-V 
und Simulation und ueberlegst dir nochmal, was daran 'Werbung' sein 
sollte.

Christoph Z. schrieb:
> Wenn das nötige Linux Wissen (also bis zu Treiberprogrammierung, die hab
> ich auch nicht) fehlt und dieses Fass auch nicht gleich aufgemacht
> werden soll, dann lohnt es sich, auf dem Zynq nicht mit Linux sondern
> mit FreeRTOS zu arbeiten

Nja, ich habe es (und mich lange mit Echtzeit-Treibern/v4l2 
beschaeftigt).
Es ist einfach gehoerig muehsam, durch all diese Layer zu debuggen, 
ausser man hat ein richtig teures Cadence-Tool aus der A-Klasse zur 
Hand, oder frickelt sich mit qemu durch die Untiefen der Co-Simulation. 
Kann sich nach nunmehr 10 Jahren geaendert haben..
FreeRTOS ist ganz ok, das ist immerhin klein genug, um's auf dem SoC 
bare metal zyklengenau zu simulieren.

Hat mich damals weniger Zeit gekostet, den kompletten SoC inkl. 
Networking from Scratch zu machen (Anwendung: latenzfreies komprimiertes 
Videostreaming), waehrend die Nachbarschaft noch am Vivado-Fehlersuchen 
war...
Ich mag Linux wirklich, aber man darf auch mal pragmatisch und v.a. 
stromsparend sein. Und man lernt dabei, wie man's machen sollte :-)

von Felix K. (pfiffiger_pfelix)


Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Mehr punkten kann man mit gut gestrickten Bare-Metal-SoCs, da umgeht man
> einige Echtzeitprobleme und eine Menge Linux-Overhead, den man u.U. gar
> nicht will (ansonsten koennte man auch einen fertigen ARM SoC nehmen).

Was genau ist ein "Bare-Metal-SoC" ?

Martin S. schrieb:
> In dem 'niederfrequenten' Bereich kannst du auch einen RISC-V deiner
> Wahl nehmen und erst noch den Komplett-SoC durchsimulieren, wenn die
> Bugs auftauchen (und das werden sie..).

Ich dachte RISC-V ist ein Open-Source-Befehlssatz für Mikroprozessoren, 
ich wollte eigentlich nicht auch noch einen eigenen Mikroprozessor für 
die Applikation bauen XD.
Oder meinst du eine RISC-V-Architektur in den FPGA packen, falls ja, wo 
lägen da die Vorteile gegenüber einem fertigen SoC, wie dem Zynq?

Christoph Z. schrieb:
> Wenn das nötige Linux Wissen (also bis zu Treiberprogrammierung, die hab
> ich auch nicht) fehlt und dieses Fass auch nicht gleich aufgemacht
> werden soll, dann lohnt es sich, auf dem Zynq nicht mit Linux sondern
> mit FreeRTOS zu arbeiten.

Bräuchte man für eine einfache Mess-Applikation mit kleiner LabView-GUI 
unbedingt ein Betriebssystem ? Könnte man das nicht direkt mit dem uC 
kommunizieren lassen ?

Gruß

von -gb- (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Je nachdem was du machen möchtest brauchst du keine CPU.
Du kannst problemlos Sampledaten erfassen, in Speicher schreiben und 
über USB oder so vom PC abholen lassen. Ich habe das mit einem Ft2232H 
im fifo modus gemacht. Das FPGA sammelt Daten, schreibt die in einen 
großen BRAM Fifo und daraus wird dann der Ft2232h bedient. Funktioniert 
wunderbar. Mit dem ft600/1 bekommt man dann auch usb3 Datenraten hin. 
Wie Ethernet ohne CPU funktioniert weiß ich nicht, aber eine minimale 
Kommunikation wird man schon hin bekommen.

von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
Felix K. schrieb:
> Bräuchte man für eine einfache Mess-Applikation mit kleiner LabView-GUI
> unbedingt ein Betriebssystem ? Könnte man das nicht direkt mit dem uC
> kommunizieren lassen ?

Natürlich kannst du das auch ohne Betriebssystem machen, ist dann halt 
das nächste Fass :-)
Der uC hat ja zwar Ethernet aber TCP/IP etc. musst du ihm dann trotzdem 
noch beibringen.

Du möchtest von LabView via Ethernet mit dem ARM im Zynq kommunizieren, 
der dann irgendwas für dich macht (eine Messung). Das Vivado SDK kommt 
mit FreeRTOS und verschiedenen Libraries wie z. B. LwIP (light weight IP 
stack) und Beispielen dazu. Das sollte dich recht schnell zu einer 
funktionierenden Kommunikation bringen.

Deine Anforderung war ja, etwas über FPGAs zu lernen und Ethernet als 
Schnittstelle ist optional aber halt sehr praktisch, also nehme ich an, 
dass du dir das Leben nicht unnötig komplex machen möchtest diese 
Schnittstelle zu implementieren.

Nebenbei: Betriessysteme wurden erfunden um dem Entwickler Arbeit 
abzunehmen. Das macht vielleicht nicht jedes OS gleich gut aber ich bin 
schon manchmal erstaunt wie allergisch manche Entwickler auf den 
Vorschlag reagieren ein OS zu verwenden.

von Kionophyton (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Felix K. schrieb:
> Martin S. schrieb:
>> Mehr punkten kann man mit gut gestrickten Bare-Metal-SoCs, da umgeht man
>> einige Echtzeitprobleme und eine Menge Linux-Overhead, den man u.U. gar
>> nicht will (ansonsten koennte man auch einen fertigen ARM SoC nehmen).
>
> Was genau ist ein "Bare-Metal-SoC" ?

Knapp gesagt, SoC ohne Linux. Also die ARM-Cores 'direkt' programmieren 
und auf die Peripherals ohne große 'Umwege' (tools, shells) benutzen. 
Eben wie ein 'dicker' µcontroller:
Beitrag "Raspberry Pi als "dicker" Mikrocontroller"

von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

Felix K. schrieb:
> Was genau ist ein "Bare-Metal-SoC" ?

Ok, saloppe Terminologie...'bare metal' steht hier fuer sowas wie ein 
nacktes Design, ohne immensen Bus-Overhead, Treiberframework, 
OS-Schichten, usw.

Felix K. schrieb:
> Ich dachte RISC-V ist ein Open-Source-Befehlssatz für Mikroprozessoren,
> ich wollte eigentlich nicht auch noch einen eigenen Mikroprozessor für
> die Applikation bauen XD.
> Oder meinst du eine RISC-V-Architektur in den FPGA packen, falls ja, wo
> lägen da die Vorteile gegenüber einem fertigen SoC, wie dem Zynq?

RISC-V waere grob erst mal die Bezeichnung fuer die Architektur 
allgemein.
Du kannst auch eine andere Architektur nehmen, aber RISC-V ist einfach 
grade sehr hip und verbreitet, Compiler auf dem Stand, usw.

Der groesste Vorteil ist, dass du das Komplettsystem inkl. Firmware 
simulieren kannst, auf den Zyklus genau, d.h. du kannst deinem 
bare-metal Programm beim Arbeiten mit der Peripherie zusehen.

Siehe auch Youtube-Video "ZPUng virtual example session", das ist 
allerdings eine ZPUng-architektur, die da zappelt.

Beim ARM-SoC/ZynQ ist das mit OpenSource sehr muehsam, da das ARM-Modell 
typischerweise nicht vorliegt, ich weiss allerdings nicht, ob Xilinx 
schon selber qemu-Setups anbietet die auch funktionieren.
Problem da: Nicht zyklengenau, unter Umstaenden gehen einem Szenarios 
durch die Lappen, und da wird's mit Echtzeit eben lustig.

Networking/TCP und die damit noetige Pufferung ist halt so eine Sache, 
wo man fast zu Linux oder einem OS gezwungen ist, oder man muss:
- mit LWIP auf bare-metal rummurksen
- oder selber einen RTP/UDP-Stack schreiben (dabei lernt man bezgl. 
Echtzeit viel)

Dazu braucht man natuerlich eine CPU-Umgebung mit vernuenftigem 
DMA-Setup. Die nimmt einem beim Debuggen/Testen schon sehr viel Arbeit 
ab. Muss nicht RISC-V sein, ZPU und msp430-Klone sind auch sehr gut 
(noch bessere Code-Dichte). Ich habe so eine Labview-Steuerung per UDP 
stack in die 32kB on-Chip-Block-RAM reinbekommen.

Genannter USB-Ansatz (FX2/FX3) ist ansich auch praktikabel, um mal 
schnell Daten einzuziehen, da gibt es ebenso eine Menge fertiger 
Referenzdesigns aus der SDR- oder Kamera-Ecke. Allerdings gibt's da u.U. 
mal Aerger betr. Treiber oder Spaesse mit isochroner Kommunikation unter 
Windows.

Es gibt halt einen grossen Knackpunkt: Du musst von vornherein deinen 
Speicherbedarf abklaeren. Wenn deine Berechnungen nicht mehr im 
on-Chip-RAM laufen oder wegen TCP/IP oder bulk USB gepuffert werden 
muessen, wird SDRAM oder gar DDRx noetig und du hast eine weitere 
Baustelle. Die nimmt dir der ZynQ auf ARM-Seite ab. Aber du kannst dann 
damit keinen Regler mehr bauen, weil dir Linux (ohne allenfalls 
handselektierte Patches) grundsaetzlich die Echtzeit verstreicht, dann 
bist du an der naechsten, noch komplexeren Baustelle.

von Blechbieger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Aber du kannst dann
> damit keinen Regler mehr bauen, weil dir Linux (ohne allenfalls
> handselektierte Patches) grundsaetzlich die Echtzeit verstreicht, dann
> bist du an der naechsten, noch komplexeren Baustelle.

Falls das SoC mehrere Cores hat kann man Asymmetric Multi-Processing 
(AMP) machen. Ein Core hat Linux laufen für Netzwerk, GUI etc., ein 
anderer Core hat Bare-Metall die Echtzeitsoftware laufen. Datenaustausch 
zw. den Cores über gemeinsamen Speicher. Ich meine Xilinx hat dafür 
sogar ein Framework.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Genannter USB-Ansatz (FX2/FX3) ist ansich auch praktikabel, um mal
> schnell Daten einzuziehen, da gibt es ebenso eine Menge fertiger
> Referenzdesigns aus der SDR- oder Kamera-Ecke. Allerdings gibt's da u.U.
> mal Aerger betr. Treiber oder Spaesse mit isochroner Kommunikation unter
> Windows.

Ja, das stimmt. Bei dem FT2232H bin ich dauerhaft auf gute Werte 
gekommen und konnte das USB2 voll auslasten. Beim FT600 aktuell habe ich 
irgendwelche Softwareprobleme und hänge bei etwas unter 60 MBytes/s 
fest.
Der Vorteil ist eben, dass wenn man "nur" Daten einsammeln will die als 
Datenstrom regelmäßig anfallen (wie das bei AD-Wandelern eben so ist), 
dann hält sich der Aufwand im FPGA sehr in Grenzen.
- ADC Interface
- Optional irgendwelche Filterung
- Zwischenspeichern
- Zum USB IC ausgeben
Dafür reicht auch ein kleines billiges FPGA ohne irgendwelche besonderen 
Features. Nur ein paar kBytes BRAM sollten vorhanden sein (der kleinste 
Artix hat 80 kByte, der kleinste Spartan7 20 kByte das ist etwas wenig) 
oder etwas externes RAM.

von Felix K. (pfiffiger_pfelix)


Bewertung
0 lesenswert
nicht lesenswert
Christoph Z. schrieb:
> Natürlich kannst du das auch ohne Betriebssystem machen, ist dann halt
> das nächste Fass :-)
> Der uC hat ja zwar Ethernet aber TCP/IP etc. musst du ihm dann trotzdem
> noch beibringen.
>
> Du möchtest von LabView via Ethernet mit dem ARM im Zynq kommunizieren,
> der dann irgendwas für dich macht (eine Messung). Das Vivado SDK kommt
> mit FreeRTOS und verschiedenen Libraries wie z. B. LwIP (light weight IP
> stack) und Beispielen dazu. Das sollte dich recht schnell zu einer
> funktionierenden Kommunikation bringen.

LabVIEW bietet mit dem LINX-Toolkit ja auch eine eigene Schnittstelle zu 
Embedded-Plattformen an, mit der Embedded-Projekte um eine grafische 
Benutzer-Oberfläche erweitert werden können.
Wäre es damit nicht auch möglich, eine GUI zu bauen, die auf einem PC 
läuft, und direkt über eine Schnittstelle (jetzt mal egal welche) mit 
der Messapplikation auf dem uC-FPGA-Board kommuniziert, ohne noch einen 
Umweg über ein Betriebssystem (auf dem uC-Board) oder ähnliches gehen zu 
müssen ?
Soweit ich weis bieten die LabVIEW-libraries auch vorgefertigte 
TCP/IP-Stacks usw. an.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Und weil ich es gerade gesehen habe:
Es gibt jetzt recht frisch das Eclypse Z7 (Board mit Zynq und Ethernet) 
und ADC-Zmods (zweifach 14Bit ADC mit 100 MSamples/S).

von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
Felix K. schrieb:
> Wäre es damit nicht auch möglich, eine GUI zu bauen, die auf einem PC
> läuft, und direkt über eine Schnittstelle (jetzt mal egal welche) mit
> der Messapplikation auf dem uC-FPGA-Board kommuniziert, ohne noch einen
> Umweg über ein Betriebssystem (auf dem uC-Board) oder ähnliches gehen zu
> müssen ?

Theoretisch wohl schon.

Das Dokument zur Portierung der LINX Sachen auf ein neues Device macht 
richtig Mut :-)

"This document contains a quick brain dump on adding support for a new 
LINX device. This page should be cleaned up and split into separate 
pages as appropriate."

Letzte Änderung war 2016...
https://www.labviewmakerhub.com/doku.php?id=learn:tutorials:libraries:linx:misc:porting_device

von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
Boese Stimmen wuerden sagen, dass alles, was im LabVIEW-Oekosystem 
erstellt wird, nach ein paar Jahren, u.U. sogar Tagen, zu 
Write-Only-Code wird.
Ich steuere darum prinzipiell den ganzen Geraetepark nur noch ueber 
Python-Frontends an, das Geraet praesentiert automatisch seine 
Eigenschaften - und wenn dann noch einer will, darf er's mit LabVIEW und 
OpenG/Python wrappen.
Gibt aber ne Menge schoener anderer Opensource-Loesungen, die auch gut 
skalieren, zum Stichwort SCADA, pvbrowser, usw. findet man eine ganze 
Latte.
Frage ist halt, wo der Fokus liegen soll. Sonst kann man auch die 
RIO-Fertigloesung kaufen.

Mit pvbrowser bin ich recht gut gefahren, damit lassen sich mal schnell 
kleine GUIs rapid prototypen aber auch komplexe Monitore fuer 
Fabrikationsueberwachung/Regeltechnik/Fernkontrolle stricken. Der letzte 
Schrei ist allerdings, alles in gehaertete Browser zu migrieren.

von Felix K. (pfiffiger_pfelix)


Bewertung
0 lesenswert
nicht lesenswert
Hallo.

Martin S. schrieb:
> Boese Stimmen wuerden sagen, dass alles, was im LabVIEW-Oekosystem
> erstellt wird, nach ein paar Jahren, u.U. sogar Tagen, zu
> Write-Only-Code wird.

Was genau meinst du mit "Write-Only-Code" ?

Martin S. schrieb:
> Der letzte
> Schrei ist allerdings, alles in gehaertete Browser zu migrieren.

Was genau kann ich mir darunter vorstellen, ein Browser erfordert ja 
dann auch wieder ein zusätzliches Betriebssystem oder nicht ?

Gruß

von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
Write-only-Code: Loesungen die man einmal zusammenfrickelt und 
hintweakt, und irgendwann wegwerfen muss, weil sie nicht mehr wartbar 
sind (Vorgaenger weg, oder neue Programmversion, usw.).

Browser: Das ist ja dann nur dein Kontroll-Frontend-Tool, was auf dem PC 
laeuft. Webserver dahinter und REST-API, die modbus/firmata/netpp/mqtt 
etc. ansteuert kann lokal oder auf dem ZynQ oder sonstwo laufen, fuer so 
viel Intelligenz macht dann (embedded) Linux Sinn - wenn du dich nicht 
noch mit Dateneinzug auf Treiberebene rumaergern musst. Aber sind halt 
wieder genannte Baustellen.

Typischerweise nehme ich fuer sowas lieber einen Standard-Embedded-PC 
der mit den Daten der FPGA-Knoten per Realtime-Protocol beschickt wird, 
diese loggt und aufbereitet (z.b. mit Grafana, openMCT, o. ae.)
Hat auch u.U. Sicherheitsaspekte, dass sich keiner auf dem primaeren 
Logikcontroller 'einloggt' und die Steuerung schrottet.

von Felix K. (pfiffiger_pfelix)


Bewertung
0 lesenswert
nicht lesenswert
Hi,

Martin S. schrieb:
> Typischerweise nehme ich fuer sowas lieber einen Standard-Embedded-PC
> der mit den Daten der FPGA-Knoten per Realtime-Protocol beschickt wird,
> diese loggt und aufbereitet (z.b. mit Grafana, openMCT, o. ae.)
> Hat auch u.U. Sicherheitsaspekte, dass sich keiner auf dem primaeren
> Logikcontroller 'einloggt' und die Steuerung schrottet.

Wie sieht so ein System aus GUI + Anwendung + Hardware denn bei 
"profesionellen" Herstellern aus, also ich meine z.B. 
Messgerätehersteller oder auch Hersteller von Küchen- und 
Haushaltsgeräten etc.
z.B. auf so einem digitalen Multimeter oder Oszilloskop namhafter 
Hersteller oder eine Mikrowelle mit Touch-Display ?
Läuft da zusätzlich zur GUI-Anwendung auch ein komplettes 
Embedded-Betriebssystem auf der Hardware ?
Das kommt mir ziemlich überdimensioniert vor irgendwie.

Martin S. schrieb:
> Browser: Das ist ja dann nur dein Kontroll-Frontend-Tool, was auf dem PC
> laeuft. Webserver dahinter und REST-API, die modbus/firmata/netpp/mqtt
> etc. ansteuert kann lokal oder auf dem ZynQ oder sonstwo laufen, fuer so
> viel Intelligenz macht dann (embedded) Linux Sinn - wenn du dich nicht
> noch mit Dateneinzug auf Treiberebene rumaergern musst. Aber sind halt
> wieder genannte Baustellen.

Mal angenommen, man würde den umgekehrten Weg gehen, also auf dem 
uC-FPGA-Board ein rudimentäres Embedded-Linux implementieren und eine 
Maus und einen Monitor anschließen. Könnte man dann eine solche GUI auch 
direkt mit Embedded-Linux bauen, sich also damit das Implementieren 
einer zusätzlichen GUI-Applikation mit LabVIEW o.ä. sparen ?
Oder wäre das für meine Vorhaben (z.B. (Sensor/Tastkopf)-Abfrage mit 
Speichern der Werte + FFT + Algorithmen im FPGA + Parameter bzw. 
Darstellung des Kurvenverlaufs auf einer GUI) wieder mit Kanonen auf 
Spatzen geschossen ?

Gruß

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Felix K. schrieb:
> Läuft da zusätzlich zur GUI-Anwendung auch ein komplettes
> Embedded-Betriebssystem auf der Hardware?

Sehr oft ja. Auf Oszilloskopen war das früher meist irgendein (embedded) 
Windows und heutzutage eher Linux und andere Unixoide.

Felix K. schrieb:
> Das kommt mir ziemlich überdimensioniert vor irgendwie.

Ja, hängt aber auch davon ab was das Gerät bieten soll. Wenn du da eine 
Maus schließen können sollst, dann Dateien auf USB gespeichert werden, 
Bildschirmaufnahme, Webserver für Remotebedienung, ... dann bietet sich 
das schon an mit einem Betriebsystem.

Aber wenn dein Gerät nur sehr wenige verschiedene Dinge können soll, 
dann kann man das auch ohne OS machen. Z. B. diese ganzen SDR Boards wie 
LimeSDR und so, die sammeln quasi nur Daten ein und geben Daten aus. Da 
stellt das FPGA quasi eine bequeme Brücke zwischen USB und RF IC her und 
bietet vielleicht noch Hardwarefilterungen und Beschleunigungen.

Die Frage ist eigentlich:
Soll das ein Standalone Gerät werden, oder wird das nur in Verbindung 
mit einem PC geneutzt?
Ein Standalonegerät muss alles, also deine FFT und Anzeige und Bedienung 
selber können. Wenn du das mit einem PC nutzt, dann könntest du fast 
alles an den PC auslagern und mit der Hardware nur die Messdaten 
anliefern.

Felix K. schrieb:
> Mal angenommen, man würde den umgekehrten Weg gehen, also auf dem
> uC-FPGA-Board ein rudimentäres Embedded-Linux implementieren und eine
> Maus und einen Monitor anschließen. Könnte man dann eine solche GUI auch
> direkt mit Embedded-Linux bauen, sich also damit das Implementieren
> einer zusätzlichen GUI-Applikation mit LabVIEW o.ä. sparen?

Naja, LabView kann ziemlich viel, das wirst du nicht so einfach auf 
deinem Zynq hinbekommen, ausser eben du installierst da ein volles 
Desktoplinux und dort installierst du dann LabView oder Ähnliches. Ist 
dann aber langsamer wie auf dem PC. Am PC hast du eben schon sehr vieles 
fertig um das du dich beim FPGA noch kümmern müsstest.

Felix K. schrieb:
> Oder wäre das für meine Vorhaben (z.B. (Sensor/Tastkopf)-Abfrage mit
> Speichern der Werte + FFT + Algorithmen im FPGA + Parameter bzw.
> Darstellung des Kurvenverlaufs auf einer GUI) wieder mit Kanonen auf
> Spatzen geschossen ?

Finde ich schon.
Ich würde Darstellung und GUI auf einem PC machen. FFT und Algorithmen 
vielleicht sogar auch. Je nachdem wie rechenlastig das wird. Wenn du das 
am PC z. B. in Python schreibst, dann kannst du das doch schneller 
ändern und debuggen wie wenn du das alles in VHDL schreibst. Mach auf 
dem FPGA was du dort machen musst und was auf dem PC zu langsam ist.

: Bearbeitet durch User
von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
Felix K. schrieb:
> Läuft da zusätzlich zur GUI-Anwendung auch ein komplettes
> Embedded-Betriebssystem auf der Hardware ?

Du hast noch eine "etwas" übertriebene Vorstellung, das alle 
Betriebssysteme gross sind, GUI und USB haben (Ja, es gibt sicher 50 mal 
mehr Betriebssysteme als nur Windows, Linux und MacOS).

Preemptives Multitasking mit garantiertem Timing, Semaphoren, Events 
etc. geht auch schon in einem ATtiny:
http://femtoos.org/

Generell ist es schon so wie Gustl es beschreibt, je vielfältiger die 
Aufgaben eines Gerätes sind, je höher die Chance, dass da irgendeine Art 
Betriebssystem läuft. Beim kleinen Multimeter eher nicht (da ist es 
sogar ohne Software direkt ein ASIC), bei der einfacheren Waschmaschine 
mit Display vielleicht ja, vielleicht nein. Die grossen Multimeter von 
Fluke die auch Datenlogger sein können, sollen mit ECOS laufen hab ich 
mal gehört. Voice-Over-IP Telefon garantiert ja.

von Felix K. (pfiffiger_pfelix)


Bewertung
0 lesenswert
nicht lesenswert
Nabend,

Christoph Z. schrieb:
> Du hast noch eine "etwas" übertriebene Vorstellung, das alle
> Betriebssysteme gross sind, GUI und USB haben (Ja, es gibt sicher 50 mal
> mehr Betriebssysteme als nur Windows, Linux und MacOS).

Ok, ich merke so langsam, dass es da einfach deutlich mehr Möglichkeiten 
gibt so etwas zu lösen, als ich gedacht habe.
Ich denke ich werde mir doch den RedPitaya mal etwas genauer anschauen. 
Denn egal, ob das mit dem Zynq nun Sinn macht oder nicht, zumindest gibt 
mir das Board eine gewisse Anzahl an Möglichkeiten vor.

Danke schonmal an alle für die bisherigen Anregungen und Erklärungen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.