Added driver for Baofeng UV-17 fixes #10865

[vdwel]

This driver adds support for the Baofeng UV-17 radio with the blue background screen. It fixes issue #10865

CHIRP PR Checklist

The following must be true before PRs can be merged:

• All tests must be passing.
• Commits should be squashed into logical units.
• Commits should be rebased (or simply rebase-able in the web UI) on current master. Do not put merge commits in a PR.
• Commits in a single PR should be related.
• Major new features or bug fixes should reference a CHIRP issue.
• New drivers should be accompanied by a test image in tests/images (except for thin aliases where the driver is sufficiently tested already).
• All files must be GPLv3 licensed or contain no license verbiage. No additional restrictions can be placed on the usage (i.e. such as noncommercial).

Please also follow these guidelines:

• Keep cleanups in separate commits from functional changes.
• Please write a reasonable commit message, especially if making some change that isn't totally obvious (such as adding a new model, adding a feature, etc).
• The first line of every commit is emailed to the users' list after each build. It should be short, but meaningful for regular users (examples: "thd74: Fixed tone decoding" or "uv5r: Added settings support").
• Do not add new py2-compatibility code (No new uses of six, future, etc).
• All new drivers should set NEEDS_COMPAT_SERIAL=False and use MemoryMapBytes.
• New drivers and radio models will affect the Python3 test matrix. You should regenerate this file with tox -emakesupported and include it in your commit.

[vdwel]

I somehow can't manage to reduce the overlapping code with the UV-17 Pro driver. Any suggestions?

[kk7ds]

Yeah, there's still a lot that is shared between them, so there's plenty of room to re-use code I think. Some of your closures like apply_code() can be brought out to module-level and used by both. Looks like your sync_in(), sync_out() and get_features() are basically identical between the two. There's no need to re-define those if they're the same as the parent of course. Also looks like a lot of get_memory() could be the same. You can refactor the pro driver to break out things like the mem.extra stuff into a separate helper and then just call that from both drivers to avoid replicating that.

[vdwel]

Don't merge this one yet. It seems that some people are not able to connect to their radio, using this driver.. I am trying to figure out if the problem is the driver or that there is another UV-17 radio out there which I haven't heard of yet.

[vdwel]

People were trying to use the Pro driver for this non-pro driver. :-) How do we fix the fact that it is all so confusing??

So don't put it on hold for merging..

I will try to fix the code reuse issue first... But I'm afraid that's going to be a challenge.. And I don't have infinite time..

[vdwel]

I have modified this driver to use a lot of code from the UV-17Pro driver. In order to do so, I also had to modify the UV-17Pro driver. The new version of the Pro driver needs to be merged before this one.

[kk7ds]

We should just put both commits in this PR, so we can see it tested together. They're definitely related enough to be merged as a unit.

[kk7ds]

Thanks, it's a holiday weekend here so I've been a bit tied up with other stuff.

[kk7ds]

Does this comment refer to the conditional offsets below?

You can use #skip in your memory format to move forward a specific amount, if it helps. When I've written drivers that don't store memories all linearly, I generally try to define the format declaratively instead of doing stuff like this. Something like:

struct mem lowmems[252];
#skip 0x0x10;
struct mem highmems[506];
// ... etc

Your comment in get_memory() mentions that there's a 16-byte "page number". Not really sure what that means but you can also do something like this:

struct {
  struct mem memories[252];
  u8 page_stuff[16];
} mem_page[3];

The reason to define it like this instead of just papering over it the way you are doing here, is that these "page number" structures will be represented in the browser as memories with non-sensical data in them, which is not great.

At the very least, you should probably make this logic a helper so you don't have to repeat it in get_memory() and set_memory(), especially if you ever have to tweak it.

Oh and this makes me realize - you didn't implement get_raw_memory() here or for the pro one. You should do that, because it makes it much easier to iterate and fix things.

[vdwel]

Fixed. Added get_raw_memory and removed the offset stuff..

[vdwel]

Thanks for looking at the code!!

[kk7ds]

Ah, looks like you squashed the refactor and new driver commits together. I had just brought the other commit in there. I know it's probably maddening to understand my preferences here but: commit history should be clean, methodical changes that build on each other and don't do and then undo things in one epoch of development. So, refactoring one driver in a commit so the next commit can make a change on its own is totally cool, and means that reviewing one commit alone is still easy.

So, if it's cool with you I'll split this back in two (commits) before I merge, since it's trivial to do so and then I promise to take my pill.

Also, I didn't notice before but you need to be adding these drivers to the test matrix as "python3 tested" which is why the existing two drivers show up on the front page with an asterisk. I'll do that for you while I'm splitting this.