SM6FBQ / HackRF clone - History

Display total M0 and M4 counts at end of hackrf_transfer.

Doing this requires keeping track of when the 32-bit counters wrap, and
updating 64-bit running totals.

Add hackrf_transfer option to display buffer stats.

This adds the `hackrf_transfer -B` option, which displays the number of
bytes currently in the buffer along with the existing per-second stats.

The number of bytes in the buffer is indicated by the difference between
the M0 and M4 byte counters. In TX, the M4 count should lead the M0 count.
In RX, the M0 count should lead the M4 count.

Add a second counter to keep track of bytes transferred by the M4.

With both counters in place, the number of bytes in the buffer is now
indicated by the difference between the M0 and M4 counts.

The M4 count needs to be increased whenever the M4 produces or consumes
data in the USB bulk buffer, so that the two counts remain correctly
synchronised.

There are three places where this is done:

1. When a USB bulk transfer in or out of the buffer completes, the count
is increased by the number of bytes transferred. This is the most
common case.

2. At TX startup, the M4 effectively sends the M0 16K of zeroes to
transmit, before the first host-provided data.

This is done by zeroing the whole 32K buffer area, and then setting
up the first bulk transfer to write to the second 16K, whilst the M0
begins transmission of the first 16K.

The count is therefore increased by 16K during TX startup, to account
for the initial 16K of zeros.

3. In sweep mode, some data is discarded. When this is done, the count
is incremented by the size of the discarded data.

The USB IRQ is masked whilst doing this, since a read-modify-write is
required, and the bulk transfer completion callback may be called at
any point, which also increases the count.

Replace M0 state offset field with a byte count.

Instead of this count wrapping at the buffer size, it now increments
continuously. The offset within the buffer is now obtained from the
lower bits of the count.

This makes it possible to keep track of the total number of bytes
transferred by the M0 core.

The count will wrap at 2^32 bytes, which at 20Msps will occur every
107 seconds.

Add USB vendor request to read M0 state, and host support for doing so.

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.

Flush bulk endpoints from USB ISR on mode change request.

The previous change moved this flush from the vendor request handler to
the transceiver_shutdown() function which runs outside ISR context.

However, without this flush in the ISR, the firmware can sometimes end up
stuck in TX or RX mode after a request to go IDLE. It's still not clear
how this happens, but keeping the flush in the USB ISR fixes it, and as
soon as a mode change is requested we know we are going to be flushing
anyway, so there is no harm to do so here.

This commit does not remove the flush in transceiver_shutdown(), because
it is possible that the ISR will return just before the transceiver loop
queues a new transfer. Rather than try to avoid that race, we can just
flush again later.

Merge pull request #1040 from gozu42/clkout

keep clkout state over general clock reconfiguration

Move transceiver mode changes out of USB ISR.

This is a defensive change to make the transceiver code easier to reason
about, and to avoid the possibility of races such as that seen in #1042.

Previously, set_transceiver_mode() was called in the vendor request
handler for the SET_TRANSCEIVER_MODE request, as well in the callback
for a USB configuration change. Both these calls are made from the USB0
ISR, so could interrupt the rx_mode(), tx_mode() and sweep_mode()
functions at any point. It was hard to tell if this was safe.

Instead, set_transceiver_mode() has been removed, and its work is split
into three parts:

- request_transceiver_mode(), which is safe to call from ISR context.
All this function does is update the requested mode and increment a
sequence number. This builds on work already done in PR #1029, but
the interface has been simplified to use a shared volatile structure.

- transceiver_startup(), which transitions the transceiver from an idle
state to the configuration required for a specific mode, including
setting up the RF path, configuring the M0, adjusting LEDs and UI etc.

- transceiver_shutdown(), which transitions the transceiver back to an
idle state.

The *_mode() functions that implement the transceiver modes now call
transceiver_startup() before starting work, and transceiver_shutdown()
before returning, and all this happens in the main thread of execution.

As such, it is now guaranteed that all the steps involved happen in a
consistent order, with the transceiver starting from an idle state, and
being returned to an idle state before control returns to the main loop.

For consistency of interface, an off_mode() function has been added to
implement the behaviour of the OFF transceiver mode. Since the
transceiver is already guaranteed to be in an idle state when this is
called, the only work required is to set the UI mode and wait for a new
mode request.

Merge pull request #1034 from schneider42/rad1o-ui-cleanup

rad1o UI support