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