phon...@mobileandembedded.org wrote:
Instead of using minicom on my device, i used hyper-terminal of Windows XP to
verify that whether i can connect to /dev/ttyS1 and /dev/ttyS2 or not?
...
Hi Khan,
I'm assuming your device is a Linux device. Please let me know if it is
not.
If it is a Linux device, you'll need some way to test the connection
from the Linux side on the device itself, not from a Windows XP
connected to the port externally. That will only acknowledge the
external side of your port.
The way GCF works is that it needs to match the way you call the
connection from the internal device-side, not from the external side.
So, if I have a Linux device, I can use minicom (or in your case
something else) to run on the Linux device itself locally to check if
"/dev/ttyS0" is connectible or not from the internal side.
That's the only way to tell if using the following code for GCF using
CDC/Foundation profile will work:
try {
CommConnection comPort = (CommConnection) Connector.open("comm:/dev/ttyS1");
}
And, the output of stack trace is:
javax.microedition.io.ConnectionNotFoundException: The requested protocol does
not exist /dev/ttyS1
Whatever I pass in Connector.open(), its portion after "comm:" is taken as a
protocol. And an exception occurs and says that requested protocol does not
exist
I think we have a bug in our Makefiles from what you mention above.
Did you build the binary yourself? If you did, try changing the
defs_cdc.mk Makefile:
In the cdc component
src/share/defs_cdc.mk
----
From this (at line #488)
com.sun.cdc.io.j2me.datagram.DatagramObject \
com.sun.cdc.io.j2me.datagram.Protocol \
To this:
com.sun.cdc.io.j2me.datagram.DatagramObject \
com.sun.cdc.io.j2me.datagram.Protocol \
com.sun.cdc.io.j2me.comm.Protocol \
Rebuild cvm then rerun your test.
If it works, I will fix it in our Makefiles.
Let us know if that's the problem or not.
Thanks,
Hinkmond