This limit allows implementing a timeout: if a TX underrun or RX overrun
continues for the specified number of bytes, the M0 will revert to idle.
A setting of zero disables the limit.
This change adds 5 cycles to the TX & RX shortfall paths, to check if a
limit is set and to check the shortfall length against the limit.
To enable this, we keep a count of the current shortfall length. Each
time an SGPIO read/write cannot be completed due to a shortfall, we
increase this length. Each time an SGPIO read/write is completed
successfully, we reset the shortfall length to zero.
When a shortfall occurs and the existing shortfall length is zero, this
indicates a new shortfall, and the shortfall count is incremented.
This change adds one cycle to the normal RX & TX paths, to zero the
shortfall count. To enable this to be done in a single cycle, we keep a
zero handy in a high register.
The extra accounting adds 10 cycles to the TX and RX shortfall paths,
plus an additional 3 cycles to the RX shortfall path since there are
now two branches involved: one to the shortfall handler, and another
back to the main loop.
In the idle mode, the M0 simply waits for a different mode to be set.
No SGPIO access is done.
One extra cycle is added to both TX code paths, to check whether the
M0 should return to the idle loop based on the mode setting. The RX
paths are unaffected as the branch to RX is handled first.
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.
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.
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.
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.
* Clean up the CMake build system and improve the FindFFTW3 module.
* Fixes for Linux build
* Include winsock.h to get struct timeval
* Couple more fixes for MSVC, also add new FindMath module
* Update host build README for new CMake changes (esp. Windows)
* Try to fix Travis OS X build error
* Add docs about pthread-win32
* Whoops, AppVeyor caught a bug in FindFFTW where the includes not being found weren't generating a fatal error.
* Travis rebuild bump
* One more fix: replace hardcoded include paths with a PATH_SUFFIX to standard include paths
* Invert Windows preprocessor flag so it's only needed when using a static build. This preserves compatibility with the previous system.
* Fix copy-paste error
* Update cmake modules from amber-cmake upstream, incorporate TryLinkLibrary into FindUSB1
* Fix missing include
The firmware has the capability to dwell on each frequency for a
configurable duration in sweep mode, but the hackrf_sweep host tool did
not behave correctly when asked to use a non-default dwell time. The
option has never worked properly, and it is not a feature anyone seems
to want.
We previously attempted to adjust the output time stamp according to the
sample rate and placement of the samples within the USB transfer data,
but the end result was a fixed time offset with respect to the time of
USB transfer completion. We are using only those samples closest to the
end of the transfer, so it makes sense to simply use the time the USB
transfer ends and not try to correct that fixed offset.
It may be possible in the future to have a more accurate time stamp
generated in firmware, but I don't think it is worth complicating the
host code with minor time adjustments until and unless firmware-based
time stamps become available.
Now that addresses are in the range 0-7, this would previously output
"Operacakes found: 0" for the default board address. This is confusing
as it looks like it found no Opera Cakes.
* Report amplitude once per second during receive
* Added missing M_LN10 for Windoze, fixed short frame detection for RSSI
* Tweaks to math expressions
* Tweaks to math expressions
Sometimes, if a small frequency interval is scanned, the callback is
triggered even though we already have the number of sweeps we want, and
sweep_count gets increased, showing the wrong "Total sweeps".
hackrf_stop_rx() is handled in hackrf_close(), so there seems to be no need
to call it separately. Furthermore, if hackrf_stop() is called separately,
it causes hackrf_close() to take more than half a second longer.
