hamlib-developer

[Hamlib-developer] target VFO proposal

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

Hi,


Finally got PC and rig powered up after the
house move (phew ..)


Looking at the latest API in rig.h,
I have come to the conclusion we are missing
something of great importance.

We have not provided a target VFO in the set/get cmd's

For example...should we have this instead..

int rig_set_freq(RIG *rig, freq_t freq, vfo_t vfo);
int rig_get_freq(RIG *rig, freq_t *freq, vfo_t *vfo);

int rig_set_mode(RIG *rig, rmode_t mode, vfo_t vfo); /* select mode */
int rig_get_mode(RIG *rig, rmode_t *mode,vfo_t vfo); /* get mode */

etc..

It seems silly, but without this, we dont have a solid
"target VFO" for the existing commands.

  int (*set_freq)(RIG *rig, freq_t freq); /* select freq */
  int (*get_freq)(RIG *rig, freq_t *freq); /* get freq */

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

etc..

ie: set freq/mode could apply to any VFO, so which
one gets the command.??   Is it really the towards
the  VFO specified in previous last set_vfo() 

For example, my FT747 has separate set_freq and set_vfo cmd's
but the FT847 and others always pass VFO along with
the parameter that is being changed.

It is not good for the frontend end "app" to be
guessing about what VFO the last cmd will target.

This also, requires the backend to "remember"  the
VFO used in the last set_vfo cmd.


So, some decisions.

1. backend must "remember".  This could be part of private data
   This is no big change to frontend API.

/*
 * ft847 - private data
 *
 */

struct ft847_priv_data {
        ..
 	unsigned char active_vfo;
	..
 etc
};

  

2. Frontend API provide API with target VFO as
   an argument shown above.

I think I prefer option (1), otherwise we may
be adding VFO to everything.



Comments please / FS

Re: [Hamlib-developer] target VFO proposal

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

On Sat, Nov 25, 2000, Frank Singleton wrote:
> 
> Looking at the latest API in rig.h,
> I have come to the conclusion we are missing
> something of great importance.
> 
> We have not provided a target VFO in the set/get cmd's
> 
  arg, you're darn right!

> For example...should we have this instead..
> 
> int rig_set_freq(RIG *rig, freq_t freq, vfo_t vfo);
> int rig_get_freq(RIG *rig, freq_t *freq, vfo_t *vfo);
                                                 ^-------- typo
> int rig_set_mode(RIG *rig, rmode_t mode, vfo_t vfo); /* select mode */
> int rig_get_mode(RIG *rig, rmode_t *mode,vfo_t vfo); /* get mode */
> 
I would prefer like this (which is the same of course):
 int rig_set_mode(RIG *rig, vfo_t vfo, rmode_t mode); /* select mode */

maybe we can extend vfo_e with defines like RIG_VFO_CURR,etc.
and add some macros:

  #define rig_set_mode_c(rig,more)  rig_set_mode((rig),RIG_VFO_CURR,(mode))

> etc..
> 
> It seems silly, but without this, we dont have a solid
> "target VFO" for the existing commands.
> 
	hmmm, embarassing indeed.

> ie: set freq/mode could apply to any VFO, so which
> one gets the command.??   Is it really the towards
> the  VFO specified in previous last set_vfo() 
> 
	right now, this is the last vfo set, which is
	tricky with multithreaded apps, see below.

> So, some decisions.
> 
> 1. backend must "remember".  This could be part of private data
>    This is no big change to frontend API.
> 
[...]

> 2. Frontend API provide API with target VFO as
>    an argument shown above.
> 
> I think I prefer option (1), otherwise we may
> be adding VFO to everything.
> 
  Well, we might end up by havign to choose both, sigh.
  Unfortunately, it looks clear that we'll have to add the target VFO
  to everything in fact.  Just look at it, reentrancy-wise.
  
  Thread A				Thread B

/* not thread safe */

  rig_set_vfo(my_rig,MAIN_VFO);
  .					rig_set_vfo(my_rig,SUB_VFO);
  .					rig_set_freq(my_rig,MHz(435));
  .
  rig_set_freq(my_rig,MHz(28)); /* !!! */


/* thread safe, with some mutex around read/writes :^) */

  rig_set_freq(my_rig,MAIN_VFO,MHz(28));
  .					rig_set_freq(my_rig,SUB_VFO,MHZ(435));

  This CAN happen (and it will!). So we need to pass the vfo along
  to all the rig functions :(. That does not mean the death
  of the rig_set_vfo function though. However, on some rigs,
  the backend will have to explicitly change the vfo to update
  stuff (freq, etc.). At this point, the question is whether
  the backend should save and restore the current VFO when
  setting values.
  In that case, we would need also to implement option (1), just
  to reduce some set_vfo/get_vfo calls.

  I'm not sure if we have a good solution yet, but at least we have
  a good question to chew!!


any ideas? comments?

-- 
Stephane

Re: [Hamlib-developer] target VFO proposal

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

Stephane Fillod wrote:
> 
> On Sat, Nov 25, 2000, Frank Singleton wrote:
> >
> > Looking at the latest API in rig.h,
> > I have come to the conclusion we are missing
> > something of great importance.
> >
> > We have not provided a target VFO in the set/get cmd's
> >
>   arg, you're darn right!

<snip>

> > int rig_set_mode(RIG *rig, rmode_t mode, vfo_t vfo); /* select mode */
> > int rig_get_mode(RIG *rig, rmode_t *mode,vfo_t vfo); /* get mode */
> >
> I would prefer like this (which is the same of course):
>  int rig_set_mode(RIG *rig, vfo_t vfo, rmode_t mode); /* select mode */

> 
> maybe we can extend vfo_e with defines like RIG_VFO_CURR,etc.
> and add some macros:
> 
>   #define rig_set_mode_c(rig,more)  rig_set_mode((rig),RIG_VFO_CURR,(mode))


yes or ... see below


<snip>

>   In that case, we would need also to implement option (1), just
>   to reduce some set_vfo/get_vfo calls.
> 
>   I'm not sure if we have a good solution yet, but at least we have
>   a good question to chew!!

crunch crunch !!

> 
> any ideas? comments?


Hmm, how does ths look??

int rig_set_mode(RIG *rig, vfo_t vfo, rmode_t mode); /* select mode */
int rig_get_mode(RIG *rig, vfo_t vfo, rmode_t *mode); /* get mode */

int rig_set_freq(RIG *rig, vfo_t vfo, freq_t freq);
int rig_get_freq(RIG *rig, vfo_t vfo, freq_t *freq);


I think it is a good thing for the application to always
be VERY specific in what is wants done, and I have no problems
with this.

Perhaps we can define define some NullVFO or CurrentVFO etc 
that could indicate that the backend should use the active
VFO (and mode ?) if the App choses to pass args like..

rig_set_freq(rig, CurrentVFO, freq_t freq); /* set freq */
rig_get_freq(rig, CurrentVFO, freq_t *freq); /* set freq */

etc..
 
Comments ?? / Frank..

ps: I want to fix this before our first release unless
you have other reasons :-)

Re: [Hamlib-developer] target VFO proposal

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

On Mon, Nov 27, 2000, Frank Singleton wrote:
<snip>
> 
> Hmm, how does ths look??
> 
> int rig_set_mode(RIG *rig, vfo_t vfo, rmode_t mode); /* select mode */
> int rig_get_mode(RIG *rig, vfo_t vfo, rmode_t *mode); /* get mode */
> 
> int rig_set_freq(RIG *rig, vfo_t vfo, freq_t freq);
> int rig_get_freq(RIG *rig, vfo_t vfo, freq_t *freq);
> 
	looks good to me
>
[...]
> 
> ps: I want to fix this before our first release unless
> you have other reasons :-)

	not a problem, let's do it before the 1.1.0 release!

  BTW, can you have a look at one of my previous email on the list

   http://www.geocrawler.com/lists/3/SourceForge/5198/0/4591360/

  especially about passband width/mode setting, and tell what do you
  think of it.

  I've made some pending commits tonight, also once the passband/mode
  is solved, I'll let you know when it's OK for me to issue
  the last update/"make dist" of the 1.1.0 release.

Cheers,
-- 
Stephane