W5500 - Example code of using the INTn interrupt

Can someone show me an example project that takes advantage of using the interrupt output pin, i.e., pin INTn (#36)? All the examples I have seen so far are using the simple receive buffer poll mechanism. The reason I am asking is that I already have a working WiFi project that uses the Atmel WINC1500 module. Their APIs heavily rely on the interrupt driven callbacks for all socket events. If I can structure the new W5500 code around the interrupt, it would be less changes on my application layer. Thanks.

Being several years here on the forum I would I saw maybe 2 projects trying using INT pin. I tried using it back in days when I was learning W5100, but decided to go polling for several reasons.

Even if you had information and sources of several projects, there no guarantee they will help you in implementation in your environment. Thus please explain your environment If it is just about code which already uses the interrupts (and nothing else), then you can map interrupt sources and conditions between your current project and W5500 and see if you can just port your current code into environment with W5500.

Thanks for the reply. After some careful looking into the W5500 socket APIs, I think the polling method is much easier to adapt.

We work with the INT interrupt. It works fine, as long as you make sure you keep polling for changes as long as the INT pin is high.

This is because the INT pin seem to be a level interrupt (remains high as long as the condition is high) rather than the edge interrupt (high when something happens, and then reset in the interrupt handler).

So the interrupt routine looks like this (schematic only, I use Microchip Dspic)

volatile unsigned int socketinterrupt = 0;

int _w5500pininterrupt()
{
socketinterrupt++; // run service routine
pininterrupt=0; // clear end of interrupt
}

and the main loop checks the service routine:

int main()
{int rcvsiz;
// lots of initialization

while (1) do
{
if (socketinterrupt)
{ socketinterrupt–; // declare interrupt as “handled”.
res=check_for_read_data(&rcvsiz); // writes SN_IR_RECV to SN_IR and reads Sn_RX_RSR0 twice till first read=second read.

     // !!!!!!!!!!!!!!! handle w5500 level instead of edge interrupt.
     if (W5500INTActive() && (socketinterrupt==0) )   // If INT  high, and no interrupts pending, retrigger.
      { socketinterrupt++;}
     if (res)
       {
           res=udpgetpayload (&rxsiz);  // get and process one payload. returns true if there are more unprocessed bytes in the RX buffer.
          if (res)
              {socketinterrupt++;}
       }

  } // if socketinterrupt
if (something else)
  {
  }

} // while
}// main

Thanks for the sharing. However, I don’t see a significant advantage of using the interrupt. In your case, I suppose you could simply check the return value from check_for_read_data(). If it is zero, then there is nothing to do. Correct?

The advantage is that I only poll RSR when the interrupt comes instead of continuesly

The workaround is that you poll extra if the interrupt line stays high (which it usually doesn’t)