SM6FBQ / HackRF clone - History

Replace TX flag with a mode setting.

This is to let us start adding new operatin modes for the M0.

Check for sufficient bytes, or space in buffer, before proceeding.

In TX, check if there are sufficient bytes in the buffer to write a
block to SGPIO. If not, write zeros to SGPIO instead.

In RX, check if there is sufficent space in the buffer to store a block
read from SGPIO. If not, do nothing, which discards the data.

In both of these shortfall cases, the M0 count is not incremented.

This ensures that in TX, old data is never repeated. The M0 will not
resume writing TX samples to SGPIO until the M4 count advances,
indicating new data being ready in the buffer. This fixes bug #180.

Similarly, in RX, old data is never overwritten. The M0 will not resume
writing RX samples to the buffer until the M4 count advances, indicating
new space being available in the buffer.

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