Ron,
This really isn't my point. If I am adding menu software to send CW and
measure reverse power how do I know if future users of the software
will even have the CW software if it can be removed with a define?
If someone does take the software and integrate it in their menu
section and it doesn't work because they defined CW out of their
software who is going to be responsible for troubleshooting why it
doesn't work? The user or the software coder?
It isn't an issue of others using my software, it is an issue of who
will be responsible for it not working in a system with all kinds of
options that could break its functionality?
tim ab0wr
On Mon, 14 May 2018 23:51:39 -0400 (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] 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;">
