Quote:
jcmarcos wrote:
So I would have to write a program that understands the Poseidon framework and, using its "rawwrap" class, I would be able to communicate with the phone? I guess I would only be able to do so if the program talked in the ActievSync language.
Except for the one command that is missing to start up the communication, you could use CMD_READ and CMD_WRITE on the usbraw.device at your will to communicate with the device. I think there even is a DOSDriver for USBRAW under MorphOS.
Quote:
Sure, that's what I feared. But I had the intention of writing "MorphSync", an application that runs on the phone, and talks to Poseidon.
Now, please correct me, because I'm wrong for sure: I expected that, after starting "MorphSync" on the phone, I could communicate with it from MorphOS through Poseidon's "USBSER:" device.
Not with the rawwrap.class. The rawwrap.class technically does not generate a device at runtime that would be of the type serial (not IOSer IORequests but IOStdReq). You could though, use USBRAW:. But then again, as I wrote above, it would be pretty easy to adapt the existing serial drivers to a new "ipaq" driver, which would qualify as a serial.device.
When you're writing your application, you'd probably want to use the pure serial device rather than through a DOSDriver. Makes it easier for the user to handle. The DOSDriver needs more configuration.
Quote:
That's because I gaev for granted the wild guss that, if I have some kind of USB serial port in MorphOS, it would couple to a generic serial port on the phone.
Would it be possible? But we haven't even started to talk about baud rates, parties and stop bits, so go figure how clueless I really am.
Usually baudrates, parities, stop bits and break signalling would be ignored for that type of serial device over USB (it is only used for /real/ USB serial adapters).
Quote:Quote:
However, if you're willing to code the ipaq adaption, I'd gladly provide you the source to the serialcp210x.class, if you want to write an ActiveSync app, too.
That sounds scary...
So that's a "no"? Because I'm not pretty fond in writing drivers for devices I don't have and therefore cannot test either.
Bye...
Chris Hodges
