1 2 3 Previous Next 34 Replies Latest reply on Jul 16, 2015 1:56 PM by JernejH

    Anyone try theTimerOne example?  ISRBLINK ?

    sierrasmith71

      There is a very simple example (in the 1.5.3 IDE) of blinking the onboard LED with a timer1 interrupt...doesn't work for  me...  complies and loads but NADA....

       

       

      I tried to copy and insert the sketch in this posting but I could not figure out how to do it

       

       

      thanks,

       

      David G.

        • 1. Re: Anyone try theTimerOne example?  ISRBLINK ?
          Clayton Hofrock

          I have just looked at this and can confirm that the sketch does not work.

           

          More information:

          The interrupt function is never called.

          The timer1.read() always returns a value of 0.

          Timer1.start() does not help.

           

          Also Timer2 and Timer3 (which are valid for Arduinos) appear to not be implemented.

           

           

          Also, this does not seem to appear in the release notes Intel® Galileo Release Notes (1.0.0)

           

          attached is the sketch that I modified to find my results.

          • 2. Re: Anyone try theTimerOne example?  ISRBLINK ?
            sierrasmith71

            Now what?  This is the third "early adopter"  Arduino compatible  board I have purchased: ChipKit Uno 32, Arduino DUE, and now the Galileo... ugh!  All had/have major compatibility problems.  Somehow I felt that Intel would get it right and NOT release hardware until the firmware/sotware was complete.

             

            D. Garrison

            • 3. Re: Anyone try theTimerOne example?  ISRBLINK ?
              AlexT_Intel

              Looking at the library sources and the respective code in interrupt.c I've found the reason - there's actually a second argument to attachInterrupt(), which is missing in the sketch. It has a default value of -1, which causes the callback not to be attached due to inconsistency with a certain check within that attachInterrupt().

               

              The easiest way to fix this is to add that second argument, which is measured in milliseconds and must be equal or whole number of times bigger than the one you've used for Timer1.initialize(). Ratio between the two will define the blinking frequency. That means the timer frequency defines maximum blinking frequency and then you can blink more seldom than that.

               

              For example:

              Timer1.initialize(100000); // the timer period is 100000 useconds, that is 0.1 sec
              Timer1.attachInterrupt(timerIsr, 500000); // the callback will be called on each 5th timer interrupt, i.e. every 0.5 sec
              

               

              And you don't really need Timer1.start() - it's actually a no-op at the moment as far as I can see.

               

              For the Galileo team: the reason is somewhat conflicting logic in these lines, in view of the default value of -1 for microseconds argument to interrupt.c::attachTimerInterrupt(), starting at line 384  in that file:

               

              /* Convert microsecond to Hz */
                  if (microseconds == -1){
                      ratio = idesc.hpet_freq;
                  }else{
                      ratio = microseconds == 0 ? 0 : microseconds/idesc.hpet_us;
                  }
              
                  if ( ratio == 0 || idesc.hpet_freq == 0 || microseconds%idesc.hpet_us != 0){
                      trace_error("Cannot add timer with period %d us - hpet @ %d Hz cp %p", microseconds, idesc.hpet_us, callback);
                      return;
              }
                  }
              

               

              With the default example sketch content microseconds here equals -1 and ratio is set properly, but then it gets to the second if and the third condition triggers an error, because -1%idesc.hpet_us != 0 is true for any valid value of idesc.hpet_us. Probably the simplest fix is to reassign microseconds with the value of idesc.hpet, the same way as ratio is assigned in this case. Callback then will be called with the period equal to the one timer was initialized with and the example sketch will work without the explicit second argument.


              I.e.

              /* Convert microsecond to Hz */
                  if (microseconds == -1){
                      ratio = idesc.hpet_freq;
                      microseconds = idesc.hpet_us; // this line needs to be added
                  }else{
                      ratio = microseconds == 0 ? 0 : microseconds/idesc.hpet_us;
                  }
              
              • 4. Re: Anyone try theTimerOne example?  ISRBLINK ?
                Clayton Hofrock

                Excellent, I guess I should have looked at the code and not at Arduino's help page.

                 

                So, to fix the ISRBlink example, if you change line 10 to this:

                  Timer1.attachInterrupt( timerIsr,200000 ); // attach the service routine here

                 

                You will get the LED to blink.

                 

                The Timer1.read() still seems to return all zeroes, which does not seem right to me.

                • 5. Re: Anyone try theTimerOne example?  ISRBLINK ?
                  AlexT_Intel

                  The Timer1.read() still seems to return all zeroes, which does not seem right to me.

                  Because it's a no-op too, just return 0 essentially. There are "TBD" comments all over the place, bringing some hope though :-)

                  • 6. Re: Anyone try theTimerOne example?  ISRBLINK ?
                    chotofu

                    Hello AlexT,

                    I want to setup the timer interrupt period in 1 sec

                    so I write the code like this

                         Timer1.initialize(1000000);     

                         Timer1.attachInterrupt( timerIsr, 1000000);

                    but interrupt period is 2 sec

                    • 7. Re: Anyone try theTimerOne example?  ISRBLINK ?
                      AlexT_Intel

                      That's interesting, I see nothing in the code, which could cause that. How do you measure the period, where do you get those 2 seconds from?

                       

                      Could you post a full sketch you're using, I'll check it out? I don't have a Galileo board with me right now, but I'll give it a try as soon as I can.

                      • 8. Re: Re: Anyone try theTimerOne example?  ISRBLINK ?
                        RGee

                        AlexT_Intel wrote:

                         

                        That's interesting, I see nothing in the code, which could cause that. How do you measure the period, where do you get those 2 seconds from?

                         

                        Could you post a full sketch you're using, I'll check it out? I don't have a Galileo board with me right now, but I'll give it a try as soon as I can.

                        I can't explain it, but I believe that  chotofo gets that because I am seeing a doubling also. It has been a long time since this thread was active and I am hoping you can take the time to see what I am doing wrong or right. I am trying to use timerone to create a running timer that is accessible in a sketch - that the basic task. They are, in my opinion, very useful, and it would be great to have this inside of a sketch.

                         

                        I have followed this thread and others. The code attached runs fine. Timer1 is working. The running timer is working. It's just not working the way I thought it would.

                        I initialize the timer with

                          Timer1.initialize(100000);


                        Attach the ISR with

                          Timer1.attachInterrupt(timerIsr,100000);


                        Have the ISR simply increment a variable (defined using volatile like you should - but it makes no difference for this issue)

                        I am expecting .10 sec resolution such that a 10 sec delay would produce a count of 100. Instead it produces a count of 50.


                        I am using delay(10000) to produce a 10 sec delay.


                        In the code comments I am showing the results of a number of settings (the resulting single values were most common but in each case the loops would sometimes vary by a count of 1 - just a little jitter). I looked through timerone.cpp and h and I see nothing to account for this. Clearly I don't understand what is happening. I certainly don't expect a great deal of precision inside a sketch or from the delay(), but I can't believe that accounts for the discrepancy. It is almost as though interrupts are triggered twice where I think they should occur only once (which sounds like me thinking rising edge only but change is triggering - this make no sense because its not a pin interrupt). Not only do I not understand it when the initialize and attach values are the same, I am equally clueless when the attach value is a used as a divider or prescaler.  So, what the heck is going on?


                         

                        • 9. Re: Anyone try theTimerOne example?  ISRBLINK ?
                          AlexT_Intel

                          That looks strange. Since that finding, the bug was fixed, AFAICS in the sources, so you don't need to specify the second argument unless you want to have your function called less frequently than the timer's frequency. I don't see anything there which would apparently stand out as a possible root cause for such behavior.

                           

                          Which Galileo release do you have, Gen1 or Gen2?

                           

                          If you have Gen1, then set the VARIANT_TRACE_LEVEL to TRACE_LEVEL_DEBUG in \arduino-1.5.3\hardware\arduino\x86\variants\galileo_fab_d\variant.h

                          If you have Gen2, the debug level is already set and no action is needed.

                           

                          Then compile the sketch (it's better to strip it to the bare minimum to avoid excessive logging) and run it.

                           

                          After that take a look at /tmp/log.txt and /tmp/log_er.txt files on the board - they will contain stdout and stderr information produced by the sketch.

                          Look for the following string (the placeholders will be replaced by the actual numbers): "Setting timer interrupt callback @%p hpet @ %lu Hz timer @ %lu Hz"

                           

                          That should give you an idea of what are the actual parameters it uses when attaching. Feel free to post the files here if you have troubles interpreting them, I'll try to help.

                          • 10. Re: Anyone try theTimerOne example?  ISRBLINK ?
                            RGee

                            AlexT_Intel wrote:

                             

                            That looks strange. Since that finding, the bug was fixed, AFAICS in the sources, so you don't need to specify the second argument unless you want to have your function called less frequently than the timer's frequency. I don't see anything there which would apparently stand out as a possible root cause for such behavior.

                             

                            Which Galileo release do you have, Gen1 or Gen2?

                             

                            If you have Gen1, then set the VARIANT_TRACE_LEVEL to TRACE_LEVEL_DEBUG in \arduino-1.5.3\hardware\arduino\x86\variants\galileo_fab_d\variant.h

                            If you have Gen2, the debug level is already set and no action is needed.

                             

                            Then compile the sketch (it's better to strip it to the bare minimum to avoid excessive logging) and run it.

                             

                            After that take a look at /tmp/log.txt and /tmp/log_er.txt files on the board - they will contain stdout and stderr information produced by the sketch.

                            Look for the following string (the placeholders will be replaced by the actual numbers): "Setting timer interrupt callback @%p hpet @ %lu Hz timer @ %lu Hz"

                             

                            That should give you an idea of what are the actual parameters it uses when attaching. Feel free to post the files here if you have troubles interpreting them, I'll try to help.

                            Thanks for the reply. I will try to look into this as you are suggesting. But, before I go spelunking - do you get a different value when you run the sketch that I had attached? Does everyone else get the right values??

                            • 11. Re: Anyone try theTimerOne example?  ISRBLINK ?
                              AlexT_Intel

                              FWIW, I haven't tried to run the sketch, just analyzed the IDE sources to see if anything has changed there.

                               

                              RGee, have you solved this since then?

                              • 12. Re: Anyone try theTimerOne example?  ISRBLINK ?
                                firmwarengineer

                                Hi,

                                "After that take a look at /tmp/log.txt and /tmp/log_er.txt files on the board - they will contain stdout and stderr information produced by the sketch."

                                Can I know where /tmp/log.txt and /tmp/log_er.txt is located?

                                • 13. Re: Anyone try theTimerOne example?  ISRBLINK ?
                                  AlexT_Intel

                                  These are on the board itself.

                                  • 14. Re: Anyone try theTimerOne example?  ISRBLINK ?
                                    darktears

                                    This example doesn't work for me, even if modify it as mentioned in the thread.

                                     

                                    I have this in my /tmp/log_er.txt

                                    unable to open /dev/hpet O_RDONLY

                                    variant-error: turnOffPWM: bad handle for pin13

                                    interrupt-error: hpet set frequency a failed

                                    interrupt-error: Cannot add timer with period 0 us - hpet @ 0 Hz cp 0x8049562



                                    1 2 3 Previous Next