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.
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 change avoids various possible races in which an autonomous mode
change by the M0 might clobber a mode change made from the M4, as well
as related races on other state fields that can be written by the M4.
The previous mode field is replaced by two separate ones:
- active_mode, which is written only by the M0, and indicates the
current operating mode.
- requested_mode, which is written by the M4 to request a change.
This field includes both the requested mode, and a flag bit. The M4
writes the field with the flag bit set, and must then wait for the
M0 to signal completion of the request by clearing the flag bit.
Whilst the M4 is blocked waiting for the flag bit to be cleared, the
M0 can safely make all the required changes to the state that are
needed for the transition to the requested mode. Once the transition
is complete, the M0 clears the flag bit and the M4 continues execution.
Request handling is implemented in the idle loop. To handle requests,
mode-specific loops simply need to check the request flag and branch to
idle if it is set.
A request from the M4 to change modes will always require passing
through the idle loop, and is not subject to timing guarantees. Only
transitions made autonomously by the M0 have guaranteed timing
constraints.
The work previously done in reset_counts is now implemented as part of
the request handling, so the tx_start, rx_start and wait_start labels
are no longer required.
An extra two cycles are required in the TX shortfall path because we
must now load the active mode to check whether we are in TX_START.
Two cycles are saved in the normal TX path because updating the active
mode to TX_RUN can now be done without checking the previous value.
Previously, finding the M0 in IDLE mode was ambiguous; it could indicate
either a normal outcome, or a shortfall limit having being hit.
To disambiguate, we add an error field to the M0 state. The errors
currently possible are an RX timeout or a TX timeout, both of which
can be obtained efficiently from the current operating mode due to
the values used.
This adds 3 cycles to both shortfall paths, in order to shift down
the mode to obtain the error code, and store it to the M0 state.
