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
;-)
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.
