If CEC firmware is selected to be the delivered "base" then you must think about the following two implications:
1. Is Ian willing to support the "base" in the future w.r.t. uBITX production hardware changes?
As well as answering all the "newbie" questions about all the options everyone is eluding to?
2. If Ian does not support the "base", then customers will be confused by having CEC as "base" and IAN still supplying CEC firmware that is different.
rOn
toggle quoted message
Show quoted text
On May 14, 2018 at 11:09 PM K9HZ <bill@...> wrote:
Tim... I think that's where we are today...with the base level, bare bones code shipped from the factory. An increasing number of people are gravitating to the CEC firmware and that gives you an idea of what is desirable in a base-level firmware for the radio. If you really want data on this issue, Arv can set up a poll...and we can vote to see which firmware is being used.
Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ
Owner - Operator
Big Signal Ranch ¨C K9ZC
Staunton, Illinois
Owner ¨C Operator
Villa Grand Piton ¨C J68HZ
Soufriere, St. Lucia W.I.
Rent it: www.VillaGrandPiton.com
Like us on Facebook!
Moderator ¨C North American QRO Group at Groups.IO.
email: bill@...
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Tim Gorman
Sent: Monday, May 14, 2018 4:42 PM
To: [email protected]
Subject: Re: [BITX20] Should we adopt the KD8CEC firmware?
Think of it this way.
I want to add a Tune item to the menu. The item will send a CW signal and monitor an i2c peripheral for reverse power indication while the CW key is held down.
Do I duplicate the CW transmit functionality in my code in case someone wants to use my code to add the Tune functionality to their program? If I don't do that then it won't work for someone who doesn't operate CW and has deleted the CW function from the software. And the code gets bloated from two different menu items duplicating the same functionality for those that do operate CW.
Or do I wind up having to maintain two versions, one for software that has CW functionality and one for software that doesn't?
It's my opinion that we *need* a base load with a set of common functionality that experimenters can build on. The current software that Ashar provides seems to fit that bill.
If someone wants to load other software then it is up to them to manage all the complexity.
tim ab0wr
On Mon, 14 May 2018 16:38:39 +0000 (UTC) "Jack Purdum via Groups.Io" <jjpurdum@...> wrote:
I think it could be done without too much confusion by using
preprocessor directives. That way, you don't actually mess with the
code; you only change the symbolic constants you wish to affect. For
example, if you don't use CW or CAT, then
#define CWINTERFACE false // Set this to true if you
want to use CW #define CATINTERFACE false // Set this
to true if you wish to use a CAT interface
and so on. The burden of getting everything right then falls on the
programmer, not the user. The user would, however, be responsible for
their own code additions/deletions.
As to how much space this saves will depend upon the programs
kept/deleted and what you mean by "very much program space". For some
users, 50 bytes might be enough to add something they want at the cost
of deleting some existing feature. The answer to that's really a
try-it-and-see answer.
Jack, W8TEE
---
This email has been checked for viruses by AVG.
