jynik
commented
10 years ago Below is a preliminary list, based upon some discussions on IRC...
Remove device-specific accesses and add USB bulk and ctrl xfer wrappers Core code should deal with what these control and bulk transfers consist of, but the backend code should only be concerned with how the transfer is performed. Most of the current backend functions are just backend-agnostic logic wrapped around usb transfers.
I envision the backends providing the following wrappers, and a majority of the existing functions being moved up a level.
- usb_bulk_xfer()
- usb_ctrl_xfer()
- usb_set_alt_interface()
I think the following calls could all be moved out of the backend function table and be implemented in the core code, using the above calls. Alternatively, the core code could provide fallbacks functions for these that use the aforementioned USB functions, allowing backends to implement optimized accesses, when appropriate.
- load_fpga()
- is_fpga_configured()
- flash_firmware()
- erase_flash()
- read_flash()
- write_flash()
- device_reset()
- jump_to_bootloader()
- get_cal()
- get_otp()
- config_gpio_write()
- config_gpio_read()
- si5338_write()
- si5338_read()
- lms_write()
- lms_read()
- dac_write()
- stats()
Initialize backend-agnostic device handle information in bladerf_open, not in the backends All fields should be allocated (and potentially initialized to sane defaults) in bladerf_open(), not in the backend. The backend should not be responsible for allocating and freeing device structure fields -- it should only be concerned with assigning them if need be.
Too much code duplication in lusb_open + lusb_probe A major portion duplicates too much code from lusb_probe.
A potential solution is to pass the devinfo from lusb_open() to lusb_probe() and then open the first matching device that way.
Too much logic and an excessive number of initializations and have snuck into the backend interface and the libusb backend. (We've gotten too comfy with this backend being the only supported one for now).
To ease development and reduce unwieldy code duplication in other backends (such as the Windows Cypress driver-based backend LazyDodo is working on), backend-agnostic initializations and higher level operations should be moved up into the libbladeRF core code.
Let's use this issue to record items that should be refactored...
With respect to this issue, I'm personally OK with removing the currently deprecated Linux driver from being built, so that we can first focus on cleaning up the libusb backend. The Linux driver needs a fairly total rewrite anyhow -- I see little value in trying to apply cleanup to portions that are very likely going to be rewritten.