Go Down

Topic: An extended TCP/IP library for the ENC28J60 (Read 16 times) previous topic - next topic

karagos

hi pijey
I think the ultimate solution is to buy a new one, I like this
work.
already connected but this happens.
if the ip is 192.168.1.15 and make a ping
I said that the timeout
and if the change by
192.168.0.15
send and receive but I get an error destination unreachable host.
help

orbitalair

pijey46049, I understand what you are saying, completely about the time involved.  I have 2(3 with yours) sets of different enc28j60 codes, and the default Ethernet lib codes.  Attempting to reconcile them is a big job.  I've spent hours just pouring over existing codes.

Originally I wanted to merge the 2, and simply have 2 'drivers' for the hardware.  This might work, but the biggest issue would then be compiled code size.  So my latest thought is to simply merge/mash/cajole the enc28j60 codes together and use the same high level interface that the default lib has.  Of course, there may be additional methods, but the basics should be close.

The idea is easier to state than to implement...


pijey46049

Quote
simply merge/mash/cajole the enc28j60 codes together and use the same high level interface that the default lib has.

Exactly my thinking. The library I customised is based on one of the most widespread codings for the ENC, which was encapsulated in an Arduino-compatible class. I thought why not use the "standard" interface?
Then I realised that the "standard" interface is not sufficient for operating the ENC28J60. Since even most of the TCP/IP overhead is already handled by the "standard" chip, it already supplies some kind of socket interface, similar to higher level operating systems. On the ENC, you need to handle the complete stack, including asynchronous answers to SYN packets to set up a TCP connection etc. The TCP/IP code used here is rather crude, with the advantage to be very small in coding and smaller still, if you do not need TCP.
Disadvantages: No socket interface and only one connection at a time.
Encapsulating the coding into a socket-style interface would cost a lot of RAM to store parameters for the open connections, and I was not ready to sacrifice the RAM. (Even now a full-sized Ethernet packet with 1500 Bytes would not fit in the buffer on a Mega328. And in most cases for small applications, that fit in my time schedule, one connection will be sufficient. So I stay with the current interface, which should be better documented, I agree...
But I would be looking forward to somebody trying and succeeding. As it is, the interface is a pain to port and use.

Go Up