Where our callback is called with a status other than COMPLETED,
something abnormal has happened and we no longer want to either
submit further transfers or await a flush. So clear the streaming
and flush flags, and proceed to transfer_finished.
Do the same in the case where libusb_submit_transfer fails when
called to submit the flush transfer.
Firmware now detects the hardware it is running on at startup and
refuses to run if it is compiled for the wrong platform. The board ID
returned by firmware to the host is now derived from run-time detection
rather than a compile-time value. A separate method to retrieve
compile-time supported platform is added.
On HackRF One, pin straps are checked to determine hardware revision.
This is informational to aid troubleshooting and does not affect any
function.
Applications may need to learn the size of the USB transfer buffer
queue, for example to determine how many bytes will be preloaded with
calls to the TX callback.
I believe this was safe before, because this code is only called from
the transfer thread, and the condition being protected is just whether
the count is zero, not the actual value of the count.
However, this isn't performance critical and it's a lot easier to
reason about the code if we just hold the lock for this whole section.
This simplifies the code required to wait for cancellations to complete.
The condition variable now reflects whether `active_transfers == 0`, and
the associated lock must be held to decrement that count to zero.
These were added in #805, as a workaround to prevent their parent
functions from returning before transfer cancellations had completed.
This has since been fixed properly in #1029.
There are now only two possible outcomes to this function: either we
successfully resubmitted a transfer, or the transfer is finished and we
end up calling transfer_finished().
So we can go ahead and simplify it accordingly.
If a transfer was cancelled, we are on our way to shutdown.
If hackrf_stop_tx() or hackrf_stop_rx() were called, they will already
have cleared this flag, but it is not cleared in hackrf_close(), and
for consistency with other paths it makes sense to clear it here.
If result < 0 here, libusb_submit_transfer returned an error, so we
need to shut down.
If !resubmit, then cancel_transfers() was already called by one of the
stop or close functions, so streaming is already false.
In the case of a libusb error, we still need the transfer thread
running, in order to handle outstanding cancellations and to signal the
condition variable when that is done.
transfer_threadproc has a timeout of half a second, so
when kill_transfer_thread tries to pthread_join, it often
has to wait until the timeout kicks in.
With this fix, we ensure that a final request is made after
request_exit has been called, so that transfer_threadproc can exit its
loop in a fast and clean manner.
This adds a `hackrf_debug [-S|--state]` option, and the necessary
plumbing to libhackrf and the M4 firmware to support it.
The USB API and libhackrf versions are bumped to reflect the changes.
Calling libusb_cancel_transfer only starts the cancellation of a
transfer. The process is not complete until the transfer callback
has been called with status LIBUSB_TRANSFER_CANCELLED.
If hackrf_start_rx() is called soon after hackrf_stop_rx(),
prepare_transfers() may be called before the previous cancellations
are completed, resulting in a LIBUSB_ERROR_BUSY when a transfer is
reused with libusb_submit_transfer().
To prevent this happening, we keep track of which transfers have
finished (either by completion, or cancellation), and make
cancel_transfers() wait until all transfers are finished.
This is implemented using a pthread condition variable which is
signalled from the transfer thread.
Fixes bug #916.
Previously, there was a race which could lead to a transfer being left
active after cancel_transfers() completed. This would then cause the
next prepare_transfers() call to fail, because libusb_submit_transfer()
would return an error due to the transfer already being in use.
The sequence of events that could cause this was:
1. Main thread calls hackrf_stop_rx(), which calls cancel_transfers(),
which iterates through the 4 transfers in use and cancels them one
by one with libusb_cancel_transfer().
2. During this time, a transfer is completed. The transfer thread calls
hackrf_libusb_transfer_callback(), which handles the data and then
calls libusb_submit_transfer() to resubmit that transfer.
3. Now, cancel_transfers() and hackrf_stop_rx() are completed but one
transfer is still active.
4. The next hackrf_start_rx() call fails, because prepare_transfers()
tries to submit a transfer which is already in use.
To fix this, we add a lock which must be held to either cancel transfers
or restart them. This ensures that only one of these actions can happen
for a given transfer; it's no longer possible for a transfer to be
cancelled and then immediately restarted.
