Hi all,
here is the description of a small upgrade I 've made to uip.
Don't know if it is of great interest to you, but it helped me a lot.

I'm using psock library to develop an embedded TCP server.
I realized that there was no way for the UIP_APPCALL routine to send data
without being
called from within uip_input(). Let me explain a bit more.

When a given new packet is received from the client and process via
uip_input(), then
a call is made to UIP_APPCALL from within uip_process(). If the routine is
waiting for this packet (e.g. PSOCK_READTO() ) and reply with data (e.g.
PSOCK_SEND_STR('data') ),uip_slen and uip_sappdata are filled in with the
length and content of 'data'. UIP_APPCALL returns, uip_process() detects new
data to be sent, and fills in uip_buf and uip_len. Device driver can then
transmit 'data' to the client.

But what if it is the server that decides to send data, as the consequence
of an internal event, timer overflow, etc.. ?
A call to UIP_APPCALL from within another function that results in a
PSOCK_SEND_STR() only fills in uip_slen and uip_sappdata, but further
processing to uip_len and uip_buf still has to be made when UIP_APPCALL
returns !

Just add the following lines to uip source code.

in uip.h
line 260:
//------------------------------------------------------
#define uip_app_input()        uip_process(UIP_APP_SEND)
//------------------------------------------------------

line 1374:
//---------------------------------------------------
#define UIP_APP_SEND 13 //or any other unused value..
//---------------------------------------------------

in uip.c
line 690 at the beginning of uip_process() after uip_connr is declared:
//------------------------
if(flag == UIP_APP_SEND) {
  goto appsend;
}
//------------------------


You can now call UIP_APPCALL from within any home-made function, followed by
a
'uip_app_input()' instruction. When it returns uip_len and uip_buf contain
the actual length and data.

I call uip_app_input() "reverse input" cause it comes from the top to the
bottom of the uip_stack.



Samuel Engelmajer




Reply via email to