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.

AM5726: reference example for UDP application

Part Number: AM5726


Dear Champs,

My customer is trying to develop UDP application on C66x DSP of AM5726 and is referencing 'NIMU_BasicExample' of PDK.

They configured network in the main() function before calling BIOS_start() and added 'DaemonNew()' in the task.

Is this OK to manage UDP task in this case? Is there any limitation?

I'm afraid this 'NIMU_BasicExample' is too simple to be used as reference for real application and I think  'NIMU_BasicClientExample' of PDK is more proper one for their application development. Could you please let me know your opinion on this?

Could you please let me know the difference between .'NIMU_BasicExample' and 'NIMU_BasicClientExample'?

And, where can I find details for 'DaemonNew()'? I could not find it on NDK UG.

My customer is using pdk_am57xx_1_0_17 now.

Thanks and Best Regards,

SI.

  • SI,

    The NDK examples from the Processor SDK are listed at http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_Foundational_Components.html#id140 with high-level descriptions.

    NIMU_BasicExamp le_evmXXXX_<core>exampleproject Example demonstrates ping from external source to Gigabit Ethernet port on EVM.

    NIMU_BasicClient Example_evmXXXX _<core>Example project Example demonstrates creating local servers: TCP, UDP , data, null and OOB.

    NIMU_BasicHello WorldExample_ evmXXXX_<core> Exampleproject Example demonstrates UDP helloworld echo test.

    NIMU_DualMac Example_evmXXXX _<core>Example project Example demonstrates using two EMAC ports with different subnets.

    NIMU_FtpExample_ evmXXXX_<core> Exampleproject Example demonstrates FTP server with put and get.

    Per the NDK UG, DaemonNew creates a New TCP/UDP Server Entry:

    Once a new entry is created, the daemon will create the desired TCP or UDP socket, and start listening for activity. In the case of TCP, when a new connection is established, a new task thread is created, and a socket session is opened. Then the user's callback function is called on the new task thread, being supplied with both the socket to the new connection and the caller specified argument (as supplied to DaemonNew()). The callback function can keep the socket and task thread for as long as necessary. It returns from the callback once it is done with the connection. The function can choose to close the socket if desired. The return code informs the daemon whether the socket has been closed(0) or is still open(1). In the case of UDP, when any data is available on the UDP socket, a new task thread is created, and a socket session is opened. Then the user's callback function is called on the new task thread, being supplied with both the UDP socket and the caller specified argument (as supplied to DaemonNew()). The callback function can keep the socket and task thread for as long as necessary. It returns from the callback only when it is done with the data. (While the callback function holds the UDP socket, the daemon will ignore further activity on it.) The callback should return 1, as it should not close the UDP socket.

    Best regards,

    Dave