I have had the ENC28J60 running stable for a few months so it can be done.
If you are using the MCHP stack then make sure you have the latest version of the stack that includes the bug fixes for ENC28J60 Errata B4.
If you are using "roll your own" hardware check that you have used the correct pinouts for the RJ45 for your specific model connector. There are multiple RJ45 with embedded magnetics on the market and most ARE NOT interchangeable because of different pinouts.
A commmon problem with "roll your own" hardware implementations is the transposition of the receive wires or the transmit wires (+ to -). The ENC28J60 is meant to be able to handle this but it cannot.
If you have modified MCHP sample code then do not forget that their implementation is a cooperative multitasking statemachine approach. If you PIC code "is doing other stuff" then the Ethernet logic does not get processed. If you are "doing other stuff" too long then the receive buffer space on the ENC may fill and the ENC will discard packets. If you are on a busy network segment, one with lots of broadcast and multicast traffic, then it is easy to overrun the receive buffers. This then requires the upper layer protocols (TCP and above) to attempt recover after timers have popped etc.
MCHPs stack is a great starting point but if you want a performance or need a reliable, deterministic production system, it is not good enough - you need to determine what is the minimal set of network functions required to meet your applications requirements. For example, using a web brower from end to interface to a PIC great for proof of concept demo etc but naturally it assumes a human at one end of the link. If you want machine - to - machine interface then there is no way you would add the complexity of a HTTP stack implementation just to set and get a few data points.
I think MCHP have provided a good prototyping tool with their stack.
|
