Pages: 1 ... 3 4 [5] 6 
|
 |
|
|
Author
|
Topic: CAT Funktion eingebaut (Read 11649 times)
|
|
DB4PLE
positron
Urgestein
 Offline
Posts: 1278
|
 |
Re:CAT Funktion eingebaut
« Reply #60 on: 08. April 2016, 16:21:15 »
|
|
Hallo Astralix,
modemmanager und Co. hast Du schon als Störenfriede ausgeschlossen?
lsof | grep /dev/ttyACM
könnte noch hilfreich sein.
73
Danilo
|
|
 Logged
|
|
|
|
DC3AX
Interessent
noch länger dabei
Offline
Posts: 186
Ich liebe dieses Forum!
|
|
Re:CAT Funktion eingebaut
« Reply #61 on: 08. April 2016, 20:30:32 »
|
|
Gehen wir mal systematisch ran:
Der Stand ist wie gestern: Sound geht, Serielle nicht.
Also mit System:
1) Programme:
fldigi, flrig, hamlib (und damit rigctl) sind aus den latest greatest Quellen neu gebaut und korrekt installiert.
which [datei] zeigt den für Ubuntu korrekten Pfad /usr/bin/[datei] an und die meisten Versionsnummern sind nun höher als zuvor.
2) Kabel
Zur Sicherheit habe ich mal das augenscheinlich sehr dünne China-USB-Kabel gegen ein hochwertiges getauscht. Wie erwartet kein Unterschied, denn wenn Sound geht, sollte auch UART gehen.
3) Device
Bus 003 Device 010: ID 0483:5732 STMicroelectronics
Ist da, na logisch, Sound geht ja
3) Modemmanager
Ich habe keinen modemmanager, der wäre mir eh immer nur im Weg, weil ich täglich mit zig UART Platinchen aller Marken am Rechner arbeite. Es gibt keinen Service der laut lsof an den Files ttyACM oder ttyUSB hängt.
Der Modemmanager war mir schon vor Jahren immer im Weg, wenn ich Embedded oder ARM Linux gemacht habe, daher ist der mit apt-get remove --purge ganz schnell abgeflogen.
Trotzdem ps aux | grep modem ergibt keinen Treffer (außer der suche selbst)
4) Fremde Dienste blockieren den Port
Eigentlich sollte das einen Fehler produzieren, der wird in den Programmen aber vielleicht nicht abgefangen?
Also picocom -b 115200 /dev/ttyACM0 behält die Verbindung. Wäre das File anderweitig verbunden, meldet picocom das und beendet sich selbst.
lsof | grep "/dev/ttyACM" findet keine Verbindung auf den Port.
5) Rechte
crw-rw-rw- 1 root dialout 166, 0 Apr 8 21:36 /dev/ttyACM0
crw-rw---- 1 root dialout 4, 64 Apr 8 21:26 /dev/ttyS0
...
crw-rw---- 1 root dialout 4, 73 Apr 8 21:26 /dev/ttyS9
crw-rw-r-- 1 root dialout 188, 0 Apr 8 21:26 /dev/ttyUSB0
Natürlich ist mein user in der Gruppe dialout.
6) Noch mal testen...
:~$ rigctl -m 120 -r /dev/ttyACM0 -v
Opened rig model 120, 'FT-817'
Rig command: f
rigctl_parse: input_line: f
get_freq: error = Communication timed out
Wie ich es drehe und wende, der Port nimmt entweder nix an, oder er gibt nichts zurück... Ich teste mal weiter.
vy 73
Ulrich
|
|
Logged
|
Es gibt drei binäre Zustände: Ein, Aus und Vielleicht. Je höher die Frequenz, desto Vielleicht...
|
|
|
|
|
DC3AX
Interessent
noch länger dabei
Offline
Posts: 186
Ich liebe dieses Forum!
|
|
Re:CAT Funktion eingebaut
« Reply #63 on: 08. April 2016, 21:59:54 »
|
|
Danke Markus,
war eine Idee, aber nichts neues 
Habe mal gerade einen Raspi 2 mit aktuellem MATE bestückt und das fldigi Paket installiert.
mcHF dran, Soundkarte da, ttyACM0 auch...
Leider das gleiche Verhalten. Sound wird dekodiert, aber Steuerung via CAT geht nicht.
Ist es denn immer noch korrekt, dass man in der hamlib die Yaesu FT817 auswählt?
Auch auf dem raspi meldet rigctl -m 120 -r /dev/ttyACM0 dass get_freq: error = Communication timed out
Das wird heute nix mehr
vy 73
Ulrich
|
|
Logged
|
Es gibt drei binäre Zustände: Ein, Aus und Vielleicht. Je höher die Frequenz, desto Vielleicht...
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:CAT Funktion eingebaut
« Reply #64 on: 08. April 2016, 22:19:45 »
|
|
Hallo,
FT-817 ist absolut korrekt. Ich werde es im Laufe des kommenden Tages nochmal anschauen. An der CAT Emulation und dem USB Code habe ich schon eine Weile nichts geändert und auch niemand anderers.
Schon komisch.
Worauf der mcHF unheimlich allergisch reagiert sind "falsche" Zeichen. Das Protokoll is 5 Byte lang. Wenn da auch nur 1 Zeichen Versatz drin ist, wird es nie was, weil man am Protokoll nicht erkennen kann, wann ein 5 Byte Block anfängt.
Das wird im echten Gerät über einen Timeout geregelt. In der mcHF Emulation noch nicht.
Sollte ich aber mal einbauen.
Im Zweifel sich einfach mal mit dem ST-Link auf die entsprechende Funktion im mcHF legen und schauen was da ankommt.
73
Danilo
|
|
Logged
|
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:CAT Funktion eingebaut
« Reply #65 on: 09. April 2016, 05:58:09 »
|
|
Hallo,
am Raspi 2, Rasbian, fldigi aus dem Repository, aktueller devel-DF8OE Source (!, ich baue selbst):
Es funktioniert sowohl CAT als auch Audio problemlos.
Kabel?
73
Danilo
|
|
Logged
|
|
|
|
|
|
DC3AX
Interessent
noch länger dabei
Offline
Posts: 186
Ich liebe dieses Forum!
|
|
Re:CAT Funktion eingebaut
« Reply #67 on: 10. April 2016, 09:04:01 »
|
|
Hallo!
Danke für die Ideen!
Ich werde mal das Binary probieren. Habe mich mal mit JTAG drauf geklemmt und kann sehen, dass Pakete empfangen werden, deren Inhalt mir jedoch seltsam vorkommt. Allerdings muss ich mir das Prokoll der FT817 erst einmal ansehen, damit ich as beurteilen kann.
Selber bauen:
- fldigi auf dem Linux PC habe ich selber gebaut, es verhält sich identisch, wie das zuvor getestete fldigi aus den Paketquellen.
- fldigi auf dem Raspi ist aus den Paketquellen installiert und verhält sich identisch.
- mcHF ist selber gebaut mit gcc-5.2 und der einzige gemeinsame Nenner bei dem Problem.
Ich verwende einen eigenen Makefile, der aber keine Veränderungen an den Optimierungen vornimmt. Im Grunde wäre es also gut, wenn die Ursache im Compiler / Toolchain liegt, dann könnten wir mal die Probleme in dem Bereich adressieren. Da mache ich mich dann mal ran.
vy 73 de Ulrich
|
|
Logged
|
Es gibt drei binäre Zustände: Ein, Aus und Vielleicht. Je höher die Frequenz, desto Vielleicht...
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:CAT Funktion eingebaut
« Reply #68 on: 10. April 2016, 10:09:00 »
|
|
FT 817 Protokoll: Super simple, immer 5 Bytes. Siehe cat_driver.c, dort stehen im Kommentar die von der Hamlib unterstützten Kommandos.
Letztes Byte ist das Kommando, davor können statt der 0 Daten kommen.
mit #define FT817_DEBUG übersetzt gibt es noch einen Buffer ft817.req[], in dem die empfangenen Daten abgelegt werden (bis er voll ist).
Viel Spaß
Danilo
|
|
Logged
|
|
|
|
DC3AX
Interessent
noch länger dabei
Offline
Posts: 186
Ich liebe dieses Forum!
|
|
Re:CAT Funktion eingebaut
« Reply #69 on: 10. April 2016, 10:25:24 »
|
|
Danke Danilo,
den DEBUG nebst Puffer hatte ich schon entdeckt. Bin nur noch nicht dazu gekommen das auszuwerten. Bei dem Wetter wollen YL und die Hunde an die frische Luft, das wird also bis heute Abend warten müssen.
vy 73
Ulrich
|
|
Logged
|
Es gibt drei binäre Zustände: Ein, Aus und Vielleicht. Je höher die Frequenz, desto Vielleicht...
|
|
|
DC3AX
Interessent
noch länger dabei
Offline
Posts: 186
Ich liebe dieses Forum!
|
|
Re:CAT Funktion eingebaut
« Reply #70 on: 10. April 2016, 17:41:38 »
|
|
Also ich habe mich mal an den USB Code gemacht...
Dabei auch gleich etwas aufgeräumt, da gab es ein paar Unstimmigkeiten.
CatInterfaceState cat_driver_state() { return USBD_User_GetStatus(); }
Dabei wird in
void CatDriverFT817CheckAndExecute() {
bei der Antwort 0xff der Puffer zurückgesetzt, weil wohl angenommen wird, dass keine USB Verbindung mehr besteht.
USBD_User_GetStatus() ist wohl aus den ST-Libs? jedenfalls kennt die eigentlich nur 0 und 1 als Antwort.
Das ist aber nicht das Problem. Bei mir landen die CAT Telegramme um 1 byte nach links versetzt im Puffer, ich habe also nicht
00 00 00 00 03 als GET FRQ AND MODE bsi mir steht da
00 00 00 03 00
Damit ist es also das fehlende Framing, dass da Ärger macht und ehe ich jetzt lange suche, hat jemand eine Funktion im mcHF entdeckt, mit der ich z.B. eine ms genaue Laufzeit bekommen kann?
Dann wäre es sehr einfach, den für das Protokoll notwendigen Timeout zu implementieren.
Ich habe auch schon ein wenig umgestellt, als eine uinion für das Telegramm, ENUMs für die Befehle...
Habe noch ein paar Optimierungen vorbereitet, aber eines nach dem Anderen. Wenn ich mit Timeout die Telegramme korrekt verschieben kann, kann ich die Ausführung von CAT noch deutlich schneller machen.
vy 73
Ulrich
|
|
Logged
|
Es gibt drei binäre Zustände: Ein, Aus und Vielleicht. Je höher die Frequenz, desto Vielleicht...
|
|
|
|
|
DC3AX
Interessent
noch länger dabei
Offline
Posts: 186
Ich liebe dieses Forum!
|
|
Re:CAT Funktion eingebaut
« Reply #72 on: 10. April 2016, 18:43:51 »
|
|
Auch mit dem daily snapshot von hier
http://www.amateurfunk-sulingen.de/mchf-projekt/modifikationen#start
auf der Seite ganz unten habe ich das gleiche Problem.
Sowohl die Linux, wie auch der RasPi mögen nicht.
Habe ja schon gesehen, dass der SysTick auch als solcher verwendet wird, damit habe ich ja dann eine ms Timeout Clock.
vy 73
Ulrich
|
|
Logged
|
Es gibt drei binäre Zustände: Ein, Aus und Vielleicht. Je höher die Frequenz, desto Vielleicht...
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:CAT Funktion eingebaut
« Reply #73 on: 10. April 2016, 18:57:51 »
|
|
Dabei auch gleich etwas aufgeräumt, da gab es ein paar Unstimmigkeiten.
CatInterfaceState cat_driver_state() { return USBD_User_GetStatus(); }
Dabei wird in
void CatDriverFT817CheckAndExecute() {
bei der Antwort 0xff der Puffer zurückgesetzt, weil wohl angenommen wird, dass keine USB Verbindung mehr besteht.
USBD_User_GetStatus() ist wohl aus den ST-Libs? jedenfalls kennt die eigentlich nur 0 und 1 als Antwort.
|
|
Ich habe das auf 0xFF geändert (vorher 0) weil es so nicht funktioniert hat (hat immer zu den Buffer resettet, ist auch logisch, es kommt ja immer wieder 0 wenn man fragt). Vorallem aber war es einfach nicht notwendig, das zu fixen. Hat ja auch so funktioniert.
Das ist aber nicht das Problem. Bei mir landen die CAT Telegramme um 1 byte nach links versetzt im Puffer, ich habe also nicht
00 00 00 00 03 als GET FRQ AND MODE bsi mir steht da
00 00 00 03 00
Damit ist es also das fehlende Framing, dass da Ärger macht und ehe ich jetzt lange suche, hat jemand eine Funktion im mcHF entdeckt, mit der ich z.B. eine ms genaue Laufzeit bekommen kann?
|
|
In der Tat finde ich es verwunderlich, das hier zuverlässig ein Versatz ist. Normalerweise kann das nicht passieren, macht es ja auch bei den meisten nicht. Es werden ja alle 5 Byte in einem USB Packet geschickt. Da ist es schwierig, mittendrin zu unterbrechen. Nur wenn ein Programm dazwischen funkt oder abstürzt, sehr viele Packete hintereinander verschickt werden, ist ein Versatz logisch erklärbar.
Dann wäre es sehr einfach, den für das Protokoll notwendigen Timeout zu implementieren.
|
|
ts.sysclock ca. 10ms Takt (abgeleitet aus 1,5Khz Audio-Interrupt).
Normaler Sysclock interrupt ist nicht angeschaltet.
Ich habe auch schon ein wenig umgestellt, als eine uinion für das Telegramm, ENUMs für die Befehle...
Habe noch ein paar Optimierungen vorbereitet, aber eines nach dem Anderen. Wenn ich mit Timeout die Telegramme korrekt verschieben kann, kann ich die Ausführung von CAT noch deutlich schneller machen.
|
|
Nur zu, ordentliche Strukturen im Code sind willkommen.
Wobei die Performance der CAT Befehle aus meiner Sicht eher nicht so kritisch ist, da sie relativ selten kommen und insgesamt kaum auftragen sollten im Vergleich zum UI, in dem ja ähnliche Funktionen aufgerufen werden und das deutlich mehr Code ausführt. Schaden solte es aber auch nicht.
73
Danilo
|
|
Logged
|
|
|
|
DC3AX
Interessent
noch länger dabei
Offline
Posts: 186
Ich liebe dieses Forum!
|
|
Re:CAT Funktion eingebaut
« Reply #74 on: 10. April 2016, 21:49:37 »
|
|
Danke,
ES GEHT!
Hätte jetzt den SysClock Counter abgefragt, da ich ja nur ein Delta brauche, keinen Interrupt. ts.systime geht aber auch gut.
Es soll ja nur nachgesehen werden, ob der Anfang des Telegramms schon mehr als 200ms in der Vergangenheit liegt, bevor es beendet wurde. Das habe ich jetzt implementiert und es geht!
Eigentlich sollten ja auch nicht mehr als ein Telegramm im USB->CAT Buffer liegen, aber USB und Timing ist so eine Sache, der packt einfach gerade das über den Bus, was gerade da ist. Also lassen wir das erst mal so.
Mir ist beim debuggen aufgefallen, dass im Buffer AT Befehle sind. Ich habe definitiv keinen Modemmanager laufen, aber ich gehe davon aus, dass das udev die Schnittstelle erkennt und eine Hardware-Erkennung dann loslegt um das Gerät zu identifizieren. Dieser Müll verursachte dann einen Offset von 1.
Es ist ebenfalls aufgefallen, dass der USB Stack sich das ein oder andere merkt. So habe ich gleich beim Start des mcHF schon CAT Telegramme empfangen, die ich wohl vorher mal versucht habe zu senden, und die dann wegen JTAG HALT noch im USB Puffer des Host lagen.
Schon jetzt ist ein TODO in der Liste:
Es ist möglich, dass die Kombination aus Schrott im Puffer + Timeout dafür sorgt, dass das erste Telegramm verloren geht.
Ich schreibe das jetzt mal noch schön und teste es, dann mache ich einen Mergerequest.
vy 73!
Ulrich
|
| « Last Edit: 10. April 2016, 21:50:14 by Astralix » |
Logged
|
Es gibt drei binäre Zustände: Ein, Aus und Vielleicht. Je höher die Frequenz, desto Vielleicht...
|
|
|
Pages: 1 ... 3 4 [5] 6 
|
|
|
|
|
|
|
