On Sat, Feb 24, 2018 at 8:50 AM, Xiaofan Chen <xiaof...@gmail.com> wrote:
> On Sat, Dec 23, 2017 at 3:43 PM, Shailendra Paliwal
> <beingshailen...@gmail.com> wrote:
> > Hello,
> > I'm trying to communicate with an Analog Devices evaluation board
> > AD has a windows software that initializes the board and can be used to
> > the data coming from the USB connection with the board.
> > I have been trying to write something in pyusb that can do the same and
> > with my Raspberry Pi. So far, I have figured out how to initialize the
> > board. I need help in understanding the protocol used in fetching data
> > it.
> > Device Descriptor: http://shailendra.me/USB.html
> Page not available.
Thanks, I have managed to make a USB driver that works nicely so far.
Coincidentally I took down that page *only* a few hours ago of your email!
Here's a copy of the page from an older commit, link
> > Here is the PCAP file of the USB trace:
> > https://github.com/vcidst/vcidst.github.io/blob/master/
> > (you can use wireshark to open pcap files)
This link has been removed too.
> > I've read a lot of write-ups of people reverse engineering USB protocols
> > which mostly include looking at the control transfers. However, this
> > only has two bulk endpoints and all the communication is done with bulk
> > transfers.
> > Quick facts about the PCAP file:
> > * Replaying packets 1-108 initialize the board.
> > * At packet 109 (use filter frame.time_relative >= 40), In the windows
> > software I chose sample size 1048576 and press Continuous Capture button.
> > * Packets 109 to 119 prepare the capture from SDP-H1.
> > * From packet 120, 6 packets of similar structure are sent/received again
> > and again.
> > * After that, I see 6 packets of different structure at
> >>= 41.059593)
> > * Packets after (frame.time_relative >=41.073968) are of different
> > again until the end.
> > * Towards the end, I stop the capture from the windows software thus the
> > last few packets should be stop packets .
> > My questions now are,
> > 1. Is this device following any standard USB protocol format that I am
> > familiar with?
> Most likely it uses vendor specific protocols not falling into standard
> USB device class definitions.
> > 2. I'm currently replaying the packets to initialize the device, is
> there a
> > better way to do this?
> If you do not know the protocol, this seems to be the only way.
> > 3. (a basic question that I still don't understand) in USB Communication,
> > after I have sent Bulk Write request. Do I need to send a bulk read
> > if I need to read some data? Can the program just not read whatever the
> > device sends without me sending the device anything?
> No. USB does not work that way. The device does not automatically send
> data to the host without host initiate the communication.
> > 4. The data packets here are huge and I was wondering if I need to send
> > entire packets whenever sending a bulk write request. Is there a way I
> > figure out what is essential information in the packet and what is not?
> If you do not know the protocol, I do not think you have a way to know
> what is essential and what is not. You have to look into the huge data
> and then try to understand. All in all the efforts required may be huge.
> > (I have read the Bulk Transfer section from USB in a Nutshell but still
> > didn't understand why it has to be this way unlike say, RS232
> > where the device can keep on sending data in continuous mode)
> USB is much more complicated than serial communication.
> On the other hand, there is probably an easier way out without using
> the SDP-H1 if your interests are to connect your Raspberry Pi to a
> daughter board. Quite some of them using SPI protocol. The schematics
> and documentations of the daughter boards are available.
I considered that option but the daughter board made the results available
on a single low voltage differential signaling self clocked interface. The
data rate required is as much as ~20 MBPS so I worked directly with their
evaluation kit first.
Thanks for your inputs. I think I will write a blog post soon detailing my
process and the tools I made use of.
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> pyusb-users mailing list
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
pyusb-users mailing list