[chirp_devel] Interleaving banks and memories

[Dan Smith]

> Apparently the firmware wizards at Leixen have decided to update the
> featureset in the VV-898S/E, and the new 1.05 firmware adds a crazy
> vfo-based bank system to the memories. Basically, instead of a single
> unbanked set of 200 memories, now there are 100 memories each assigned
> to VFO A and VFO B. To keep things really interesting, these memories
> are interleaved.

Bizarre :/

> The old layout had all 200 memory's data structs all in series, then
> all 200 memory's name/labels all in series after that. Roughly
> speaking, it looks like:
> 
> struct mem_data memories[200];
> struct mem_name names[200];
> 
> The new layout has "memory data 1A (first memory for VFO A)", then
> "memory data 1B (first mem VFO B)", then 2A, 2B, etc. Then it starts
> all over with the same interleaving of label/names.
> 
> I don't think this would actually work, but the way I vizualize it
> right now is something like:
> 
> struct mem_interleaved_data { mem_data a, mem_data b };
> struct mem_interleaved_name { mem_name a, mem_name b };
> 
> struct mem_interleaved_data memories[100];
> struct mem_interleaved_name mem_names[100];

I think you can do this.

Also, this kinda sounds like the dual-receive dual-vfo radios that keep
memories separate on each side. I hate radios like that, but there are a
nonzero number of them. Check out some of those to see if using that
pattern would work for you. Basically, when you open such a radio, you
get two new tabs instead of one, one for each VFO. It uses the same
driver and backing file, but gives you two "views" into the memory. It's
not a super elegant solution, but it works and requires mostly minimal
effort.

Basically you just need to declare that your radio has "subdevices" and
then you have two mostly-empty subclasses of your main driver, so that
each can provide different behavior if needed. A lot of those kinds of
radios only have extended receive on one of the two VFOs.

--Dan