The current code does reads and writes in two chunks: one of
6 words, followed by one of 2.
Instead, use two chunks of 4 words each. This takes the same number of
total cycles, but frees up two registers for other uses.
Note that we can't do things in one chunk, because we'd need eight
registers to hold the data, plus a ninth to hold the buffer pointer. The
ldm/stm instructions can only use the eight low registers, r0-r7.
So we have to use two chunks, and the most register-efficient way to do
that is to use two equal chunks.
Previously this register was reloaded with the same value during each loop.
Initialising it once, outside the loop, saves two cycles.
Note the separation of the loop start ("loop") from the entry point ("main").
Code between these labels will be run once, at startup.
These variables are already placed together; this commit just groups
them into a struct and declares this in a new header.
This commit should not result in any change to the firmware binary.
Only the names of symbols are changed.
This removes the definition of the offset variable,
volatile uint32_t usb_bulk_buffer_offset = 0;
which is actually superfluous. This variable, along with its neighbour
usb_bulk_buffer_tx, is placed explicitly by the linker script. Its type
is defined by the declaration in usb_bulk_buffer.h.
There is no need to define it here, and doing so gives the misleading
impression that its initial value can be changed by modifying this line!
The initialization to zero never actually takes effect, because the
variable is not placed in the .data or .bss sections which are
initialised by the startup code.
The offset and tx variables are both set in set_transceiver_mode
before SGPIO streaming is started, so the M0 code does not use
them uninitialised.
* 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.
This uses `add_custom_command` to run a cmake script instead of using
`configure_file` directly, which allows for adding dependencies and
creates an ouput that can be depended on.
It also uses `add_custom_command` instead of `add_custom_target` to
create the M0 binary, since custom targets have no output file to depend
on.
Unfortunately, multiple targets cannot depend on the same generated file
or cmake tries to run the generation multiple times in parallel. So, the
.bin/.s generation is now duplicated for each target so they don't
conflict.
fixes#693
Build on Linux fails if libfftw3 is not available since commit
a8c1fc92e9
which replaced
pkg_check_modules(FFTW REQUIRED fftw3f)
by
find_package(FFTW REQUIRED)
Fix this build failure by updating FindFFTW.cmake to check for fftw3f
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
