Previously these calls were leaving the amplifiers on, since the
control settings passed were missing SWITCHCTRL_NO_TX_AMP_PWR and
SWITCHCTRL_NO_RX_AMP_PWR. Use the predefined SWITCHCTRL_SAFE here.
Also move these calls before setting the GPIO pins to output mode,
to avoid driving them to the wrong states briefly first.
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.
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.
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.
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."
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.
