minor issue: hackrf_max2837_read endianness?

[mildsunrise]

I was reading the code and found that in hackrf_max2837_read:

https://github.com/mossmann/hackrf/blob/e93d70eddc6a2ed95af252c5acb7022fabba642f/host/libhackrf/src/hackrf.c#L700-L709

The value is returned straight from the USB transfer. Shouldn't it be converted to little endian?

[mildsunrise]

~~(And similarly for hackrf_si5351c_read)~~

[mildsunrise]

also, in

https://github.com/mossmann/hackrf/blob/e93d70eddc6a2ed95af252c5acb7022fabba642f/host/libhackrf/src/hackrf.c#L213

that should be sizeof(struct libusb_transfer*) I think

[mildsunrise]

one question: if I understand correctly, hackrf_start_tx submits 6 bulk transfers full of zeroes, then the user can start feeding its own data through the callback. is that correct?

[miek]

I was reading the code and found that in hackrf_max2837_read:

https://github.com/mossmann/hackrf/blob/e93d70eddc6a2ed95af252c5acb7022fabba642f/host/libhackrf/src/hackrf.c#L700-L709

The value is returned straight from the USB transfer. Shouldn't it be converted to little endian?

I think it's correct, it gets loaded in to the buffer as little-endian on the firmware side: https://github.com/mossmann/hackrf/blob/6e5cbda2945c3bab0e6e1510eae418eda60c358e/firmware/hackrf_usb/usb_api_register.c#L53:L64

Reading out some values seems correct too:

$ grep 'static const uint16_t max2837_regs_default' firmware/common/max2837.c -A5                                                                                                                                            
static const uint16_t max2837_regs_default[MAX2837_NUM_REGS] = { 
	0x150,   /* 0 */
	0x002,   /* 1 */
	0x1f4,   /* 2 */
	0x1b9,   /* 3 */
	0x00a,   /* 4 */
$ hackrf_debug --max2837 -r -n 0                                                                                                                                                                                                                   
[ 0] -> 0x150
$ hackrf_debug --max2837 -r -n 1                                                                                                                                                                                                                   
[ 1] -> 0x002

also, in

https://github.com/mossmann/hackrf/blob/e93d70eddc6a2ed95af252c5acb7022fabba642f/host/libhackrf/src/hackrf.c#L213

that should be sizeof(struct libusb_transfer*) I think

Yep! I think you're right. Feel free to put in a pull request to fix that, if you want.

one question: if I understand correctly, hackrf_start_tx submits 6 bulk transfers full of zeroes, then the user can start feeding its own data through the callback. is that correct?

I think it's 4 transfers but I could be missing something. Otherwise yes, that's correct.

[penguin359]

@miek I think the concern is that it's sensitive to the endianness of the host. It will break if compiled on a big endian ARM architecture, for example. Ideally, it should explicitly cast it into little endian.

[mildsunrise]

yes, sorry, I meant it should be converted from little-endian to host endianness, as we do in i.e. hackrf_board_partid_serialno_read

(also applies to hackrf_rffc5071_read I think)

Yep! I think you're right. Feel free to put in a pull request to fix that, if you want.

Okay, will do shortly :)

I think it's 4 transfers but I could be missing something. Otherwise yes, that's correct.

Ah yes, sorry, I meant 4. Perfect, thanks!

[straithe]

@mildsunrise, are you still working on creating a pull request to fix this issue, or have you moved onto other projects?

[mildsunrise]

sorry, I forgot in the end. feel free to take over :)