Products > Board Support Package (Installation, Licensing, ...)

Multiple board support

(1/2) > >>

weavech1:
Does the driver/BSP supplied support controlling multiple boards (ML605 with FMC150 in our case via ethernet) via the same PC?  It seems that it should be possible if we have each board on a different ethernet device to open, however the sipif methods do not allow for anything other than an internal address to be passed in as an argument. Does that mean the device ID/address is hidden behind the driver?

arnaudNL:
Dear Sir,
That's correct, our reference design does not permit to use several devices. The protocol is low level packet based communication, we are not using TCP/IP as the MAC layer is handled by a state machine in the firmware. The ethernet mac IDs are hardcoded in both the firmware and the software.
I believe it should be possible to connect to Xilinx devboard on two distinct Ethernet peripherals on your machine even if they have the same ethernet ID as in this case it is on two different NDIS interfaces but this is not something we have attempted.
The API is actually process packets as per the ethernet star documentation and the device driver is a Windows NDIS driver.
One of our customers is using two FMCxxx product on the same machine so there must be a way to do it, we have provided ETHAPI source code "AS-IS" to this customer, meaning no support is provided on the API source code itself.
Best Regards,
Arnaud
Best Regards,
Arnaud

weavech1:
Thank you for the quick response. Is the source code for the driver available?

arnaudNL:
The driver itself, not. But it is pretty much the NDIS reference driver conatined the Windows Driver Kit. But you don't need the device driver, you would only need API source code. Typically you need to digitally sign drivers so they run on 64 bit windows, etc..
 

weavech1:
After looking into the reference code a bit more, it is pretty obvious the NDIS driver supports the multiple device access. Unfortunately the ethapi.dll 4dsp provides doesn't expose the device id to the read/write commands, which leads me to believe it always talks to the most recently opened device. If you could provide the ethapi code as a reference, then it would be a trivial change to add the device id to the access commands. Otherwise, that leaves me with a couple of unappealing (for me) options that I can see (I'm happy to hear other ideas, since you know the system much better than I do).
(1) open/close the device each time I need to access one of the boards. This is a timing nightmare.
(2) reconstruct the driver based on the state machine in the provided ref design (unless you could provide a document with the low level protocol that sits on top of the ethernet).


Any other ideas (or can you throw some source code or snippets of that have the protocol in it my way ;) [size=78%])?[/size]

Navigation

[0] Message Index

[#] Next page