5 Replies Latest reply on Feb 23, 2014 8:33 PM by nikvh

    Issue using an rtos timer

      [WICED-SDK-2.2.1, ThreadX]

       

       

      I am trying to setup a periodic timer to update the time in my application.

       

      To do this, I decided to set up an RTOS timer to call my time get function process_ntp_time()

       

      Example code is posted below:

       

       

      wiced_rtos_init_timer(&timer, 10000, process_ntp_time, 0 ); 
      wiced_rtos_start_timer(&timer);
      
      void process_ntp_time()
      {
         ntp_timestamp_t timestamp;
      
         WPRINT_APP_INFO(("process_ntp_time
      "));
         if( sntp_get_time( &target_ip_addr, &timestamp) != WICED_SUCCESS )
         {
             WPRINT_APP_INFO(("sntp_get_time failed
      "));
         }
         else
         {
             //uint8_t rx;
             WPRINT_APP_INFO(("Seconds = %lu Fraction = %lu
      ", 
             timestamp.seconds,timestamp.fraction));
         }
      }
      

       

       

       

      Unfortunately, only "process_ntp_time" gets printed out to the console but nothing else happens.

       

      Shortly afterwards it seems the watchdog timer kicks in and restarts the processor.

       

      It seems the sntp_get_time function is blocking or failing within the time callback.

       

       

      Its interesting to note that if I call process_ntp_time() before starting the rtos timer

       

      the function executes fine on its own and prints the seconds and Fractions.

       

       

      What am I doing wrong?
        • 1. Re: Issue using an rtos timer
          For ThreadX, the RTOS timers run in interrupt space, so it is very bad

           

          to do almost anything other than set a variable or semaphore.

           

          This is almost certainly causing your issue.

           

           

          Because of this limitation WICED provides two worker threads dedicated to doing asynchronous work.

           

          This post has some more details about the worker threads.
          • 2. Re: Issue using an rtos timer
            MaGr_2160016

            What post are you referring to?

             

            Thanks.

            • 3. Re: Issue using an rtos timer

              It looks like the porting of data from the old forum into the new site has lost some data.

              Do you have a particular question about worker threads?

              • 4. Re: Issue using an rtos timer
                MaGr_2160016

                Yes, just curious about the two worker threads and how they can be used as mentioned in the sentence:

                 

                "Because of this limitation WICED provides two worker threads dedicated to doing asynchronous work."

                 

                I was trying to use a RTOS timer to run a periodic function (1 sec) but it was locking the system and I had to use a timed event instead.

                • 5. Re: Issue using an rtos timer

                  The function you provide in the RTOS timer runs in the interrupt context which permits you to have very low latency however limits the actions you can perform.

                  If you use wiced_rtos_register_timed_event() it will create an RTOS timer that will pass a message to a worker thread to call your function. This adds latency but since it is called from a thread context it is free to call any function from the WICED API.

                   

                  A worker thread is a thread that waits on a message queue to allow you to defer the execution of a function to another thread context. The SDK adds two worker threads to your project by default; the network worker thread which is used to deal with link notification changes and other asynchronous network or socket activity, and the hardware worker thread that is to be used as an offload thread for hardware interrupts that require further processing that you don't want to do from within the interrupt context.

                  Currently the hardware worker thread is only utilized by the temp_control demo app which uses it to process push button activity. In theory you can use a single worker thread however some of the asynchronous network activity may take seconds to complete which is not suitable for responding to button presses.