I have a few more suggestions for Ethernet improvements.
- add functions that allow you to build or parse UDP packets in 'chunks' so that you don't have to malloc 1500 bytes of RAM to build (or parse) a packet.
one way to do this is to split up the 'recv_data_processing' and 'send_data_processing' functions in W5100Class into 3 parts.
The first part would simply return the 'ptr' value, i.e. "return readSnRX_RD(s);" (for receive) where 's' is the SOCKET parameter passed to the function. This function would be called when you begin creating or parsing the packet.
The second 'middle' part would use 'read_data' or implement write similar to 'send_data_processing'. You would call this function multiple times for each 'chunk' of a packet, passing a reference to 'ptr' so that it can be updated.
The third function would then update the W5100's register with the new 'ptr' value, i.e. "writeSnTX_WR(s, ptr);" (for send). You would call this function once when you are ready to send or finished reading a packet.
The caller would then invoke the appropriate 'Cmd' function separately (similar to the way 'recvfrom' and 'sendto' work).
Replace ALL occurrences of 'private' in the class definitions with 'protected' - this way you can create a derived class that has access to the (otherwise) "inaccessible" data members. Rather than renaming the library and re-writing the whole thing yourself, you can simply derive your own class to do specialized things. Oh, same change on everything else, too, kthx. Tying programmer hands via private class members on an embedded platform is just silly. 'protected' has the same connotation as 'private' (as in 'leave it alone unless you know what you are doing') but removes the use restriction for derived classes. It's a much better way to do things anyway.
complete socket support (like in the UDP class) by adding a parameter 'uint8_t sock=0' (or similar) to functions that hard-code the socket to 0. This allows existing code to work, and new code to specify a socket other than zero.
NOTE: I came up with '1' while writing a decent DHCP implementation as a superclass of 'EthernetClass'. '2' gave me problems, forcing me to make a copy of the library as 'MyEthernet' so I could fix it. '3' was just an observation.