[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Savannah-register-public] Re: [task #7917] Submission of Otavio Luiz Bo

From: Alexander Shulgin
Subject: [Savannah-register-public] Re: [task #7917] Submission of Otavio Luiz Bottecchia
Date: Fri, 18 Apr 2008 22:32:01 +0300

Hi Savannah Hackers,

I need some advice on this project submission:

On Fri, Apr 18, 2008 at 3:49 AM, Otavio <address@hidden> wrote:
>  Follow-up Comment #7, task #7917 (project administration):
>  No, I have not tried to run it on Linux.
>  The program just send a sequence of commands to the controller, which, in
>  turn, sends other commands to the transceiver. The syntax is determined by 
> the
>  rigs. The primary handshake (i.e., between PC and PTC) will depend both on 
> the
>  OS and the Basic interpreter (or compiler). In principle, only the following
>  data transfer format is important: 8 data bits, 1 stop bit, no parity and 
> half
>  duplex. The later I did not define and the program run, so I did not paid
>  attention on it. Of course, the baud rate is also important, but PTC has an
>  option to detect baud rate automatically.
>  I fear there is no universal way to solve the handshake problem. I used
>  another interpreter years ago and the syntax was similar, but not equal.

The program in question uses code like open("COM3") to communicate
with the transceiver via COM port.  In my experience this is
DOS/Windows who makes such special file names be mapped onto serial
ports, and to achieve similar effect in Unix-like systems we need
something like open("/dev/ttySn").

That said, I'm aware that the world of free operating systems is not
limited to GNU/Linux and BSDs, and the code might be found happily
running w/o modifications on, for example, FreeDOS...  Moreover,
actual name of device file to use is not likely to be hardcoded in a
real program and users can specify 'COMn' on Windows and '/dev/ttySn'
on Unix-likes.

Also, in GPL there is a disclaimer of warranties and in the current
state the program runs on my box, but just doesn't do what it's
supposed to do.  And that depends on how do you look at this: the
program provides 'more features' (it actually works) on Windows while
it runs, but it doesn't work (less features) on GNU/Linux. ;-)

I believe there's no real obstacle to approve the project now, but
still I feel we need to persuade author to 'improve users experience'
on GNU/Linux.

Your comments?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]