Hi Guys, 2010/4/9 vasile surducan <[email protected]>: > > Since the second is computed with > 11 digits accuracy, > it must be verified with the same accuracy, else the whole theory is useless > (as we have both agree, except maybe Matt) > So, assuming you have that second at an IO, how do you measure the second > accuracy ? Don't use the IO to show seconds - we don't have the equipment to check this with desired accuracy - but use it to see if the isr does not take too long.
> Computing is useless, since > you don't know the real oscillator value and temperature versus frequency > deviation... This is where we have different views. I see it as a chain: 1- a crystal oscillator with it's imperfection that creates a clock. 2- a counter that generates an interrupt at a given time. 3- code that handles the interrupt 4- code that maintains the rtc values, based on the interrupt. Look at each part separately before verifying if the total is correct, especially since it latter is difficult to achieve. 1- In contrast to you, I suggest to ignore this for now. We are checking if the library at hand works as expected. Deal with a accurate timing source when you build the application. 2- this is hardware and should work okay if setup properly. 3- This can best be verified with the datasheet and the code. A free running timer (in contrast to a timer that is reloaded by software) should give no deviation. 4- the most complex and thus error-prone part. Easy to verify if you add a counter to (3) and print both that counter and the values of the RTC (including the faction counters used) and verify if each value is what you intend. Note1: Real testing professionals will tell you you must not verify, but predict & compare. So: calculate the outcome of the rtc and faction timers for a number of interrupts, run the code and then compare. If there is a difference, explain what went wrong - the prediction or the measurement. Note2: 'easy to verify' does not mean it goes automagicly. It takes 'manual' labour, quite some accurate work. But that is just part of good engineering practice... Anyway, if you take this approach, you have a much higher degree of certainty the software is correct and as such a good building block of a larger system. But you can never be sure. For example, see http://en.wikipedia.org/wiki/MIM-104_Patriot#Failure_at_Dhahran If you take the deviation into account: 0.34 seconds in 100 days is 1 in 25.000.000, which is very unlikely to be detected in an integral test unless you know what you are looking for... Joep -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
