I've made some custom converters in the past for RFNoC devices. This page
is supposed to be useful:
https://files.ettus.com/manual/page_converters.html
Attached is the relevant code to make a simple converter. Note it isn't
performant, but it gets the job done.
In my main(), I then call register_converter() which adds the converters.
When streaming, I then have stream_args("f32","u32") and the appropriate
converter is used by UHD.
Feel free to play around.
Brian
On Tue, Mar 14, 2023 at 2:23 PM Rob Kossler <rkoss...@nd.edu> wrote:
> I think that there are 2 places where byte ordering occurs: in the FPGA at
> the Streaming Endpoint (SEP) and in UHD with a particular converter.
> Assuming a 64-bit CHDR word coming into the SEP, the SEP orders the bytes
> according to what it thinks the "item" size is (I really don't know how it
> knows the item size or if/how you can configure it differently). But, in
> any case, if the SEP thinks that the item size is 4 bytes, it will order
> the bytes by MSB in order to send across the link (e.g., Ethernet). If the
> CHDR width is 8 bytes and the item size is 4 bytes, I'm not sure if the SEP
> will send the lower "item" first or the upper "item" first.
>
> On the UHD side, it will assume an item type based on the rx streamer OTW
> setting (e.g., "sc16") and will swap bytes if needed for a little endian
> host. (I do not know if the OTW setting affects the behavior of the SEP on
> the FPGA but perhaps it does.)
>
> Until I understand things better, I have resigned myself to having to
> assume that both the FPGA and UHD will treat my bytes as an sc16 such that
> I have to pre-arrange and/or post-arrange any manipulations performed by
> the SEP and UHD converter. This is not very convenient.
> Rob
>
> On Tue, Mar 14, 2023 at 12:10 PM Marcus D. Leech <patchvonbr...@gmail.com>
> wrote:
>
>> On 14/03/2023 10:27, Vermeulen, Bas (Consultant) wrote:
>>
>> The problem isn't so much the byteswapping in the int16, but the int16's
>> being swapped.
>>
>> I am sending SC16's (I0 Q0 I1 Q1 I2 Q2 I3 Q3), and expect to receive the
>> 16 bit values in the same order (Val0 Val1 Val2 Val3).
>> When using sc8's, I got (I3 Q3 I2 Q2 I1 Q1 I0 Q0) which I didn't expect
>> at all.
>>
>> Regards,
>>
>> Bas Vermeulen
>>
>> Like i pointed out earlier, X310 doesn't support SC8 data, so I have no
>> idea what it will do if you try to "force" the issue.
>>
>>
>> ------------------------------
>> *From:* Marcus D. Leech <patchvonbr...@gmail.com>
>> <patchvonbr...@gmail.com>
>> *Sent:* Wednesday, March 8, 2023 8:46 PM
>> *To:* Rob Kossler <rkoss...@nd.edu> <rkoss...@nd.edu>
>> *Cc:* usrp-users@lists.ettus.com <usrp-users@lists.ettus.com>
>> <usrp-users@lists.ettus.com>
>> *Subject:* [USRP-users] Re: RFNOC module sending back (or receiving)
>> data in the wrong order
>>
>> Sent by an external sender
>> ------------------------------
>> On 08/03/2023 14:41, Rob Kossler wrote:
>>
>> Agreed, but it doesn't seem too much to expect that UHD should natively
>> supply a "non-swapping" converter so that each user who needs one doesn't
>> have to develop it.
>> Rob
>>
>> In this case, the RFNOC code is kinda pretending that it's sending int16
>> integers, but the actual semantic is somewhat different.
>> So a non-swapping converter would happen to work in this case, but it's
>> kind of subverting the "object model" a bit.
>>
>> Perhaps some kind of "raw" converter in which there's no implied object
>> semantics.
>>
>>
>> On Wed, Mar 8, 2023 at 1:45 PM Marcus D. Leech <patchvonbr...@gmail.com>
>> wrote:
>>
>> On 08/03/2023 13:36, Rob Kossler wrote:
>>
>> Oh yeah, I forgot. Does this imply that there is no way to keep UHD from
>> swapping bytes in an rx_streamer (using X310)? If so, this seems like a
>> problem for RFNoC development since the data coming across the wire can be
>> in any format the designer chooses. And, swapping in the FPGA is not a
>> good solution because you don't know the Endianness of the host.
>> Rob
>>
>> The "doctrine" has been to represent data types in their "natural
>> network-byte-order" on the wire, and the host code
>> can do whatever it needs to do. This is consistent with practice in
>> nearly-all other disciplines that send data over
>> the network (whether that's the Internet or other ethernet networks,
>> etc).
>>
>> For little-endian hosts, UHD has to do the swap.
>>
>> But UHD allows you to register your own converter methods. I've never
>> done it myself, but I don't think it's that hard.
>>
>>
>>
>> On Wed, Mar 8, 2023 at 12:07 PM Marcus D. Leech <patchvonbr...@gmail.com>
>> wrote:
>>
>> On 08/03/2023 11:42, Rob Kossler wrote:
>>
>> Maybe can you just change the streamer OTW & CPU format to "sc8" such
>> that no byte swapping will occur?
>>
>> I know that on the default X3xx builds, there's no sc8 format implemented
>> on the USRP end.
>>
>>
>>
>> On Tue, Mar 7, 2023 at 10:31 PM Wade Fife <wade.f...@ettus.com> wrote:
>>
>> You could swap the bytes in your block, or swap them in software on the
>> host. The data gets rearranged by the streamer depending on the data type
>> configured (e.g., sc16) and the endianness of the host machine.
>>
>> Wade
>>
>> On Tue, Mar 7, 2023 at 2:45 AM Vermeulen, Bas (Consultant) via USRP-users
>> <usrp-users@lists.ettus.com> wrote:
>>
>> Hi,
>>
>> We are developing an RFNOC module that takes I/Q data, and turns that
>> into two 8 bit values.
>> I have a test program that sends data to the RFNOC module, and receives
>> the modified data.
>>
>> The RFNOC module treats the two 8 bit values as one signed 16 bit value.
>> When I read the data from the test program, I get it in the wrong order:
>>
>> Send: Re0 Im0 Re1 Im1 Re2 Im2 Re3 Im3
>> Receive: Val1 Val0 Val3 Val2
>>
>> Does anyone have any idea how to fix the order of the received values?
>>
>> Regards,
>>
>> Bas Vermeulen
>>
>> ------------------------------
>>
>>
>>
>> CONFIDENTIALITY NOTICE: This message (including any attachments) may
>> contain Molex confidential information, protected by law. If this message
>> is confidential, forwarding it to individuals, other than those with a need
>> to know, without the permission of the sender, is prohibited.
>>
>> This message is also intended for a specific individual. If you are not
>> the intended recipient, you should delete this message and are hereby
>> notified that any disclosure, copying, or distribution of this message or
>> taking of any action based upon it, is strictly prohibited.
>>
>> English | Chinese | Japanese
>> www.molex.com/confidentiality.html
>> _______________________________________________
>> USRP-users mailing list -- usrp-users@lists.ettus.com
>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>
>> _______________________________________________
>> USRP-users mailing list -- usrp-users@lists.ettus.com
>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>
>>
>> _______________________________________________
>> USRP-users mailing list -- usrp-users@lists.ettus.com
>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>
>>
>> _______________________________________________
>> USRP-users mailing list -- usrp-users@lists.ettus.com
>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>
>>
>>
>>
>> ------------------------------
>>
>>
>>
>> CONFIDENTIALITY NOTICE: This message (including any attachments) may
>> contain Molex confidential information, protected by law. If this message
>> is confidential, forwarding it to individuals, other than those with a need
>> to know, without the permission of the sender, is prohibited.
>>
>> This message is also intended for a specific individual. If you are not
>> the intended recipient, you should delete this message and are hereby
>> notified that any disclosure, copying, or distribution of this message or
>> taking of any action based upon it, is strictly prohibited.
>>
>> English | Chinese | Japanese
>> www.molex.com/confidentiality.html
>>
>>
>> _______________________________________________
>> USRP-users mailing list -- usrp-users@lists.ettus.com
>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>>
> _______________________________________________
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
>
#include <uhd/convert.hpp>
#include <arpa/inet.h>
uhd::convert::converter::~converter() { }
class convert_u32_u32 : public uhd::convert::converter {
public:
convert_u32_u32(void) { }
~convert_u32_u32(void) { }
void set_scalar(const double scalar) { (void)scalar ; }
private:
void operator()(const input_type &inputs, const output_type &outputs, const size_t nsamps) {
const uint32_t *input = reinterpret_cast<const uint32_t *>(inputs[0]) ;
uint32_t *output = reinterpret_cast<uint32_t *>(outputs[0]) ;
size_t i ;
for(i = 0 ; i < nsamps ; i++) {
output[i] = ntohl(input[i]) ;
}
}
} ;
class convert_u32_f32 : public uhd::convert::converter {
public:
convert_u32_f32(void) : _scalar(1.0f/4294967295.0f) {
// NOP
}
~convert_u32_f32(void) { }
void set_scalar(const double scalar) {
(void)scalar ;
// _scalar = static_cast<float>(scalar) ;
}
private:
void operator()(const input_type &inputs, const output_type &outputs, const size_t nsamps) {
const uint32_t *input = reinterpret_cast<const uint32_t *>(inputs[0]) ;
float *output = reinterpret_cast<float *>(outputs[0]) ;
size_t i ;
for(i = 0 ; i < nsamps ; i++) {
output[i] = ntohl(input[i]) * _scalar ;
}
}
double _scalar ;
} ;
static uhd::convert::converter::sptr make_convert_u32_f32(void) {
return uhd::convert::converter::sptr(new convert_u32_f32()) ;
}
static uhd::convert::converter::sptr make_convert_u32_u32(void) {
return uhd::convert::converter::sptr(new convert_u32_u32()) ;
}
void register_converter() {
uhd::convert::register_bytes_per_item("u32", sizeof(uint32_t)) ;
uhd::convert::id_type id ;
id.num_inputs = 1 ;
id.num_outputs = 1 ;
id.output_format = "f32" ;
id.input_format = "u32_item32_be" ;
uhd::convert::register_converter(id, &make_convert_u32_f32, 0) ;
id.output_format = "u32" ;
uhd::convert::register_converter(id, &make_convert_u32_u32, 0) ;
}
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
