On rad1o, the UI update could block this loop from running for long
enough that it could stall in a state where neither of the conditions
was met.
Fix this by removing the 'phase' variable, in favour of a counter
tracking the number of bytes that have been scheduled for USB transfer.
Whenever there are enough bytes to schedule the next transfer, do so.
Meanwhile, the M0 count is prevented from wrapping around and clobbering
data not yet sent, because the M0 code monitors the m4_count variable
which is updated as each transfer completes.
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.
The existing 'delay' function is not calibrated to any specific measure
of time. Add a new function using a loop with a known cycle count, to
produce delays of a given duration at a given CPU clock speed.
* jenkins: initial commit
* jenkins: add missing usb hub check script
* jenkins: squish docker apt package install commands into a single command
* jenkins: fix type in Dockerfile
* jenkins: override interactive installations in Dockerfile (build-essentials fails due to tzdata)
* jenkins: set executable flag on ci scripts
* jenkins: remove sudo prefix from install scripts
* jenkins: add python3 venv to Dockerfile and build scripts
* jenkins: add missing python venv command to host install script
* jenkins: remove python install and venv redundancies
* jenkins: remove make install step, run hackrf tools directly from their build directory
* jenkins: re-add python3 and pip installations to docker because usbhub depends on them
* jenkins: add missing git install to docker
* jenkins: add python-is-python3 to docker's installed dependencies
* jenkins: use path string to specify the correct device for dfu-util
* jenkins: specify usbhub id for dual hub setup
* jenkins: turn unused usb hub ports off for testing
* jenkins: remove custom job throttle property
* use --disable-i2c usbhub option, install usbhub from latest, replace --privileged with cgroups option, remove redundancies from Dockerfile
* update device usb path for dfu-util
* remove apt/lists/* and fix typos
* ci: remove redundant environment setup in Jenkins
* Documentation: Add RF shield installation instructions page.
Add a page with written instructions for installing a RF shield on a HackRF One. Includes pictures of various steps in the process
* Documentation: Add rf_shield_installation.rst that was left out of previous commit.
* Documentation: Move tag in multiple_device_hardware_synch.rst to correct location.
* Documentation: Add edits suggested by straithe to rf_shield instructions
From USB 2.0, section 9.4.5:
"For endpoints using data toggle, regardless of whether an endpoint has
the Halt feature set, a ClearFeature(ENDPOINT_HALT) request always
results in the data toggle being reinitialized to DATA0."
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.
