USB & die X10 Fernbedienung

[Falko]

@mpz

suche schon den Thread mit den PIC und USB schon die ganze Zeit. Den Bauplan für die verwendung es PIC auch noch.
Gib mir doch mal bitte den Links dazu.

Danke

Ich denke die Suchfunktion hier im neuen Forum müsste jetzt wieder korrekt funktionieren, nachdem ich
die Suche selbst von ca. 12.00Uhr bis heute Abend 21.40Uhr neu indiziert habe. Könnte das dieser Thread bzw. topic gewesen sein?

http://www.purebasic.fr/german/viewtopi ... 14#p123014

Gruß Falko

[mpz]

Hi,

ja das war meine Bauanleitung mit Stromlaufplan, PIC Programm und PB Steuerungsprogramm. Der Vorteil ist das man einzelne Elemente benutzen kann und die anderen Elemente (termo, Ir Empfänger etc.) einfach weglassen kann...

Gruß Michael

[laserjones]

So, ich bin wieder einen kleinen Schritt weiter mit der Adaption deines Programms. Ich habe jetzt deinen Code auf eine Reportlänge von 1 Byte geändert (passend zu meinem PIC-Testprogramm) und alle Zeilen rauskommentiert, in denen höhere Array-Elemente als BufferIn/Out(0) benutzt werden. Dann habe ich eine Zeile eingebaut, die mir nach dem Lesen des Empfangspuffers den Wert von BufferIn(0) anzeigt. Wenn ich dann mit einem deiner Buttons eine 0 über BufferOut(0) sende, wird diese vom PIC zurückgesendet und als empfangen angezeigt. Nur seltsamerweise klappt das nur mit 0. Sende ich einen anderen Wert, wird überhaupt nichts empfangen. Hat jemand eine Idee, woran das liegen könnte?

Wenn ich parallel das HID-Terminal laufen lasse, werden die empfangenen Nullen auch dort korrekt angezeigt. Allerdings: Wenn ich über das HID-Terminal z. B. den Wert 121 (dezimal) sende, wird dieser vom Terminal auch wieder als 121 empfangen - das PB-Programm hingegen zeigt hier wieder eine empfangene 0 an. Das könnte jetzt mehrere Gründe haben: Entweder stimmt was in dem PB-Progamm nicht und es wird nicht der tatsächlich empfangene Wert angezeigt, oder der USB-Empfangspuffer wird vom HID-Terminal nach dem Auslesen auf 0 zurückgesetzt und das PB-Programm liest ihn dann minimal später aus. Kann das sein?

[Helmut]

Dank Michaels Code und meinem Spieltrieb habe ich schon einiges mit USB-HID-Devices gemacht.
Nicht unbedingt, aber auch mit Purebasic geht einiges.
So ein bischen in die Richtung Hausautomation geht es hier:

http://www.ip-symcon.de/forum/f19/feuch ... #post63929

Eine Anwendung auch mit USB-HID (2.Bild von links) gibt es hier

http://www.ip-symcon.de/forum/f19/touch ... #post46584

Wird viel über das IPSymcon-Programm gemacht, habe aber auch schon GUI mit Purebasic gemacht.
So ala Grundriss mit eingeblendeten Leuchte und Steckdosen, die man dann per Gadget Toggeln kann.

Da hat mit Michaels Programm sehr geholfen, aber seinen Level hat es nicht!!

Aber alles nur Basteleien!!

[laserjones]

Wenn ich über das HID-Terminal z. B. den Wert 121 (dezimal) sende, wird dieser vom Terminal auch wieder als 121 empfangen - das PB-Programm hingegen zeigt hier wieder eine empfangene 0 an. Das könnte jetzt mehrere Gründe haben: Entweder stimmt was in dem PB-Progamm nicht und es wird nicht der tatsächlich empfangene Wert angezeigt, oder der USB-Empfangspuffer wird vom HID-Terminal nach dem Auslesen auf 0 zurückgesetzt und das PB-Programm liest ihn dann minimal später aus. Kann das sein?

Die letzte Frage kann ich mir inzwischen selbst beantworten: Ich habe jetzt das PIC-Programm so geändert, dass es jedes an den PIC gesendete Byte mit einer "42" beantwortet. Das funktioniert auch, wie ich im HID-Terminal sehen kann. Wenn ich nun aus dem modifizierten Michael-Programm (MMP) per Button eine 0 sende, wird nach wie vor eine 0 als empfangen angezeigt, obwohl es eine 42 sein müsste. Das ist unabhängig davon, ob das HID-Terminal parallel läuft. Der Fehler muss also im PureBasic-Code liegen. (Nach wie vor wird auch gar nichts empfangen, wenn ich etwas anderes als 0 sende.)

Kann jemand helfen?

[mpz]

Hi,

was erhältst Du den wenn Du die Input / Output Datenlänge des PIC Programms ausließt?

Code: Alles auswählen

AddGadgetItem(#Listview_0,-1, "Input Datenlänge in Bytes = "+Str(hidGetInputReportLength (DeviceHandle.l)))
AddGadgetItem(#Listview_0,-1, "Output Datenlänge in Bytes = "+Str(hidGetOutputReportLength (DeviceHandle.l)))

gruß Michael

[laserjones]

was erhältst Du den wenn Du die Input / Output Datenlänge des PIC Programms ausließt?

Mehrere interessante Phänomene:

1. Fehlermeldung, dass die Konstante #Listview_0 unbekannt sei. Ich habe sie daher durch #Listview_INPUT ersetzt wie bei den sonstigen Textausgaben. Damit geht es.
[Nachtrag: Sehe gerade, dass dein Code in diesem Thread ganz anders aussieht als meine Version - habe offenbar eine alte Version, die speziell für deinen PIC mit Temperaturmodul usw. ausgelegt war ...]

2. Ich habe deine beiden Zeilen in der WinProc direkt hinter "If DeviceHandle" eingefügt. Interessanterweise wird dieser Programmteil anscheinend dreimal durchlaufen, denn ich bekomme die Ausgabe dreifach. Ich hätte erwartet, dass das nur einmal durchlaufen sollte (Initialisierung nach Erkennen des Gerätes).

3. Es wird eine Input/Output-Datenlänge von 2 ausgegeben. Der USB-Deskriptor für meinen PIC ist aber definitiv auf eine Reportlänge von 1 eingestellt. Das wird vom HID-Terminal auch so angezeigt. Verpasse ich dem PIC eine Reportlänge von 2, zeigt dein Programm 3 an. Stelle ich sie aber auf 0, zeigt auch dein Programm 0 an. Bei den zuletzt genannten beiden Einstellungen empängt dein Programm überhaupt keine Daten vom PIC.

[Rödel, rödel, test, hack ...]

Aha!!! Wenn ich zum Senden und Empfangen BufferOut/In(1) statt BufferOut/In(0) benutze, dann funktioniert plötzlich alles wie gewünscht! Ich habe das dumpfe Gefühl, dass das Problem irgendwie mit den Arraylängen in PB zusammenhängt. Genau verstanden habe ich es allerdings noch nicht. Wenn die Reportlänge 1 ist, sollte doch auch das erste Byte des Buffer-Arrays (0) relevant sein und nicht das zweite (1)? Und selbst wenn PB von einer Reportlänge von 2 ausgeht (warum auch immer), müsste man das erste (und hier einzig relevante) Byte doch trotzdem im Element (0) des Arrays finden, oder? Sehr seltsam.

Wäre noch interessant, was passiert, wenn man einfach eine normale Byte-Variable statt eines Arrays als Buffer nimmt, da ja ohnehin nur ein Byte benötigt wird. Aber da das Programm ja offenbar immer mindestens eine Reportlänge von 2 annimmt, wird das vermutlich Probleme geben.

Wie auch immer, dein Tipp hat es zum Laufen gebracht - vielen Dank!

[mpz]

Hi Laserjones,

das Program zeigt hier die "wirkliche Länge" an. Ich vermute einmal das das erste Byte ein Informationsbyte ist und dann erste die Daten kommen. Um das genau zu sagen müsste ich mich wieder reinknien. aber Hauptsache Dur kannst was damit anfangen...

Gruß Michael

[Helmut]

Kann auch sein, dass Buffer(0) den Describtor 0 vom USB-Gerät beschreibt.
Siehe Erklärung PIC-Guro-Sprut hier:
http://www.sprut.de/electronic/interfaces/usb/usb.htm

@Laserjones
nach deiner "42" bist du mit mikroe unterwegs, kann das sein?
Gruß Helmut

[laserjones]

Da schau her ... Bei Sprut habe ich schon oft rumgesurft (ohne ihn wäre ich verloren), aber diese Seiten hatte ich noch gar nicht entdeckt.

nach deiner "42" bist du mit mikroe unterwegs, kann das sein?

Ja, habe das EasyPIC4-Development-Board und MikroPascal. Das nimmt einem die PIC-seitige Arbeit für HID fast komplett ab - man muss nur noch VID/PID, Hersteller-/Produktname und Reportlänge festlegen, die ganzen Deskriptoren werden dann automatisch erzeugt. Mit dem mitgelieferten HID-Terminal kann man den Datenverkehr dann beobachten. Von Mikroelektronika stammt auch das Testprogramm, das die empfangenen Daten einfach zurücksendet. Aber die Modifikation mit der "42" ist meine eigene wahnsinnskreative Leistung! Daher erstaunt mich, dass du ausgerechnet daraus auf Mikroelektronika geschlossen hast.