FPGA für Zeitmessung

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.

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 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?

Ü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.

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.

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?

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

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

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.

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?

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.

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.

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?

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

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