| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
By calling radio_control::enable_rx_timestamps(false, chan), the radio
will not add timestamps to outgoing packets.
|
| |
|
|
| |
This matches the streamer code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a separate version of multi_usrp for RFNoC devices. It is
compatible with RFNoC devices only, and prefers C++ APIs over property
tree usage. The factory of multi_usrp is modified such that it picks the
correct version, users of multi_usrp don't care about this change.
This also introduces some API changes:
- Removing redundant GPIO functions. Now all GPIO control, setting, and
readback is done with uint32_t's.
- Adding getter/setter for GPIO source. This was done to simplify the
other GPIO settings, as the source for each pin is not always a
binary. The CTRL mode, for example, can either be ATR or GPIO.
However, the source can be controlled by various radios or "PS" or
some other source.
- Removing the mask from the RFNoC radio controllers' set_gpio_attr().
- Adding state caching to gpio_atr_3000, and a getter for it. Whenever
an attribute is set, that value is cached, and can now be retreieved.
- Remove low-level register API. Since UHD 3.10, there is no USRP that
implements that API.
Modifying the filter API in the following ways:
- Splitting filter API getter/setter/list into separate RX and TX
functions
- Adding channel numbers as an argument
- The filter name will no longer be a property tree path, but rather a
filter name. For RFNoC devices, this will take the form
`BLOCK_ID:FILTER_NAME`. For non-RFNoC devices, this will just be the
filter name (e.g. `HB_1`)
- Removing search mask from listing function. Users can do their own
searching
Co-Authored-By: Martin Braun <martin.braun@ettus.com>
|
| |
|
|
|
|
|
| |
- Burst ACKs are already handled by the TX streamer, but the radio now
also sends an action upstream on reception of a burst ACK
- Late commands were only acquitted by an 'L', now an action gets sent
downstream and is handled in the rx streamer
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This modifies the overrun handling such that the RX streamer does not
restart the radios until the packets that were buffered prior to the
overrun are read by the user.
When an RX streamer receives an overrun, it will run the following
algorithm:
1. Stop all upstream producers.
2. Set an internal flag in the streamer that indicates that the
producers have stopped due to an overrun.
3. Continue servicing calls to recv until it runs out of packets in the
host buffer (packets that can be read from the transport using a 0
timeout).
4. Once the packets are exhausted, return an overrun error from recv.
The radio, if it was in continuous streaming mode before the overrun,
includes a flag in its initial action whether or not to restart
streaming.
5. If the radio requested a restart, the streamer submits a restart
request action upstream. This action will be received by the radio.
The radio will then check the current time, and send a stream command
action back downstream.
6. The RX streamer receives the stream command action, and uses it to
send another stream command to all upstream producers. This way, all
upstream producers receive a start command for the same time.
|
| |
|
|
|
|
| |
Add an async message queue that aggregates errors from multiple sources.
Errors can come from the strs packets originating from the stream
endpoint or from the radio block through control packets to the host.
|
| |
|
|
|
| |
This adds a method to the radio to check if an async message is valid,
which can be used to ack async messages immediately.
|
| |
|
|
|
| |
This is a helper method for property resolution, where set_rate() is not
appropriate.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MTUs are now tracked through the framework for all childs of
noc_block_base. Every edge gets an 'mtu' property. MTU can be set and
get either through the prop API, or through new API calls (get_mtu(),
set_mtu()). It is also possible to create custom properties that depend
on the MTU by asking for a reference to the MTU property, and then
adding that to the input list of a property resolver.
The radio_control_impl includes a change in this commit where it sets
the spp based on the MTU.
Blocks can also set an MTU forwarding policy. The DDC block includes a
change in this commit that sets a forwarding policy of ONE_TO_ONE,
meaning that the MTU on an input edge is forwarded to the corresponding
output edge (but not the other edges, as with the tick rate).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to enable overrun handling through the action API, a few new
features are implemented:
- The RX streamer can now accept stream command actions. The streamer
will interpret stream command actions as a request to send stream
commands upstream to all producers.
- A new action type is defined ('restart request') which is understood
by the radio and streamer, and is a handshake between producers and
consumers. In this case, it will ask the radio to send a stream
command itself.
When an RX streamer receives an overrun, it will now run the following
algorithm:
1. Stop all upstream producers (this was already in the code before this
commit).
2. If no restart is required, Wait for the radios to have space in the
downstream blocks.
The radio, if it was in continuous streaming mode before the overrun,
includes a flag in its initial action whether or not to restart the
streaming. Also, it will wait for the stop stream command from the
streamer. When it receives that, it will initiate a restart request
handshake.
3. The streamer submits a restart request action upstream. This action
will be received by the radio.
The radio will then check the current time, and send a stream command
action back downstream.
4. The RX streamer receives the stream command action, and uses it to
send another stream command to all upstream producers. This way, all
upstream producers receive a start command for the same time.
|
| |
|
|
| |
These are no longer used.
|
| |
|
|
|
|
|
|
|
| |
Async messages (like, e.g., overrun messages) can include a timestamp.
This change enables access to the timestamp in the async message
handler. It is up to the FPGA block implementation to include the
timestamp, if desired/necessary. The definition of the timestamp may
also depend on the block, for example, the overrun async message will
include the time when the overrun occurred.
|
| |
|
|
|
|
|
| |
This will receive async messages from the radio, and print OUL
characters where appropriate.
When an overrun message is received, it will send an action upstream to
initiate overrun handling.
|
| |
|
