Please Reply : TCP Server Interrupt issue

Question

hi all, please help me… here is my server ISR code: processWiznetISR() { uint8_t ucharIRvalue; ucharIRvalue = getIR(); do { if (ucharIRvalue & IR_SOCK(SOCKET_0)) { /* save interrupt value*/ TCP_IR_Status[SOCKET_0] = read_wiznet_reg(Sn_IR(SOCKET_0)); /* Clear the interrupt */ write_wiznet_reg(Sn_IR(SOCKET_0), TCP_IR_Status[SOCKET_0]); /* set TCP flag enable*/ uc_IsTCPInterruptOccur = TRUE; } /* re-read interrupt value*/ ucharIRvalue = read_wiznet_reg(W5100_IR); }while (ucharIRvalue != 0x00); /* if exist, contiue to process */ } I am able to connect/disconnect/send/receive using interrupt. Following are my questions: when i disconnect the server from TCP client. i am getting interrupt 2 times, first time i am getting ucharIRvalue value of corresponding socket and next time i am getting value of ucharIRvalue 0xff. i am not getting it,why the interrupt is generated 2ndtime i want to use all the socket (MAX 4 supported ) simultaneously on port no 502 , i have little idea about linux socket programming in that socket descriptor is generated and that descriptor used for sending and receiving in the child process or thread. how can i implement it in micro controller without RTOS ? what will be the value of IR register when all socket interrupt occur simultaneously ??

Coccoliso · Answer

Hi, There are 2 common register and 1 register for socket IR It reads to see which socket has generated the interrupt ( bits S0_INT/S3_INT datasheet page 21 ) IMR to mask the intervention of the interrupt for the 4 socket ( bits IM_IR0/IM_IR3 datasheet page 22 ) Sn_IR to know what condition generated the interrupt on a given socket ( datasheet page 27 ) I think the first is due to the condition of disconnection and the second is due to the closure of the socket but reading the n socket register (Sn_IR ) you should figure out what caused it and act accordingly. All four sockets are waiting on the same port but an incoming connection acts on the first available socket then as above said first read socket which has generated the interrupt then if it is a connection and as mentioned above act accordingly. If all 4 socket must act in the same way (in response) I do not understand what is the need to know whether the socket is and a wrong thing is to store the state that then could change in the meantime you’re going to answer … if state changes in “closed” the socket becomes available only after the timeout and you can not use it to that time (30 secs) and you lose a socket. You must be able to check and create the response “in line” when an interrupt occurs and then clear the interrupt reg. As I’ve already been to answer the use of interrupts in the case of TCP server is unnecessary… the purpose is to provide answers then you’re always waiting for the same condition and between test a pin ( cleared by interrupt) or read a register there is no changes except the hw latency (and since we really do not have other things to do in the meantime … unless you can find something else to do ). In a case you must first read the IR register and understand what is the socket and then read if is a connection and then read request size and then read the request… in the other case directly read socket stat and then read the request size and then read the request. Only a main a loop…