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
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
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
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.
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, ...
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
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.
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
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.
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.
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.
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.
@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 :-)
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ß
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.
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.
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"
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 https://www.youtube.com/watch?v=vIELshvKB_A, 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.
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.
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.
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.
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).
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
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.
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ß
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.
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ß
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
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.
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.
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.