Feature request: allow bumble-rtk-util to work with serial transport

[jsmif]

I have a Realtek dev board which exposes the chip via serial rather than USB. I confirmed on Windows that bumble-rtk-util info usb:2550:8761 and bumble-rtk-util load usb:2550:8761 work on a different normal USB dongle, to confirm it's not having the same issue as #746. And then I want to issue bumble-rtk-util info serial:COM6,115200 and bumble-rtk-util load serial:COM6,115200 on the dev board, to take advantage of the fact that Bumble supports HCI over serial (so I don't have to implement firmware download myself).

However, when I do bumble-rtk-util info serial:COM6,115200 I get an error "USB device not supported by this RTK driver" (caused by the check() function failing because there is of course no USB metadata when I'm giving a serial transport.)

Interestingly, if I add --force it gets around this and works for info and load, despite the fact that the code is written in such a way as to assume USB transport.

However ultimately the --force with load (which is what I really care about) is unsuccessful. It seems to me based on serial logging like it's padding out the end of the last 0xFC20 VSC download command and including a lot of extra 0 bytes despite the fact that the default rtl8761bu_config.bin file has a size set to 0. Then the chip just doesn't reply, either with success or failure, and gets stuck in a failed mode and refuses to respond to anything else. So perhaps that issue would be fixed by giving the code the once-over necessary to support HCI over serial.

Edit: re load over serial not working, the issue is perhaps due to using a fixed size RTK_FRAGMENT_LENGTH, which I suspect it doesn't like over serial. I couldn't immediately figure out how to fix your OO code, but somehow you need to not be using the fixed-size length here, or else the last packet is almost guaranteed to be padded out to a size other than the size mentioned in the data format itself, which it either doesn't like, or doesn't handle gracefully.

[jsmif]

Incidentally, how can I change the logging/print verbosity to enable the printouts for things like logger.warning()? (Or where do they log to? I don't think this is mentioned in the documentation is it?)

[barbibulle]

Incidentally, how can I change the logging/print verbosity to enable the printouts for things like logger.warning()? (Or where do they log to? I don't think this is mentioned in the documentation is it?)

You can change the default logger's logging level by setting the env variable BUMBLE_LOGLEVEL (ex: BUMBLE_LOGLEVEL=DEBUG)

[jsmif]

Thanks!

Also an important thing I learned today is that the Realtek dev board is using three-wire UART (aka H5), not just normal (H4) UART. That means that in reality a freshly-plugged device requires some SLIP initialization. I had just been working around this in practice by connecting once with a Realtek tool, which did the initialization for me. But to actually support bumble-rtk-util properly with the serial transport would require reading the three-wire UART spec and adding SLIP initialization and config the same way Realtek does. (Or one could read the old rtk_hciattach which is what I did, and which is where I suspect some of the Bumble header parsing info came from?)

[jsmif]

Since I saw you mentioned nRF52 dongles & Zephyr on your supported hardware, it looks like they have H5 support for that too which you could perhaps use without needing to buy the Realtek dev board. https://docs.zephyrproject.org/latest/samples/bluetooth/hci_uart_3wire/README.html

[barbibulle]

The H5 mode/protocol is fairly complex (not the framing, but all the possible states and error conditions, including managing sequence numbers and retransmissions). This may be a good candidate for a community contribution.