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.

Is there a Socket Data Available Event on CC3100?

Other Parts Discussed in Thread: CC3100, AM1808

I have a battery operated device that has to poll for receive data. It would be better if there was an event so I could cut down the response latency and cut down on the wasted cycles polling the CC3100 when there is no data present. I saw a similar question on the CC3000 forum, I'm hoping there is a plan to support such an event on the CC3100.

  • Hi Brian,

    We don't have any async event to notify if the data is available on the socket.

    Regards,
    Ankur
  • I'd like to throw my support for adding an event like this (Socket Data Available) to the API.  Without it, it's impossible to avoid polling the CC3100 for received data on all open connections.  That's more than just inconvenient.  Performance will suffer quite a bit as the host ping-pongs between transmit and receive unnecessarily.  For example, an application that is mostly transmitting and only occasionally needs to accept a command (but respond quickly), it must frequently poll the CC3100 for a command which is only infrequently there... wasted time for the host and CC3100!

    Brian's right, it would support a much better host application design.  Polling is just a clumsier approach that ripples through the whole host application and communication protocol design.

    Regards,

    Dale

  • Hi,
    The SimpleLink API is a BSD adherence. In BSD there are two modes of a socket, the blocking and non-blocking modes.

    If you are running on Non-OS platform, you can’t avoid polling, but you can use the select API to do it once for all open connections. Depends on the response time you want, you should call select from your main loop from time to time and check if one of the socket received data or accept new connection. In case there is no more data to transmit and in regards to Brain’s concern about the power-consumption, you can set the socket back to blocking mode and call receive/select. In this mode you can set the system in sleep until a data will be received as long as your system will know to wake-up from the HIRQ line of the SimpleLink device. To do that you should define _SlSyncWaitLoopCallback in user.h and from this definition set your system in sleep mode.

    If you are running on OS platform you should work in blocking mode and avoid this constrain. In this case you can set one thread to wait for reception and the other to transmit whatever is needed. Depends on their priority you can achieve the immediate response for the receive thread. In this architecture, to reduce the power-consumption you can also set the system in sleep mode from “idle” task that is in lower priority than these threads again as long as your system will know to wake-up from the HIRQ line of the SimpleLink device.

    We do understand that the BSD impose constrain in this kind of scenario (non-os) and we considering other method to give better solution.

    Barak
  • Thanks for the response, Barak.

    On an OS platform in blocking mode, if one thread has called "read" and is blocked, can another thread keep calling transmit while the other thread is waiting for reception?

    If that's not possible, then I suppose creating two sockets would work for us... one for streaming data from the CC3100, and the other for receving and ack'ing an occasional command.

    Regards,

    Dale

  • Barak,

    Thanks for the detailed and quick response.

    The BSD API is brilliant. I ported an my application that was running on embedded Linux platform to a TivaC+CC3100 and the socket management dropped in with almost no change. That was a pleasant surprise.

    My application can't block and go to sleep on the socket read because it needs to do other stuff while waiting for data over WiFi. Using the OS is an option, but I have no real use for the OS other than to allow the blocking socket read. Polling is OK, but it's not as responsive and it's a bit wasteful.

    -Brian 

  • Thanks you both for your feedbacks.

    Dale,
    Regarding the question about two different thread using the same socket, it is working as long as one thread is transmitting and the second receiving.

    Brain,
    If OS is an option, even for very few threads, I think it could simplify your use case.

    Anyway, we will update once we will have the solution for non-os in this kind of use case.

    Barak
  • @Brain

    You mentioned embedded linux (most probably ucLinux I guess) running on Tiva C. This sounds amazing. Can you share some more info on it I mean any link or material from TI or other??

    I think there's no such document available from TI which explains running linux on Tiva C launchpad.

    Niral

  • Sorry Niral, I wasn't clear.

    The embedded Linux platform I ported from is a TI Sitara AM1808. We have a simple ZigBee-to-Ethernet gateway application; the embedded Linux operating system and Sitara class processor are overkill.

    Regards,
    -Brian
  • Hi,

    I am closing this thread, for follow up queries please open a new thread with a link to this one for reference.

    Regards,
    Ankur
  • Any update on this?
    Why can't you add socket event or ability to use callback function when new data is received? ( non-OS env.)
    I understand you want to adhere to BSD, but it would not hurt if you added something that could be very useful for low power apps. I am porting my app from W5500 to CC3100 and I am stuck because of this.