Hallo zusammen,
ich habe folgende Programm geschreiben um Daten von FPGA an Arduino zu
schicken. Leider schickt der FPGA nach 75 min keine Daten mehr...
anbei schicke ich euch auch das Code,ich konnte die Fehler leider nicht
identifizieren.
könnte jemand mir helfen um den Feler zu finden. Danke
Mampf F. schrieb:> und wohl nicht nochmal neu initialisiert.
Höchstens wenn TX_Start zwischendurch mal wieder inaktiv wird.
Und auch dazu noch ein Wort:
1
if(TX_Start='1'andtxstart1='0')then
Das TX_Start muss unbedingt einsynchronisiert werden, wenn es ein
asynchrones externes Signal ist. Sonst passiert mit den ganzen Zählens
m, i und counter das hier:
http://www.lothar-miller.de/s9y/archives/41-Einsynchronisieren-von-asynchronen-Signalen.html
In meinem Code auf http://www.lothar-miller.de/s9y/categories/42-RS232
ist angenommen, dass dieses TX_Start ein synchrones Signal ist, das von
einem anderen Modul des FPGAs kommt.
Und ich würde diese Verwaltung mit m1=1,m1=3,m1=5, also welches Byte zu
senden ist, ausserhalb der TX-Geschichte machen. So, dass das
Sendemodul tatsächlich einfach nur 1 Byte versendet, wie es eben
zigmilliarden µC auch machen.
Mampf F. schrieb:> Versuch mal den vhdl tag zum Code posten zu nutzen^^
So wie es über jeder Texteingabebox geschrieben steht:
1
Antwort schreiben
2
Wichtige Regeln - erst lesen, dann posten!
3
Groß- und Kleinschreibung verwenden
4
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
Nun, also der Code
- benötigt externe Signale zu denen du nix geschrieben hast. Konkret:
TX_Start. Nach TX_Start sendet der Code 3 Bytes. Mehr konnte ich nicht
beobachten. Ob das also nach langer Zeit nichtmehr funktioniert muss
nicht an dem Code liegen, sondern kann auch daran liegen, dass dann aus
unbekannten Gründen TX_Start ausbleibt.
- verwendet sehr ähnliche Namen
signal txstart : std_logic := '0';
signal txstart1 : std_logic := '0';
TX_Start
Sowas sollte man vermeiden.
- verwendet Variablen ohne Not.
- wenig hilfreiche Kommentare:
i:=600000; ------Anzahl von Daten im Packet
100000(2ms)*(3*2)---2geht high dann low
Mag sein, aber in deinem Code ist kein Signal/Variable das wie ein Paket
aussieht.
if (COUNTER1 < 100000) then
Wie bist du auf diese Zahlen gekommen?
Woher kommt das externe TX_Start das einen Sendevorgang auslöst?
Edit:
txstart <= Trigger;
if (Trigger='0' and txstart='1') then -- steigende Flanke, los
gehts
Ist leider falsch. Das ist die fallende Flanke von Trigger.
Gustl B. schrieb:> txstart <= Trigger;> if (Trigger='0' and txstart='1') then -- steigende Flanke, los gehts> Ist leider falsch. Das ist die fallende Flanke von Trigger.
Der Kommentar ist noch von meinem Originalcode, da bin ich richtig
erschrocken, dass da evtl. noch ein Fehler drin wäre. Ist zum Glück aber
nicht... ;-)
Lothar M. schrieb:> Das TX_Start muss unbedingt einsynchronisiert werden, wenn es ein> asynchrones externes Signal ist. Sonst passiert mit den ganzen Zählens> m, i und counter das hier:> http://www.lothar-miller.de/s9y/archives/41-Einsynchronisieren-von-asynchronen-Signalen.html
Synchronisieren ist nur die halbe Lösung. Die andere Hälfte besteht
darin, eine Replication dieses Signals zu unterdrücken. Dazu gilt es -
plattformabhängig - entsprechende Attribute zu setzen.
Felix schrieb:> Daten von FPGA an Arduino zu schicken. Leider schickt der FPGA nach 75> min keine Daten mehr...
Kann es sein, dass der Arduino nach 75 min keine Daten mehr empfängt
oder dein Terminal oder der USB-Serial-Adapter hängt? Oder wurde das
schon alles ausgeschlossen?
mfg mf
dfIas schrieb:> Synchronisieren ist nur die halbe Lösung. Die andere Hälfte besteht> darin, eine Replication dieses Signals zu unterdrücken.
Aha, hast du dir an dieser Ecke auch mal die Finger verbrannt? ;-)
> Die andere Hälfte besteht> darin, eine Replication dieses Signals zu unterdrücken.
Die Ursache für dieses "Problem" ist die selbe wie der Grund für das
Einsynchronisieren: es darf nicht aus 1 Signal durch (interne)
Laufzeiten zu nachfolgend inkonsistenten Signalen kommen.
Allerdings reicht bei den schnellen Flipflops, die heutzutage in FPGAs
zu finden sind, 1 einziges Flipflop aus, um ein externes Signal nach 1
Taktzyklus trotz jeglicher Metastabilität sicher auf einem definierten
Pegel zu haben. Und ab dann (also in der 2. Ebene) darf es beliebig
dupliziert werden.
Das heißt final, dass ich 3 FFs verwende: das 1. zum eigentlichen
Eintakten (das auch nirgends in einer Abfrage verwendet wird), dahinter
das 2. (ab dem Dupliziert werden darf) und das 3. (das zusammen mit dem
vorigen für die vermutlich sowieso nötige Flankenerkennung eingesetzt
wird).
Und wer trotzdem noch Angst hat, der setzt vor das 1. Flipflop noch
eines, damit jede statistische Wahrscheinlichkeit für ein Fehlverhalten
so klein wird, dass es sogar noch wahrscheinlicher ist, laufend jeden
Samstag 6 Richtige im Lotto zu haben... ;-)
Zu dieser Thematik noch ein Link:
http://www.lothar-miller.de/s9y/archives/62-Testaufbau-Metastabilitaet.html
Und wenn man sich diesen Mechanismus zur vermeintlich allgegenwärtigen
Metastabilität mal angeschaut und durchschaut hat, dann findet man den
Fehler in Videos wie z.B. https://www.youtube.com/watch?v=vw3BG6StOFk
ganz leicht. Das, was dort den Zähler so schnell hochzählen lässt, ist
mitnichten eine Metastabilität, sondern einfach die unterschiedliche
Laufzeit vom Pin bis zu den beiden Flipflops:
http://www.lothar-miller.de/s9y/archives/64-State-Machine-mit-asynchronem-Eingang.html
Achim M. schrieb:> Kann es sein, dass der Arduino nach 75 min keine Daten mehr empfängt> oder dein Terminal oder der USB-Serial-Adapter hängt? Oder wurde das> schon alles ausgeschlossen?
Das Problem hatte ich mal. So wirklich einen Schuldigen konnte ich nicht
finden. Mit Windows stoppte die Übertragung früher als unter Linux. Und
das war auch schlecht reproduzierbar. Ich habe dann aufgegeben und statt
der cp2102 ft232rl verwendet und pyserial. Bei mir kamen die Abbrüche
recht zufällig. Mal nach paar Stunden, mal erst nach Tagen oder gar
Wochen. Könnte auch daran liegen dass das keine konstante Datenrate war.
So, Nachtrag:
Ich habe das jetzt mal simuliert und es wird noch wunderlicher:
Das TXLCD seldet die 3 Bytes nicht jedes Mal wenn TX_Start '1' ist,
sondern nur jedes zweite Mal.
Warum ist das so? Gekürzt:
Gustl B. schrieb:> Ich habe das jetzt mal simuliert
HGW, du bist der Erste, der das tut... ;-)
> und es wird noch wunderlicher
Da bin ich schon wieder erschrocken, weil trotz TXbusy am Ausgang TX nix
zappelt. Aber klar, da wird das txsr-Schieberegister gar nicht
angefasst, behält den Wert x"3ff" und schiebt laufend '1' raus. Da lag
ich mit meinem initialen Misstrauen in diesen Multiplexer gar nicht so
daneben.
Gustl B. schrieb:> das mit dem Code anderer Leute ist nicht gut für den Puls.
Da sagste was. Insbesondere, wenn der Code wild von anderen Seiten
zusammenkopiert ("geschrieben") wurde, irgendwelche planlosen Änderungen
daran vorgenommen wurden, ohne jedoch z. B. die Kommentare anzupassen,
und das Ganze dann vom vollkommen unerfahrenen TO ohne eigene Simulation
und unter Fehlen der Beschreibung der gesamten Peripherie mit der
Fehlerbeschreibung "geht nicht – bitte heile machen" im Forum abgeladen
wird.
Lothar M. schrieb:> Und wer trotzdem noch Angst hat, der setzt vor das 1. Flipflop noch> eines, damit jede statistische Wahrscheinlichkeit für ein Fehlverhalten> so klein wird, dass es sogar noch wahrscheinlicher ist, laufend jeden> Samstag 6 Richtige im Lotto zu haben... ;-)
Nein, die Sache liegt anders. Zur Zeit, als man noch mit Schematic Entry
seine Schaltung vorgegeben hatte, hätte man schon selbst Replizieren
müssen. Das Replizieren haben sich aber die Synthese-Tools angeeignet,
um Fan-outs zu verwalten. Du setzt also vermeintlich ein (einzelnes) FF
vor das Eingangssignal, und ohne es zu merken macht die Synthese daraus
hinterrücks zwei oder mehrere.
Zugegeben, bei derart simplen Schaltungen ist die Wahrscheinlichkeit
einer Replizierung gering, aber theoretisch besteht sie. Ich entwickle
Schaltungen für die Raumfahrt, die haben eine andere Komplexität und mit
Replication muss man fest rechnen. Derlei Ausfälle können/dürfen wir uns
nicht erlauben. Sehr häufig haben wir den Fall, dass für die Entwicklung
auf Flash-basierten FPGAs aufgrund eines größeren Resourcenangebots
keine Replication stattfindet, aber spätestens dann beim Übergang auf
die (kleineren) Rad-hard-Typen. Daher: grundsätzlich auch dem
Synthese-Tool immer mitteilen, dass ein Signal bzw. ein Register nicht
vervielfältigt werden darf, sondern unique bleibt.