Martin Ling 361c4ac54f 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.
2022-02-08 13:45:41 +00:00
2020-01-20 23:33:44 +00:00
2021-12-28 18:27:01 -05:00
2016-07-14 10:27:28 -06:00
2012-03-16 09:59:45 -06:00
2021-11-15 19:29:01 -05:00

HackRF

This repository contains hardware designs and software for HackRF, a low cost, open source Software Defined Radio platform.

HackRF One

(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.

Description
No description provided
Readme 49 MiB
Languages
KiCad 70.6%
C 26%
CMake 1%
Python 1%
Assembly 0.8%
Other 0.5%