¿ªÔÆÌåÓý

  1. BITX20
  2. Messages
Single Messages Topics Expanded Polls

Re: Should we adopt the KD8CEC firmware?

Jack Purdum
 

Tim:

With the same amount of respect, I was not talking about coding style as in brace placement. I was referring to good standard C coding practices. In your example, if you want a TUNE feature and know that it needs a CW feature that has been turned off, it's your problem to make a non-standard change. The conditional compiles would state the impact: "If you turn this off, all CW features are turned off". Since your example assumes you don't want CW features, but you do want a TUNE feature, perhaps your solution is to figure out how to use the Tone library to send a constant note through the transmitter chain when the TUNE feature is needed. Perhaps you can bypass the CW demands with some alternative approach. But again, your demands are non-standard (not the conditional compile where CW is either ON/OFF), so the ball's in your court to solve.

Where you state:

??? If they add my functionality what's the first thing they are going to see happen? It won't work. Who then gets to
????figure out why and then who gets to fix it?

That answer's simple: You do. If you added your functionality and stated it will work without the CW features compiled into the code and it doesn't work, clearly there's a bug in your software. The key there is "...they added my functionality...". If that means they used your code and it fails, I think they rightly can expect you to tell them where they went wrong. If they modified your code, that now becomes their problem.

Also, I think you're overstating the regression testing demands. True, they may be a bit wearisome, but they are not difficult. Again, if someone wants to modify the stock software, it's up to them to make the changes. Well-designed conditional compiles are either ON or OFF, even with multiple options only one option should be active and the end of the preprocessor pass. The user can always revert to the stock software if they can't get it to meet their special needs. My guess is that you will see the same evolution for the stock software that you saw here: Users will supply code for non-standard enhancements, like your TUNE feature.

Jack, W8TEE


On Tuesday, May 15, 2018, 10:49:58 AM EDT, Tim Gorman <tgorman2@...> wrote:


Jack,

Respectfully, you missed my point. I probably wasn't clear. I didn't
mean a "coding" standard. I meant a standard software load with defined
functionality.

Trying to add functionality that others might want to use, in an
environment of multiple conditional compiles, becomes a true nightmare
of regression testing to insure the added functionality works with all
combinations of the conditional compiles.

Not doing such regression testing and throwing a software modification
out into the wild means many users are going to find that their
individual software load no longer works as intended if they try to use
the software modification.

For instance, your mention of deleting keyer code if you never use CW.
If I develop functionality like a "Tune" option that requires the CW
transmit module and some kind of a CW key to transmit a carrier, it
won't work with someone that has deleted the keyer code using their
conditional compile. If they add my functionality what's the first
thing they are going to see happen? It won't work. Who then gets to
figure out why and then who gets to fix it?

tim ab0wr

On Tue, 15 May 2018 13:25:23 +0000 (UTC)
"Jack Purdum via Groups.Io" <jjpurdum=[email protected]> wrote:

> I agree with Ron, here. Tim's statement:
>
>? ????It's important to have a *standard* to write to.
>
> would be nice, but as we all know, there is a difference between
> coding style and functionality. Cut-and-paste code is also nice to
> have, but any code may be useful if you can read and understand it.
> To me, the litmus test of good code is code that can be read and
> understood easily. When that's true, it becomes much easier to adapt
> it to your needs. Simple things like using #define's instead of
> "magic numbers" make it easier to read and adapt code. (If the IDE
> had a symbolic debugger, I might use constants, although symbolic
> constants are typeless and that can be a huge benefit in writing
> reusable code.) Writing "clever" code is rarely a benefit. Which
> would you rather read:
>
> ?? a = b >> 1;
>
> or
>
> ?? averageVoltage = baseVoltage / 2;?? // Voltage divider derives
> average voltage that's applied to pin AVERAGEVOLTAGE
>
> Perhaps the only real reason the first version might make sense is to
> cause some speed gain in the executed code, or perhaps save some
> memory. Even that, however, often makes no sense because the Gnu
> compiler is quite good at optimizations. Indeed, my guess is that the
> two forms above generate exactly the same code. You can examine the
> *.lst file to get a feel for the final answer.
>
> The final step before making it available to the public is to ask
> yourself: What can I do to make it easier to read and understand this
> code? If you cannot find changes that enhance readability, it's read
> for prime time. Even then, readers will have difference preferences
> on the way they would write the code...that's to be expected.
> However, the fact they have preferences means they can read,
> understand, and hopefully use the code.
>
> For reasons most can guess, I have not read Ian's code recently, but
> I'm sure it's readable. The fact that Farhan has even suggested using
> it as the standard means he's happy with it. If it's possible to
> conditionally compile the code (e.g., why have a keyer if you know
> you'll never use CW, leaving some room for additions you know you
> want), it seems to me to be a moot question.
>
> And to those who argue: "But conditional compiles means the users
> have to be able to change the code!" Yeah, so what? If you can't
> change the code, you still have several options: 1) accept the radio
> "as is", 2) learn enough programming to make the changes you want, or
> 3) pay a programmer to implement the changes you want. Trying to get
> a boo-hoo from me for people who don't want to invest a weekend in
> learning how to make such changes is pretty much going to fall on a
> deaf set of ears. Besides, this kind of programming is going to get
> more important down the road, not less. May as well bite the bullet
> and jump on board...you may even find you like it!
>
> Jack, W8TEE
>
>
>
>? ? On Monday, May 14, 2018, 11:53:47 PM EDT, W2CTX
> <w2ctx@...> wrote:
>
> Tim
>
>
>
>
>
> ?? When I write software I don't have reuse as part of my mindset.? I
> try to make something work that is
>
>
> broken or develop something new that does not exist.? Once it is
> tested it is given to the community to
>
>
> use.
>
>
>
>
>
> ?So if I don't care if others use my code how does that advance the
> radio?? Well one case comes to mind in that
>
>
> my keyer code had iambic A/B working correctly.? After I published
> the firmware I believe Ian looked at it.? Now
>
>
> he could not cut-n-paste my code into his firmware because he used
> different timing and different hardware pins.
>
>
> As he stated in his description of his keyer routine, he looked at my
> logic and? adapted my code into his.
>
>
> And as all good programmers do gave me acknowledgement in his header
> of his keyer module.
>
>
>
>
>
> So you don't have to create code that can be cut-n-paste to be
> useful.
>
>
>
>
>
> rOn
>
>
> On May 14, 2018 at 10:32 PM Tim Gorman wrote:
>
>
> John,
>
> If I am writing a function that others might want to use, how do I
> know which analog input to look at for a trigger by the CW key?
>
> Does my function need to look at both A3 and A6 just in case? Or do I
> use one or the other and let the user worry about fiddling with my
> code to make it work?
>
> It's important to have a *standard* to write to.
>
> tim ab0wr
>
>
>
> On Mon, 14 May 2018 13:54:44 -0700
> "John" wrote:
> I disagree that the original software is a good starting point for
> building on as its tuning and keying section need work.
>
> I think the uBitx should be shipped with a software that best
> promotes it's capabilities. That way the user can enjoy it fully
> without having to go through an upgrade process that he may not be
> willing to go through.
>
> Making room for later software changes is easy if, as said above, the
> software is segmented and shows the "memory cost" of each option.
>
> As an example below is the start of the my ubitx_20.ino file, based
> on Ian's 1.061 version.
>
> It is easy to make room by commenting out options to insert one's own
> code if desired, or simply enable "extra features".
> //================== Compile options for adding/removing features and
> saving memory =====================
> //When there are no hardware modifications (i.e. wired as per the
> HfSignals web-site) // If UNdefined, or commented OUT, assumes that
> the CW key is connected to the PTT input (A3) to free-up A6 for //
> the handsfree option here. (note that A6 could also be used for SWR
> or supply voltage monitoring). No memory impact.
>
> Groups.io Links:
>
> You receive all messages sent to this group.
>
> View/Reply Online (#49147): /g/BITX20/message/49147
> View All Messages In Topic (64):
> /g/BITX20/topic/19183012 Mute This Topic:
> The original BITX
> BITX40 by HFSignals
> uBITX by HFSignals
> BITX Store by Sunil
> BITX Web Site of Mike ZL1AXG
> -=-=-
> Change Your Subscription: /g/BITX20/editsub/141851
> Group Home: /g/BITX20
> Contact Group Owner: BITX20+[email protected]
> Terms of Service: /static/tos
> Unsubscribe: /g/BITX20/leave/defanged<hr
> style="height: 0; border: 0; border-top: 1px solid #aaa; margin: 8px
> 0;">



Join [email protected] to automatically receive all group messages.