UDP + ARP driver for Ethernet PHY accessory board
As I've mentioned in the last live forum I have written an UDP and ARP protocol driver for the Ethernet port of my CNC and flight simulator motion control board (which has the same circuit as the Ethernet accessory board).
UDP is ideal for transmitting repeating smaller data chunks for real time control, for example
- LED lighting
- relays, solenoids...
- motion control
- sensor input
UDP supports no segmentation or error correction. But retransmitting lost packets doesn't make much sense, anyway, because old data is replaced by new data in the next cycle. Of course for file transfer or HTML related applications you'd still need an IP stack.
If anyone is interested I could put it on OBEX.
BTW, I also support ARP. At startup, the driver sends a gratuitous ARP message to advertise the IP adress. And it sends normal ARP responses if the PC asks for it. At the moment I only support a hardcoded IP address. Does anybody know an easy way to automatically or manually assign an IP address? DHCP is very complicated, AFAIK, and only works if a router is present in the network which is not always the case.
My idea was to use an UDP broadcast to "ping" all devices connected that have no IP address assigned, yet. If they respond to the ping the PC application can then assign an IP address to each with reverse-ARP.
Comments
I'm interested. Could be very useful for control systems...
Would be great to be in OBEX.
Does it just need one cog?
For me, I'd just manually assign IPs to everything on the local lan anyway.
I see you did the accessory board in Eagle. Did you post the files for that? That would be very useful. But, the schematic might be enough.
It needs 3 cogs at the moment, two for the RMII driver (RX+TX) and one for the UDP protocol. The RX cog needs to listen all the time for input, so that's really required. The TX and UDP cog can be possibly eliminated. You could call the UDP task from time to time from your main loop and the TX function could be merged with some other PASM driver. I think the code is too big to be called as inline PASM from Spin without disturbing the Interpreter or compiler register usage.
Yes, the PCB was done in Eagle. I can upload it tomorrow.
I wrote a DHCP client that seems to be reliable for the W6100 driver. I don't think it retries if it fails, so that could be better. It should give you an idea of what the exchange is and the data structure of the UDP payloads are. It's actually kind of ingenious the way DHCP was designed.