Hallo, ich bin absolut unerfahren bezüglich FPGAs. Ich möchte 100 digitale Signale auf ihre Richtigkeit prüfen. Sollte ein Signal (oder theoretisch auch alle 100)sich ändern möchte ich dies erkennen. Die Dauer des Signals kann durchaus nur ca. 0,1µs betragen. Die Ereignisse möchte ich per USB oder LAN mit einem PC kommuniziueren. Zunächst einmal meine Frage ob dies realistisch mit einem FPGA ist, oder eher eine Mikrocontroller verwendet werden sollte. Des weiteren Frage ich mich ob man ein Board was diese Schnittstellen beinhaltet bevorzugen sollte, oder einfach den Chip selber anschaffen und alle drum rum selber aufbauen?
irge schrieb: > Zunächst einmal meine Frage ob dies realistisch mit einem FPGA ist, oder > eher eine Mikrocontroller verwendet werden sollte. Ein FPGA halte ich für realistischer. Der Controller müsste ja jeden Eingang mit 10 MHz abtasten, um das Signal zu erkennen, und die Signale noch auswerten. Für einen FPGA ist 0,1 µs kein Problem. Wenn ein Board alles hat, was du brauchst, ist ein Board besser, weil es einfacher zu bedienen und billiger ist.
@ irge (Gast) >ich bin absolut unerfahren bezüglich FPGAs. Ich möchte 100 digitale >Signale auf ihre Richtigkeit prüfen. Sollte ein Signal (oder theoretisch >auch alle 100)sich ändern möchte ich dies erkennen. Das macht jeder Logicanalyzer. > Die Dauer des >Signals kann durchaus nur ca. 0,1µs betragen. Das sind 100ns, eine kleine Ewigkeit für moderne Digitalschaltkreise. > Die Ereignisse möchte ich >per USB oder LAN mit einem PC kommuniziueren. Dann mal los. >Zunächst einmal meine Frage ob dies realistisch mit einem FPGA ist, Ja. >oder >eher eine Mikrocontroller verwendet werden sollte. Eher nicht. >Des weiteren Frage ich mich ob man ein Board was diese Schnittstellen >beinhaltet bevorzugen sollte, Ja. > oder einfach den Chip selber anschaffen >und alle drum rum selber aufbauen? Nicht unbedingt. Man kann auch einfach einen preiswerten Logicanalyzer von Ebay nehmen, die haben viele Kanäle, wenn gleich nicht 100. Aber 3x von dem sollte reichen. Allerings muss man dann sehen, wie man die 3 Datenströme auf dem PC synchronisieren kann. http://www.ebay.de/itm/USB-Logic-Analyzer-34-Channels-124MHz-/331572399012?hash=item4d33414ba4
Dussel schrieb: > Ein FPGA halte ich für realistischer. Ich habe mir mal den Aruino DUE angeschaut und auch dieser scheint mir mit seiner Taktfrequenz von 84MHz angemessen oder? https://www.arduino.cc/en/Main/ArduinoBoardDue
irge schrieb: > Dussel schrieb: >> Ein FPGA halte ich für realistischer. > > Ich habe mir mal den Aruino DUE angeschaut und auch dieser scheint mir > mit seiner Taktfrequenz von 84MHz angemessen oder? > Selbst wenn er mit 840MHz getaktet wäre, sagt das gar nichts darüber aus wie schnell der die I/O Pins sampeln kann.
@ irge (Gast) >> Ein FPGA halte ich für realistischer. Ist er auch. >Ich habe mir mal den Aruino DUE angeschaut und auch dieser scheint mir >mit seiner Taktfrequenz von 84MHz angemessen oder? Oder. Ein uC mit 84 MHz kann DEUTLICH weniger verarbeiten als ein FPGA mit dem gleichen Takt. Wenn du 100ns breite Pulse erkennen willst, solltest du mit mindesten 40 MHz abtasten. Das kann ein FPGA mühelos, auch 100 Bit breit (parallel arbeitende Logik!). Ein uC braucht dafür mehrere Befehle und damit Takte (serielle Befehlsausführung), somit sinkt die effektive Abtastrate ganz fix. Ich würde mal grob tippen, dass der Arduino Due 100 IOs mit maximal mit 2-3 MHz abtasten kann, mit handoptimierten Assembler etwas schneller. Hat der überhaupt 100 freie IOs?
irge schrieb: > Ich habe mir mal den Aruino DUE angeschaut und auch dieser scheint mir > mit seiner Taktfrequenz von 84MHz angemessen oder? Dann bin ich mal gespannt auf den Ansatz.
irge schrieb: > Aruino DUE
1 | It has 54 digital input/output pins... |
> Taktfrequenz von 84MHz Läuft der Bus mit den GPIOs auch mit dieser Frequenz? Kann man die GPIO-Pins per DMA in den Speicher streamen? irge schrieb: > Sollte ein Signal (oder theoretisch > auch alle 100)sich ändern möchte ich dies erkennen. Reicht es villeicht, die Signale alle mit XOR zu verknüpfen? Duke
Falk B. schrieb: > Wenn du 100ns breite Pulse erkennen willst, > solltest du mit mindesten 40 MHz abtasten. Warum? Ich hätte gesagt, theoretisch reichen 10 MHz, praktisch 20 MHz. Wie sind wir jetzt eigentlich von FPGA mit der Überlegung zum selber Routen auf Arduino gekommen?
https://hackaday.io/project/6592-dipsy/log/24784-another-blinky-dipsy-as-spi-slave-with-pwm-output winziges FPGA in DIP8 gehäuse, kannst mit arduino konfigurieren und dann als SPI slave verwenden. Takt frequenzen >100mhz sollten möglich sein.
@ Antti Lukats (xilant) >https://hackaday.io/project/6592-dipsy/log/24784-a... >winziges FPGA in DIP8 gehäuse, kannst mit arduino konfigurieren und dann >als SPI slave verwenden. Takt frequenzen >100mhz sollten möglich sein. Thema verfehlt! "Ich möchte 100 digitale Signale auf ihre Richtigkeit prüfen." Hast du die Schleichwerbung wirklich so dringend nötig? http://www.eetimes.com/author.asp?section_id=216&doc_id=1327108 "I just received a message from Antti Lukats, who is the research and development manager at Trenz Electronic in Germany."
@ Dussel (Gast) >> Wenn du 100ns breite Pulse erkennen willst, >> solltest du mit mindesten 40 MHz abtasten. >Warum? Ich hätte gesagt, theoretisch reichen 10 MHz, praktisch 20 MHz. Damit es nicht ganz so auf Kante hängt, eben 40 MHz. Full Speed USB (12 Mbit/s) arbeitet mit 48 MHz Abtastung beim Empfang, das scheint zu reichen.
Übrigens, wie sieht das Problem auf der "Rückseite" aus? Wenn auf 100 Eingängen richtig was los ist - der Zufall ist ein Schelm - so wird das Datenvolumen, zusammen mit der Info: "Wer" ganz schön ziemlich. Die Info allein wird ja nicht der große Bringer sein, sondern dessen Auswertung. Für ein FPGA eigentlich null Problemo, aber...
Falk B. schrieb: > Damit es nicht ganz so auf Kante hängt Dafür würden meiner Meinung nach 20 MHz reichen. Aber auch 40 MHz sind für einen FPGA ja jetzt nicht so viel. Amateur schrieb: > Wenn auf 100 Eingängen richtig was los ist - der Zufall ist ein Schelm - > so wird das Datenvolumen, zusammen mit der Info: "Wer" ganz schön > ziemlich. Wir wissen nicht, was gemacht werden soll, aber für mich hört sich das eher so an, als träten die Pulse selten auf. Sollte doch mal viel los sein, kann man das immer noch abfangen (anstatt es auszuwerten).
Erstmal Danke für die große Resonanz. Meine Annahme war, das der Due, wenn er mit 84MHz getaktet ist auch 32 Kanäle in einem Taktzyklus mit der besagten Frequenz abtasten kann. Demnach wären alle Kanäle in zwei Taktzyklen abgetastet. Ich würde für dann zwei der Arduino DUE verwenden. Hier scheint allgemein eher ein FPGA bevorzugt zu werden. Hat jemand einen Ansatz welches FPGA-Board dazu geeignet sein könnte? Wie gesagt ich habe bisher keinerlei vorstellung von dem Aufwand dieser umsetzung. Zumal eine Kommunikation Per USB, LAN oder vergleichbarem mit einem PC umgesetzt werden muss.
irge schrieb: > Meine Annahme war, das der Due, > wenn er mit 84MHz getaktet ist auch 32 Kanäle in einem Taktzyklus mit > der besagten Frequenz abtasten kann. Demnach wären alle Kanäle in zwei > Taktzyklen abgetastet. 32 Kanäle pro Zyklus bedeutet 100 Kanäle in zwei Zyklen? Langsam habe ich das Gefühl, dass praktisch keine Erfahrung hast. Wie sind deine Vorkenntnisse? Mit welchen Controllern kennst du dich aus und welche Programmiersprache kannst du? Ich rate dir, klein anzufangen. Insbesondere USB-Kommunikation ist nicht leicht, auch wenn der Controller das kann. (Es gibt die FDTI-Chips, aber die müssen auch erstmal richtig eingebaut und angesteuert werden.) irge schrieb: > Hat jemand einen Ansatz welches FPGA-Board dazu geeignet sein könnte? Jedes, das 100 Eingänge Pins des FPGA nach außen führt.
@ irge (Gast) >Hier scheint allgemein eher ein FPGA bevorzugt zu werden. Hat jemand >einen Ansatz welches FPGA-Board dazu geeignet sein könnte? Eins mit ausreichend Pins und einem USB-Anschluss. >Wie gesagt >ich habe bisher keinerlei vorstellung von dem Aufwand dieser umsetzung. Für einen Fortgeschrittenen ist das eher eine Fingerübung, für einen Anfänger viel Holz. >Zumal eine Kommunikation Per USB, LAN oder vergleichbarem mit einem PC >umgesetzt werden muss. Geh es einfach an. Viele FPGA Boards haben RS232-USB Umsetzer, die sind sehr einfach zu nutzen. Je nach Konzept kann man die abgetasteten Daten mittels einer größeren Statemachine über RS232-USB an den PC senden. Oder man nimmt einen kleine SoftCore Prozessor ala Picoblaze oder Nios, der die Daten formatiert und zum PC schickt. Das ist aber schon wieder anspruchsvoller. Für den ersten Versuch reicht die Statemachine.
Dussel schrieb: > 32 Kanäle pro Zyklus bedeutet 100 Kanäle in zwei Zyklen? Nein ich meinte alle 54 vorhandenen Eingänge werden in zwei Taktzyklen abgearbeitet. Ich habe Erfahrung in der Programmierung von AVR Controllern. Progmmiererfahrung in C und der Arduino IDE. Von FPGAs habe ich keine Ahnung. USB ist eine Möglichkeit, auch Ethernet wäre denkbar.
Stellt sich die Frage, was willst du mit 100 Inputs machen? Wie sieht die Anwendung aus, was soll daraus ermittelt werden. Vielleicht reicht auch ein OR mit 100 Eingängen.
Dussel schrieb: > Wie sind wir jetzt eigentlich von FPGA mit der Überlegung zum selber > Routen auf Arduino gekommen? Es stand schon ganz zu Beginn zur Debatte, denn irge schrieb: > ... mit einem FPGA ist, oder eher eine Mikrocontroller ... irge schrieb: > Sollte ein Signal (oder theoretisch auch alle 100)sich ändern möchte ich > dies erkennen. Du willst es also nur "erkennen" und dann melden: "es hat sich auf irgendeiner der 100 Leitungen was getan"? > Die Ereignisse möchte ich per USB oder LAN mit einem PC kommuniziueren. Für eine Meldung "Achtung: Änderung an irgendeinem Pin!" reicht ein einziges Bit oder einen einzige Leitung aus :-o Schreib doch einfach mal, was dann passieren soll, wenn sich eine der 100 Leitungen geändert hat. Und auch, wie oft das passieren kann. Oder noch besser: beschreibe die komplette Aufgabe...
Lothar M. schrieb: > Schreib doch einfach mal, was dann passieren soll, wenn sich eine der > 100 Leitungen geändert hat. Und auch, wie oft das passieren kann. Oder > noch besser: beschreibe die komplette Aufgabe... Das Ziel ist es in einer vorhandenen Elektronik ungewollte Pegel während dem Intilisierungsvorgang zu erkennen. Zu Anfang reicht es aus ca. 100 Kanäle abzufragen, erweiterungsmöglichkeit allerdings erwünscht. Es soll zusätzlich erkannt werden auf welchem Kanal der Fehler und wie lange er aufgetreten ist. Diese Ergebnmisse sollen dann an einen PC weiter gegeben werden. Erschwerend kommt hinzu, das verschiedene Logikpegel (3,3V; 5V; 12V) erkannt werden sollen. Ich denke allerdings das kann bei der Hardwarekonfig. über Spannungsteiler realisiert werden.
Ich glaube, Du hast Dir etwas zu viel vorgenommen. Versuche, anders an die Aufgabe heranzugehen, indem nur Signale betrachtet werden, die tatsächlich kritisch sein können. Mal eben irgendwo einen Spannungsteiler 'einzulöten', vergiß es.
m.n. schrieb: > Versuche, anders an die Aufgabe heranzugehen, indem nur Signale > betrachtet werden, die tatsächlich kritisch sein können. Es sind alle 100 Signale kritisch. m.n. schrieb: > Mal eben irgendwo einen Spannungsteiler 'einzulöten', vergiß es. Ich will ihn ja nicht einfach so einlöten, sondern eine Platine anfertigen, die je nach gefordertem Pegel über jumper die Spannungsteiler auswählen die benötigt werden. Da stellt sich mir auch so die Frage für welche Signalpegel sind FPGAs geeignet? Meine bisherigen Recherchen haben mich in einen Riesigen Pool aus FPGAs geführt, wo mir nicht ganz klar ist was alles möglich ist.
Eine weitere Idee die mir grad kam. wie sieht es mit einer Kombination aus FPGA und arduino aus? FPGA zur asuwertung der Signale und der Arduino zur Kommunikation mit dem PC? Arduino und FPGA könnten dann per I2C kommunizieren. Oder ist dies ein komplett überflüssiger Ansatz?
irge schrieb: > FPGA zur asuwertung der Signale und der > Arduino zur Kommunikation mit dem PC? Arduino und FPGA könnten dann per > I2C kommunizieren. Da kommt es halt wieder darauf an, wie viel Daten anfallen, und wie schnell Du diese haben must. Das heisst, das System sollte etwas genauer beschrieben, resp. definiert sein Ich nehme mal an, Du willst steigende und fallende Flanken auf Deinen 100 Signalen erkennen und übermitteln. Mit einer minimalen Pulslänge ist das System noch viel zu wenig beschrieben. Wenn alle 100 Signale ständig nahe der Minimalpulsbreite zwipseln, brauchst Du eine viel grössere Bandbreite (vergiss I2C), als wenn alle 2 Minuten mal ein Puls daher kommt (I2C reicht völlig, geeignetes Datenprotokoll vorausgesetzt). Wenn Du die Daten nicht sofort brauchst, kannst Du den Snapshot mal auf dem FPGA speichern (oder angehängter Speicher) und später langsam zum PC laden und auswerten (in dem Falle könnte I2C auch für grosse Eventmassen wieder in Frage kommen). Du siehst, es wichtig, das System erst mal zu definieren, insbesondere die zu erwartenden Datendruchsätze und Speicherkapazitäten, und erst danach die Mittel zu wählen. Falk B. schrieb: > Viele FPGA Boards haben RS232-USB Umsetzer, die sind > sehr einfach zu nutzen. Eine Lösung in der Art solltest Du ins Auge fassen, wenn die Bandbreite nicht zu gross ist (wahlweise auch UART-USB Umsetzer). Damit entfallen dann USB oder ETH Chips (oder FPGA IPs) mit eigenem Firmwarebedarf.
Lothar M. schrieb: > Dussel schrieb: >> Wie sind wir jetzt eigentlich von FPGA mit der Überlegung zum selber >> Routen auf Arduino gekommen? > Es stand schon ganz zu Beginn zur Debatte, denn > irge schrieb: >> ... mit einem FPGA ist, oder eher eine Mikrocontroller ... Ich muss zugeben, dass ich mir den/die/das Arduino nicht angesehen und an 8-Bit-AVR gedacht habe. Deshalb habe ich mich gewundert, warum jetzt wieder ein kleiner Controller zur Diskussion steht, wo wir uns schon praktisch auf das FPGA geeinigt hatten. irge schrieb: > Da stellt sich mir auch so die Frage für welche Signalpegel sind FPGAs > geeignet? 1,8 V bis 3,3 V geht sicher. Vielleicht geht es inzwischen auch bis 1,2 V, 1,0 V oder sogar 0,8 V. Da bin ich nicht auf dem Laufenden. irge schrieb: > FPGA zur asuwertung der Signale und der > Arduino zur Kommunikation mit dem PC? Das Prinzip habe ich in meiner Bachelorarbeit genutzt, aber nicht als einzelne Chips. Es gibt von verschiedenen Herstellern Mikrocontroller mit Logik (nicht umgekehrt, wie Xilinx betont), bei denen praktisch ein FPGA und ein Controller, meistens ein ARM auf einem Chip sind. Die heißen bei Xilinx Zynq, bei Altera Cyclone, bei Microsemi SmartFusion und so weiter. Hier ist mal beispielhaft ein günstiges Board, aber 'nur' mit 80 Eingängen. http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=941&PartNo=2
irge schrieb: > Das Ziel ist es in einer vorhandenen Elektronik ungewollte Pegel während > dem Intilisierungsvorgang zu erkennen. Bei jedem Start oder nur einmal beim Test oder der Inbetriebnahme? irge schrieb: > Da stellt sich mir auch so die Frage für welche Signalpegel sind FPGAs > geeignet? Der übliche Bereich ist 1,2V bis 3,3V.
P. K. schrieb: > Ich nehme mal an, Du willst steigende und fallende Flanken auf Deinen > 100 Signalen erkennen und übermitteln. Wenn ich das richtig Verstanden habe, sollen die 100 Signale mit einem Sollwert verglichen werden. Mir ist noch unklar, ob der Sollwert statisch ist, oder ein 'Muster'. Ebenfalls offen ist, wo der Vergleich stattfinden soll/kann. Da gibt es mehrere Varianten: live im Controller/FPGA oder anschließend im Host-PC... Duke
Dussel schrieb: > Das Prinzip habe ich in meiner Bachelorarbeit genutzt Würdest du mir deine Arebit zur verfügung stellen, damit ich eine Bewertung dieser möglichkeit für meine zwecke durchführen kann?
irge schrieb: > Das Ziel ist es in einer vorhandenen Elektronik ungewollte Pegel während > dem Intilisierungsvorgang zu erkennen. Ich habs leider noch nicht kapiert. Meinst du mit "ungewollte Pegel", dass sich zwischenzeitlich "falsche" Kombinationen der 100 Bit ergeben? Das könntest du mit dem FPGA angehen. Wenn das FPGA eine Möglichkeit hätte zu unterscheiden, ob die jeweils aktuelle Bitkombination gültig oder ungültig ist (z.B. ein Prüfbit oder eine CRC), wäre es keine all zu große Sache. Oder willst du etwa detektieren, wenn einzelne Leitungen zwischendurch keinen definierten Logikpegel haben? Das macht die Sache komplizierter. Wie soll das FPGA erkennen, ob es sich um einen definierten Logikpegel handelt oder nicht? Das FPGA wird am Eingang immer eine 1 oder eine 0 interpretieren, so etwas wie "undefinierter Pegel" wird es dir nicht als verwertbare Information liefern. (wäre beim µController genau so). Wie du mit Spannungsteilern rauskriegen willst, ob ein sauberer Logikpegel anliegt, ist mir auch unklar. Mal davon abgesehen, dass der Spannungsteiler deine Leitung beeinflusst: falls der undefinierte Pegel aufgrund floatender Leitungen zustande kam, wirst du durch den Spannungsteiler die Fehlersituation verhindern, die du eigentlich detektieren wolltest. Wenn du wirklich sicherstellen willst, dass auf jeder der 100 Leitungen ein gültiger Logikpegel anliegt, bräuchtest du z.B. 100 schnelle Fensterkomparatoren: deren Ausgang geht auf High für gültige Logikpegel, auf low für ungültige, und diese Komparatorausgänge könntest du per FPGA aufzeichnen oder auswerten. Zusätzlich müsstest du ganz kurze Fehlerpulse unterdrücken. Denn bei jeder Schaltflanke ist der Pegel zwangsläufig im undefinierten Bereich (für eine sehr kurze Zeit).
Achim S. schrieb: > einst du mit "ungewollte Pegel", > dass sich zwischenzeitlich "falsche" Kombinationen der 100 Bit ergeben? Genau das meine ich. Es kommt ab und zu vor, das die Elektronik während der Initialisierung die Pegel ungewollt verändert. Diese veränderungen sollen erkannt (nicht verhindert werden). Anschließend sollen diese informationen an den PC übertragen werden. Kann mir jemand eine passende Hardware dazu empfehlen? Wie sieht es aus mit z.B. dem hier schon erwähnten Xilinx Zynq?
irge schrieb: > Genau das meine ich. Danke für die Klarstellung. Gibt es eine Möglichkeit, wie das FPGA selbst entscheiden kann, ob die Bitkombination richtig oder falsch ist? Gibt es vielleicht nur eine "kleine" Zahl von erlaubten Bitkombinationen? Oder ist so was wie eine Prüfsumme über die 100 Signale denkbar? Oder kann das FPGA die "richtige" Reihenfolge irgendwie algorithmisch generieren? In dem Fall müsstest du nur bei erkannten Fehlersituationen reagieren und einen Timestamp samt Fehlerinfo verschicken. Oder muss das FPGA zwingend die vollen 100bit mit der vollen Abtastrate an den PC schicken, weil nur der die Analyse durchführen kann? Einige 100MByte/s dauerhaft an einen oder mehrere Rechner zu schicken ist zwar nicht völlig unmöglich, aber keinesfalls was für Anfänger. Eine Zwischenlösung (wurde oben auch schon geschrieben) wäre, die Daten in einem schnellen Zwischenspeicher beim FPGA zu puffern und dann gemütlich zum Rechner zu schicken. Geht aber halt nur für relativ kurze Messzeiten im Bereich unter 1s, weil sonst der Puffer überläuft. Die gewünschte Hardwareempfehlung hängt stark davon ab, welche dieser drei (oder anderer) Möglichkeiten du implementieren willst.
Achim S. schrieb: > Oder muss das FPGA zwingend die vollen 100bit mit der vollen Abtastrate > an den PC schicken, weil nur der die Analyse durchführen kann? Der FPGA soll durch den PC den Startzeitpunkt der Messung und das Ende Kommuniziert bekommen. Ab dem Start liegt die gewollte Bitkombination vor und nur im Fehlerfall muss ein Timestamp + die erkannten Fehler-Kanäle gesendet werden.
irge schrieb: > Ab dem Start liegt die gewollte Bitkombination vor und nur im Fehlerfall > muss ein Timestamp + die erkannten Fehler-Kanäle gesendet werden. Und ist diese statisch, d.h. es darf sich beim Test nichts ändern?
danke, es wird immer klarer. Die Bitkombination muss also während der Messzeit statisch anliegen, und jede Abweichung davon wird als Fehlermessage an den PC geschickt. Das ist voraussichtlich ein überschaubares Datenvolumen, damit kommt fast jedes FPGA mit USB oder Ethernetanbindung klar. Sorry, dass ich weiterfrage: wie (zeitlich) genau muss die Synchronisierung von Beginn und Ende der Messzeit sein? Reichen einige 10ms? Oder muss es genauer gehen? Falls einige 10ms ausreichen dürften tatsächlich so ziemlich alle FPGA-boards passen, die >100 frei verfügbare IO-Pins rausgeführt haben und "irgendein" Interface nach außen anbieten (Ethernet, USB, meinetwegen sogar RS232). Die Interfaces sind je nach Board und Implementierung etwas unterschiedlich aufwändig in Betrieb zu nehmen, aber für viele boards kannst du dir Beispielimplementierungen runterladen. Hat eure Firma eine Lizenz für ein FPGA Entwicklungssystem? Falls nicht, achte darauf, dass das verwendete FPGA von den freien Tools der Hersteller unterstützt wird (die "kleinen" FPGAs werden das normalerweise, die "großen" eher nicht). Alternativ kann bei einigen boards evtl. auch eine Schmalspurlizenz mitkaufen, die nur für den Einsatz auf diesem Board gilt.
Achim S. schrieb: > Sorry, dass ich weiterfrage: wie (zeitlich) genau muss die > Synchronisierung von Beginn und Ende der Messzeit sein? Ich bin dir sehr dankbar das du dich meinem Problem so annimmst. Eine Synchronisation im Bereich von 10ms sollte ausreichen. Hersteller dieser Boards kannst du mir empfehlen? Ich gegeh mal davon aus das du mit solchen Produkten bereits erfahrung hast. Preislich ist so bis 300€ vorgesehen
Was Du suchst ist quasi ein LogiC-Analyzer mit 100 Kanälen! Es gibt hier im Forum bei den Artikeln einige gute OpenHardware-Modelle die Du eventuell erweitern kannst! Hier: https://www.mikrocontroller.net/articles/Logic_Analyzer
:
Bearbeitet durch User
irge schrieb: > Hersteller dieser Boards kannst du mir empfehlen? Dir ist klar, dass du dann noch ein Hardwarebeschreibung für dieses teuer gekaufte Board brauchst? Dem bisherigen Thread entnehme ich, dass du noch keine Erfahrung mit Hardwarebeschreibung hast, deshalb die Frage: Wieviel Zeit hast du zum Lösen der Aufgabe?
irge schrieb: > Würdest du mir deine Arebit zur verfügung stellen, damit ich eine > Bewertung dieser möglichkeit für meine zwecke durchführen kann? Das würde dir nichts bringen, da ich darauf nur ganz kurz eingehe. Um es klarzustellen, ich habe die Bachelorarbeit nicht über dein Problem geschrieben, sondern darin nur die Logik-Controller-USB-Kommunikationskette genutzt. Das Stichwort ist APB (Advanced Peripheral Bus). Einfach gesagt, schreibt die Logik die Daten in Register, der Controller holt die Daten (z.B. mit Register_Read()) ab und sendet sie über USB (z.B. USB_Send()). Die Frage bleibt trotzdem, ob es sich lohnt, so ein System einzusetzen, bei dem der Prozessor nur für die Kommunikation genutzt wird.
Dussel schrieb: > Die Frage bleibt trotzdem, ob es sich lohnt, so ein System einzusetzen, > bei dem der Prozessor nur für die Kommunikation genutzt wird. Ich würde hier zur Kommunikation einfach einen RS232-USB Wandler verwenden. Ethernet ist eh' Overkill und wozu noch einen Prozessor ins System holen?
irge schrieb: > Hersteller dieser Boards kannst du mir empfehlen? Ich würde jetzt wahrscheinlich anfangen, bei Trenz das Angebot an Boards durchzugehen. Ich arbeite (aus Preisgründen) des öfteren mit deren Spartan6 Industrie-Mikromodulen, da dürfte es aber mit der Zahl der freien IOs knapp werden. Wenn Antti Lukats noch mitliest, kann er vielleicht aus dem Stegreif sagen, welches ihrer boards taugen wird. Nochmal die Anforderungen aus meiner Sicht: mehr als 100 single ended IOs rausgeführt FPGA-Unterstützung durch freie Tools (keine Lizenzprobleme) "einfaches" Interface um Daten mit einigen MByte/s mit dem PC auszutauschen möglichst mit verfügbaren Beispielprojekten zum Betrieb dieses Interfaces Preis bis 300€ sollte bei den Anforderungen machbar sein. Die Warnungen der anderen Diskussionsteilnehmer sind natürlich auch ernst zu nehmen: wenn du tatsächlich noch gar keine Ahnung von Hardwarebeschreibung fürs FPGA hast, dann ist der Einstieg eine zähe Sache, die nicht in ein paar Wochen nebenbei erledigt ist. Jemand mit Erfahrung in diesem Bereich baut dir die FPGA-Beschreibung in ein paar Tagen (oder schneller, wenn schon vorhandene Komponenten mitnutzt). Ein Neuling auf dem Gebiet braucht ein paar Monate. Wie dringend ist der Testaufbau denn? Sowas wäre aus meiner Sicht eine schöne Abschlussarbeit für einen Studi, der zumindest schon ein etwas praktische FPGA-Erfahrung mitbringt.
Achim S. schrieb: > Wie dringend ist der Testaufbau denn? Also es wäre schön wenn es bis ende des Jahres (also ca. 3-4 Monaten) fertig ist. Mittlerweile steht fest das die Kommunikation per USB oder Ethernet zum PC stattfinden MUSS, da keine anderen Schnittstllen zur Verfügung stehen. Glaubst du es ist realistisch dies ohne Vorkenntnisse in der Zeit umzusetzen?
Achim S. schrieb: > Interface um Daten mit einigen MByte/s mit dem PC auszutauschen Und wozu das nochmal? Denn irge schrieb: >> Es kommt ab und zu vor, das die Elektronik während der Initialisierung >> die Pegel ungewollt verändert. Diese veränderungen sollen erkannt (nicht >> verhindert werden). Anschließend sollen diese informationen an den PC >> übertragen werden. "Ab und zu" hört sich für mich ín der Summe nach einer sehr überschaubaren Datenmenge an. Und das Wort "Anschließend" vermittelt einen relativ lockeren Zeitbezug...
:
Bearbeitet durch Moderator
irge schrieb: > Glaubst du es ist realistisch dies ohne Vorkenntnisse in der Zeit > umzusetzen? Ich halte das für durchaus realistisch, wenn du schon Erfahrung mit Controllern hast, die über das Zusammenkopieren von Beispielen hinausgehen. Anliegende Daten einlesen, mit dem Sollwert vergleichen und bei Abweichung nacheinander an einen SPI-IP-Core senden, der eine FTDI-Chip ansteuert. Die Schwierigkeit sehe ich nur darin zu überlegen, wie man die Daten senden soll.
@ irge (Gast) >Genau das meine ich. Es kommt ab und zu vor, das die Elektronik während >der Initialisierung die Pegel ungewollt verändert. Diese veränderungen >sollen erkannt (nicht verhindert werden). Anschließend sollen diese >informationen an den PC übertragen werden. Wie ich schon sagte, das macht man mit einem Logicanalyzer. Die gibt es fertig für wenig geld zu kaufen, wenn gleich nicht mit 100 Kanälen. Muss man halt mehrere nutzen. >Kann mir jemand eine passende Hardware dazu empfehlen? Wie sieht es aus >mit z.B. dem hier schon erwähnten Xilinx Zynq? ;-) Diese FPGAs liegen um WELTEN über deiner (Wissens)Liga.
Lothar M. schrieb: >> Interface um Daten mit einigen MByte/s mit dem PC auszutauschen > Und wozu das nochmal? Um den "Vergleichswert" zu übermitteln, Messungen zu starten und zu stoppen, und um bei Bedarf ein paar Fehlermeldungen zu verschicken. Ja, je nach Fehlerhäufigkeit darf die Bandbreite auch 1-2 Größenordnungen kleiner sein. Aber wenn jetzt eh USB oder Ethernet vorgegeben sind, macht das nicht wirklich einen Unterschied. irge schrieb: > Glaubst du es ist realistisch dies ohne Vorkenntnisse in der Zeit > umzusetzen? Trivial wird das nicht, klappen kann es schon, ob es ökonomisch sinnvoll ist bezweifle ich. Was ist denn deine Rolle bei der Sache? Bist du fest angestellt und würdest deine gesamte Arbeitszeit während der kommenden Monate dafür einsetzen? Dann wäre es preiswerter, das als kleinen Auftrag an einen Profi zu vergeben. Das board für die Signalanpassung könnte ja zur Kostenoptimierung trotzdem jemand (mit Erfahrung) von euch machen. Auf existierenden offenen Logicanalyzer-Projekten aufzusetzen und diese zu modifizieren klingt zwar erst mal gut. Andererseits ist dein Hauptproblem ja überhaupt einen Zugang zur VHDL-Welt zu finden. Den brauchst du auch, wenn du "nur" ein existierendes Projekt für deinen Zweck abändern willst. "Fertige" LAs parallel einzusetzen geht auch ohne VHDL-Kenntnisse. Aber ein paar Wochen wirst du wahrscheinlich auch dort damit verbringen, die passenden Teile zu finden und sie in der gewünschten Art anzusteuern und zu synchronisieren. Wahrscheinlich zahlst du dann etwas mehr an Hardwarekosten, aber deutlich weniger als Mitarbeitkosten für 3 Monate. Falls du nicht fest angestellt bis sondern z.B. grade deine eigene Abschlussarbeit planst: wenn du einen Betreuer mit Ahnung hast, der sich alle paar Wochen deine Fortschritte anschaut und dich wieder auf den richtigen Weg bringt, könnte das klappen. Wenn du völlig in der Luft hängst, würde ich eher die Finger davon lassen. Die meiste Lern-Zeit verpufft an eigentlich simplen Dingen und Konzepten, auf die man als einzelkämpfender Anfänger von alleine nicht so schnell kommt.
irge schrieb: > Also es wäre schön wenn es bis ende des Jahres (also ca. 3-4 Monaten) > fertig ist. Wenn du stramm bei der Arbeit bleibst und so lange nichts anderes machst. > Mittlerweile steht fest das die Kommunikation per USB Nimm das erwähnte RS232-USB Interface.
Wie sieht es hiermit http://www.exp-tech.de/mojo-v3-fpga-development-board?gclid=CM3ji72Z7McCFQnmwgodqo0Bnw aus? Könnte dies eine geeignete Variante sein, wenn man mal davon absieht, das nur 84 eingänge zur Verfügung stehen?
irge schrieb: > Könnte dies eine geeignete Variante sein, wenn man mal davon absieht, > das nur 84 eingänge zur Verfügung stehen? Jein. Es reicht für den Anfang zum Lernen, aber später brauchst du schon noch ein paar Pins für was Anderes (z.B. Debugging, RS232, LEDs...). Und vor die Frage kommt hier die Antwort: Nein, es ist nicht einfach, zwei solcher Boards miteinander zu verbinden. Achim S. schrieb: > Lothar M. schrieb: >>> Interface um Daten mit einigen MByte/s mit dem PC auszutauschen >> Und wozu das nochmal? > Um den "Vergleichswert" zu übermitteln, Messungen zu starten und zu > stoppen, und um bei Bedarf ein paar Fehlermeldungen zu verschicken. Das sind für mich ein paar Bytes beim Einschalten einer Maschine. Wenn da mal 10 Zustandswechsel vorkommen, dann sind das gerade mal 1000 Bits. Bei 115 kBit/s sind die mach knapp 10 ms versendet...
:
Bearbeitet durch Moderator
So wie es im Moment (d.h EIN konstantes Bitmuster) verstehe reicht auch ein MachXO2 Breakout Board. Hat etwas mehr als 100 I/Os, USB (FTDI) zum Flashen und serielle Schnittstelle zum FPGA. Dagegen spricht allenfalls wenn es besondere Anforderungen an die Connectoren gibt.
Dieses Minimal-Board hat laut Schaltplan 116 IO verfügbar und auf die Header rausgeführt. Demo-Code, wie man einen UART oder ein CY7C68013A Modul (USB schnell) ansteuert ist auch da: http://www.waveshare.com/wiki/Core3S500E Kostet bei eb*y inkl. Versand 31 Euro (braucht einen Monat aus China). Nach "XC3S500E board" suchen und nach aufsteigendem Preis sortieren.
Lothar M. schrieb: > Das sind für mich ein paar Bytes beim Einschalten einer Maschine. Wenn > da mal 10 Zustandswechsel vorkommen, dann sind das gerade mal 1000 Bits. > Bei 115 kBit/s sind die mach knapp 10 ms versendet... Jo. In der Zeile, die du grade nicht mehr mitzitiert hast, hatte ich das glaube ich schon bestätigt ;-) Achim S. schrieb: > Um den "Vergleichswert" zu übermitteln, Messungen zu starten und zu > stoppen, und um bei Bedarf ein paar Fehlermeldungen zu verschicken. Ja, > je nach Fehlerhäufigkeit darf die Bandbreite auch 1-2 Größenordnungen > kleiner sein. irge schrieb: > Könnte dies eine geeignete Variante sein, wenn man mal davon > absieht, das nur 84 eingänge zur Verfügung stehen? Das wäre ein "Minimalboard", das für die geplante Anwendung zwar reichen könnte, aber für alles andere dann schnell zu knapp wird. Wie Lothar schreibt sind zumindest ein paar LEDs zum Signalisieren von Zuständen und ein freier Port zum Debuggen oft hilfreich. Auch die anderen genannten Minimalboards könnten ausreichend sein, wobei du beachten musst, dass bei einigen boards noch ein zusätzlicher Programmer benötigt wird. Allerdings treten die Hardwarekosten im Vergleich zum Zeitaufwand ziemlich in den Hintergrund. Du bist übrigens nicht auf ein Board angewiesen, um die Entwicklung mal zu beginnen und zu sehen, ob es für dich taugt. Die Entwicklungssoftware kannst du dir frei herunterladen (kostet nur viel Downloadzeit). Damit kannst du die Entwicklung starten, dich mit den Tools vertraut machen und deine ersten Entwürfe simulieren. Sowei geht alles auch noch ohne board.
Hab noch ein board gefunden was mir auf den ersten Blick als tauglich erscheint und anfängerfreundlich ist. Spricht da irgendwas gegen? http://zedboard.org/product/microzed
irge schrieb: > Spricht da irgendwas gegen? Der Preis. Technischer Overkill. Kompliziertes FPGA für den Anfang. Das selbe wie vorhin: zu wenig Pins, wenn du da noch was debuggen willst. Und das wirst du wollen/müssen/brauchen... Was genau spricht jetzt gegen das 10 mal billigere MachXO2 Board?
:
Bearbeitet durch Moderator
Ich würde auch das Machxo2 Breakout nehmen. > http://www.waveshare.com/wiki/Core3S500E Hierfür wird noch ein (möglichst günstiges?) Progammierkabel benötigt, dass dennoch garantiert funktioniert. > http://zedboard.org/product/microzed Zu komplex, IOs für den TO schwer zugänglich. Also mindestestens das Carrierboard dazu, welches allein schon 250USD kostet. Alternativ ein Trenz+Baseboard, falls dieses genügend IOs hat. Mit Programmierkabel insgesamt Größenordnung 250EUR brutto. Vorteilhaft für den TO wäre, wenn er jemanden vor Ort hat, der helfen kann. Dann ist entscheidend, welche FPGAs diese Person einsetzt. Falls diese Person Xilinx nutzt, so ist Core3S500E geeignet. Die Person kann dann bzgl. Programmieradapter beraten... ...wer ein hochwertiges, qualitatives Möbelstück selbst herstellen möchte, muss (Hobby-)Schreiner werden. Wahrscheinlich wird das erste Werkstück nicht die beste Qualität haben... ...in einem Schrauberforum könntest Du fragen, welchen V6 Du am besten in Deinen Golf3 einpflanzen sollst, oder ob es einen R5 gibt, mit dem das besonders einfach geht... ..und hier kann man fragen, ob es mit FPGAs geht oder besser mit uCs.
Lothar M. schrieb: > Und vor die Frage kommt hier die Antwort: > Nein, es ist nicht einfach, zwei solcher Boards miteinander zu > verbinden. Ist es nicht möglich einfach eine Verbindung per SPI umzusetzen?
Lothar M. schrieb: > Es reicht für den Anfang zum Lernen, aber später brauchst du schon noch > ein paar Pins für was Anderes (z.B. Debugging, RS232, LEDs...). Kann ich den vorhandenen USb eigentlich auch dazu nutzen Daten mit dem Host PC auszutauschen, oder ist er nur für die Programmierung gedacht?
irge schrieb: > Kann ich den vorhandenen USb eigentlich auch dazu nutzen Daten mit dem > Host PC auszutauschen, oder ist er nur für die Programmierung gedacht? Der FTDI-Chip auf dem MACH-XO2-Breakout-Board hat zwei Kanäle. An dem einen hängt JTAG und auf dem anderen kann man UART machen. Für UART müssen noch zwei Lötbrücken gesetzt werden. Duke
irge schrieb: > Kann ich den vorhandenen USb eigentlich auch dazu nutzen Daten mit dem > Host PC auszutauschen, oder ist er nur für die Programmierung gedacht? Kommt auf das konkrete Board an. Das MachX02 Board kanns, aber meist ist der USB-Port nur der Programmieradapter. Für eine serielle Schnittstelle brauchst du dann noch den zusätzlichen RS232TTL-USB-Adapter für ca. 3,50€ aufwärts... http://www.ebay.de/sch/i.html?_from=R40&_sacat=0&_nkw=ftdi+usb+ttl&_sop=15
:
Bearbeitet durch Moderator
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.