• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 43 subscribers
  • Views 486 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Reading from Socket (Interrupt based)

Swanand
Intellectual 640 points

Other Parts Discussed in Thread: CC3300

Hi,

For reading data, I keep on calling "recv()" function, which calls for "simple_link_recv()".

This function sends HCI_CMND_RECV to CC3300 and waits for response.

So, In my application, I keep on calling recv() and if return value is more than 0, I process the data.

 

Is there any way where data available in socket will raise an interrupt or something and on getting that interrupt, I will call recv() function.

Or Is there any place from where I can put a semaphore/raise an event flag to indicate data is available in socket and application can call recv()

  • 0
    TI__Mastermind 27625 points

    Hi Swanand,

    Sorry there is no unsolicited event from the CC3000 corresponding to the reciept of data. You have to query the CC3000 to see if data is recieved.

    Regards,

    Aaron

  • 0 in reply to made4engineering
    Intellectual 640 points

    That's sad! I assume, I have to keep on Polling! :(

  • 0 in reply to Swanand
    Genius 4895 points

    Hello Aaron,

    I agree with Swanand. Would it be possible to put this on wishlist for next software release? I think the mechanism itself is already implemented e.g. with KEEP ALIVE. Why not report when there is an incoming packet?

    Background:

    When you have a battery driven device, polling every x msec means, that you controller must wake up every x msec, initialize SPI, send SPI data, receive SPI data, just to see: "oh, there was no data". No you can prepare to go to sleep again.

    When you have an interrupt for this, you can keep sleeping endless (or at least till configurable KEEP ALIVE happens) till interrupt line reports something. Much better for power consumption of controller.

    Best regards,

    Martin

  • 0 in reply to Marie Maurer
    Expert 1305 points

    Hi Aaron,

    I would also concur with Martin.  The power conservation is an import point in considering having an interrupt available instead of polling.  I have a different situation but having to poll is also impacting my application.  I have limited resources in my controller and having to take the time needed to keep polling is impacting my system performance and I may have to go with a more expensive controller in order to poll.  If there was an interrupt available, I would be perfectly fine with the controller I have.

    In my observations in bringing up my system, I am surprised at the amount of overhead required to run the CC3000.  It seems that with a little forethought (in cases like this one) that the impact on the controller could be greatly reduced.  I, too, would like to see this function implemented.  I don't know if it is a hardware limitation or could be fixed with a patch to the FW but would like to see it fixed on the CC3000 and if that is not possible, on the follow on product.

    Thanks,

    Brent

  • 0 in reply to Brent Rasmussen
    Intellectual 640 points

    So, My problems seems a widely observed scenario!

    Hope this will drive TI to make changes soon!