hamlib-developer — hamlib developers forum

Re: [Hamlib-developer] Proposal

[Frank S. <vk...@ix...>]

Luc Langehegermann wrote:
> 
> Hi Folks,
> 
> On Mon, 09 Oct 2000, Stephane Fillod wrote:
> >   Well, I've already asked myself if glib would be of any
> >   help for Hamlib. In some cases yes, in other cases not.
> >   If you ask me for a answer right now, I would say
> >   no to glib. I know it would make things easier for us,
> >   but do we need all these gizmos to have a real lib?
> >   I mean It's so good to have something selfcontained,
> >   that does not require you to install xx .DLL^H^H^H^H
> >   shared libraries to run.
> 
> I fully agree with you, Stephane
> 
> >   REM: I do recognize glib has plenty of cool stuff, and is very
> >       portable.
> >
> >   Ok, that's my answer today. It could change, especially if
> >   we need more and more of this kind of reusable code.
> >   Actually, this is a point where I'd love to see other
> >   developpers (other than you and me) debate upon...

Hmm, have to agree to disagree on glib for the moment :-(


> >
> > So what do you think of what we got? Can we make a hamlib-1.1.0
> > release and call for help? We DO need help to finalize the API,
> > choose the function names and semantics, etc.
> > Potential Hamlib users are already knocking at the door!
> >
> > Cheers,


Yep lets do it !! There is only 24 hours in a day, and I am running
at 110 % already <:)
Lets make a cvs tagged relase (1.1.0) and pop it in the "Latest File
Releases"
area first.

Some things for the announcement to *.ham.* etc are:

1. Nice project summary/aims.
2. Outline design architecture
3. sample code snippet ( a few lines)
4. refs to hamlib links, and discussion groups.
5. Current project status (early :-))
6. Platform operability.
7. DEVELOPERS WANTED, LOTS OF WORK (LIBS) TODO

etc..


Comments / Frank..

-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

Re: [Hamlib-developer] Proposal

[Luc L. <lx...@qs...>]

Hi Folks,

On Mon, 09 Oct 2000, Stephane Fillod wrote:
>   Well, I've already asked myself if glib would be of any
>   help for Hamlib. In some cases yes, in other cases not.
>   If you ask me for a answer right now, I would say
>   no to glib. I know it would make things easier for us,
>   but do we need all these gizmos to have a real lib?
>   I mean It's so good to have something selfcontained,
>   that does not require you to install xx .DLL^H^H^H^H
>   shared libraries to run.

I fully agree with you, Stephane

>   REM: I do recognize glib has plenty of cool stuff, and is very
> 	portable.
>
>   Ok, that's my answer today. It could change, especially if
>   we need more and more of this kind of reusable code.
>   Actually, this is a point where I'd love to see other
>   developpers (other than you and me) debate upon...
>
>
> Fresh news:
> ----------
> * added dynamic backend loading (still need the LD_LIBRARY_PATH though)
> * a new listcaps to list all known caps
> * include/rig.h moved to include/hamlib/rig.h
> * file buffered access, this works in parallel with unbuffered.
> 	It lets you do read 1 byte at a time, at no IO penalty.
> * added transceive mode, ie. asynchronous rig notificication handling
> 	It works quite nice with SIGIO and sigaction. see testtrn
> * More icom stuff
>
> For details, please see cvs-digest
>
> So what do you think of what we got? Can we make a hamlib-1.1.0
> release and call for help? We DO need help to finalize the API,
> choose the function names and semantics, etc.
> Potential Hamlib users are already knocking at the door!
>
> Cheers,

I just took a look at the rig.h file, and was a bit suprised to read how you 
use the mode. Is it not easier use an rig_mode_t and an rig_bandwidth_t? At 
least for the USB/LSB modes? I also thing that RTTY is not really clear 
enough... Some rigs make afsk, others afsk or fsk... Ans how to know if they 
do the acually USB or LSB? (Especially if I think on my psk31 project thats 
important to know)


-- 
Greetings, Luc

Re: [Hamlib-developer] Proposal

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

On Sun, Oct 08, 2000 at 04:08:56PM -0500, Frank Singleton wrote:
> 
> I have been writing some dissectors for a cool opensource
> project called "ethereal". see http://www.ethereal.com/
> 
	I'll give it a look tomorrow.

> Anyway, we use glib and gtk, and that goes a long way
> to helping support multiple platforms. Ethereal
> compiles and runs on Unix (+flavors), Linux, window$ etc..
> 
  Well, I've already asked myself if glib would be of any
  help for Hamlib. In some cases yes, in other cases not.
  If you ask me for a answer right now, I would say
  no to glib. I know it would make things easier for us,
  but do we need all these gizmos to have a real lib?
  I mean It's so good to have something selfcontained,
  that does not require you to install xx .DLL^H^H^H^H
  shared libraries to run.
  REM: I do recognize glib has plenty of cool stuff, and is very
	portable.

  Ok, that's my answer today. It could change, especially if
  we need more and more of this kind of reusable code.
  Actually, this is a point where I'd love to see other
  developpers (other than you and me) debate upon...


Fresh news:
----------
* added dynamic backend loading (still need the LD_LIBRARY_PATH though)
* a new listcaps to list all known caps
* include/rig.h moved to include/hamlib/rig.h
* file buffered access, this works in parallel with unbuffered.
	It lets you do read 1 byte at a time, at no IO penalty.
* added transceive mode, ie. asynchronous rig notificication handling
	It works quite nice with SIGIO and sigaction. see testtrn
* More icom stuff

For details, please see cvs-digest

So what do you think of what we got? Can we make a hamlib-1.1.0
release and call for help? We DO need help to finalize the API,
choose the function names and semantics, etc.
Potential Hamlib users are already knocking at the door!

Cheers,
-- 
Stephane Fillod				F4CFE

[Hamlib-developer] Proposal

[Frank S. <vk...@ix...>]

Hi,

I have been writing some dissectors for a cool opensource
project called "ethereal". see http://www.ethereal.com/

Anyway, we use glib and gtk, and that goes a long way
to helping support multiple platforms. Ethereal
compiles and runs on Unix (+flavors), Linux, window$ etc..

I have been thinking about the long term project
goals for hamlib, and I think that ease of
development accross platforms is probably one
of the most important goals.

So, I would like to propose that we use glib
also in our project. It provides a variety
of nice (data types (eg: guint8), functions like hashes, 
mem allocation , trees, etc and is supported (like gtk)
across many platforms.


eg: guint8 is an unsigned 8 bit int.
eg: guint16 is an unsigned 16 bit int.
etc..

It provides a nice abstraction from the basic C types, a plus
for portability.

See http://developer.gnome.org/doc/API/glib/index.html
for some examples.

Also http://gtk.org/ for some gtk stuff.

I think with hamlib/glib/gtk, we could do some seriously
cool stuff !

It would not take much effort now to "glibify" the codebase
we have, before it gets too large.

Comments ??

/ Frank

-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

Re: [Hamlib-developer] FT-920

[Frank S. <vk...@ix...>]

Luc Langehegermann wrote:
> 

> 
> No Problem... Wat exactly do you need? Or can I simply scan the description
> and Mail it to the list?
>

I sent you a private mail outlining what I need. Please take
a look at that. ;-)

> 
> I find your project really interesting. But at a first time, I need 'only' a
> way to provide transceiver control in my PSK31 Application. But maybe if I
> find the time I will begin in writing an cool KDE2 frontend for your libs :)

That would be most excellent, nothing like a screenshot or two of a cool
GUI to spice up a project :-)

> 
> The problem I have is, that I cannot access the cvs directly from here... It
> there a way to get snapshots over HTTP?
>

You should be able to get nightly cvs tarballs from

http://cvs.sourceforge.net/cvstarballs/hamlib-cvsroot.tar.gz

Let me know how you go.

/Frank

-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

[Hamlib-developer] FT-920

[Luc L. <lx...@qs...>]

Hi Folks,

>   Hi,
>   Welcome to the hamlib site. Initially I started this
>   site with 2 shared libs (now potential backends) for the FT747
>   and FT847, and they worked ok. I was thinking about
>   some generic frontend when Stephane joined the project
>   and helped implement the frontend code and generic API
>   structure. I think this is definitely a good thing :-)
>   Just to follow up with your yaesu question, I am updating
>   backends for the FT747 and FT847. I would be most pleased
>   if we could see what commonality there is in the command
>   set for the FT-920 and the others (eg: FT847).
>   This could help a to reduce a lot of common code.
>   eg: we could have eg: yaesu.[ch] etc that contain common
>   stuff. Luc, is it possible to get a copy of the command
>   set details, so we can check this

No Problem... Wat exactly do you need? Or can I simply scan the description 
and Mail it to the list? 

>   examples are: 5 byte command set , this is true for FT747
>   and FT847.
>   Once again welcome, and let me us know if you want to
>   join the crew. We have LOTS to do !

I find your project really interesting. But at a first time, I need 'only' a 
way to provide transceiver control in my PSK31 Application. But maybe if I 
find the time I will begin in writing an cool KDE2 frontend for your libs :) 

The problem I have is, that I cannot access the cvs directly from here... It 
there a way to get snapshots over HTTP?

>   Cheers / Frank
>   vk3fcs/km5ws

-- 
Greetings, Luc

Re: [Hamlib-developer] important commit: dir reorganized, autoconf added

[Frank S. <vk...@ix...>]

Stephane Fillod wrote:

> I've finaly reorganized a bit the Hamlib directories,
> please see my previous mail for an idea of the new tree.
> The common/ directory is to be removed very soon
> (-> Attic), all the sources moved to src/
> 

Ok,

> Next, I've played a bit with automake/autoconf. Now, the whole
> Hamlib module is ruled by these handy applications.
> Once you have the configure.in, and Makfile.am's files,
> here is what you need to do in the hamlib dir the first time:
> 
>         $ aclocal
>         $ autoheader
>         $ automake --add-missing --copy --include-deps
>         $ autoconf
> 
> If the main Makefile is already generated (by ./configure),
> then the sub Makfile will be automatically generated
> (ie. no need to re-issue all these commands! make and that's it!).
> This is pretty cool, the only thing I've haven't figured
> out is the shared lib directory setting.
> Right now, these files are located in src/.libs/, icom/.libs/,
> ft847/.libs/, and so on.
> So if you want to run any of the tests/ dir apps, you will have
> to set your LD_LIBRARY_PATH to all these dirs. This is only a quick
> work around until we have the backend registering interface.
> 
>   $ export LD_LIBRARY_PATH=`pwd`/src/.libs:`pwd`/ft847/.libs:`pwd`/ft747/.libs:`pwd`/icom/.libs
> 


Useful info,
Lets put this in in the INSTALL or README file..


> The good news is all of this compile, link, run, and do what
> it is supposed to do! Yesterday, I grabbed a MAX232, a handfull of caps
> to make a V.24<->CI-V converter, and I am now able to control
> my IC706MKIIG using hamlib!!! yipeee :-)

go hamlib !!

> Well, I still have a bunch of API calls to implement, but that should
> be fairly easy with the generic layout.
> 
> Meanwhile, I've added couple of simple features, like convenient
> debugging, generic bcd functions, and a printcaps program that dumps
> in a human readable form the capabilities of a rig.
> There must other changes I forget to mention here, but they're
> listed in the CVS rep (BTW, maybe a cvs-commit-digest mailing list would help)
> 

Done, see 
                        
ham...@li...

SHould be visible soon...

> Next on the TODO list: the backend registering stuff with dynamic loading..
> Big time!
> 

Yup, sounds good to me.

I am in the middle of building a house at the moment, and plan to move
in
in 4 weeks, so I am VERY BUSY !!!!
But I will try and have at least weekly visit and updates ..

Cheers / Frank..

-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

Re: [Hamlib-developer] backend lib loading strategy.

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

Frank Singleton wrote:
> 
> 1. frontend should load appropriate backend lib
>    at say, rig_init or similar.

	nope, rig_init is already in use. init_rig isn't ;-)
> 
> 2. multiple instances of same RIG type should not 
>    cause multiple dl_open requests ??
> 
	sure not. Actually, the backend won't be loaded
  by rig type, but by backend lib!
  using something like rig_load_backend("ft847");
  which would load libhamlib-ft847.so and register it.

> 3. Must have way of resolving symbol names for
>    dlsym(handle, "symbol_name"); stuff.
> 
    We need to call dlsym() only once, ie. when the frontend
    resolves the init_rig symbol. Then, the init_rig function
    will register the capabilities in the frontend rig list.
    And that's it! Thanks to the cool API design.

> 4. A whole lot more to come, but you see the idea.
> 
	Well, very much. The registering and rig_load_backend()
  are coded, and are working fine! There's only a couple of
  lines to add in a backend to support it!
  I haven't commited this code yet, just to let you some time
  to catch up with the last commit. I will do on monday.

> 5. GNU libtool ??
> 
	done already with autoconf/automake stuff

> 6. Lots of other stuff to follow...
> 
	yup, sure!

-- 
Stephane Fillod					F4CFE

[Hamlib-developer] important commit: dir reorganized, autoconf added

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

Hi,

I can't tell you for the Olympics, I don't have TV.
However, I heard on the radio that the french basket ball 
team made his way to final, beating you know who during
their previous game ;-)  Besides that, I don't think we
have a chance with the USA..

Okay, enough noise, let have some signal:

I've finaly reorganized a bit the Hamlib directories,
please see my previous mail for an idea of the new tree.
The common/ directory is to be removed very soon
(-> Attic), all the sources moved to src/

Next, I've played a bit with automake/autoconf. Now, the whole
Hamlib module is ruled by these handy applications.
Once you have the configure.in, and Makfile.am's files,
here is what you need to do in the hamlib dir the first time:

	$ aclocal
	$ autoheader
	$ automake --add-missing --copy --include-deps
	$ autoconf

If the main Makefile is already generated (by ./configure),
then the sub Makfile will be automatically generated
(ie. no need to re-issue all these commands! make and that's it!).
This is pretty cool, the only thing I've haven't figured
out is the shared lib directory setting.
Right now, these files are located in src/.libs/, icom/.libs/,
ft847/.libs/, and so on.
So if you want to run any of the tests/ dir apps, you will have
to set your LD_LIBRARY_PATH to all these dirs. This is only a quick
work around until we have the backend registering interface.

  $ export LD_LIBRARY_PATH=`pwd`/src/.libs:`pwd`/ft847/.libs:`pwd`/ft747/.libs:`pwd`/icom/.libs

The good news is all of this compile, link, run, and do what 
it is supposed to do! Yesterday, I grabbed a MAX232, a handfull of caps
to make a V.24<->CI-V converter, and I am now able to control
my IC706MKIIG using hamlib!!! yipeee :-)
Well, I still have a bunch of API calls to implement, but that should
be fairly easy with the generic layout.

Meanwhile, I've added couple of simple features, like convenient
debugging, generic bcd functions, and a printcaps program that dumps
in a human readable form the capabilities of a rig.
There must other changes I forget to mention here, but they're
listed in the CVS rep (BTW, maybe a cvs-commit-digest mailing list would help)

Next on the TODO list: the backend registering stuff with dynamic loading..
Big time!

-- 
Stephane Fillod					F4CFE

Re: [Hamlib-developer] common reorganise and Makefile updates

[Frank S. <vk...@ix...>]

Stephane Fillod wrote:
> 
>  Frank Singleton wrote:
> >
> > And , libhamlib.so.1.0.1 is born !! I feel like a proud dad ;-()
> >
>   Hold on, I just broke it again. Nah, just kidding ;-)
>   Good work on the Makefiles!

Thanks ..

> 
> > Made common/include and common/lib where lib headers and hamlib.so
> > can be stored.

> >
>   Hmm, IMO, this is not the best approach.
>   According to most GNU projects, the directory hierarchy should
>   look like something as following(not exhaustive):

This was just to start compiling the frontend lib for verification
of what we had done so far ... 


<snip>

Lets do it ..

> If you agree with this organisation, I'll do that tomorrow,
> along with the autoconf setup.

Yep, sounds good to me :-)

> 
> We should definitely clean up the source tree, make a compilable/linkable/
> runnable release (hamlib-1.1.0), and then summon for help/advices/wishes
> from other linux-hams.


Yes, lets get directory organized.  A hamlib release done, and then
we have something to show and attract others :-)


> Also it would be good to make it clear that hamlib is not CAT specific
> (as one might understand from sourceforge summary or radio.linux.org.au),
> nor linux specific (it should be developped to run on any UNIX flavors,
> and also on Win32/etc.)

Check the updated summary.. (limited to 255 characters)

I think it would be good to get the reorg done, and then I will
post to various groups about our project, its goals, status,
and request for help.


> 
> Have fun..
> 
> PS: have you checked out http://google.com page lately? I'm sure
>     you'll like it ;-)

Yeah, talented little kangaroo :-)

Cheers / Frank

-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

[Hamlib-developer] libhamlib frontend ok

[Frank S. <vk...@ix...>]

Hi,

Some activity, when not watching Olympics... :)

I have successfully built testrig.c and linked it
against libhamlib frontend , and run part of it 
successfully - cool !!!!!!!!!

rig.c
-----

Removed rig_caps references for the time being, and replaced with
a more generic declaration. At least now I can build "libhamlib.0.0.1"
ok, and link testrig against it, and run it !! yippeee :-)


#if 0
static const struct rig_caps *rig_base[] = { 
	&ft747_caps, &ic706_caps, &ic706mkiig_caps, /* ... */ NULL, };

#endif

/*
 * removed references to xxx_caps for testing. perhaps we should use
 * the declaration below, an dthnk about populating it another way -- FS
 *
 */


#define MAXRIGSIZE  10		/* put this in .h later */
static const struct rig_caps *rig_base[MAXRIGSIZE];


Also,

Added a few printf's to verify rig_xxx is being called ok.


Makefile.testrig
----------------

Created this make file to allow compiling and linking
of testrig.c against "libhamlib"

make -f Makefile.testrig
make -f Makefile.testrig runtest
make -f Makefile.testrig cleanlocal


Some output as follows, we are getting closer !!

[frank@kirk common]$ make -f Makefile.testrig runtest
LD_LIBRARY_PATH="./lib" ./testrig ; ldd ./testrig
testrig:main() has been called
rig:rig_init called
        libm.so.6 => /lib/libm.so.6 (0x4001a000)
        libhamlib.so.0 => ./lib/libhamlib.so.0 (0x40037000)
        libc.so.6 => /lib/libc.so.6 (0x4003c000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
[frank@kirk common]$                                         


Outstanding
-----------

1. Get a good way of populating rig_base[] array.
2. Test drive a backend lib after frontend dlopens the
   approriate backend.
3. Symbol resolution - needs a generic approach here..

Cheers / Frank..

-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

Re: [Hamlib-developer] common reorganise and Makefile updates

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

Frank Singleton wrote:
> 
> And , libhamlib.so.1.0.1 is born !! I feel like a proud dad ;-()
> 
  Hold on, I just broke it again. Nah, just kidding ;-)
  Good work on the Makefiles!

> Made common/include and common/lib where lib headers and hamlib.so
> can be stored.
> 
  Hmm, IMO, this is not the best approach.
  According to most GNU projects, the directory hierarchy should
  look like something as following(not exhaustive):

hamlib
 |-- README
 |-- INSTALL
 |-- Makefile.in
 |-- configure
 |-- LICENSE
 |-- any other all-uppercase file
 |-- include				# exported includes
 |   |-- rig.h				# API interface
 |   `-- riglist.h
 |-- lib				# compiled libs
 |   |-- backend
 |   |   |-- libft747.so
 |   |   `-- libicom.so
 |   |-- libhamlib.so -> libhamlib.so.1
 |   |-- libhamlib.so.1 -> libhamlib.so.1.0.1
 |   `-- libhamlib.so.1.0.1
 |-- etc
 |   `-- hamlib.conf			# pref file locating backend.so list
 |-- src				# used to be common/
 |   |-- rig.c
 |   |-- register.c			# backend registering
 |   |-- misc.c				# hex_dump, BCD stuff, etc.
 |   |-- serial.c
 |   |-- serial.h
 |   `-- any other frontend sources
 |-- test
 |   |-- testrig.c			# sample test program
 |   `-- any regression test suite?
 |-- docs
 |   |-- html
 |   |-- man
 |   `-- well documented API in various formats
 |-- mybackendrig
 |   |-- mybackendrig.h
 |   `-- mybackendrig.c
 `-- myotherbackendrig
     `-- myotherbackendrig.c

What do you think of it?
If you agree with this organisation, I'll do that tomorrow (well today),
along with the autoconf setup.

We should definitely clean up the source tree, make a compilable/linkable/
runnable release (hamlib-1.1.0), and then summon for help/advices/wishes
from other linux-hams.
Also it would be good to make it clear that hamlib is not CAT specific
(as one might understand from sourceforge summary or radio.linux.org.au),
nor linux specific (it should be developped to run on any UNIX flavors,
and also on Win32/etc.)

Have fun..


PS: have you checked out http://google.com page lately? I'm sure 
    you'll like it ;-)

-- 
Stephane Fillod					F4CFE

Re: [Hamlib-developer] common reorganise and Makefile updates

[Stephane F. <ste...@in...>]

 Frank Singleton wrote:
> 
> And , libhamlib.so.1.0.1 is born !! I feel like a proud dad ;-()
> 
  Hold on, I just broke it again. Nah, just kidding ;-)
  Good work on the Makefiles!

> Made common/include and common/lib where lib headers and hamlib.so
> can be stored.
> 
  Hmm, IMO, this is not the best approach.
  According to most GNU projects, the directory hierarchy should
  look like something as following(not exhaustive):

hamlib
 |-- README
 |-- INSTALL
 |-- Makefile.in
 |-- configure
 |-- LICENSE
 |-- any other all-uppercase file
 |-- include				# exported includes
 |   |-- rig.h				# API interface
 |   `-- riglist.h
 |-- lib				# compiled libs
 |   |-- backend
 |   |   |-- libft747.so
 |   |   `-- libicom.so
 |   |-- libhamlib.so -> libhamlib.so.1
 |   |-- libhamlib.so.1 -> libhamlib.so.1.0.1
 |   `-- libhamlib.so.1.0.1
 |-- etc
 |   `-- hamlib.conf			# pref file locating backend.so list
 |-- src				# used to be common/
 |   |-- rig.c
 |   |-- register.c			# backend registering
 |   |-- misc.c				# hex_dump, BCD stuff, etc.
 |   |-- serial.c
 |   |-- serial.h
 |   `-- any other frontend sources
 |-- test
 |   |-- testrig.c			# sample test program
 |   `-- any regression test suite?
 |-- docs
 |   |-- html
 |   |-- man
 |   `-- well documented API in various formats
 |-- mybackendrig
 |   |-- mybackendrig.h
 |   `-- mybackendrig.c
 `-- myotherbackendrig
     `-- myotherbackendrig.c

What do you think of it?
If you agree with this organisation, I'll do that tomorrow,
along with the autoconf setup.

We should definitely clean up the source tree, make a compilable/linkable/
runnable release (hamlib-1.1.0), and then summon for help/advices/wishes
from other linux-hams.
Also it would be good to make it clear that hamlib is not CAT specific
(as one might understand from sourceforge summary or radio.linux.org.au),
nor linux specific (it should be developped to run on any UNIX flavors,
and also on Win32/etc.)

Have fun..


PS: have you checked out http://google.com page lately? I'm sure 
    you'll like it ;-)

-- 
Stephane Fillod					F4CFE

[Hamlib-developer] backend lib loading strategy.

[Frank S. <vk...@ix...>]

Hi,

In between the Olympic events I had some thoughts
on loading strategies, and share them below.

After browsing man page for dl_open etc... :-)

Reference Example.

<snip>
       Load the math library, and print the cosine of 2.0:
              #include <dlfcn.h>
 
              int main(int argc, char **argv) {
                  void *handle = dlopen ("/lib/libm.so", RTLD_LAZY);
                  double (*cosine)(double) = dlsym(handle, "cos");
                  printf ("%f\n", (*cosine)(2.0));
                  dlclose(handle);
              }
 <snip>

1. frontend should load appropriate backend lib
   at say, rig_init or similar.

2. multiple instances of same RIG type should not 
   cause multiple dl_open requests ??

3. Must have way of resolving symbol names for
   dlsym(handle, "symbol_name"); stuff.

  eg: for things like ..
  void *handle = dlopen ("libft747.so", RTLD_LAZY);
  int (*cmd_set_vfo)(vfo_t vfo)= dlsym(handle, "rig_set_vfo");
   (*cmd_set_vfo)(RIg_MAIN_VFO)

etc..	

4. A whole lot more to come, but you see the idea.

5. GNU libtool ??

6. Lots of other stuff to follow...

/Frank
        
-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

[Hamlib-developer] common reorganise and Makefile updates

[Frank S. <vk...@ix...>]

Hi,

Made some updates to common/Makefile so "make", "make install"
and "make clean" work as expected. Still some things to sort out
but at least it gives us some framework..

And , libhamlib.so.1.0.1 is born !! I feel like a proud dad ;-()

Made common/include and common/lib where lib headers and hamlib.so
can be stored.

Here is the common/ tree after doing "make" and "make install" from
common/ directory. This is the same structure as backend
libs for consistency.


[frank@kirk common]$ tree
.
|-- API_Candidates
|-- CVS
|   |-- Entries
|   |-- Repository
|   `-- Root
|-- Makefile
|-- include
|   |-- CVS
|   |   |-- Entries
|   |   |-- Repository
|   |   `-- Root
|   |-- rig.h
|   |-- riglist.h
|   `-- serial.h
|-- lib
|   |-- CVS
|   |   |-- Entries
|   |   |-- Repository
|   |   `-- Root
|   |-- libhamlib.so -> libhamlib.so.1
|   |-- libhamlib.so.1 -> libhamlib.so.1.0.1
|   `-- libhamlib.so.1.0.1
|-- rig.c
|-- rig.h
|-- rig.o
|-- riglist.h
|-- serial.c
|-- serial.h
|-- serial.o
`-- testrig.c            


Cheers / Frank..

-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

Re: [Hamlib-developer] API suggestions

[Frank S. <vk...@ix...>]

Stephane Fillod wrote:
> 
...
> Just a word about the {cmd,backend}_get_* functions. IMO, it's not a good
> idea to have them return the data immediately, because we may loose
> the return code in case of failure. So I would stick with something like
> this:
>         int cmd_get_freq(RIG *rig, freq_t *freq);
> 

I like this format, set passes freq, get passes *freq etc..
and returning "int" covers return code..

> Your struct channel looks fine, we need also to support splits:
> So instead of having only one "freq_t freq" field,
> maybe we ought to have
> 
>   freq_t rxfreq;
>   freq_t txfreq;
> 
> and also:
> 
>   unsigned long func; /* bitwise OR'ed RIG_FUNC_AGC, NB, et al. */
>   unsigned long tuning_step; /* freq_t is not needed here */
>   rig_rptr_shift_t rptr_shift; /* repeater shift is not (cross)split */
> 
> Not to mention the Preamp/Att state (expressed in dB?), and the selected
> antenna too (provided the rig supports it of course).
> 
> Correct me if I'm wrong, the purpose of the "struct channel" is designed
> to manage freq memories, right? 

Yep..

>Oh, yeah, it can be convenient
> to use it to get the state of the current vfo, all at once! is what
> you intended with get_channel/set_channel or is it for memory managment
> exclusively?  maybe both if the memory number is not defined (eg. -1)?
> 

Hopefully we can  use it for both ..

> Comments?

frontend starting to look good.

Perhaps a "general.c" file for stuff like hex_dump(), bcd conversions,
dBm <-> milliwatts, whatever
etc so I can rip them out of serial.[ch] 

Comments ??


/Frank

-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

[Hamlib-developer] updates

[Frank S. <vk...@ix...>]

Hi,

ft747.[ch] / ft847.[ch]
------------------------

Updated caps structures

testrig.c
---------

Examples of set/get with simple error checking

common/Makefile
----------------

simple hack to allow "make hamlib" as a target.
Still lots to do, includign autoconf one day :0

What do you think about making a lib and include
directory under common where the frontend lib
can be "make install'd", similar to backend
directory structure. also, a  common/test
diretory also.

eg:
common/lib
common/include
common/test

Also testrig can use these directories to find
libhamlib frontend and include file to match and
link against when testing.

serial.c
--------
updated read_sleep to use usleep

Cheers / Frank

-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

Re: [Hamlib-developer] API suggestions

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

Frank Singleton wrote:
> 
> So if frontend API says
> 
>     int (*set_freq)(RIG *rig, freq_t freq);
>     int (*set_mode)(RIG *rig, rig_mode_t mode);
>     int (*set_vfo)(RIG *rig, rig_vfo_t vfo);
> 
> backend equivalents for ft747
> 
>    int ft747_set_freq(RIG *rig, freq_t freq);
>    int ft747_set_mode(RIG *rig, rig_mode_t mode);
     int ft747_set_vfo(RIG *rig, rig_vfo_t vfo);
[...]
> etc..
> 
> What do you think ??

 make sense!

freq_t cmd_get_freq(RIG *rig);

Just a word about the {cmd,backend}_get_* functions. IMO, it's not a good
idea to have them return the data immediately, because we may loose
the return code in case of failure. So I would stick with something like 
this:
	int cmd_get_freq(RIG *rig, freq_t *freq);


Your struct channel looks fine, we need also to support splits:
So instead of having only one "freq_t freq" field,
maybe we ought to have

  freq_t rxfreq;
  freq_t txfreq;

and also:

  unsigned long func; /* bitwise OR'ed RIG_FUNC_AGC, NB, et al. */
  unsigned long tuning_step; /* freq_t is not needed here */
  rig_rptr_shift_t rptr_shift; /* repeater shift is not (cross)split */

Not to mention the Preamp/Att state (expressed in dB?), and the selected
antenna too (provided the rig supports it of course).

Correct me if I'm wrong, the purpose of the "struct channel" is designed
to manage freq memories, right? Oh, yeah, it can be convenient
to use it to get the state of the current vfo, all at once! is what
you intended with get_channel/set_channel or is it for memory managment 
exclusively?  maybe both if the memory number is not defined (eg. -1)?

Comments?

-- 
Stephane					F4CFE

Re: [Hamlib-developer] rig_caps_register

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

Frank Singleton wrote:
> 
> In order for rig.c to populate the  rig_caps array automagically,as
> suggested
> 
[..]
> We could have backend call a frontend rig_caps_register function that
> simple passes an address of their own cap structure into
> the rig_caps array in rig.c
> 
> ie:
> 
> int rig_caps_register(RIG *rig) {
> 
you mean	int rig_caps_register(const struct rig_caps *my_backend_caps)

> .... insert cap ptr into rig_base[]
> .... and return result to caller
> 
> }
> 
> This way,  frontend can init all backends via a rig_backend_poll()
> function. backends must respond by registering their caps,
> rig_caps_register() and
> any other things we may add in future :-)
> 
  So if I understand correctly, the rig_backend_poll() function
  (called by who?) would call some backend initializer function
  (constructor?) that would in term call rig_caps_register().
  Well, this is not too far fetched, especially if you consider
  the dlopen/_init facility (in case of external loadable modules).

> This way 
> 
> rig_caps *rig_base[MAX_RIG_CAPS]  will be 
> dynamically populated.
> 
> eg:
> 
> frontend                   backend
> --------                   -------
> 
> for all rigs do

   gotcha! there you still have to have a backend array with pointer to
   functions, or at least explicitly reference all the backend
   constructors.
> 
>       rig_backend_poll
>     --------------------->
> 
>          rig_caps_regisyter
>      <---------------------  ft747_caps
> 
>       rig_backend_poll
>     --------------------->
> 
[...]

> rig_base[] is now populated ...
> 
> 
> The rig_backend_poll could be done at
> loading of the frontend libhamlib library that
> can access all the backends.
> 
  This idea needs some maturation, let's think about it,
  see how we can work it out.


> Also, should we have 1 lib "libhamlib"
> that contains the frontend and all the backends (easy), or
> should we load frontend "libhamlib" and he can
> dynamically load backend libraries on demand.
> This second option is probably more 
> professional ;-)

  and also more fun :-) 
  As usual, I think both are good, like in SANE (no pun here :)

-- 
Stephane Fillod					F4CFE

Re: [Hamlib-developer] Re: API suggestions

[Frank S. <vk...@ix...>]

Stephane Fillod wrote:


<snip>

> REM: the problem with xxxx_t cmd_get_xxx(RIG *rig) would be the
>      unability to check the return code.

I have seen in some circumstances the  use  of stuff like

struct ret_val {
	return_value;
	int validity_indicator;
}

struct ret_val *get_whatever(..)

So when you get a ptr to ret_val when returning
from the function, you can always check the
"data valid indicator" to see if there is a 
proper return_value, or if the indicator says,
an error occurred. 

Could we use this for setting and getting data ??

Or, pass &result into functions so that it may be set like

int rig_get_mode(RIG *rig, mode_t mode, int *result)

ie: rig_get_mode updates mode and result.

Comments ??

> 
> BTW, is the "_" in "cmd_set_xxx_" a typo ?

TYPO !! :-()

> 
> Also, I'm thinking that the "cmd_" prefix can generate some namespace
> clashes (well, no if the other objects is not dealing with vfo's
> and ham specific stuff :). Anyway, would it be better to have this:
> 
>         rig_set_mode(RIG *rig, rig_mode_t mode)
>         rig_set_vfo(RIG *rig, vfo_t vfo)
>         rig_set_freq(RIG *rig, freq_t freq)
>         rig_set_filter(RIG *rig, filter_t filter)
> 

Thats fine, I am glad we can agree before the API gets too big :-)

> Talking about namespace, I'd prefer to have mode_t instead of rig_mode_t.
> Should you see any concern?

mode_t looks good to me

> 
> About convenience functions like:
> >
> > cmd_set_channel_(RIG *rig,freq_t freq, rig_mode_t mode, vfo_t vfo
> > ....,,,, filter_t filter..)
> >
> > is some frontend convenience function that backend libs can handle
> > either directly as is toward the rig if the rig can handle it that way,
> > or the backend lib breaks it into the simpler functions shown above if
> > the rig needs it that way. We dont care up the front how its done
> > int the back of course (apart from efficiency issues of course)!
> >
> 
> In your previous mail, you were proposing that we can pass NULL
> parameters into the cmd_set for those things you
> dont want to change since previos command. Well, it depends
> on what your understanding of NULL. For instance, 0 can be meaningfull
> for the vfo_t type, etc.  (anyway, we can use -1)

I guess we should have a value that has no meaning in any other
context than indicating PARAM_NULL (-1 is a candidate of course).

But, using rig_set_mode(rig,mode) is maybe cleaner than
rig_set_channel(rig,NULL_PARAM, mode, NULL_PARAM, NULL_PARAM ..)


> > Ok, now I sleep better !!
> >
> 
> Sometimes, coding is like certain ham bands,
> it's only open at night :-)
> 

Yeah, I sometimes have bit too much D-layer absorbption
in the neural net sometimes.. :)

> --
> Stephane                                        F4CFE
>

Also, many times I get the following errors from your mail


    **********************************************
    **      THIS IS A WARNING MESSAGE ONLY      **
    **  YOU DO NOT NEED TO RESEND YOUR MESSAGE  **
    **********************************************

The original message was received at Mon, 18 Sep 2000 11:18:14 +0200
from cismrelais.univ-lyon1.fr [134.214.101.250]

   ----- The following addresses had transient non-fatal errors -----
ste...@en...
    (expanded from: <ste...@in...>)


OR


    **********************************************
    **      THIS IS A WARNING MESSAGE ONLY      **
    **  YOU DO NOT NEED TO RESEND YOUR MESSAGE  **
    **********************************************

The original message was received at Mon, 18 Sep 2000 07:59:37 +0200
from cismrelais.univ-lyon1.fr [134.214.101.250]

   ----- The following addresses had transient non-fatal errors -----
ste...@en...
    (expanded from: <ste...@in...>)

   ----- Transcript of session follows -----
... while talking to hotu.ens.insa-rennes.fr.:
>>> MAIL From:<vk...@ix...> SIZE=1811
<<< 451 <vk...@ix...>... Go away!
ste...@en...... Deferred: 451
<vk...@ix...>... Go away!
Warning: message still undelivered after 4 hours
Will keep trying until message is 5 days old

So, you may have to check hamlib-developer instead ??

/Frank..
-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

[Hamlib-developer] Re: API suggestions

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

Frank Singleton wrote:
> 
> Actually now that I think about it, the cleanest approach
> is probably for the frontend API to provide as a minimum functions
> like 
> 
> cmd_set_mode(RIG *rig, rig_mode_t mode)
> cmd_set_vfo(RIG *rig, vfo_t vfo)
> cmd_set_freq_(RIG *rig, freq_t freq)
> cmd_set_filter_(RIG *rig, filter_t filter)
> 
> and in general
> cmd_set_xxx_(RIG *rig, xxx_t xxx)

and cmd_get_xxx(RIG *rig, xxx_t *xxx)
REM: the problem with xxxx_t cmd_get_xxx(RIG *rig) would be the
     unability to check the return code.

BTW, is the "_" in "cmd_set_xxx_" a typo ?

Also, I'm thinking that the "cmd_" prefix can generate some namespace
clashes (well, no if the other objects is not dealing with vfo's 
and ham specific stuff :). Anyway, would it be better to have this:

	rig_set_mode(RIG *rig, rig_mode_t mode)
	rig_set_vfo(RIG *rig, vfo_t vfo)
	rig_set_freq(RIG *rig, freq_t freq)
	rig_set_filter(RIG *rig, filter_t filter)

Talking about namespace, I'd prefer to have mode_t instead of rig_mode_t.
Should you see any concern?

About convenience functions like:
> 
> cmd_set_channel_(RIG *rig,freq_t freq, rig_mode_t mode, vfo_t vfo
> ....,,,, filter_t filter..)
> 
> is some frontend convenience function that backend libs can handle
> either directly as is toward the rig if the rig can handle it that way, 
> or the backend lib breaks it into the simpler functions shown above if 
> the rig needs it that way. We dont care up the front how its done
> int the back of course (apart from efficiency issues of course)!
> 

In your previous mail, you were proposing that we can pass NULL
parameters into the cmd_set for those things you
dont want to change since previos command. Well, it depends
on what your understanding of NULL. For instance, 0 can be meaningfull 
for the vfo_t type, etc.  (anyway, we can use -1)

> 
> Ok, now I sleep better !!
> 

Sometimes, coding is like certain ham bands, 
it's only open at night :-)


-- 
Stephane					F4CFE

[Hamlib-developer] API Updates

[Frank S. <vk...@ix...>]

Hi,

Started to think about  API  set/get functions.

rig.h
-----


Added  channel struct for mem handling and possible convenience
functions.

struct channel {
  int channel_num;
  freq_t freq;
  mode_t mode;
  vfo_t vfo;
  char channel_desc[MAXCHANDESC];
};

Added set/get pairs for API in rig_caps struct

<snip>

  /*
   *  General API commands, from most primitive to least.. :()
   *  List Set/Get functions pairs
   */
  
  int (*set_freq)(RIG *rig, freq_t freq); /* select freq */
  struct freq_t (*get_freq)(RIG *rig); /* get freq */

  int (*set_mode)(RIG *rig, rig_mode_t mode); /* select mode */
  struct rig_mode_t (*get_mode)(RIG *rig, rig_mode_t mode); /* get mode
*/

  int (*set_vfo)(RIG *rig, rig_vfo_t vfo); /* select vfo */
  struct rig_vfo_t (*get_vfo)(RIG *rig); /* get vfo */

  int (*set_ptt)(RIG *rig, rig_ptt_t ptt); /* ptt on/off */
  struct rig_ptt_t (*get_ptt)(RIG *rig); /* get ptt status */

  int (*set_rpt_shift)(RIG *rig, rig_rptr_shift_t rig_rptr_shift ); /*
set repeater shift */
  struct rig_rptr_shift_t (*get_rpt_shift)(RIG *rig); /* get repeater
shift */

/* etc */
  
/*
 * Convenience Functions
 * 
 */

  int (*set_channel)(RIG *rig, struct channel ch);
  int (*get_channel)(RIG *rig, freq_t freq, rig_mode_t mode, rig_vfo_t
vfo);


<snip>

rig.c
------

Added 3 commands to rig.c for examples
cmd_set_freq
cmd_set_mode
cmd_set_vfo

Compiles ok (no linking) with 
 gcc -c rig.c -I.   


testrig.c
----------
Updated testrig.c with 3 examples also

Compiles ok (no linking) with 
 gcc -c testrig.c -I.   


Cheers / Frank..


    

-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

[Hamlib-developer] rig_caps_register

[Frank S. <vk...@ix...>]

Hi,

In order for rig.c to populate the  rig_caps array automagically,as
suggested



<snip>
/*
 * It would be nice to have an automatic way of referencing all the
backends
 * supported by hamlib. Maybe this array should be placed in a separate
file..
 * 
 * The rig_base is a variable length rig_caps* array, NULL terminated
 */

static const struct rig_caps *rig_base[] = { 
	&ft747_caps, &ic706_caps, &ic706mkiig_caps, /* ... */ NULL, };


We could have backend call a frontend rig_caps_register function that
simple passes an address of their own cap structure into
the rig_caps array in rig.c

ie:

int rig_caps_register(RIG *rig) {

.... insert cap ptr into rig_base[]
.... and return result to caller

}


This way,  frontend can init all backends via a rig_backend_poll()
function. backends must respond by registering their caps,
rig_caps_register() and
any other things we may add in future :-)

This way 

rig_caps *rig_base[MAX_RIG_CAPS]  will be 
dynamically populated.

eg:

frontend                   backend
--------                   -------

for all rigs do

      rig_backend_poll
    --------------------->

         rig_caps_regisyter
     <---------------------  ft747_caps

      rig_backend_poll
    --------------------->

         rig_caps_regisyter
     <---------------------  ft847_caps

                  ...

  
      rig_backend_poll
    --------------------->

         rig_caps_regisyter
     <---------------------  icom_caps


rig_base[] is now populated ...


The rig_backend_poll could be done at
loading of the frontend libhamlib library that
can access all the backends.

Question:

Also, should we have 1 lib "libhamlib"
that contains the frontend and all the backends (easy), or
should we load frontend "libhamlib" and he can
dynamically load backend libraries on demand.
This second option is probably more 
professional ;-)


Comments ??


-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

Re: [Hamlib-developer] API suggestions

[Frank S. <vk...@ix...>]

Hi,

Thinking about naming convention for maintenance :0
when we have all these functions in the backend 
mapping (via pointers )onto the frontend declarations..

frontend prototype says...

<snip> from rig.h

struct rig_caps {
	rig_model_t rig_model; /* eg. RIG_MODEL_FT847 */
	unsigned char model_name[RIGNAMSIZ]; /* eg "ft847" */
	unsigned char mfg_name[RIGNAMSIZ]; /* eg "Yeasu" */
	char version[RIGVERSIZ]; /* driver version, eg "0.5" */
	enum rig_status_e status; /* among ALPHA, BETA, STABLE, NEW  */
	enum rig_type_e rig_type;
	int serial_rate_min; /* eg 4800 */
	int serial_rate_max; /* eg 9600 */
	int serial_data_bits; /* eg 8 */
	int serial_stop_bits; /* eg 2 */
	enum serial_parity_e serial_parity; /* */
	enum serial_handshake_e serial_handshake; /* */
	int write_delay;		/* delay in ms between each byte sent out */
	int timeout;	/* in ms */
	int retry;		/* maximum number of retries, 0 to disable */
	struct freq_range_list rx_range_list[FRQRANGESIZ];
	struct freq_range_list tx_range_list[FRQRANGESIZ];

	int (*rig_init)(RIG *rig);	/* setup *priv */
	int (*rig_cleanup)(RIG *rig);
	int (*rig_open)(RIG *rig);	/* called when port just opened */
	int (*rig_close)(RIG *rig);	/* called before port is to close */
	int (*rig_probe)(RIG *rig); /* Experimental: may work.. */
  
       /* cmd API below */
	int (*set_freq_main_vfo_hz)(RIG *rig, freq_t freq, rig_mode_t mode);

  /*
    int (*set_freq)(RIG *rig, freq_t freq);
    int (*set_mode)(RIG *rig, rig_mode_t mode);
    int (*set_vfo)(RIG *rig, rig_vfo_t vfo);
  */


<snip>

So if frontend API says

    int (*set_freq)(RIG *rig, freq_t freq);
    int (*set_mode)(RIG *rig, rig_mode_t mode);
    int (*set_vfo)(RIG *rig, rig_vfo_t vfo);



backend equivalents for ft747

   int ft747_set_freq(RIG *rig, freq_t freq);
   int ft747_set_mode(RIG *rig, rig_mode_t mode);
   int ft747_(RIG *rig, rig_vfo_t vfo);

backend equivalents for ft847

   int ft847_set_freq(RIG *rig, freq_t freq);
   int ft847_set_mode(RIG *rig, rig_mode_t mode);
   int ft847_(RIG *rig, rig_vfo_t vfo);

etc..

What do you think ??


-- Frank

[Hamlib-developer] API suggestions

[Frank S. <vk...@ix...>]

Hi,

previously, on this channel.....
> 
> > > cmd_set_freq(RIG *rig,freq_t freq, rig_mode_t mode, vfo_t vfo )
> > > long int cmd_get_freq_mode_status(RIG *rig, unsigned char *mode, vfo_t
> > > vfo);
> > >
> >   Looks definitely better this way!
> >   Just a question: what if the application just wants to change
> >   the mode only? It might be troublesome in certain case to have
> >   to remember the current frequency or having to query it.
> 
> true, I guess we have some options...
> 
> API provides
> cmd_set_freq_(RIG *rig,freq_t freq, rig_mode_t mode, vfo_t vfo )
> 
> and possibly
> cmd_set_mode(RIG *rig, rig_mode_t mode)
> cmd_set_vfo(RIG *rig, vfo_t vfo)


I must have had too many beers during the Olympic opening
ceremony :-)


Actually now that I think about it, the cleanest approach
is probably for the frontend API to provide as a minimum functions
like 

cmd_set_mode(RIG *rig, rig_mode_t mode)
cmd_set_vfo(RIG *rig, vfo_t vfo)
cmd_set_freq_(RIG *rig, freq_t freq)
cmd_set_filter_(RIG *rig, filter_t filter)

and in general
cmd_set_xxx_(RIG *rig, xxx_t xxx)

and that optional  convenience functions like 

cmd_set_channel_(RIG *rig,freq_t freq, rig_mode_t mode, vfo_t vfo
....,,,, filter_t filter..)

is some frontend convenience function that backend libs can handle
either directly as is toward the rig if the rig can handle it that way, 
or the backend lib breaks it into the simpler functions shown above if 
the rig needs it that way. We dont care up the front how its done
int the back of course (apart from efficiency issues of course)!


So, 1 frontend convenience functions may cause multiple backend
calls to the rig as it iterates through the convenience functions
argumant list and  calls individual "primitives" towards the rig.

Ok, now I sleep better !!

Should be no state issues to deal with..

just trying to avoid long function names like
cmd_set_freq_mode_vfo_filter_power_this_that_whatever(....)

Comments ??

/Frank..