since the chip seemed quite popular and was inexpensive, I built an ethernet-board to be used with Atmel Microcontrollers, especially the Arduino. After studying the available library options, I chose the etherShield library, as used by Nuelectronics, Andy's Life, and others.
Unfortunately, the interface is not quite well documented and after some experimenting with the library and a client to display if my account holds POP3 mails, I somehow understood the concept and noticed, that the library does not seem to support continuing a TCP/IP client conversation after the initial data exchange of one telegram.
So I added a function to continue the conversation and, as an example, my pop 3 mail notifier client.
I hope, somebody has a use for this library.
the library is not mine, I just extended the TCP client part. It contained already a http client part that should be able to generate a http get.
I only did the POP3 mail checker and there seems to be no explicit http client example included, although there is some comment around the client functions within the library code.
With this library, you need to understand how the functions process the data.
You need the loop function "ES_packetloop_icmp_tcp()" to be run regularly to process requests to the Arduino, like Ping or just the usual TCP/IP handshake.
When you want to send a http get request, you need to use the "ES_client_browse_url()" function. Within the URL string, you must put the get statement.
Internally, the function sets up callback functions that insert the URL data into the packet and handle the returned data.
My mail checker does the same and it works the whole day, requesting the data every 10 Minutes.
Could you maybe post your code, so the community can have a look?
I am afraid that this link is not reachable, you probably need to replace "localhost" by the IP address or name of your web server.
To the community:
Unfortunately, I don't have any webspace available where I can put the library. Understandably, this forum does not have the capacity to host all user uploads. I don't really like to use these free upload providers. Can anybody recommend a free alternative?
I have just downloaded your library and i wonder i it possible to receive "HTTP POST" ??
Certainly. First, you need to configure the Arduino as a web server. The library contains code for that already.
The tricky thing is, that you need to have a look into the handling of the received html code to implement the POST command, if it is not already in. (I did not change or use the function yet, but I think one of the examples does).
When the library receives a packet, a callback function is called that handles the received data, e.g. stores it somewhere. In there, you should find the code you have to adapt.
Is the function interface the same as the default Ethernet library?
Cause you know, if the interfaces are the same, then its plug-n-play, and we don't have to code 2 completely different interfaces just to get ping working.
Cause you know, if the interfaces are the same, then its plug-n-play, and we don't have to code 2 completely different interfaces just to get ping working.
That was my original thought also. A cheap Ethernet controller as an alternative to the original one. I think I am quite good in networking, but soon found out that writing TCP/IP from scratch needs much more time than I could spend. I reviewed some stacks available for microcontrollers, and there are really nice ones, but in the end, the one I used needed the least work to get going.
Unfortunately, the library is constructed quite differently, so that I didn't even try to change the interface to adapt to the original Ethernet library. This may be because the ENC28J60 is only supporting Ethernet, whereas the original chip at least partially supports higher protocol levels. The IP, TCP, and UDP layers needed to be implemented in software completely. So the program must be able to handle e.g. ARP and the TCP handshake asynchronously to the data telegram transfer.
Thus the callback function mechanism. When I find the time, I should document a little more for you guys and implement DHCP to improve plug and play. Time is a little short at the moment, so the original authors may be faster.
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
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.
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.