async messages and Re: [Hamlib-developer] Re: Kenwood TH-D7A(G) patch

[Stephane F. <f4...@fr...>]

Hi Francois!

On Fri, Jan 04, 2002, Francois Retief wrote:
> Here is some more. ;-) Should I add the commands to the th.c or thd7.c
> file?   Do you know how similar the TH-F7E/TH-D7 are?

If I know? It's very simple. I have absolutly no documentation
whatsoever on the TH-F7E protocol. Google is dumb on the subject.
So when I tried the table top Kenwood protocol and firgured out it wasn't 
the right one, it turned out the TH-D7 worked. So as long as it works,
I'll assume TH-F7E/TH-D7 are similar :)  So go ahead, add the commands to
the th.c file, and I'll test them on my TH-F7E.

I guess to right solution would be to ask a Kenwood representative to
disclose the procotol specifications..

> I aspect that still bother me is how async messages should be handled.
> How does the callback infrastructure of hamlib work? I don't quite
> follow the Icom implementation.

The async messages works in Hamlib using SIGIO. aoi would be better but
it's not yet mature for Linux (wip).
Have a look in src/event.c
 * add_trn_rig() installs a sig handler dispatcher and setup the file
		descriptor to send SIGIO whenever data arrived.
 * sigiohandler, unfortunately the O_ASYNC/SIGINFO is unable to report the
		associated fd, which is really too bad. So sigiohandler
		has to find it out.
 * search_rig_and_decode() checks if the rig sent async messages and
		then calls the decode_event method associated to the
		backend.
 * decode_event then in turn decode the message and calls any appropriate
		setup rig_callbacks.

In order to support async messages, all a backend needs to have is the
decode_event function, and eventually set_trn/get_trn if available.

Note: there's a race hazard because of the async nature. Async IO has to
be disabled during normal backend transactions, hence the
state.hold_decode field. This acts as a mutex, however, right now, it's
not completly safe because the operation may not be atomic. To be fix one
day, when event decoding becomes more mature (read tested :).

There's a sample user program tests/testtrn.c, and it works with my Ic706.
I know Kenwood protocol is able to report async events. Do you have
the format of the "AI" async message?

> Almost all the Kenwood command are string based. Thus we can work
> with strings instead of buffer/length.  See the read_string
> function I added with the Easycomm patch. It is basically a 
> replacement for the port_transaction function.

Hmmm, the attached patch in your mail is the same one you sent me already
last week (hamlib.kenwood_thd7.20020103.patch). 

BTW, what is your sourceforge login name so I add you to the developer
list. It'll be easier for you to commit directly to the cvs rep.

> btw. Why the difference between read_block and fread_block?

read_block is using read and fread_block is using fread.
The difference is read is non-buffered whereas fread is. 
This means fread tries to read more than you requested, so any subsequent
call to fread will save for system calls.
IOW, this is a performance improvement, esp. when reading bytes one by
one.


Cheers,

Stephane


> diff -u3 -rP --exclude=CVS --exclude='*.in' --exclude=configure --exclude=aclocal.m4 --exclude=autom4te.cache --exclude='*~' hamlib-cvs/kenwood/th.c hamlib-20020103/kenwood/th.c
> --- hamlib-cvs/kenwood/th.c	Fri Dec 21 10:48:40 2001
> +++ hamlib-20020103/kenwood/th.c	Thu Jan  3 19:35:53 2002
> @@ -62,7 +62,7 @@
>  int th_set_vfo(RIG *rig, vfo_t vfo)
>  {