Hi Manish
PPP is a suite of protocols and so you will need to know which parts are required for the communication in question. The PPP task in the uTasker project only gives an example of the basic low-level framing and so will probably need some additional protocols to be able to actually work in this case. I would suggest seeing whether there are some open source PPP implementations that could be used together with the existing 'driver' since I haven't any additional PPP code.
I have however used TCP/IP over serial interfaces and this is not that complicated. There is however a basic question as to whether you also have an Ethernet connection or just the single UART based one? If only the UART based one, this can take over the MAC address/IP address etc. of the network interface. If two, you may require two interfaces on the same IP connection (the same MAC/IP address is used on both physical connections) or else you may need a dual-homed solution with two individual IP addresses and MAC addresses.
There are some projects now released including the multiple network support (see
http://www.utasker.com/forum/index.php?topic=1748.0 ) which allows this to be configured and controlled quite easily. There is also an LPC2xxx Beta project version with it that will be released shortly.
My suggestion is therefore:
1) Verify the PPP requirements and see whether the basic communication can be acheived with the PPP task, plus some adjustements, or whether you can find a suitable PPP stack to add the missing parts there.
2) I will get an LPC2xxx release with the multiple network/interface support made around the beginning of next week in case this is required.
3) The actual TCP/IP interface is then a bit project specific but I have examples when needed - the reception side is not complicated; one stores the received frame in a buffer and sets up an ETHERNET_FRAME struct with details pointing to it, which is then passed to the stack for processing. In the transmit direction a "user write" function is declared (the additional interface receives a queue and a QUEUE_HANDLE) and all data sent by the TCP/IP stack (to the network/port in question) passes through a user-defined function which does the details of the copy to the alternative physical connection using whatever technique is required. I will need to document this procedure in any case so that it can be used generally.
Regards
Mark