* Initial commit of hackrf_biast
* Cleaned up hackrf_biast
* Cleaned up usage info
* Include getopt.h for non-GNU systems
* Add support for overriding HackRF's default antenna power behavior in firmware. Add support for specifying antenna power behavior in libhackrf.
* Moved bias tee config routines into user_config.c, cleaned up operation of hackrf_biast
* hackrf_biast now calls usage() and exits when invoked with no arguments
* Fixed minor documentation error in usage()
* minor syntax cleanup
* Add some documentation to the host API call
* Add proper declaration magic in hackrf.h to hackrf_set_user_bias_t_opts() to appease Visual Studio
* Documentation changes suggested by @martinling
* Moved bias t setting above switch statement, removed line that explicit turned bias t off when entering OFF mode
* Change hackrf_set_user_bias_t_opts() to use a friendly struct() instead of a bitmask. User friendliness fixes to hackrf_biast options. More clang-format appeasement.
* Removed support for integer mode args from hackrf_biast
* clang-format error fixes
* Tweaked position of comment for clang-format v14
* Reformat files with clang-format v14 instead of 16
* Remove internal numeric modes for bias T settings
Co-authored-by: Martin Ling <martin-github@earth.li>
* Fix documentation error in hackrf_biast.c
---------
Co-authored-by: Martin Ling <martin-github@earth.li>
Previously we checked for OG support instead of r9 support because we
didn't yet have a way to tag firmware binaries with support for multiple
platforms.
During r9 hardware development it was thought that the MAX2839 would use
a different GPIO pin for chip select, but it ended up being the same pin
as is used for MAX2837 on other hardware revisions.
This takes the MAX283x abstraction a bit further and fixes a bug with
hackrf_debug -m.
The bootloader is configured by pin straps on certain pins. We use some
of those for other purposes in r9 which causes the bootloader to
misbehave if the device is reset from software. By switching these pins
from outputs to inputs just before reset this problem is avoided.
On the first spin of r9 one of the pins used for platform detection is
pulled up to VAA, not VCC, and VAA hasn't been switched on yet at the
time of platform detection. This results in r9 being misidentified as OG
from time to time.
As a temporary workaround until the next board spin, change the platform
from OG to r9 if it is detected as OG but has r9 pin straps.
Writing to the output bits in the TIMER3 external match register
resulted in intermittent failures that varied in likelihood from board
to board and from commit to commit for no apparent reason.
The rad1o was not starting the M0 when powered up by inserting a USB
cable. Interestingly the M0 does start when toggling the power switch.
Resetting the M0 before starting it in `main()` solves this issue.
Starting with this release we will no longer use "unknown" as the
default software version string used in cases where the version cannot
be determined from context. Instead we commit the release version string
to git so that any software built from the tagged commit will have the
appropriate release version string. After the release we will commit a
post-release version string as the new default.
We will continue to use the commit hash as version string when the
software is built inside a git repository.
On macOS 12.6 running libusb 1.0.26, the host was seen to sometimes
make an incomplete ClearFeature(ENDPOINT_HALT) request when
ClearPipeStallBothEnds was called from libusb_cancel_transfer.
The host would send the SETUP packet, and the firmware would
call usb_transfer_schedule_ack to acknowledge the upcoming IN
token. However, the host would then not send the IN token,
proceeding directly to the next SETUP.
Since an empty transfer was queued to schedule the ACK, the
firmware would leak one transfer from the free_transfers list.
After a few iterations of this, the firmware would run out of
free transfers and the next request would hang waiting for one.
Fix this by flushing the transfer queues for the control endpoint
when a new SETUP is received, since that token implicitly cancels
any previously ongoing request.
