Hello,
Attached is patch vx8-4881-1.patch. This patch lays some groundwork for adding setting support for the VX-8 (Issue #4881).
The patch simply moves all VX8DRadio class functions that I anticipate will be needed for the VX-8R up to the VX8Radio class.
None of the functions have been modified in any way and there are no changes to Chirp behaviour. I will follow this patch with a second groundwork patch where I will modify the radio memory layout to accommodate differences between the VX-8DR/VX-8GE and VX-8R layouts.
I have tested the attached patch will all three radio image files and all tests pass except that the Settings test continues to be skipped for the VX-8R only.
73's,
Keith
On Mon, Jun 5, 2017 at 5:07 PM, Keith Williamson hkwilliamson@gmail.com wrote:
Hello,
Attached is patch "vx8-4883.patch" which resolves bug issue #4883. This patch simply creates distinct MODELs for each of the supported VX-8 variants and removes the VARIANT constant for each of the radio classes. The result is new Yaesu radio drop down selections for VX-8R, VX-8DR, and VX-8GE. Also attached are test image files for each of the three radios. Running "run-tests" for each of the radios yields all PASSED except for the VX-8R which yields SKIPPED for the Settings test. Running a full "run-tests" shows 735 TOTAL with 624 PASSED and 111 SKIPPED.
The tests/images file Yaesu_VX-8_R.img is replaced by identical file Yaesu_VX-8R.img reflecting the assumed naming convention of MANUFACTURER_MODEL[_VARIANT]. img since the "R" variant was subsumed into the model.
Cheers,
Keith KF7DRV
On Mon, Jun 5, 2017 at 1:49 PM, Dan Smith via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
OK cool. In that case, I'll leave the bug fix as is and make that the first patch. The goal of the first patch is simply to ensure that if you download from a VX-8R, you don't generate trace back errors and you don't get a Settings menu at all. In other words, ensure that the correct code gets called for a given variant.
Yeah, good plan.
On an administrative note, should we just reject Issue 4881 and have me create a new issue with the scope of work limited to the bug fix?
It's up to you, but I don't think you need to close it. You could call all of your patches "groundwork" for getting to 4881, or open a new bug for the correctness (i.e. fixing the tracebacks) and then any refactors are mostly groundwork for the end goal of settings support for the base driver.
But, your call as you're doing the work. I just granted you permissions to monkey with the issues, so you can close/create/link as you see fit.
Thanks!
--Dan
chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers