| USB TestPort for TITAN [message #1800845] |
Wed, 09 January 2019 01:48  |
|
Hi!
I wanted to share with you that I've been working on a TITAN test port for USB. The goal here is to run on a (Linux) computer with USB host controller and being able to use that system to run ATS (Abstract Test Suites) against USB devices attached to that USB host.
The test port is some glue logic between libus-1.0, the standard library for accessing USB devices from userspace. The API of libusb-1.0 has been mapped (at least partially) to TTCN-3 messages which are exchanged over the test port.
The current status of the code can be found in the osmocom GIT repository at http://git.osmocom.org/titan.TestPorts.USB/about/http://git.osmocom.org/titan.TestPorts.USB/about/. It's still quite basic but already allows you to open a USB device, read descriptors and submit transfers.
The purpose for writing this module is to be able to validate the USB protocol/interface of various devices' USB firmware that I've been writing. In the past, there was no explicit test suite and one would simply use the device with its normal driver and hack until it works. However, with the power of TTCN-3 and Titan, I'm aiming to implement a codec for the USB-CCID (chip card interface device) class specification, and then a test suite on top of that.
Maybe this is useful to some other people here. If you have feedback on the code, feel free to share. Keep in mind that I'm a C, Python, Erlang, Perl and by now TTCN-3 programmer, but C++ is not my most comfortable/native environment.
What I generally figured when implementing test ports this time and in the past is that quite often one wants to have both message and procedure style interfaces in a single port, but one has to choose between the two. In the USB example, there's actions like reading the descriptors, opening a device, etc. which would best be done with procedures, while the actual USB transfers on the IN/OUT/INT endpoints are best represented as messages. This leaves the choice to either have some native functions similar to f_Connect/f_Bind and the like in the IPL4asp, or to have rather cumbersome request-response message pairs. I don't like the IPL4asp approach because I often stack one or multiple translation or dual-faced ports on top, and then you each time need to manually write some C++ and TTCN-3 code to re-expose the connect/bind/... functions. So for USB, I went for the "message request and resposne" pair. Would be great if conceptually there were ports that could do both messaging and procedure based communication...
Regards,
Harald
|
|
|
| Re: USB TestPort for TITAN [message #1800866 is a reply to message #1800845] |
Wed, 09 January 2019 09:17  |
|
Hi Harald,
thanks for sharing.
IPL4asp is unique in the sense that it has an API different from all the other test ports; it started as an experiment and then unfortunately we got
stuck with it and today its probably one of our most used ports as it covers UDP, TCP/TLS and SCTP; but it seems unaffordably costly to rewrite it at this stage.
But that's how evolution works.
As for mixing messaging and procedure based , technically it should be possible but apparently there was no need for it so far.
Best regards
Elemer
|
|
|
Powered by
FUDForum. Page generated in 0.02794 seconds
] 
Search
Help
Register
Login
Home
