Skip to main content

Please review serial communication channel

6 replies [Last post]
Anonymous

Hi Vladimir, team,

please review implementation of serial communication channel:
http://fisheye4.cenqua.com/changelog/cqme/?cs=1057
Client side of this implementation is used Generic Connection Framework of
CLDC/CDC platforms. Server side is used Java Comm API.

Also I've integrated this channel to the interview:
http://fisheye4.cenqua.com/changelog/cqme/?cs=1065
Now it possible to select serial based communication in additional to others.

Thanks,
Alexander

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Vladimir Sizikov

Alexander,

On Tue, May 29, 2007 at 05:33:45PM +0400, Alexander Alexeev wrote:
> Also I've integrated this channel to the interview:
> http://fisheye4.cenqua.com/changelog/cqme/?cs=1065
> Now it possible to select serial based communication in additional to
> others.

Very good! A few minor things worth addressing:

1. Description of COM port question is unclear (in summary and more
info):
" Specify a comm port ..."

Maybe, we should be more specific and explain a bit what this for.
Also, I'd prefer to replace confusing "comm" to COM or serial.

I like "serial".

The question can also be named "Server Serial Port" rather than
"Communication Server Port" (communication port sounds like
TCP/IP-UDP-like port, while we explicitly deal with serial port here).

2. The COM port question's usability could be improved significantly,
if suggestions were provided via drop-down list.

For example, take a look at MIDP TCK, "Serial support" secion.

It provides the following suggestions:
COM1
COM2
COM3
COM4
/dev/term/a
/dev/term/b
/dev/ttyS0 -- /dev/ttyS3

These are typical names for serial ports under Win, Lin, Solaris.

With such suggestions, users will no longer be guessing what kind of
port they are asked for.

I don't have anything else for the interviews. Will review the actual
Client/Server shortly.

Thanks,
--Vladimir

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Alexander Alexeev

Hi Vladimir,

About suggestions... First of all I've implemented the solution as in MIDP TCK
but then I decided to implement more smart solution with listing ports really
available on host. But then I realized that interview will have dependency on
comm API and it's very inconvenient for users who doesn't want to use serial
connection. And I've just created simple string question :-). But I agree list
with hard coded suggestions will be more user friendly. We can implement more
smart solution in the future.

Thanks,
Alexander

Vladimir Sizikov wrote:
> Alexander,
>
> On Tue, May 29, 2007 at 05:33:45PM +0400, Alexander Alexeev wrote:
>> Also I've integrated this channel to the interview:
>> http://fisheye4.cenqua.com/changelog/cqme/?cs=1065
>> Now it possible to select serial based communication in additional to
>> others.
>
> Very good! A few minor things worth addressing:
>
> 1. Description of COM port question is unclear (in summary and more
> info):
> " Specify a comm port ..."
>
> Maybe, we should be more specific and explain a bit what this for.
> Also, I'd prefer to replace confusing "comm" to COM or serial.
>
> I like "serial".
>
> The question can also be named "Server Serial Port" rather than
> "Communication Server Port" (communication port sounds like
> TCP/IP-UDP-like port, while we explicitly deal with serial port here).
>
> 2. The COM port question's usability could be improved significantly,
> if suggestions were provided via drop-down list.
>
> For example, take a look at MIDP TCK, "Serial support" secion.
>
> It provides the following suggestions:
> COM1
> COM2
> COM3
> COM4
> /dev/term/a
> /dev/term/b
> /dev/ttyS0 -- /dev/ttyS3
>
> These are typical names for serial ports under Win, Lin, Solaris.
>
> With such suggestions, users will no longer be guessing what kind of
> port they are asked for.
>
> I don't have anything else for the interviews. Will review the actual
> Client/Server shortly.
>
> Thanks,
> --Vladimir
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Vladimir Sizikov

Hi Alexander,

Thanks for the explanation. :)

I've fixed some of the simple things in my branch, so feel free to
merge them back into yours:

http://fisheye4.cenqua.com/changelog/cqme/?cs=1068
http://fisheye4.cenqua.com/changelog/cqme/?cs=1069
http://fisheye4.cenqua.com/changelog/cqme/?cs=1072
http://fisheye4.cenqua.com/changelog/cqme/?cs=1073

(Basically, you can merge al the changes from my branch).

Also, some things that I did'n fix:
1. in Server:

if (commPort == null) {
throw new RuntimeException("SerialCommServer: commPort is null.");
}

Should probably be in init(), after decodeArgs(), and should throw
IllegalArgumentException.

2. Baud Rate question's More Info should state the limits, so that
users will not
be guessing.

3. Most probably the RuntimeException:

throw new RuntimeException("SerialCommServer: commPort " +
commPort + " is not serial");

should be moved to init() too. Should it not?

4. Stupid question, but I can't seem to figuree out why createServer()
is needed in SerialCommServer? We just create a running thread that
does nothing. I most definitely miss something, but I'd better ask
rather than spend more time with no effect. :)

Thanks,
--Vladimir

On Tue, May 29, 2007 at 06:25:14PM +0400, Alexander Alexeev wrote:
> Hi Vladimir,
>
> About suggestions... First of all I've implemented the solution as in MIDP
> TCK
> but then I decided to implement more smart solution with listing ports
> really
> available on host. But then I realized that interview will have dependency
> on
> comm API and it's very inconvenient for users who doesn't want to use serial
> connection. And I've just created simple string question :-). But I agree
> list
> with hard coded suggestions will be more user friendly. We can implement
> more
> smart solution in the future.
>
> Thanks,
> Alexander
>
> Vladimir Sizikov wrote:
> >Alexander,
> >
> >On Tue, May 29, 2007 at 05:33:45PM +0400, Alexander Alexeev wrote:
> >>Also I've integrated this channel to the interview:
> >>http://fisheye4.cenqua.com/changelog/cqme/?cs=1065
> >>Now it possible to select serial based communication in additional to
> >>others.
> >
> >Very good! A few minor things worth addressing:
> >
> >1. Description of COM port question is unclear (in summary and more
> > info):
> >" Specify a comm port ..."
> >
> >Maybe, we should be more specific and explain a bit what this for.
> >Also, I'd prefer to replace confusing "comm" to COM or serial.
> >
> >I like "serial".
> >
> >The question can also be named "Server Serial Port" rather than
> >"Communication Server Port" (communication port sounds like
> >TCP/IP-UDP-like port, while we explicitly deal with serial port here).
> >
> >2. The COM port question's usability could be improved significantly,
> > if suggestions were provided via drop-down list.
> >
> >For example, take a look at MIDP TCK, "Serial support" secion.
> >
> >It provides the following suggestions:
> >COM1
> >COM2
> >COM3
> >COM4
> >/dev/term/a
> >/dev/term/b
> >/dev/ttyS0 -- /dev/ttyS3
> >
> >These are typical names for serial ports under Win, Lin, Solaris.
> >
> >With such suggestions, users will no longer be guessing what kind of
> >port they are asked for.
> >
> >I don't have anything else for the interviews. Will review the actual
> >Client/Server shortly.
> >
> >Thanks,
> > --Vladimir
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> >For additional commands, e-mail: meframework-help@cqme.dev.java.net
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Vladimir Sizikov

Hi Alexander,

I've finished the review. I've also reformatted the sources a little
bit, so that there would be no TABs(!!), no spaces and the end of
lines, and maximum line width is 80 (that way, it's much easier to
review changes in side-by-side diff file viewers).

http://fisheye4.cenqua.com/changelog/cqme/?cs=1082

In addition to my previous questions and comments, there is one more:
project.xml file from nbproject dir has been fully converted to windows
EOLs, which is not right. Please restore the original EOLs.

Thanks,
--Vladimir

On Tue, May 29, 2007 at 10:41:11AM -0700, Vladimir Sizikov wrote:
> Hi Alexander,
>
> Thanks for the explanation. :)
>
> I've fixed some of the simple things in my branch, so feel free to
> merge them back into yours:
>
> http://fisheye4.cenqua.com/changelog/cqme/?cs=1068
> http://fisheye4.cenqua.com/changelog/cqme/?cs=1069
> http://fisheye4.cenqua.com/changelog/cqme/?cs=1072
> http://fisheye4.cenqua.com/changelog/cqme/?cs=1073
>
> (Basically, you can merge al the changes from my branch).
>
> Also, some things that I did'n fix:
> 1. in Server:
>
> if (commPort == null) {
> throw new RuntimeException("SerialCommServer: commPort is null.");
> }
>
> Should probably be in init(), after decodeArgs(), and should throw
> IllegalArgumentException.
>
> 2. Baud Rate question's More Info should state the limits, so that
> users will not
> be guessing.
>
> 3. Most probably the RuntimeException:
>
> throw new RuntimeException("SerialCommServer: commPort " +
> commPort + " is not serial");
>
> should be moved to init() too. Should it not?
>
> 4. Stupid question, but I can't seem to figuree out why createServer()
> is needed in SerialCommServer? We just create a running thread that
> does nothing. I most definitely miss something, but I'd better ask
> rather than spend more time with no effect. :)
>
> Thanks,
> --Vladimir
>
> On Tue, May 29, 2007 at 06:25:14PM +0400, Alexander Alexeev wrote:
> > Hi Vladimir,
> >
> > About suggestions... First of all I've implemented the solution as in MIDP
> > TCK
> > but then I decided to implement more smart solution with listing ports
> > really
> > available on host. But then I realized that interview will have dependency
> > on
> > comm API and it's very inconvenient for users who doesn't want to use serial
> > connection. And I've just created simple string question :-). But I agree
> > list
> > with hard coded suggestions will be more user friendly. We can implement
> > more
> > smart solution in the future.
> >
> > Thanks,
> > Alexander
> >
> > Vladimir Sizikov wrote:
> > >Alexander,
> > >
> > >On Tue, May 29, 2007 at 05:33:45PM +0400, Alexander Alexeev wrote:
> > >>Also I've integrated this channel to the interview:
> > >>http://fisheye4.cenqua.com/changelog/cqme/?cs=1065
> > >>Now it possible to select serial based communication in additional to
> > >>others.
> > >
> > >Very good! A few minor things worth addressing:
> > >
> > >1. Description of COM port question is unclear (in summary and more
> > > info):
> > >" Specify a comm port ..."
> > >
> > >Maybe, we should be more specific and explain a bit what this for.
> > >Also, I'd prefer to replace confusing "comm" to COM or serial.
> > >
> > >I like "serial".
> > >
> > >The question can also be named "Server Serial Port" rather than
> > >"Communication Server Port" (communication port sounds like
> > >TCP/IP-UDP-like port, while we explicitly deal with serial port here).
> > >
> > >2. The COM port question's usability could be improved significantly,
> > > if suggestions were provided via drop-down list.
> > >
> > >For example, take a look at MIDP TCK, "Serial support" secion.
> > >
> > >It provides the following suggestions:
> > >COM1
> > >COM2
> > >COM3
> > >COM4
> > >/dev/term/a
> > >/dev/term/b
> > >/dev/ttyS0 -- /dev/ttyS3
> > >
> > >These are typical names for serial ports under Win, Lin, Solaris.
> > >
> > >With such suggestions, users will no longer be guessing what kind of
> > >port they are asked for.
> > >
> > >I don't have anything else for the interviews. Will review the actual
> > >Client/Server shortly.
> > >
> > >Thanks,
> > > --Vladimir
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> > >For additional commands, e-mail: meframework-help@cqme.dev.java.net
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Alexander Alexeev

Hi Vladimir,

I've updated sources based on your comments. Please see:
http://fisheye4.cenqua.com/changelog/cqme/?cs=1087

Also I've changed default baud rate to 9600 since it's default value in COMM
API. And the range was extended to allow setting up high baud rate for special
serial ports (like IrDa Virtual Comm Port).

>> 4. Stupid question, but I can't seem to figuree out why createServer()
>> is needed in SerialCommServer? We just create a running thread that
>> does nothing. I most definitely miss something, but I'd better ask
>> rather than spend more time with no effect. :)

Well, good question in reality. As we can see from the code we just set up
the listener and that's all. From which thread this listener will be called? I
guess from some daemon thread of JVM. So how long the server will be living
depends on how long the daemon thread will be living. For example in samples in
Comm API SimpleRead server creates thread lives 20 seconds to allow listen port
during that time. After that the program is closed as no threads excepts daemons
exist. So I decided to make server independent from other threads like it is
running standalone and created this nothing-to-do thread. But may be it's
needless, not sure.

Thanks,
Alexander

Vladimir Sizikov wrote:
> Hi Alexander,
>
> I've finished the review. I've also reformatted the sources a little
> bit, so that there would be no TABs(!!), no spaces and the end of
> lines, and maximum line width is 80 (that way, it's much easier to
> review changes in side-by-side diff file viewers).
>
> http://fisheye4.cenqua.com/changelog/cqme/?cs=1082
>
> In addition to my previous questions and comments, there is one more:
> project.xml file from nbproject dir has been fully converted to windows
> EOLs, which is not right. Please restore the original EOLs.
>
> Thanks,
> --Vladimir
>
> On Tue, May 29, 2007 at 10:41:11AM -0700, Vladimir Sizikov wrote:
>> Hi Alexander,
>>
>> Thanks for the explanation. :)
>>
>> I've fixed some of the simple things in my branch, so feel free to
>> merge them back into yours:
>>
>> http://fisheye4.cenqua.com/changelog/cqme/?cs=1068
>> http://fisheye4.cenqua.com/changelog/cqme/?cs=1069
>> http://fisheye4.cenqua.com/changelog/cqme/?cs=1072
>> http://fisheye4.cenqua.com/changelog/cqme/?cs=1073
>>
>> (Basically, you can merge al the changes from my branch).
>>
>> Also, some things that I did'n fix:
>> 1. in Server:
>>
>> if (commPort == null) {
>> throw new RuntimeException("SerialCommServer: commPort is null.");
>> }
>>
>> Should probably be in init(), after decodeArgs(), and should throw
>> IllegalArgumentException.
>>
>> 2. Baud Rate question's More Info should state the limits, so that
>> users will not
>> be guessing.
>>
>> 3. Most probably the RuntimeException:
>>
>> throw new RuntimeException("SerialCommServer: commPort " +
>> commPort + " is not serial");
>>
>> should be moved to init() too. Should it not?
>>
>> 4. Stupid question, but I can't seem to figuree out why createServer()
>> is needed in SerialCommServer? We just create a running thread that
>> does nothing. I most definitely miss something, but I'd better ask
>> rather than spend more time with no effect. :)
>>
>> Thanks,
>> --Vladimir
>>
>> On Tue, May 29, 2007 at 06:25:14PM +0400, Alexander Alexeev wrote:
>>> Hi Vladimir,
>>>
>>> About suggestions... First of all I've implemented the solution as in MIDP
>>> TCK
>>> but then I decided to implement more smart solution with listing ports
>>> really
>>> available on host. But then I realized that interview will have dependency
>>> on
>>> comm API and it's very inconvenient for users who doesn't want to use serial
>>> connection. And I've just created simple string question :-). But I agree
>>> list
>>> with hard coded suggestions will be more user friendly. We can implement
>>> more
>>> smart solution in the future.
>>>
>>> Thanks,
>>> Alexander
>>>
>>> Vladimir Sizikov wrote:
>>>> Alexander,
>>>>
>>>> On Tue, May 29, 2007 at 05:33:45PM +0400, Alexander Alexeev wrote:
>>>>> Also I've integrated this channel to the interview:
>>>>> http://fisheye4.cenqua.com/changelog/cqme/?cs=1065
>>>>> Now it possible to select serial based communication in additional to
>>>>> others.
>>>> Very good! A few minor things worth addressing:
>>>>
>>>> 1. Description of COM port question is unclear (in summary and more
>>>> info):
>>>> " Specify a comm port ..."
>>>>
>>>> Maybe, we should be more specific and explain a bit what this for.
>>>> Also, I'd prefer to replace confusing "comm" to COM or serial.
>>>>
>>>> I like "serial".
>>>>
>>>> The question can also be named "Server Serial Port" rather than
>>>> "Communication Server Port" (communication port sounds like
>>>> TCP/IP-UDP-like port, while we explicitly deal with serial port here).
>>>>
>>>> 2. The COM port question's usability could be improved significantly,
>>>> if suggestions were provided via drop-down list.
>>>>
>>>> For example, take a look at MIDP TCK, "Serial support" secion.
>>>>
>>>> It provides the following suggestions:
>>>> COM1
>>>> COM2
>>>> COM3
>>>> COM4
>>>> /dev/term/a
>>>> /dev/term/b
>>>> /dev/ttyS0 -- /dev/ttyS3
>>>>
>>>> These are typical names for serial ports under Win, Lin, Solaris.
>>>>
>>>> With such suggestions, users will no longer be guessing what kind of
>>>> port they are asked for.
>>>>
>>>> I don't have anything else for the interviews. Will review the actual
>>>> Client/Server shortly.
>>>>
>>>> Thanks,
>>>> --Vladimir
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
>>>> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
>> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Vladimir Sizikov

Hi Alexander,

On Wed, May 30, 2007 at 02:20:50PM +0400, Alexander Alexeev wrote:
> I've updated sources based on your comments. Please see:
> http://fisheye4.cenqua.com/changelog/cqme/?cs=1087

Looks good.

As for the question:

> >> 4. Stupid question, but I can't seem to figuree out why createServer()
> >> is needed in SerialCommServer? We just create a running thread that
> >> does nothing. I most definitely miss something, but I'd better ask
> >> rather than spend more time with no effect. :)
>
> Well, good question in reality. As we can see from the code we just
> set up the listener and that's all. From which thread this listener
> will be called? I guess from some daemon thread of JVM. So how long
> the server will be living depends on how long the daemon thread will
> be living.

That's OK for our needs. The server is being run as part of JTharness,
and there are more than enough threads to keep JTHarness running :)

> For example in samples in Comm API SimpleRead server
> creates thread lives 20 seconds to allow listen port during that
> time.

I understand that for stand-alone samples one might need to have this
thread, but for us it not really needed, it just consumes resources.

> After that the program is closed as no threads excepts daemons
> exist. So I decided to make server independent from other threads
> like it is running standalone and created this nothing-to-do
> thread.

If somebody wants to use the Server standalone (or in some tests), on
can easily create the thread if needed, or block on sleep/wait before
exiting the stand-alone program.

> But may be it's needless, not sure.

Yeah, I'd say that it's not needed. Feel free to delete it and commit
afterwards.

Once you've committed the changes, please provide instructions to
Release Engineering on what to change in their scripts.

Thanks,
--Vladimir

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net