Anyone have luck with Interrupt driven Wiznet w5100 part?

[James Marquardt]

All,
I have been working with the Wiznet w5100 Ethernet IC and have the demo webserver running just fine.

I would like the device to operate more independently rather than take up most of the microcontrollers time polling it.
Essentially I want teh 5100 to trigger it's interrupt pin when a connection has been made, but it appears from the community forum Wiznet has, and what I have found in my searches, the device, and it's cousins do not support this.  Instead they offer an interrupt for each phase which for that matter I might as well stick with polling, and possibly using a second, smaller micro to support it on it's own, which would really stink.

So, after the micro sets up the w5100'e IP info I want to do the following:

Micro opens up the socket(s)
Sets the socket(s) to LISTEN for the HTTP request string
Upon receipt of the request send an interrupt to the micro telling it that a CONNECTION has been made
The micro then goes to teh Interrupt service routine and does it's thing
Upon completion, disconnect the connection
Close the socket
Clear all the interrupt flags in the micro and the w5100
Re-open the socket
Go back to the main loop.


So, the question I have is:
Has anyone been able to set up the w5100 to work as an interrupt driven webserver?

Thanks
Jim

[Brooklyn Robots]

Hi James,

I did a lot of work with the w5100 part 6 years ago (so my memory's not perfect) but I was able to find my sample PIC C code AND hardcopy of the data sheet with all of my notes on it!

I used the w5100 as 4 virtual serial ports in interrupt mode.  You are right, it can generate interrupts on a variety of conditions, but you cannot mask them so you only get the ones you want.  Still, I don't think this too is a serious problem and is still a lot better than polling.

In my interrupt service routine, I check the SOCK_IR register (per socket) for the following conditions:

  TIMEOUT, RECV, DISCCON and CON.  

This checking should be relatively quick: a little code and a few SPI transactions with the v5100 to read and clear the per socket interrupt registers...  I remember spending a lot of time understanding when interrupts were generated, especially for received data.

I don't see a problem with the sequence you describe above.  The only change I would make is I would clear the set interrupt flags on every interrupt, not near the end of the loop as you describe above.

I had a lot of fun with this part but now I have to ask if it still makes sense.  The w5100, cpu, (and storage?)  combination may cost about the same as a Raspberry Pi.  I guess it depends on what other h/w interfacing you're doing.

Good luck, and Happy Thanksgiving,

Michael Jamet

--
You received this message because you are subscribed to the Google Groups "NYCResistor:Microcontrollers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nycresistormicrocon...@googlegroups.com.
To post to this group, send email to nycresistormi...@googlegroups.com.
Visit this group at http://groups.google.com/group/nycresistormicrocontrollers.
For more options, visit https://groups.google.com/d/optout.

[James Marquardt]

Hey Michael,
Thanks for the response.

THere is a register that does indeed allow you to mask interrupts so that you only get the one(s) you want. 
From what you wrote below, the interrupts that the wiznet can trigger are essentially useless as the code will have to read the register and determine what the interrupt was from anyway.  The datasheet says otherwise and Wiznet says they are too busy to answer questions on their own forum.  From the code examples I see the micro is going to have to make all the decisions so even in interrupt mode you still have to poll everything and respond which given the fact that the unit is constantly receiving data off the network the AVR will be constantly servicing the 5100.

At this point I am about to accept that I may have to use a second small controller to handle the 5100 and then pass information off to the primary processor when needed using an interrupt.  This way the co processor takes care of weeding out garbage, and only gets the primary involved when the incoming data is truly for the system.

Thanks!

I would love to see anything you have code wise even though I am working with an AVR. 

[Brooklyn Robots]

Hi James,

Yes and no regarding the interrupt mask register.  We may be on the same page so let me clarify.  

The W5100 has general registers and socket-specific registers.  Using the general IMR reg, you can mask which of the 4 sockets is allowed to generate an interrupt using the general IMR register but you cannot know what caused an interrupt until you poll the device for socket-specific details after the interrupt occurs.

I agree the processor has to do work inside its ISR to figure out what happened.  I disagree that it's a problem which requires a second processor.  I don' t think the burden is that severe.

I'll dig out my code.  I also switched to the AVR after 2008, but you won't have a problem following my one-socket interrupt demo.  I've also written a full blown Unix-like terminal driver - fully interrupt driven. This however is written in a Pascal-lite compiler (wrote the compiler as part of separate project...)  It is this second example which makes me feel confident about being able to handle interrupts in your single processor.

Will send code off list.

Michael

--

[James Marquardt]

Yep, we are on the same page!  I was referring to teh IMR, and the fact that you really do not know what the interrupt is until you poll the other register.

Looking forward to see the code.  Off to see what the family is up to.

Jim

On Wednesday, November 26, 2014 2:32:32 PM UTC-5, James Marquardt wrote: