My uBitX arrived in the mail today and I found some time tonight to put together a sample of what is possible for developing our uBitX sketch on Github, similar to what Allard has done for the Bitx40. Farhan has indicated that he is looking for volunteers to help integrate patches () and tools like Git, GitHub, and continuous integration can make that job much more manageable for whoever is doing it.

I forked Farhan's afarhan/ubitx Github repository at . As a proof of concept, I merged the two existing pull requests from Farhan's repository. Then I added some configuration for the PlatformIO tool that has been mentioned on this list before (). PlatformIO allows building Arduino sketches from the command line and it reports many more warnings and errors than the Arduino IDE (unused variables, incorrect return types, incorrect type casts, see ).

Finally, I added configuration for the Travis-CI.org continuous integration tool. This service is free for open-source projects and watches Github for changes and runs a test suite for the new versions. A tool like this is crucial when welcoming contributions from others because it provides some basic assurances that the submitted code will at least compile. As an example, I configured a test that fails if the Arduino code has trailing whitespace (yuck; ).? You can see here that the build "failed" because there was trailing whitespace in Farhan's code, but another change in Git removed the problem and made the Travis build pass .

I just wanted to do this to show what is possible with modern software engineering tools to make it easy and reliable for many people to contribute to the uBitX code. I'd happily welcome Ian Lee's pull request adding further CAT control code for the BitX, or W8TEE's change to actual .cpp files, or improvements to the keyer timing, or who knows what comes next! Then all of us together can be sure that the code meets the (minimal) standards that the community sets out before it gets merged with the "master" branch.

In my dream world, Farhan could keep shipping uBitX kits with the basic code from his afarhan/ubitx repository, while all of us together can iterate new features in a ubitx-ng repository. The hope would be that new builders would get a working radio, but the first thing we would encourage them to do is to get the latest and greatest code from ubitx-ng. Like Allard did with the bitx40, we would maintain hardware compatibility with the radio as delivered and people who wanted to make hardware modifications could make further changes in their own repositories. (Although K3NG has shown with his arduino keyer that many different configurations can be supported in one codebase with some additional effort.)

Thanks for reading this far, and I hope, whatever people decide, that uBitx firmware development will be rapid, reliable, long-lived, community-wide, and use modern software engineering tools, for all of our benefit.

-Neil N0FN

My uBitX arrived in the mail today and I found some time tonight to put together a sample of what is possible for developing our uBitX sketch on Github, similar to what Allard has done for the Bitx40. Farhan has indicated that he is looking for volunteers to help integrate patches () and tools like Git, GitHub, and continuous integration can make that job much more manageable for whoever is doing it.

I forked Farhan's afarhan/ubitx Github repository at . As a proof of concept, I merged the two existing pull requests from Farhan's repository. Then I added some configuration for the PlatformIO tool that has been mentioned on this list before (). PlatformIO allows building Arduino sketches from the command line and it reports many more warnings and errors than the Arduino IDE (unused variables, incorrect return types, incorrect type casts, see ).

Finally, I added configuration for the Travis-CI.org continuous integration tool. This service is free for open-source projects and watches Github for changes and runs a test suite for the new versions. A tool like this is crucial when welcoming contributions from others because it provides some basic assurances that the submitted code will at least compile. As an example, I configured a test that fails if the Arduino code has trailing whitespace (yuck; ).? You can see here that the build "failed" because there was trailing whitespace in Farhan's code, but another change in Git removed the problem and made the Travis build pass .

I just wanted to do this to show what is possible with modern software engineering tools to make it easy and reliable for many people to contribute to the uBitX code. I'd happily welcome Ian Lee's pull request adding further CAT control code for the BitX, or W8TEE's change to actual .cpp files, or improvements to the keyer timing, or who knows what comes next! Then all of us together can be sure that the code meets the (minimal) standards that the community sets out before it gets merged with the "master" branch.

In my dream world, Farhan could keep shipping uBitX kits with the basic code from his afarhan/ubitx repository, while all of us together can iterate new features in a ubitx-ng repository. The hope would be that new builders would get a working radio, but the first thing we would encourage them to do is to get the latest and greatest code from ubitx-ng. Like Allard did with the bitx40, we would maintain hardware compatibility with the radio as delivered and people who wanted to make hardware modifications could make further changes in their own repositories. (Although K3NG has shown with his arduino keyer that many different configurations can be supported in one codebase with some additional effort.)

Thanks for reading this far, and I hope, whatever people decide, that uBitx firmware development will be rapid, reliable, long-lived, community-wide, and use modern software engineering tools, for all of our benefit.

-Neil N0FN

My uBitX arrived in the mail today and I found some time tonight to put
together a sample of what is possible for developing our uBitX sketch on
Github, similar to what Allard has done for the Bitx40. Farhan has
indicated that he is looking for volunteers to help integrate patches (
) and tools
like Git, GitHub, and continuous integration can make that job much more
manageable for whoever is doing it.

I forked Farhan's afarhan/ubitx Github repository at
. As a proof of concept, I merged the
two
existing pull requests from Farhan's repository. Then I added some
configuration for the PlatformIO tool that has been mentioned on this
list
before (
).
PlatformIO allows building Arduino sketches from the command line and it
reports many more warnings and errors than the Arduino IDE (unused
variables, incorrect return types, incorrect type casts, see

).

Finally, I added configuration for the Travis-CI.org continuous
integration
tool. This service is free for open-source projects and watches Github
for
changes and runs a test suite for the new versions. A tool like this is
crucial when welcoming contributions from others because it provides
some
basic assurances that the submitted code will at least compile. As an
example, I configured a test that fails if the Arduino code has trailing
whitespace (yuck;
).
You can see here
that the build "failed" because there was trailing whitespace in
Farhan's
code, but another change in Git

removed the problem and made the Travis build pass
.

I just wanted to do this to show what is possible with modern software
engineering tools to make it easy and reliable for many people to
contribute to the uBitX code. I'd happily welcome Ian Lee's pull request
adding further CAT control code for the BitX, or W8TEE's change to actual
.cpp files, or improvements to the keyer timing, or who knows what comes
next! Then all of us together can be sure that the code meets the (minimal)
standards that the community sets out before it gets merged with the
"master" branch.

In my dream world, Farhan could keep shipping uBitX kits with the basic
code from his afarhan/ubitx repository, while all of us together can
iterate new features in a ubitx-ng repository. The hope would be that new
builders would get a working radio, but the first thing we would encourage
them to do is to get the latest and greatest code from ubitx-ng. Like
Allard did with the bitx40, we would maintain hardware compatibility with
the radio as delivered and people who wanted to make hardware modifications
could make further changes in their own repositories. (Although K3NG has
shown with his arduino keyer that many different configurations can be
supported in one codebase with some additional effort.)

Thanks for reading this far, and I hope, whatever people decide, that uBitx
firmware development will be rapid, reliable, long-lived, community-wide,
and use modern software engineering tools, for all of our benefit.

-Neil N0FN