Hi,
Could U please help me with a technical problem I am facing?
I want to communicate to an external DSP board through the ethernet port
of my PC running under Windows NT.
The card does not have any OS or TCP/IP support.
But it has an ethernet port and associated drivers.I want to send data
from my program on PC to the board and recieve it back on the PC.The
connection is direct and not through any network.How do I do it.
Can I call NDIS library functions in an application?
Could U please help me with it?
Thanks & regards
jay
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> Could U please help me with a technical problem I am facing?
I want to communicate to an external DSP board through the ethernet port
of my PC running under Windows NT.
The card does not have any OS or TCP/IP support.
But it has an ethernet port and associated drivers.I want to send data
Looks like you need to write an NDIS protocol driver.
Max
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Hi
I think you can write a NDIS packet(protocol) driver. But a better approach
will be to make a TCP/IP stack in the DSP board. There are a lot of TCP/IP
stack source code available in the net. You can port it to DSP (Is it ADSP
or TMS?) and in that case your application can use WinSock functions. You
can even have a mini WebServer running in your DSP board and a usual Web
Browser could be used to communicate with your card. No applications needed.
Please visit http://www.csonline.net/bpaddock/tinytcp/default.htm for source
code for a tiny TCP stack. There are other sites also which provides ROMable
TCP solutions. You could make your implementation interoperable
jojan
-----Original Message-----
From: Jayachandran.B [mailto:xxxxx@miel.mot.com]
Sent: Friday, December 22, 2000 4:10 PM
To: NT Developers Interest List
Subject: [ntdev] NDIS help reqd
Hi,
Could U please help me with a technical problem I am facing?
I want to communicate to an external DSP board through the ethernet port
of my PC running under Windows NT.
The card does not have any OS or TCP/IP support.
But it has an ethernet port and associated drivers.I want to send data
from my program on PC to the board and recieve it back on the PC.The
connection is direct and not through any network.How do I do it.
Can I call NDIS library functions in an application?
Could U please help me with it?
Thanks & regards
jay
You are currently subscribed to ntdev as: xxxxx@nestec.net
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>I want to communicate to an external DSP board through the ethernet port
of my PC running under Windows NT.
The card does not have any OS or TCP/IP support.
But it has an ethernet port and associated drivers.I want to send data
from my program on PC to the board and recieve it back on the PC.The
connection is direct and not through any network.How do I do it.
Can I call NDIS library functions in an application?
If you have control over the packet format on the DSP board end, you could
possible do the following.
a) Use the command line “arp” command to assign a fixed ethernet address to
some appropriate IP address for your DSP device. This is to prevent your
device from needing to respond to ARP requests.
b) Then write app software that sends UDP datagrams to/from your device. A
little problem will be teaching your DSP device the correct IP address of
your PC. You will also have to format the responses as UDP packets, so
probably have to correctly calculate UDP checksums. There ahve been some
recent articles in Circuit Cellar on ethernet connectivity for embedded
devices. If I’m not mistaken, the UDP packet header format is pretty
simple. Your device will also need to remember the correct ethernet address
to send responses too, which will be the source address of packets sent to
it. It’s possible you could also use multcast IP addresses, and manage to
get the ethernet destination address to be a broadcast address, bypassing
all the IP<–>ethernet address issures altogether.
I’d STRONGLY suggest you use a packet sniffer to watch what’s happening.
Any Linux box can sniff packets. A W2K/NT box can sniff packets if you
install the network monitor component (I believe the packet sniffer
included with Windows workstation doesn’t support promiscuous mode, the
ones included with the network admin tools do).
Keep in mind UDP packets do NOT have guaranteed delivery, so any checking
and retrying will have to be done you by your app/device firmware. There
may also be no flow control. This is all probably much easier than
implementing a full TCP/IP stack.
I suppose there also must be some way for apps to interface to the network
monitor device, to receive raw ethernet packets (not sure of you can send
them). I also don’t remember the story on Windows NT boxes opening a “raw”
mode Winsock socket, which is basically a way to send/recv raw ethernet
packets (the Microsoft Winsock implementation might not support this). I’d
suggest a couple hours of searching the SDK docs to answer some of these
questions.
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> I suppose there also must be some way for apps to interface to the network
monitor device, to receive raw ethernet packets (not sure of you can send
them). I also don’t remember the story on Windows NT boxes opening a “raw”
mode Winsock socket, which is basically a way to send/recv raw ethernet
packets (the Microsoft Winsock implementation might not support this). I’d
A bit more detailed correction:
- “raw” sockets (PF_INET/SOCK_RAW) allows to send and receive IP datagrams -
without TCP or UDP. One can implement user-mode TCP using raw sockets
- what Jan mentioned is “packet” sockets (PF_PACKET/SOCK_RAW) - which really
allow user mode apps to work with raw Ethernet.
Packet sockets are not supported on NT - only on UNIX. You must write a
protocol driver for NT to use them.
Raw sockets are supported on NT - though using some non-trivial hacks, I
don’t remember what.
Max
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com