f3633e285f
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.
HackRF
This repository contains hardware designs and software for HackRF, a low cost, open source Software Defined Radio platform.
(photo by fd0 from https://github.com/fd0/hackrf-one-pictures)
principal author: Michael Ossmann mike@ossmann.com
Information on HackRF and purchasing HackRF: https://greatscottgadgets.com/hackrf/
Documentation
Documentation for HackRF can be viewed on Read the Docs. The raw documenation files for HackRF are in the docs folder in this repository and can be built locally by installing Sphinx Docs and running make html. Documentation changes can be submitted through pull request and suggestions can be made as GitHub issues.
Getting Help
Before asking for help with HackRF, check to see if your question is listed in the FAQ.
For assistance with HackRF general use or development, please look at the issues on the GitHub project. This is the preferred place to ask questions so that others may locate the answer to your question in the future.
We invite you to join our community discussions on Discord. Note that while technical support requests are welcome here, we do not have support staff on duty at all times. Be sure to also submit an issue on GitHub if you've found a bug or if you want to ensure that your request will be tracked and not overlooked.
If you wish to see past discussions and questions about HackRF, you may also view the mailing list archives.
GitHub issues on this repository that are labelled "technical support" by Great Scott Gadgets employees can expect a response time of two weeks. We currently do not have expected response times for other GitHub issues or pull requests for this repository.