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:
/mt/19183012/141851 New Topic:
/g/BITX20/post -=-=-
The original BITX
BITX40 by HFSignals
uBITX by HFSignals
BITX Store by Sunil
BITX Web Site of Mike ZL1AXG
/g/BITX20/wiki/home Wiki
-=-=-
Change Your Subscription: /g/BITX20/editsub/141851
Group Home: /g/BITX20
Contact Group Owner: [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;">

开云体育

with the wa6isp and other replacement boards you have i2c but I cant
get multi screens working.. anyone have a howto for multi screen

I haven't looked at Ian's code yet.
But suspect it is plenty readable.
And if it's readable, there's a bunch of people here that could
support it. And I doubt Farhan would ship with it unless he was
confident he understood it and could make his own mods and fixes.

Farhan would be shipping something that is hopefully stable.
And if Ian is so inclined, he will continue adjusting the code to
suit his whims. Now I'm confused, was there somehow a problem with
this??

Generally, a few hundred lines of C code is fairly easy to figure out.
Though there are exceptions:
? ?
? ??

Jerry, KE7ER

On Mon, May 14, 2018 at 09:24 pm, W2CTX wrote:

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.

Tim

? On this point I agree with you 100%.?

That is why our team (W0EB/N5IB/W2CTX) tries to supply a single package that has all the options

people might want.

All this discussion is like trying to cram 10 pounds of potatoes into a 5 pound bag!? Lets face it the NANO is not

the processor for what the future of uBITX is.

rOn

Hello Tim,

The keyer input is also defined so your program only need make
reference to the defined label (ANALOG_KEYER here), not the hardware
pin per say:

From the code:

#define ANALOG_KEYER? ? (A3)

73, John (VK2ETA)

Support? You think the uBITx is supported?

This is right off the HFSignals webside as indicates the limit of
support: " This program is distributed in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied warranty
of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE." And..." If
you are interested or building any of the HF Signals’ kits, you can
join the BITX20 group by visiting /g/bitx20. That’s
the only support we provide. The level of collective wisdom and
experience on the Forum is enough to sort out almost any technical
problem or question you may have. You will also meet some really
great builders on the Forum."

Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ
PJ2/K9HZ

Owner - Operator
Big Signal Ranch – K9ZC
Staunton, Illinois

Owner – Operator
Villa Grand Piton – J68HZ
Soufriere, St. Lucia W.I.
Rent it: www.VillaGrandPiton.com
Like us on Facebook!

Moderator – North American QRO Group at Groups.IO.

email: bill@...

开云体育

Hi,

May I order one AGC and one Click kit please for delivery to France ...

Many thanks,

Gilles Delpech, F1BFU?

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:
/mt/19183012/141851 New Topic:
/g/BITX20/post -=-=-
The original BITX
BITX40 by HFSignals
uBITX by HFSignals
BITX Store by Sunil
BITX Web Site of Mike ZL1AXG
/g/BITX20/wiki/home Wiki
-=-=-
Change Your Subscription:
/g/BITX20/editsub/141851 Group Home:
/g/BITX20 Contact Group Owner:
[email protected] mailto:[email protected] Terms of
Service: /static/tos Unsubscribe:
---------------------------------------------
/g/BITX20/leave/defanged<hr
/g/BITX20/leave/defanged style="height: 0; border:
0; border-top: 1px solid #aaa; margin: 8px 0;">