I thought a MAC address was 8 bytes.
It **MIGHT** be worth including an 'ID' byte in the broadcast and response packets which would be a simple user settable value (stored in NV storage) just as a more convenient way of identifying a DAC then needing the MAC address when setting up?
Ethernet disconnect should probably open the interlock.
After all the point of the projector interlock is to prove out cable integrity...
I might argue that a software crash is sufficiently serious to warrant a full on need to power cycle to reboot, not merely a WDT reset (Also makes debugging easier if the crash state is still around).
Two things that would make the far end of the link a bit simpler:-
Each command should have a 16 bit 'token' field that the remote end can set to any thing it likes and that is then echoed back in the response packet. This allows the remote end to match response to command if there are several things in transit at a time (Sort of like IMAP).
Could we have a command that sets the thing to automatically send a status packet every time the buffer fill drops below XXXX points? That way we can set the DAC to tell the PC when it needs more data, rather then having to ping it and guess. The level this is set to will determine the latency/reliability tradeoff.
It might be worth making one of the bits in the control word a 'loop here' flag which would allow the thing to run in either 'frame' or 'streaming' mode in terms of how it handles buffer underrun.
Probably more to come.
Regards, Dan.