• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 47 subscribers
  • Views 132 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

USB2ANY: Linux Support

USB2ANY: Does USB2ANY work when controlled in Linux commands in Linux terminal on Window?

Ella KIM
Expert 4212 points
Part Number: USB2ANY
Other Parts Discussed in Thread: TPS631012

Tool/software:

Hello, 

My customer manufactures smartphones and TI is designing our dc/dc converter on the system. They'd like to verify their linux kernel driver code with our EVM first before they build their own board. They will send/receive command via linux terminal.

Can USB2ANY function in this scenario? It seems USB2ANY is Window-based driver, and I'm wondering if it would work same as in window-based GUI, when it's controlled via linux terminal on Window. 

Please advise if there's any misunderstanding or if you need further information to answer. 

Thank you for your help.

Ella

  • 0
    TI__Mastermind 33690 points

    In principle it is possible. USB2ANY enumerates as an HID device, and sends/receives all of its information in control packets. So it's possible to construct something that wraps hidlib or an equivalent os-level interface driver, manually construct and deconstruct the HID packets, and interact with the device at any firmware revision without the use of any windows-specific drivers or libraries. In practice, I don't think anyone has written portable code to do this yet, except for a GUI Composer library that runs in a browser (for which I have had some trouble locating the source code).

    Depending on the features required (GPIO? SPI? I2C?) it may be possible for us to put this together, or at least provide enough scaffolding to show how to fill in the remainder yourself.

    What specific behaviors does the customer need out of USB2ANY that couldn't be accomplished directly from within a linux environment? Most linux machines have some I2C, SMBus, PMBus, and UART/SPI capability built into the processor, is there some reason they want to insert a USB2ANY in the loop?

  • 0 in reply to Derek Payne
    TI__Expert 4212 points

    Hi Derek,

    Appreciate for your comments. 

    This is for I2C communication for TPS631012EVM, TPS631012 Evaluation Module User's Guide, and the operation is simple - read/write registers.  

    Derek Payne said:
    What specific behaviors does the customer need out of USB2ANY that couldn't be accomplished directly from within a linux environment?

    I was thinking that USB2ANY might be required for physical I2C interface conversion. While the Linux will run in the terminal, the packet should be converted into the form of 3.3V/GND/SDA/SCL from PC USB port. From your comment above, can you please explain more how the I2C communication can be accomplished directly from PC Linux environment to TI EVM board?

    Sincerely,

    Ella 

  • 0 in reply to Ella KIM
    TI__Mastermind 33690 points

    Again, depending on the host processor, there may be an I2C bus master present in the system SoC or processor, or there may be expansion bus devices available over some other collection of interfaces. Most linux kernels also come pre-compiled with an i2c-tools package which includes i2cdetect, i2cdump, i2cget, i2cset, i2ctransfer command line programs (see the man pages - I linked to Debian, but the programs should be effectively identical across different distros). These are simple to include and compile with custom kernels, take up very little space, and can be chained and concatenated with other command line programs as needed. I would be very surprised if these tools (or a version of them) wasn't already available in the customer's SoC kernel, since you mentioned they're using this for a smartphone.

    A brief review of the TPS631012 datasheet suggests that there are three total registers, so it seems to me that it shouldn't take much effort to implement a simple user-space driver. The i2c-tools package provides libi2c to userspace programs for more complex scenarios, and the kernel docs provide instruction on how to write both kernel and userspace drivers - again, I would be very surprised if the customer wasn't already aware of all this.

    I also checked the TPS631012 datasheet, and it looks like there's only three registers to control the whole device. I think it should be very straightforward to implement the required functionality, whether as a driver, a simple userspace program, a shell script, etc.