WriteSerialPortString()

[PIC18F2550]

Hallo,

ich versuche gerade einen PIC18F2550 mit USBALL10 CDC Version von Sprut, über den Befehl WriteSerialPortString() anzusprechen.
Leider Tut der nix.

Der Chip ist ordnungsgemäß Programmiert und läst sich mit dem USBTEST von Sprut ansteuern, ebenso über die Linuxconsole.

Die Schnittstelle zum Chip wird gefunden und ist richtig eingestellt.
Als Beispiel steht in der Doku der Initalisierungsstring sei "#50-01-00-00-00-00"+chr(0) .

Irgendwie hab ich keine weiteren Ideen um das Problem zu lösen.

[DePe]

Vielleicht musst du vorher mit SetSerialPortStatus() den Status von DTR setzen. Hatte vor kurzen auch so ein Problem, wo ein Gerät ohne DTR nicht geantwortet hat.

Ansonst ich habe PIC18F2550/4550 hier und kann dir eventuell helfen.

Edit: Und du musst WriteSerialPortData() verwenden, wenn du 0-Zeichen (Null) senden musst.

Peter

[NicTheQuick]

Eventuell brauchst du auch #PB_Ascii als Format, obwohl UTF-8 sich ja in den unteren 7 Bit nicht von ASCII unterscheidet.

[PIC18F2550]

Das mit dem SetSerialPortStatus und DTR werde ich heut Abend mal testen.

Ob ich ein 0-Zeichen senden muss kann ich nicht so genau sagen da in der Doku vom USBALL10 das so steht.

Für die MCD Version (binär) mit dll
Der String (0x50-0x01-0x00-0x00-0x00-0x00) macht alle Pins zu Ausgängen.
Der String (0x50-0x01-0xFF-0xFF-0xFF-0x00) macht alle Pins wieder zu Eingängen.

Für die CDC Version (Ascii) COM1
Der String "#50-01-00-00-00-00"+chr(0) macht alle Pins zu Ausgängen.
Der String "#50-01-FF-FF-FF-00"+chr(0) macht alle Pins wieder zu Eingängen.

Beispiel:
Um das LCD1 zu initialisieren muß man folgende 4 Datenbytes zum USB4all senden:
0x55, 0x01, 0x02, 0x16
Für das USB4all-CDC sendet man dafür folgenden 13 Byte langen String:
"#55-01-02-16"+0x00

Es könnte auch sein das das +chr(0) nicht mit gesendet wird weil WriteSerialPortString dort ein datenende vermutet.

Normalerweise benutze ich die MCD Version unter Win und linux aber da es den Treiber nicht in 64Bit gibt binn ich gezwungen auf die CDC auszuweichen

Danke.

[PIC18F2550]

Eventuell brauchst du auch #PB_Ascii als Format, obwohl UTF-8 sich ja in den unteren 7 Bit nicht von ASCII unterscheidet.

Hab ich eingestellt. eine Änderung bringt auch nichts neues.

[DePe]

Also ich habe mir das Hanbuch kurz angeschaut, aber das ist die Rede von 'Bytes' für das Senden und Empfangen. Die Bezeichnung 'String' wird nur im Text als Erklärung verwendet, das sollte man aber nicht wörtlich nehmen denke ich.
Probiere die Daten mit Write/ReadSerialPortData() zu senden und empfangen.

Peter

[PIC18F2550]

MCD Version -> Bytes -> 64 bro Block
CDC Version -> ASCII -> 20 "Bytes" pro Block

[PIC18F2550]

So es läuft jetzt.
Mann sollte schon richtig und bis zum Ende Lesen.

Code: Alles auswählen

Den Beginn eines Kommandostrings kennzeichnet ein ‘#’.
Das Ende eines Kommandostrings kennzeichnet ein Byte mit dem Wert 0x00
(nullterminiert), 0x0A (Zeilenvorschub) oder 0x0D (Wagenrücklauf). Die Gesamtlänge des
String darf nicht größer als 64 sein. Da für ein Datenbyte im String drei ASCII-Zeichen
verwendet werden, ist die Befehlslänge auf 20 Datenbyes begrenzt, was aber nur bei
einigen Blocktranfer-Befehlen eine Einschränkung darstellen könnte.
Beispiel:
Um das LCD1 zu initialisieren muß man folgende 4 Datenbytes zum USB4all senden:
0x55, 0x01, 0x02, 0x16
Für das USB4all-CDC sendet man dafür folgenden 13 Byte langen String:
‘#55-01-02-16’+0x00

Das geht in PureBasic nicht -> ‘#55-01-02-16’+chr($0) weil das das Stringende kennzeichnet.

Aber das geht -> ‘#55-01-02-16’+chr($A) "Zeilenvorschub"

Danke.

[DePe]

Ich habe die Firmware mit einem PIC18F4550 ausprobiert. Den CDC-Treiber habe ich mit Zadig unter Windows 7 x64 installiert. Ein Test mit meinem Skript-Programm hat funktioniert, die Version der Fimware konnte ich richtig abfragen.
Geflasht habe ich direkt die 40-Pin Version ohne Bootloader. Ich habe nur die Taktfrequenz vom Oszillator in der Konfiguration geändert.
Hier ein Screenshot: https://www.dreisiebner.at/temp/PB_Usb4All.png

Ist ein interessantes Projekt von sprut.de, kannte ich nicht.

Peter

[PIC18F2550]

Das war mein 1.Risc Prozessor den fand ich damals schon toll.
Das einzige wass mich immer genervt hat das die Funktionen an bestimmte Pins gebunden waren.

Derzeit hänge ich hauptsächlich am Parallax Propeller1 und Propeller2.
Das sind Risc prozessoren mit 8 Kerne.