FPGA Firmware 1.1b ( IDN =2.0 ) , PUT geht, GET nicht

[HSiebrecht]

Hallo zusammen,


endlich Winterzeit = Bastelzeit, jetzt kann es mit dem c't Lab ja weitergehen, und auch noch Spätdienst.

Spaß beiseite, habe die Firmware 1.1b ( 2.0 laut IDN ) ins FPGA geflashed und mit LabScript etwas herumgespielt.


@cm, Danke, tolle neue Features, QVGA-Treiber FPGA funktioniert einwandfrei.


Nun zu meinem Problem, es gelingt mir nicht Daten von anderen Modulen auszulesen, um sie z.B. auf dem VGA Monitor anzuzeigen oder anderweitig zu verarbeiten. Es sieht so aus, als würde der GET Befehl nicht richtig funktionieren, mit PUT habe ich keine Probleme.

- Das FPGA ist das erste Modul in der OPTO Bus Kette.

- Nachfolgend mal die Ein- und Ausgaben meines Versuches den Port 30 vom ADA-IO Module ( erster Port der IO8-32 ) auszulesen.

5:IDN?
#5:254=2.0 [FPGA by CM/c't 06/2008]
0:IDN?
#0:254=1.732 [ADA by CM/c't 04/2007; I/O-Cards: DA16 AD16 IO32 LCD ]

5:ACC?
#5:300=0.00000

5:REG1?
#5:301=0.00000

5:MCH=0
5:SCH=30

0:VAL30=241 -----> funktioniert, Panelanzeige = F1h = 241

5:GET0?
#0:30=241

ACC?
#5:300=0.00000 -----> hier erwarte ich den Wert von Port 30 = 241

REG0? ----------------> Zum Testen auch mal REG0 = ACC = Akku abgefragt.
#5:300=0.00000

GET1? ----------------> Wie oben mal Test mit REG1
#0:30=241
5:REG1?
#5:301=0.00000

- Jetzt mal PUT getestet

5:REG1=128
5:REG1?
#5:301=128.000

5:PUT1 -----> funktioniert, Port 30 = 128, Panelanzeige = 80h = 128

0:VAL30?
#0:30=128

REG1?
#5:301=128.000


Habe ich hier einen Denkfehler, oder haben wir es hier mit einem " PEBCAK " zu tun.

Könnt Ihr das mal bitte ausprobieren, ggf. wenn keine IO8-32 vorhanden mal Port 20 DA Kanal nehmen, hat bei mir auch nicht funktioniert.

[ompf]

Nun zu meinem Problem, es gelingt mir nicht Daten von anderen Modulen auszulesen, um sie z.B. auf dem VGA Monitor anzuzeigen oder anderweitig zu verarbeiten. Es sieht so aus, als würde der GET Befehl nicht richtig funktionieren, mit PUT habe ich keine Probleme.

- Das FPGA ist das erste Modul in der OPTO Bus Kette.

Damit hast Du ja schon die Antwort. Das FPGA ist das erste Modul, d.h. die anderen folgen in der Befehlskette.

* Du tippst was ein, das geht zum FPGA, dann zur ADA, dann zum Bildschirm.
* Das FPGA tippt was ein, das geht zur ADA, dann zum Bildschirm.
* Die ADA sendet was, das geht zum Bildschirm.
* ...

Um die Daten nachfolgender Module empfangen zu können, müßte über einen zweiten UART der Rückweg des Optobus ebenfalls ausgewertet werden.


Gruß
Patrick

[magicroomy]

Hi,
ja, das FPGA Modul kann leider die Antworten der Module nicht empfangen. Es wäre sensationell wenn es zumindest für FPGA möglich wäre den Rückkanal über Steckbrücken in einen zweiten UART des AT-Mega auf dem FPGA Modul zu leiten.
Wenn das FPGA dann das erste im Optobus ist, dann könnte man das FPGA Modul mit erweiterter Firmware zur Auswertung des Rückkanals auch als Steuerzentrale für das c't Lab benutzen ohne einen PC zu brauchen. Mit Huckepackplatine noch eine Tastatur anschließen, und und und.

Gruss
Magic Roomy

[ompf]

Wenn das FPGA dann das erste im Optobus ist, dann könnte man das FPGA Modul mit erweiterter Firmware zur Auswertung des Rückkanals auch als Steuerzentrale für das c't Lab benutzen ohne einen PC zu brauchen.

Man kann zumindest den Optobus so umverdrahten, daß das FPGA sendet und empfängt. RxD und TxD werden dann so verschaltet wie die Leitungen des MAX232 der IFP.

Damit ist der PC natürlich raus. Wenn der mitspielen soll, wäre eine Oder-Verknüpfung denkbar, wie in der IFP. Hier hängen ja FTDI und MAX auch an der selben Schnittstelle. Kollisionsvermeidung ist dann natürlich Sache des Anwenders.


Gruß
Patrick

[HSiebrecht]

Hallo zusammen,

erst einmal Danke für Eure Antworten, habe da aber eine Verständnis Frage, oder auch mehrere.

Alles was ich probiert hatte waren ja Befehle die die Firmware des ATmega ausführt,
der eigentliche FPGA Chip ist ja aussen vor.

Mal kurz ein Abschnit aus dem c't-Lab Wiki / Ergänzungen / Berichtigungen FPGA LabScript.

" Ebenso ist es möglich, über das Script Befehle/Abfragen an andere c't-Lab-Module abzusetzen,
dafür muss das FPGA-Modul aber das erste in der OptoBus-Kette sein. "

Stelle mir das so vor :
===============

- Erstes Modul in der OptoBus-Kette ist FPGA, ist ja so.

- Mit MCH und SCH werden Modul und Subchannel Adresse gesetzt um Befehle / Abfragen an andere Module zu senden.

- FPGA-Modul Firmware, die im ATmega, gibt beim GET Befehl diese Werte auf dem Opto-Bus aus, in meinem Beispiel
MCH=0 , Modul = 0 bei mir = ADA-IO
SCH=30 , Subchannel = 30 = Erster Port der IO8-32

- Also 0:30

- Dieser Wert läuft jetzt über den Opto-Bus durch alle nachfolgenden Module, bis zur ADA-IO, in meinem Fall das letzte Modul in der Kette.
ADA-IO interpretiert Modul und Subchannel und reagiert auf diese Abfrage mit dem Ergebnis, in meinem Beispiel 0:30=241 und liefert diesen Wert auf dem Opto-Bus. Jetzt geht es ja rückwärts durch alle Module bis zum FPGA-Modul und schliesslich zur IFP und raus zum Terminalprogramm.
Damit das beim GET Befehl funktioniert muss IMHO die "FPGA-Modul Firmware" ( ATmega-Firmware ) auf den String 0:30 reagieren und das Ergebnis in das entsprechende Register ( FPGA-Modul / ATmega Firmware Register, nicht FPGA Register ) schreiben. Dazu müsste das FPGA ( erstes Modul in der Opto-Bus Kette ) ja auf der Receive Leitung "sniffen" können, aber wie ?

- In meinem Beispiel sieht das ja noch gut aus :

5:GET0? ---> Abfrage
#0:30=241 ---> Antwort

Leider landet das Ergebnis 241 nicht im Register 0 = Akku der "FPGA-Modul Firmware" ( ATmega-Firmware ), dies ist ja mein Problem.

Wenn das ja nicht funktionieren sollte, für was brauchen wir dann den GET Befehl. Auszug aus der Doku :
GET 400..409 GET <zielregister>? 400..409 Warte auf Ergebnis, speichere in Registerinhalt 0..9
auf angeforderten Wert warten (#X:XXX gleich Kanal-Match) und in Register <labelnr> (0..31)
speichern


Es gibt jetzt mehrere Möglichkeiten, voll zu spät, nix kapiert oder voll einen an der Kappe.

Mit der Bitte um Aufklärung, Dankeee

[psclab38]

- Dieser Wert läuft jetzt über den Opto-Bus durch alle nachfolgenden Module, bis zur ADA-IO, in meinem Fall das letzte Modul in der Kette.
ADA-IO interpretiert Modul und Subchannel und reagiert auf diese Abfrage mit dem Ergebnis, in meinem Beispiel 0:30=241 und liefert diesen Wert auf dem Opto-Bus. Jetzt geht es ja rückwärts durch alle Module bis zum FPGA-Modul und schliesslich zur IFP und raus zum Terminalprogramm.

Im Prinzip hast Du recht, aber die Daten gehen auf dem Rückweg durch alle Module nur elektrisch zurück, werden aber nicht durch die jeweiligen Steuerprozessoren geleitet, das passiert nur auf dem Hinweg. Die Daten des physikalisch letzten Moduls in der Kette gehen damit von den anderen Modulen ungesehen an die IFP zurück. Damit kann der FPGA-Steuerprozessor diese Daten gar nicht lesen.

Eine Idee, das zu umgehen, ist weiter oben schon mal erwähnt worden, nämlich dem FPGA-Modul einen zweiten UART zum Lauschen zu spendieren. Das ist SO aber noch nicht vorgesehen.

Viele Grüße
Paul

[HSiebrecht]

Hallo zusammen,

Im Prinzip hast Du recht, aber die Daten gehen auf dem Rückweg durch alle Module nur elektrisch zurück, werden aber nicht durch die jeweiligen Steuerprozessoren geleitet, das passiert nur auf dem Hinweg. Die Daten des physikalisch letzten Moduls in der Kette gehen damit von den anderen Modulen ungesehen an die IFP zurück. Damit kann der FPGA-Steuerprozessor diese Daten gar nicht lesen.

Hatte ich ja auch so geschrieben, sehe ich ja auch so.

Leider beantwortet das aber nicht meine Frage :

Wenn das ja nicht funktionieren sollte, für was brauchen wir dann den GET Befehl. Auszug aus der Doku :
GET 400..409 GET <zielregister>? 400..409 Warte auf Ergebnis, speichere in Registerinhalt 0..9
auf angeforderten Wert warten (#X:XXX gleich Kanal-Match) und in Register <labelnr> (0..31)
speichern

Irgendwelche Ideen ?

[magicroomy]

Hi,
ist eine sehr gute Frage wegen dem GET.
Also nach der oben einstimmig erörterten Theorie kann ein vom FPGA ausgelöster GET nicht funktionieren.

CM schreibt aber auch...
"Prinzipiell ist LabScript völlig unabhängig von der Nutzung des FPGA. In Verbindung mit dem VGA-Interface ..."
Evtl. bastelt er an einem Labscript Interpreter für den PC. Dann würde es funktionieren. Das ist aber nur eine Vermutung.

=> Nur CM kann hier Licht ins Dunkel bringen.

Gruß
Magic Roomy

[ompf]

"Prinzipiell ist LabScript völlig unabhängig von der Nutzung des FPGA. In Verbindung mit dem VGA-Interface ..."

Im Prinzip ja, aber...

Steck die nachfolgenden Module an OptoOut vom FPGA und steck einen Loopback-Stecker (siehe Leser-Wiki im Heise-Forum) auf Opto-In. Jetzt kannst Du senden und empfangen. Funktionable Firmware vorausgesetzt.

Dein PC darf nun aber nicht mehr mitspielen.


Andere Lösung: guck Dir auf der IFP an, wie da RxD und TxD vom MAX232 angeschlossen sind: einmal einfach abgegriffen und einmal über eine Diode eingekoppelt. Genauso schließt Du jetzt RxD und TxD vom FPGA-Atmel an die IFP an. Jetzt noch ne Masse rüberziehen, und fertig. Schon darf der ATmega gleichberechtigt mit USB und RS-232 mitquatschen.

Die restlichen Module werden am OptoOut der IFP angestöpselt.

Die Potentialtrennung zwischen PC und FPGA ist jetzt allerdings hin, da ja der Optobus weg ist.



Gruß
Patrick

[EXA]

Hallo zusammen, nur mal so ne Idee zur Diskussion in den Raum geworfen:
Wie wäre es denn mit einer Art "Optobus Splitter". Ein Atmel/PIC mit zwei "Master" Eingängen (einen Für IFP und einen Für FPGA), auf denen das Senden und Empfangen für die komplette Modulkette möglich ist. An die "Slave" Ausgänge kommen die Module (recht viel mehr als 8 braucht mann nicht, weil eh nicht mehr in ein 19" Rack passen). Der Splitter sortiert jetz die Auflaufenden Befehle und schickt sie an den passenden Slave Ausgang.
Zum Beispiel: Ein Befehl "0:***" trifft an MasterEingang_1 (vom IFP kommend) auf. Der Splitter leitet den Befehl dann an MasterEingang_2 (FPGA) und an SlaveAusgang_0 weiter. Hierbei muss die Moduladresse natürlich mit der SlaveAusgangsadresse übereinstimmen. Das selbe passiert für die Empfangsseite in umgekehrter Reihenfolge.
Das hätte den Vorteil, dass die Befehle nicht die komplette Modulkette durchlaufen müssen. Außerdem könnte man Prioritäten für einzelne Module vergen, die dann schneller behandelt werden. Der Controller bräuchte vermutlich ein FIFO.

Wie gesagt, nur mal so ne Idee ...

MfG
EXA

[amd-65]

Hi,

wenn man Modulen untereinander agieren lassen will, muß man für Module, die Befehle senden können, folgendes implementieren:
- Selbst gesendete Befehle werden nicht weiter geleitet, wenn diese wieder empfangen werden.
- Antworten auf selbst gesendete Befehle werden nicht weiter geleitet.

Auf der PC-Seite muß man folgendes implementieren:
- Befehle, die nicht selbst gesendet wurden, werden weiter geleitet.
- Antworten, für die keine Befehle gesendet wurden, werden weiter geleitet. Ein paar spezielle Antworten, z.B. Debug-Meldungen von (meiner) DCG-Firmware dürfen nicht weiter gesendet werden.

Man könnte dann auch ein 'Super-Panel-Modul' entwickeln, über das man ohne PC oder parallel zum PC, alle Module bedienen könnte.

Gruß
amd-65

[ompf]

wenn man Modulen untereinander agieren lassen will,

...dann hätte man sich eigentlich für ein sternförmiges Bussystem entscheiden sollen, welches auch ruhig etwas performanter hätte sein dürfen. c't-Lab ist low-cost, also RS-485. Mit etwas mehr Budget wäre auch CAN oder GPIB oder Ethernet drin.


Aber die Idee einer Weiterleitung der Antworten auf nicht selbst gesendete Befehle durch den PC ist gut -- dies entspricht ja quasi dem aufgesteckten Loopback-Stecker. Damit wäre zumindes HSiebrecht's originäres Problem gelöst -- das FPGA kann was empfangen.

Nun muss also jemand einen Papagei in Labview basteln.


Gruß
Patrick

[guenter1604]

Hallo,
>Man könnte dann auch ein 'Super-Panel-Modul' entwickeln, über das man ohne PC oder parallel zum PC, alle Module bedienen könnte.

Also ein Modul mit Tastaturanschluss, Fernbedienungsempfänger und Display?

http://www.gerold-online.de/cms/index.php?id=136

Günter

[magicroomy]

Ja, so ähnlich, aber es sollte schon programmierbar sein, und zwar ohne Programmieradapter. Da ist das FPGA schon die beste Wahl.

Gruss
Magic Roomy