This sort of answers my concerns about documentation and software engineering practices...sigh...
Brian K9WIS
---- Tim Gorman <tgorman2@...> 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" <vk2eta@...> 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.
