This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/EK-TM4C129EXL: NDK Stack -reg

Part Number: EK-TM4C129EXL

Tool/software: TI-RTOS

I am working with Network Development Kit. I need to receive the data from the client. Is there any sequence using api like NDK_connect(), NDK_recv() to receieve data.  What are the things that I need to edit in tcpHandler.c to receive data from the Client.

  • Hi Naveen,

    Is there a reason you don't want to use BSD sockets (which the NDK supports). The TCP Echo uses these. If you want to use the NDK specific APIs, you can basically just replace the BSD call with the NDK counterpart. For example, if you look at the source code for connect, it is simply calling the NDK one:

    static inline int connect(SOCKET s, PSA pName, int len)
    {
    return NDK_connect(s, pName, len);
    }

    Todd
  • Hi todd,

          I may use BSD sockets also. I am able to get the data from the client but I don't know how to read that data.. Refereing to the NDK manual I  had found an API

     int NDK_recv(SOCKET s, void *pbuf, int size, int flags);

           I don't know where to include this API in the code to read the data. Do I need to create a separate task (I mean a separate function) to read the Data ???  or  To include the NDK_recv() API in tcpWorker part of the  code??

  • Hi Naveen,

    Were you able to run the tcpEcho example?

    Naveen Kumar29 said:
    Is there any sequence using api like NDK_connect(), NDK_recv() to receieve data

    Yes, there is a certain order to make the socket API calls in, depending on whether or not your code is a client or a server.

    A server will typically call bind(), listen() and accept() to wait for connections before it can send() and recv() data.

    A client will call connect() to connect to a server before it can send() and recv() data.

    The following diagram I found with a Google search may help you. Note that you can substitute the API names in the diagram for their NDK equivalents (e.g. "connect()" in the diagram would be equivalent to "NDK_connect()" and so on).

    Naveen Kumar29 said:
    What are the things that I need to edit in tcpHandler.c to receive data from the Client.

    The TCP echo example is a TCP server. It has a companion application that acts as a client, which is run from a PC (please refer to the README file in the tcpEcho example for guidance).

    If you follow the code of the tcpEcho example, starting first with the tcpHandler task, and then the tcpWorker task, you should see how its socket API calls map to the server part of the above diagram.

    Naveen Kumar29 said:
    I am able to get the data from the client but I don't know how to read that data.. Refereing to the NDK manual I  had found an API
    1
    int NDK_recv(SOCKET s, void *pbuf, int size, int flags);

    Yes, the NDK_recv() function is used to receive (read) data from a socket. You have to give this API a buffer to copy the data that's read into (this is the pbuf argument of the API).

    Once the NDK_recv() function returns (successfully), you should be able to access the data that was read within the pbuf buffer.

    Naveen Kumar29 said:

           I don't know where to include this API in the code to read the data. Do I need to create a separate task (I mean a separate function) to read the Data ???  or  To include the NDK_recv() API in tcpWorker part of the  code??

    In the tcpEcho example, the recv() calls can be found within the tcpWorker task function.

    If you're trying to figure out in general where/when to call recv(), then the above diagram should help you with that.

    Steve

  • Naveen,

    Can I mark this as resolved?

    Todd

    [update: Marking as TI Thinks Resolved because of no response from original poster 8/3]

  • Hi Todd,
    I am currently working on SPI and DMA part of the application. It will take another three weeks to comeback again to the TCP/IP part. Lock this thread as of now.