timed operations #86
Labels
enhancement
potential new feature
Comments
Closed
martinling
added a commit
to martinling/hackrf
that referenced
this issue
Dec 29, 2021
This lays the groundwork for implementing timed operations (greatscottgadgets#86). The M0 can be configured to automatically change modes when its byte count reaches a specific value. Checking the counter against the threshold and dispatching to the next mode is handled by a new `jump_next_mode` macro, which replaces the unconditional branches back to the start of the TX and RX loops. Making this change work requires some rearrangement of the code, such that the destinations of all conditional branch instructions are within reach. These branch instructions (`b[cond] label`) have a range of -256 to +254 bytes from the current program counter. For this reason, the TX shortfall handling is moved earlier in the file, and branches in the idle loop are restructured to use an unconditional branch to rx_start, which is furthest away. The additional code for switching modes adds 9 cycles to the normal RX path, and 10 to the TX path (the difference is because the dispatch in `jump_next_mode` is optimised for the longer RX path).
martinling
added a commit
to martinling/hackrf
that referenced
this issue
Dec 29, 2021
This lays the groundwork for implementing timed operations (greatscottgadgets#86). The M0 can be configured to automatically change modes when its byte count reaches a specific value. Checking the counter against the threshold and dispatching to the next mode is handled by a new `jump_next_mode` macro, which replaces the unconditional branches back to the start of the TX and RX loops. Making this change work requires some rearrangement of the code, such that the destinations of all conditional branch instructions are within reach. These branch instructions (`b[cond] label`) have a range of -256 to +254 bytes from the current program counter. For this reason, the TX shortfall handling is moved earlier in the file, and branches in the idle loop are restructured to use an unconditional branch to rx_start, which is furthest away. The additional code for switching modes adds 9 cycles to the normal RX path, and 10 to the TX path (the difference is because the dispatch in `jump_next_mode` is optimised for the longer RX path).
martinling
added a commit
to martinling/hackrf
that referenced
this issue
Dec 29, 2021
This lays the groundwork for implementing timed operations (greatscottgadgets#86). The M0 can be configured to automatically change modes when its byte count reaches a specific value. Checking the counter against the threshold and dispatching to the next mode is handled by a new `jump_next_mode` macro, which replaces the unconditional branches back to the start of the TX and RX loops. Making this change work requires some rearrangement of the code, such that the destinations of all conditional branch instructions are within reach. These branch instructions (`b[cond] label`) have a range of -256 to +254 bytes from the current program counter. For this reason, the TX shortfall handling is moved earlier in the file, and branches in the idle loop are restructured to use an unconditional branch to rx_start, which is furthest away. The additional code for switching modes adds 9 cycles to the normal RX path, and 10 to the TX path (the difference is because the dispatch in `jump_next_mode` is optimised for the longer RX path).
martinling
added a commit
to martinling/hackrf
that referenced
this issue
Dec 29, 2021
This lays the groundwork for implementing timed operations (greatscottgadgets#86). The M0 can be configured to automatically change modes when its byte count reaches a specific value. Checking the counter against the threshold and dispatching to the next mode is handled by a new `jump_next_mode` macro, which replaces the unconditional branches back to the start of the TX and RX loops. Making this change work requires some rearrangement of the code, such that the destinations of all conditional branch instructions are within reach. These branch instructions (`b[cond] label`) have a range of -256 to +254 bytes from the current program counter. For this reason, the TX shortfall handling is moved earlier in the file, and branches in the idle loop are restructured to use an unconditional branch to rx_start, which is furthest away. The additional code for switching modes adds 9 cycles to the normal RX path, and 10 to the TX path (the difference is because the dispatch in `jump_next_mode` is optimised for the longer RX path).
martinling
added a commit
to martinling/hackrf
that referenced
this issue
Dec 29, 2021
This lays the groundwork for implementing timed operations (greatscottgadgets#86). The M0 can be configured to automatically change modes when its byte count reaches a specific value. Checking the counter against the threshold and dispatching to the next mode is handled by a new `jump_next_mode` macro, which replaces the unconditional branches back to the start of the TX and RX loops. Making this change work requires some rearrangement of the code, such that the destinations of all conditional branch instructions are within reach. These branch instructions (`b[cond] label`) have a range of -256 to +254 bytes from the current program counter. For this reason, the TX shortfall handling is moved earlier in the file, and branches in the idle loop are restructured to use an unconditional branch to rx_start, which is furthest away. The additional code for switching modes adds 9 cycles to the normal RX path, and 10 to the TX path (the difference is because the dispatch in `jump_next_mode` is optimised for the longer RX path).
martinling
added a commit
to martinling/hackrf
that referenced
this issue
Dec 30, 2021
This lays the groundwork for implementing timed operations (greatscottgadgets#86). The M0 can be configured to automatically change modes when its byte count reaches a specific value. Checking the counter against the threshold and dispatching to the next mode is handled by a new `jump_next_mode` macro, which replaces the unconditional branches back to the start of the TX and RX loops. Making this change work requires some rearrangement of the code, such that the destinations of all conditional branch instructions are within reach. These branch instructions (`b[cond] label`) have a range of -256 to +254 bytes from the current program counter. For this reason, the TX shortfall handling is moved earlier in the file, and branches in the idle loop are restructured to use an unconditional branch to rx_start, which is furthest away. The additional code for switching modes adds 9 cycles to the normal RX path, and 10 to the TX path (the difference is because the dispatch in `jump_next_mode` is optimised for the longer RX path).
martinling
added a commit
to martinling/hackrf
that referenced
this issue
Dec 30, 2021
This lays the groundwork for implementing timed operations (greatscottgadgets#86). The M0 can be configured to automatically change modes when its byte count reaches a specific value. Checking the counter against the threshold and dispatching to the next mode is handled by a new `jump_next_mode` macro, which replaces the unconditional branches back to the start of the TX and RX loops. Making this change work requires some rearrangement of the code, such that the destinations of all conditional branch instructions are within reach. These branch instructions (`b[cond] label`) have a range of -256 to +254 bytes from the current program counter. For this reason, the TX shortfall handling is moved earlier in the file, and branches in the idle loop are restructured to use an unconditional branch to rx_start, which is furthest away. The additional code for switching modes adds 9 cycles to the normal RX path, and 10 to the TX path (the difference is because the dispatch in `jump_next_mode` is optimised for the longer RX path).
martinling
added a commit
to martinling/hackrf
that referenced
this issue
Dec 30, 2021
This lays the groundwork for implementing timed operations (greatscottgadgets#86). The M0 can be configured to automatically change modes when its byte count reaches a specific value. Checking the counter against the threshold and dispatching to the next mode is handled by a new `jump_next_mode` macro, which replaces the unconditional branches back to the start of the TX and RX loops. Making this change work requires some rearrangement of the code, such that the destinations of all conditional branch instructions are within reach. These branch instructions (`b[cond] label`) have a range of -256 to +254 bytes from the current program counter. For this reason, the TX shortfall handling is moved earlier in the file, and branches in the idle loop are restructured to use an unconditional branch to rx_start, which is furthest away. The additional code for switching modes adds 9 cycles to the normal RX path, and 10 to the TX path (the difference is because the dispatch in `jump_next_mode` is optimised for the longer RX path).
martinling
added a commit
to martinling/hackrf
that referenced
this issue
Jan 3, 2022
This lays the groundwork for implementing timed operations (greatscottgadgets#86). The M0 can be configured to automatically change modes when its byte count reaches a specific value. Checking the counter against the threshold and dispatching to the next mode is handled by a new `jump_next_mode` macro, which replaces the unconditional branches back to the start of the TX and RX loops. Making this change work requires some rearrangement of the code, such that the destinations of all conditional branch instructions are within reach. These branch instructions (`b[cond] label`) have a range of -256 to +254 bytes from the current program counter. For this reason, the TX shortfall handling is moved earlier in the file, and branches in the idle loop are restructured to use an unconditional branch to rx_start, which is furthest away. The additional code for switching modes adds 9 cycles to the normal RX path, and 10 to the TX path (the difference is because the dispatch in `jump_next_mode` is optimised for the longer RX path).
martinling
added a commit
to martinling/hackrf
that referenced
this issue
Feb 8, 2022
This lays the groundwork for implementing timed operations (greatscottgadgets#86). The M0 can be configured to automatically change modes when its byte count reaches a specific value. Checking the counter against the threshold and dispatching to the next mode is handled by a new `jump_next_mode` macro, which replaces the unconditional branches back to the start of the TX and RX loops. Making this change work requires some rearrangement of the code, such that the destinations of all conditional branch instructions are within reach. These branch instructions (`b[cond] label`) have a range of -256 to +254 bytes from the current program counter. For this reason, the TX shortfall handling is moved earlier in the file, and branches in the idle loop are restructured to use an unconditional branch to rx_start, which is furthest away. The additional code for switching modes adds 9 cycles to the normal RX path, and 10 to the TX path (the difference is because the dispatch in `jump_next_mode` is optimised for the longer RX path).
martinling
added a commit
to martinling/hackrf
that referenced
this issue
Feb 8, 2022
This lays the groundwork for implementing timed operations (greatscottgadgets#86). The M0 can be configured to automatically change modes when its byte count reaches a specific value. Checking the counter against the threshold and dispatching to the next mode is handled by a new `jump_next_mode` macro, which replaces the unconditional branches back to the start of the TX and RX loops. Making this change work requires some rearrangement of the code, such that the destinations of all conditional branch instructions are within reach. These branch instructions (`b[cond] label`) have a range of -256 to +254 bytes from the current program counter. For this reason, the TX shortfall handling is moved earlier in the file, and branches in the idle loop are restructured to use an unconditional branch to rx_start, which is furthest away. The additional code for switching modes adds 9 cycles to the normal RX path, and 10 to the TX path (the difference is because the dispatch in `jump_next_mode` is optimised for the longer RX path).
martinling
added a commit
to martinling/hackrf
that referenced
this issue
Feb 13, 2022
This lays the groundwork for implementing timed operations (greatscottgadgets#86). The M0 can be configured to automatically change modes when its byte count reaches a specific value. Checking the counter against the threshold and dispatching to the next mode is handled by a new `jump_next_mode` macro, which replaces the unconditional branches back to the start of the TX and RX loops. Making this change work requires some rearrangement of the code, such that the destinations of all conditional branch instructions are within reach. These branch instructions (`b[cond] label`) have a range of -256 to +254 bytes from the current program counter. For this reason, the TX shortfall handling is moved earlier in the file, and branches in the idle loop are restructured to use an unconditional branch to rx_start, which is furthest away. The additional code for switching modes adds 9 cycles to the normal RX path, and 10 to the TX path (the difference is because the dispatch in `jump_next_mode` is optimised for the longer RX path).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Implement timed TX and RX operations: The host requests an operation to start and/or stop at a particular time in the future.
See also: #85
┆Issue is synchronized with this Basecamp todo by Unito
The text was updated successfully, but these errors were encountered: