Sorry dass ich den uralt Thread ausgrabe - ok.. der ist von 2007.. da stell ich meine Fragen in einem neuen Thread: Da muss ich ja jetzt gute chancen haben ;-) Antworten auf folgende Fragen zu erhalten.... Erst einmal "Ein gesundes Neues Jahr" in die Runde ;-) Alle wieder wohlauf? .. Es geht um folgendes.. der PDIUSBD12 ist in mancher Hardware verbaut worden, besteht die Möglichkeit diesen zu ersetzen? ( FTDI hab ich was gelesen aber ich glaube damit ist nicht das gemeint was ich suche .. ) Ich möchte den USB der unter Windows als Virtueller Com Port installiert wird, als echten RS232 mit einem PIC ( Rx Tx ) nutzen... sowas wie einen USB 2 RS232 gibt es wohl nicht als USB HOST OTG oder`? Ich habe das Datenblatt einmal durchgeflogen... das scheint ein Parallel USB Chip zu sein.. also USB <---D0..D7---- MCE ----D0..D7 ---> USB kann ich den irgendwie in einem Versuch "auslöten" und einen RS232 oder TTL Chip an die D0..D7 hängen ( wenn es sowas gibt .. welchen Chip ? ) .. Könnte ich eventuell die D0..D7 an einen Port eines PIC hängen, z.B. 18F2550 ..? Wäre super wenn mir jemand eine Richtung gibt .. ich möchte meine "Hausaufgabe" demnächst anfangen und wissen, ob das total umsonst sein wird.. weil es nicht geht oder was auch immer... ..ich kann mir auch gut vorstellen, dass es unter Windows einen "wrapper" gibt, und der virtuelle comport nicht so bedient wird, wie ich mir das womöglich "leicht" unter RS232 / Com vorstelle... es wird vieleichtr auch ein bestimmtes Protokoll über den "wrapper" verwendet...das weiss ich leider nicht...noch nicht.. ich stell mir halt vor, dass ich entweder einen PIC24 der USB Host unterstützt und als MINI MINI Weiche dienen soll, den PDIUSBD12 dort anstöbseln kann und die alte Hardware über einen "virtuellen Comport" in diesem Sinne ansteuern kann...indem ich einen zweiten PIC 18F2550 mit dem PIC24 verbinde.. lieber wäre es mir ich könnte alles mit dem 18F2550 machen... oder eben den PDIUSBD12 mit einem anderen "Huckebak" chip an einen RS232 bekomme... ..eiere da schon sehr lange auf Theorie Basis rum. Zum PDIUSBD12 gabs mal ein Developkit.. viel googlen und web archive brachten heraus, dass die Firmware vom PDIUSBD12 nicht ganz ohne ist...( wozu brauche ich die eigentlich? ... ) ...soll ich das lassen oder weiter graben ? ;-)... möcht halt die alte Hardware ( Modem ) das einen USB Anschluss hat ( PDIUSBD12 ) und in WIndows / Linux über einen Virtuellen Com Port angesprochen wird, direkt mit einem PIC verbinden und über ihn steuern ( AT Commands ) ... Danke fürs lesen und für jeden Tip! gruss Rudi ;-)
Der PDIUSBD12 ist kein USB-Host, damit kannst Du keine anderen
USB-Geräte ansteuern.
Um damit zu kommunizieren, brauchst Du einen USB-Host, wie z.B. den
VNC1L von FTDI ("Vinculum").
Zusätzlich musst Du noch das zwischen Modem und USB-Devicetreiber
verwendete Protokoll herausfinden. Das kann CDC sein, das kann aber auch
etwas völlig selbsterfundenes sein, das sich die Leute einfallen ließen,
die das USB-Modem gebaut und den Devicetreiber dafür geschrieben haben.
Dieses Protokoll musst Du nun zusammen mit dem VNC1L nachbilden.
Was ist das für ein tolles Modem, daß Du diesen Aufwand treiben
möchtest?
Hallo Rufus danke Dir! > Um damit zu kommunizieren, brauchst Du einen USB-Host, wie z.B. den > VNC1L von FTDI ("Vinculum"). Ok .. den werde ich mir gleich mal ansehen .. ich glaube jetzt verstanden zu haben.. der VNC1L übernimmt dann die Aufgabe des ganzen PC*S an dem das USB Modem angesteckt wird... oder?... > > Zusätzlich musst Du noch das zwischen Modem und USB-Devicetreiber > verwendete Protokoll herausfinden. Das kann CDC sein, das kann aber auch > etwas völlig selbsterfundenes sein, das sich die Leute einfallen ließen, > die das USB-Modem gebaut und den Devicetreiber dafür geschrieben haben. Und genau da meine ich reden die Leute in den Archiven immer von einer "nicht leichten Firmware"....davon, > > Dieses Protokoll musst Du nun zusammen mit dem VNC1L nachbilden. > ok... > > Was ist das für ein tolles Modem, daß Du diesen Aufwand treiben > möchtest? ;-) für mich ist das schon sehr interessant, Rufus, ich glaube auch für andere. Es gibt da ein uralt Funkmodem mit dem PDISUBD12 als USB Baustein anstatt RS232... ich suche Dir die genauen Daten heute Abend raus und stelle auch ein Bild ein. Habs schon zerlegt ;-)))... btw: es funkt einwandfrei und ist vielseitig verwendbar , aber mit dem PDIUSBD12 hängt man sich an ein System fest ( USB.. Windows... ect ) Es gibt / gab davon auch eine RS232 Version aber das ist total anders aufgebaut.. Mit Adroid Tablet ( OTG ) kann ich das schon mal über VID und PID greifen... ansteuern über die Endpoints ect...folgt noch dazu habe ich mir das Datenblatt des PDIUSBD12 gesucht, dort steht eine Menge von Adressen ect... das muss ich erst noch "lernen"... das Modem überträgt alles transparent ( eingehend Virtueller Com Port über Funk zur Gegenstelle ) und lässt sich mit einer Konfigurations Message auf AT Basis stellen, damit löst sich der Transparent Mode und man kann das Modem einstellen. Zurück gehts dann wiede mit AT Command ... Man kann es auch für RS232 Funkbrücken verwenden... Wenn es ein USB TTL Wandeler wäre ( CP2103 oder so ) dann wäre das super einfach zu handhaben, für Android und auch für MCU ...aber es gibt anscheinend nicht mal mehr Unterlagen zu diesen Develop Tools vom PDIUSBD12..der auch nich so klein ist wenn man da ranlöten will... ..ich stelle die genauen Daten heute Abend mit Bildern rein... Danke einstweilen! Gruss Rudi ;-)
Angehängte Dateien:
-
IMG_1288.JPG
80 KB
Sorry for delay.. ..war leider verhindert. Ok.. es handelt sich um das alte Gigaset M105, der vorgänger M101 hat eine Serielle Schnittstelle, der Nachfolger den USB Baustein. Ich hab mir das mal angesehen Rufus.. .. da gibt es auch anscheinend fertige Eval Boards,. ich bin auf der Suche auf FT120 gestossen, ist das in etwa das gleiche? Auf jeden Fall will ich den USB des M105 auf Seriell bringen.. dachte ich kann mit dem UART des SC14404 irgendwie kommunizieren, aber die Pegel denke ich sind nicht aktiviert (CR16) oder brauchen eine bestimmts Protokoll. jedenfalls ist am Gehäuse des M105 aussen der Zugang zu dem UART per Löcher zugänglich, entweder Firmware ,, oder Prüfen oder was auch immer, hätte mich gefreut, wenn der parallel zum PDIUSBD12 laufen würde... aber die D0-D7 werden wahrscheinlich auf dem SC14404 ganz anders angesteuert und ausgewertet werden. Ich bleibe in jedem Fall da dran, weil mir die Hardware aich heute noch gefällt und die Vorgänger M101 mit sage und schreibe knappen 100 EUR manchmal auch billiger in der Bucht gibt... und die USB dingsen mit Glück für einen EUR.. das wäre doch mal wieder ein interessantes Projekt?! wie die VIP1710 oder??? ;-) Ich werde mich mal mit deinem Link zum Chip auseinande settzen und auch den FT120 mal ansehen.. http://www.ftdichip.com/Support/Documents/AppNotes/AN_209_PDIUSBD12_to_FT120_Migration_Guide.pdf Würde mich freuen wenn ich noch ein paar "Anhänger" überreden kann, da mitzumachen... ich bleibe auf alle Fälle mal dran, Mit ANDROID kann ich schon mal den PDIUSBD12 anfassen und auch vom Androiden Daten über den USB ( OTG ) senden..... der Empfang ist schwieriger ( für mich ) da ich noch nicht geübt bin, den INT als in_end_point abzuhandeln... werde ich aber auch dran bleiben.... wem es interssiert, ich kann ja mal bei Zeiten die APP ( apk ) hier ablegen ( wenn es erlaubt ist ). Das ganze mache ich in Eclipse / Basic4Android wems interessiert ... Mein Ziel ist: Den PDIUSBD12 ( M105 ) an einen Mikrocontroller anstatt einen WIndows PC anzustecken und eben die alte Hardware als DECT Modem zu verwenden, ich habe auch RS232 WIFI Module .. ( kosten ab 25 EUR ) von Microchip die sind mir aber zum basteln zu kostenintensive... Wenn ich einen FTI120 oder eben Deinen genannten Chip brauche für den USB HOST Ersatz, und das ganze dann funktioniert, wäre ich überglücklich. Ich würde dann einen PIC18F2550 als Rudimentären Chip nehmen ( Arduino, AVR ect habe ich leider keine Erfahrung ) und an dem Taster hängen. Der PIC18 soll dann mit dem USB HOST CHIP kommunizieren und die Befehle umsetzen auf den PDIUSBD12 und die Daten über DECT wegsenden... auf der Gegenseite auch wieder die gleiche Hardware , kann dann an einem Windows rechner oder auch Mikrocontroller hängen... und ich kann Steuerungsaufgaben betreiben... da will ich hin ;-)... Wenn einfacher geht oder wer noch einen oder anderen Tip hat, her damit ;-)))... danke fürs Lesen!!! Gruss Rudi ;-)
Rudi schrieb: > Ich würde dann einen PIC18F2550 als Rudimentären Chip nehmen ( Arduino, Nimm lieber einen PIC32MX250F128B, der hat USB OTG, d.h. der kann direkt als USB Host dienen, ohne weitere Bausteine. fchk
Frank K. schrieb: > > Nimm lieber einen PIC32MX250F128B, der hat USB OTG, d.h. der kann direkt > als USB Host dienen, ohne weitere Bausteine. Hi Frank, danke.. ..hast Du mit PIC32 MPLAP Harmony schon mal was versucht? habe den PIC32MX440 128H mit MRF24WB0MB Wifi als Modul..( knapp unter 25 EUR ) das nehm ich her als RS232/RS485/TTL zu WiFi - ist bereits fertig firmware drauf... das gleiche wollt ich jetzt mit dem Gigaset M105 machen, aber der PDIUSBD12 macht mir einfach nicht so mit wie ich will.. :-). Habe mit dem PIC32 selbst nocht keine Erfahrung, will mir demnächst das Harmony mal ansehen.. wie ist der anzugehen, habe PicKit3... wollte die Firmware mal runter nehmen habe aber noch nicht weiter darüber nachgedacht... ob das alles so einfach geht und dann wieder neue Firmware drauf... wie würdest Du den Pic32 proggen? Assembler / c...`? hast Du eventuell USB Host Code Beispiele? Bin ehrlich - habe danach noch nicht gegoogelt ect.. Danke erstmal --- Rudi ;-)
Rudi W. schrieb: > ..hast Du mit PIC32 MPLAP Harmony schon mal was versucht? Nein, das ist mir noch zu neu, das muss noch reifen. Ich bin da etwas konservativ. > wie würdest Du den Pic32 proggen? Assembler / c...`? Niemand programmiert sowas heutzutage mehr in Assembler. > hast Du eventuell USB Host Code Beispiele? Gibts bei Microchip. fchk
Frank K. schrieb: > Nimm lieber einen PIC32MX250F128B, hey Frank.... ..hab mal gegoogelt danach.. der ist ja bastelfreundlich gegenüber den ich da habe... und ist ja auch nicht so kostenintensiv... 3,65 mouser...579-32MX250F128BISP ..den schauh ich mir doch glatt mal genauer an.. danke! Gruss Rudi ;-)
Also hier blickt keine Sau mehr durch! Ich habe vor Jahren den PDIUSBD12 mit einem ATmega8 angesteuert. Das ist auch nicht anders als bei anderer Peripherie, nur das der D12 ein paralleles Interface hat und eben kein SPI oder IIC. Das USB-Protokoll ist aber genau gleich (wie solls auch anders sein). Du musst den EP0 und Interrupt oder Bulk Transfers unterstützen - jenachdem. Ansonsten - wie Rufus schon sagte - ist der D12 ein Geräte-IC und kein Host-IC. Falls Du tatsächlich Hilfe suchst, wäre es ganz gut, wenn Du noch einmal mit einfachen Worten und möglichst strukturiert Dein Vorhaben erläuterst.
Daß in dem Gigaset-Modem ein PDIUSBD12 verbaut ist, ist für die Lösung des Problemes irrelevant. Das Modem ist als "black box" anzusehen, und es muss über USB angesteuert werden. Also geht es darum, einen geeigneten USB-Host zu finden, das ist entweder der VNC1L oder jeder beliebige µC mit USB-Host bzw. USB-OTG-Unterstützung und die dazu erforderliche Software. Die restlichen erforderlichen Schritte (Analyse des vom Gigaset-Modems genutzten USB-Protokolls, Implementieren desselbigen entweder auf dem µC mit USB-Host oder auf dem den VNC1L ansteuernden µC) habe ich weiter oben schon erwähnt. Ich habe allerdings starke Zweifel daran, daß es sinnvoll ist, sich noch mit dem M105 zu beschäftigen. Das ist eine Art USB-ISDN-Karte über DECT, mit der man einen eher sehr langsamen Internet-Zugang über ISDN nutzen kann, wenn man eine der dazu passenden ISDN-Telephonanlagen mit DECT hat. ISDN ist tot. Noch bekommt man mit etwas Mühe zwar noch neue ISDN-Anschlüsse, aber im Wesentlichen wird ISDN nur noch für Bestandskunden weitergepflegt und dann auch funktional zurückgerüstet. In absehbarer Zeit werden auch ISDN-Bestandskunden dazu "motiviert" werden, sich von ihren ISDN-Anschlüssen zu trennen, bzw. diese nur noch mit reiner Sprachtelephonie zu betreiben. Dann gibt es einen VDSL-Anschluss und entweder eine neue Telephonanlage oder eine dicke VoIP-zu-ISDN-Umsetzerkiste, die vor die jeweiligen alten Telephonanlagen gestellt wird. Datenübertragung per ISDN geht spätestens dann nicht mehr. Die ISDN-Technik in den Vermittlungsstellen ist abgeschrieben und wird von den Telekommunikationsunternehmen nur noch als Kostenfaktor angesehen, sie nimmt Platz weg, ist wartungsintensiv (Notstromversorgung für Notspeisefähigkeit der ISDN-Anschlüsse) und teuer zu ersetzen, weil nicht mehr produziert. Der Trend geht dazu, Vermittlungsstellen aufzulösen und die Reste der Vermittlungstechnik IP-basiert zu betreiben. Zwar gibt es dafür keine offiziellen Zeitpläne, aber bereits an der Tatsache, daß kein Hersteller mehr in den letzten fünf Jahren neue ISDN-Hardware auf den Markt gebracht hat, ist ein sehr deutliches Indiz für die Endlichkeit von ISDN. Insofern fürchte ich, daß das schöne DECT-ISDN-Modem ein totes Pferd und der Versuch, es mit einem µC anzusteuern, eine neue Satteldecke für das tote Pferd ist.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.