comprehension question Timer

RE: comprehension question Timer

Ivan Gómez — Mon, 11 Aug 2014 09:58:51 GMT

This is for sure the best post I found related with timers explanations in this forum. I'm trying to work with timers with a nRF51822 BLUETOOTH SMART BEACON KIT but I'm not able to make it work well. I get the date as I want ( I haven't programmed timers at this level before) but I haven't modified any timer in the example provided with the kit. The problem is that I use strftime call to get the time in the format I want but the hours pass like seconds and the minutes and seconds... really fast. I think that maybe the timer RTC0 is used for another task and there is a conflict with it. I don't know well how can I check in order to modify the code to get the date as I want to.

Regards.

Iván Gómez.

RE: comprehension question Timer

Philip Freidin — Mon, 05 Aug 2013 04:10:59 GMT

Hi Nils,

I'm glad to help. (sorry for my english, I am Australian and American :-)

With regard to temperature, it is better to describe it as temperature dependence rather than compensation.

The short answer to your question is Xtal or synth are both better than RC.

The long answer is:

Since the synthesizer depends on a crystal (16 or 32 MHz) , both the synthesizer and 32768 Hz crystal options will have similar characteristics. It depends on the crystal you specify and buy, but typically in the range of +/- 10 ppm to +/- 100ppm. On page 31 of the product spec, Nordic gives the worst case values of 60 ppm or 40 ppm. Lower values usually mean more expensive parts, but not always.

In general, crystal oscillators will always be less affected by temperature than an RC oscillator. This is why crystals are used whenever an accurate clock is needed. There are also special crystal oscillators with extra stuff to compensate for temperature effects (TCXO) and oscillators that include a miniature oven to create a stable temperature (OCXO). Look here if you want to learn more http://www.vectron.com For work with the Nordic chips, you do not need these type of oscillators, I just thought you might be interested.

Also, you may want to consider other things: 32768 Hz RC oscillator is totally inside the chip, XTAL/Synth both require an external crystal, but if you are using the radio, you need a crystal anyway. Also the 16/32 MHz crystal oscillators requires about 400 uA (page 31 and 32). The 32768 crystal oscillator needs only 1 uA (page 33, fabulous), and the RC oscillator need 0.8 uA (page 34). These are all typical numbers.

You asked "Why does it depend on Vcc ?"

A crystal oscillator is only affected a tiny amount by change in VCC. An RC oscillator is affected more by change in VCC.

The reason is that the resistor (R) and capacitor (C) are implemented with various structures on the chip, and these structures are affected by the voltage the chip runs at, and also by temperature.

When Nordic give a +/- 2% accuracy range for the RC oscillator, that range includes the combined effects of voltage (1.8V to 3.6V, page 29), and temperature (-25C to 75C, page 29), and the general variability from one chip to another (usually described as "Process"). This is usually referred to as PVT parameters.

Cheers, Philip

RE: comprehension question Timer

Nils Minor — Sun, 04 Aug 2013 20:16:39 GMT

Hi Philip,

thanks for your usefull informations. Every time you telling me how to understand the things i realy get more and more points of reference (sorry for my english, i am german :D), thanks because this is great for a newbie. I just read the part you told me. Is it better , for tempreture compensating, to use an RC or an XTAL or to synth?

Why does it depent on Vcc ?

best regards Nils :)

RE: comprehension question Timer

Philip Freidin — Sun, 04 Aug 2013 16:38:18 GMT

The accuracy of the frequency you get from RTC0 or 1 depends on the accuracy of LFCLK. In my example function RTC1_ms_timer.c , I have selected the RC oscillator on line 36. In the reference manual on page 54, LFCLKSRC has 3 possible choices. If you use either the synthesizer, or the 32768 Hz external crystal, you will have accuracy that depends on the crystal, probably around 60 ppm. On page 34 of the product spec, the spec fTOL,RC32k is given as +/- 2% , which is +/- 20000 ppm .

There is also a calibration process that can use the 16MHz oscillator to temporarily (4 seconds according to fTOL,CAL,RC32k) improve accuracy of the RC oscillator to +/- 250 ppm. I've read the description in the ref manual at 12.1.3 , page 51, the information provided is insufficient for me to figure out how this should be used. I could not find any examples for this part of the chip.

If you just want an approximate 1 ms tick, then the RC oscillator may be sufficient. If you need a more accurate tick, then use either the synthesizer (which needs the 16MHz crystal) or use the 32768 Hz crystal.

Also, although you write "a perfect millisecond" , I suspect that it is just close, rather than perfect. Watch the signal on the oscilloscope, as you apply heat (hot air gun) or cold (can of instant freeze) to the chip, and you will see that it is temperature dependent. Probably also dependent on VCC.

RE: comprehension question Timer

Nils Minor — Sun, 04 Aug 2013 14:53:35 GMT

Are there any informations for newbies to understand this better?

best regards Nils

RE: comprehension question Timer

Nils Minor — Sun, 04 Aug 2013 14:52:34 GMT

Hi Philip,

thanks for your answer, it works. But i changed the parameters like the preascaler. I messeured with the oscilloscope and when i take a prescaler with (idon#t know the exact value,i have to look on monday) 33 or 34 i get aa perfect millisecond. why don't i get the calculated time?

best regards Nils

RE: comprehension question Timer

Audun — Fri, 02 Aug 2013 09:30:50 GMT

Thanks again, Philip. Your feedback is appreciated :)

RE: comprehension question Timer

Philip Freidin — Fri, 02 Aug 2013 07:35:34 GMT

Hi Audun,

Thanks for engaging on this documentation topic, I'm glad you will be passing it on. Given the choice of tutorials in the SDK or a stand alone document, I think a standalone document is better, but once it is written, it could be included in nrf51_sdk.chm as a section, at the same level as the current two top-level topics: Modules and Data Structures.

In my experience, once a document is called an Application Note, the tendency can be to go for brevity, and focus on specific applications. To set the tone correctly, I would suggest "nRF51 Programmer's Guide".

The tone of the document is to explain in detail how each part of the chip operates, explain what tradeoffs should be considered where various setting have interactions or where there are dependencies on other parts of the chip, or even system goals such as power consumption, latency, code size, memory usage, etc. I think giving a rationale for the structure and features of each peripheral is also very worthwhile, and mandatory for many of the peripherals.

A complete set of drivers with a uniform API will probably help, but it will likely rely on a vast number of #define constants , which is probably not much better than the current situation. Lacking the same rationale information, I think it would just let you do things you can already do, but easier. The tough things will still be tough, and people will end up having to look at driver sources to figure out what is going on to then write code for things the drivers don't do or is unclear how to call the driver to do what you want.

(As an aside, I depend on sources for all library functions. While I understand why source for S110 is not available, I am very concerned about the lack of sources for esb_arm.lib and gzll_arm.lib )

If I had to choose between a well written "nRF51 Programmer's Guide" and a well written set of drivers, I would choose the Guide. With the right information, I can program my self through pretty much anything. With drivers, there will always be things that aren't covered.

In terms of resources at Nordic, the better the "nRF51 Programmers Guide" is , the less support questions you get. Of course the same is true of a driver library :-)

RE: comprehension question Timer

Philip Freidin — Fri, 02 Aug 2013 06:55:23 GMT

Hi Nils,

I am delighted that my comments and example code are helping you.

The PRESCALER register is set to 31 because the actual divide operation is the register value + 1. This is shown in the first formula in 18.1.2

So if you want to divide by 32, you load PRESCALER with 31. Although 2 examples are given they are not clear enough about what is going on. Here is what I would add to the first example:

round(32768/100) - 1 = round(327.68) - 1 = 328 - 1 = 327 So PRESCALER is set to 327, and the LFCLK is divided by 328 giving 99.9 Hz

You wrote "Why restarts the rtc_counter if it is bigger then 42?" In my example code, I do not reset the rtc_counter if it is bigger than 42. The rtc_counter is never reset, it just keeps counting at 1024 Hz, due to the divide by 32 of the LFCLK (because PRESCALER is 31). In fact my code doesn't even care about the value in COUNTER. But every time COUNTER is incremented (every 976.5625 us), a TICK interrupt also occurs, and that is what I use for the rest of my code.

So the RTC1 causes an interrupt at slightly faster than every millisecond (976.5625 us) and so on each tick, the "millisecond clock gains 23.4375 us". After 1 second of real time, the RTC1_Milliseconds value would be 1024 (which is no surprise, since the RTC1 is running at 1024 Hz).

So how do you make it increase by 1000 every second, rather than 1024. We could just subtract 24 once per second, but that would be a big jump. Instead I decided to not do the increment (skip it) on 24 occurrences during the 1 second period, and spread these skips out evenly during the 1 second. So if you increment RTC1_Milliseconds every tick (at 1024 Hz) but after 41 of these, on the next tick we don't do the increment, then after 1024 interrupts (ticks) the RTC1_Milliseconds will have increased by 1000. RTC1_skip_increment_counter is what controls this.

RE: comprehension question Timer

Audun — Fri, 02 Aug 2013 05:42:11 GMT

Hi Philip,

Thanks. This is valuable feedback for us. I'll make sure it's passed on internally.

Regarding item 3, tutorials. There's been some discussions about including tutorials as step-by-step code examples in the SDK, showing the 'why' as well as the 'how'. Do you think this is a usable format, or should it be a completely standalone document like for example an Application Note?

There's also been discussed including a complete set of peripheral drivers with a uniform API in the SDK. Using a driver API can be an alternative to learning registers and details regarding peripheral operation. Hopefully this can make development quicker and easier for at least the more common peripheral uses. As you say however, the PPI is not a common interface intuitively understood. A driver by itself won't give any rationale or insights into how the PPI can be best used.

RE: comprehension question Timer

Nils Minor — Thu, 01 Aug 2013 19:39:59 GMT

I think this Topic here is pretty interesting for ather perople and newbies how starts programming the chip. To understand what ervy part of the chip does and how it can be programmed is essential for the users.

I think i understand how to programm th rtc the HFCLK Timer is to programm similar? How to use this compare [] things in the pwm example?

But i didn't understand how to use schedluing and what it is good for, its a little bit to abstract for me. When i have to use it and when not and what is the main task of the scheduler?

When i have tu use the PPI and the GPIOTE ? Are they good for relieve the cpu? Or have i to use it also when i just to make a calculation with the cpu and then make an reaction at the output?

Which timers ar use by the softdevice? Timer 0 and rtc 0?

I hope you have some indulgence with me when i ask to much questions. It like i tell before i am a newbie. Its pretty much to lern but i hope i will understand it.

Best regards, Nils :)

RE: comprehension question Timer

Nils Minor — Thu, 01 Aug 2013 19:28:06 GMT

Yes Philip great Comment. With Tutorial it would be much easier to understand how the things work and to use them.

Just for newbies like me it is pretty hard to understand the coherences so a turorial would be pretty helpful.

Nils :)

RE: comprehension question Timer

Nils Minor — Thu, 01 Aug 2013 19:15:49 GMT

Hi Philip,

thanks for this great answer you helped me pretty much with the understanding how to use the rtc or the timer.

Thanks for this great example, perfect for me but i have some question.

Why is the prescaler 31, you want to devide the timervalue by 32 is 31 right?
Why restarts the rtc_counter if it is bigger then 42 ? why this value?

Thank you for helping, i am a newbie who trys to understand all this stuff. It is a lot to learn but with such examples it works fine :)

RE: comprehension question Timer

cocoa — Thu, 01 Aug 2013 13:22:00 GMT

This is one of the best ever written proactive comments posted here. The hope is that Nordic decides to publish a guide with practical examples and not just references, often difficult to interpret.

Totally agree with you.

Cheers.

-cocoa

RE: comprehension question Timer

Philip Freidin — Thu, 01 Aug 2013 12:42:08 GMT

Hi Audun,

Thanks for your reply. Let me try and be clearer. There are at least 3 ways to inform customers of the functionality of the chip, and how it should be used.

Reference documents. We have this in the Reference Manual. This document (should) explicitly state functionality, and where registers have multiple values, give tables of values.
Example programs. These demonstrate how the chip might be programmed to achieve a specific task. Its effectiveness depends on the amount of documentation either in the code, or supplied with it.

The supplied examples show specific instances of how various peripherals might be programmed, but do not cover all possibilities. The comments might explain what the code is doing, but does not cover the reason a certain technique is being used (rationale). The examples do not explain the tradeoffs that may have been considered, in choosing the way the code has been written.
Tutorials. These documents discuss in detail how a peripheral is designed to work, it discusses how various settings might interact, it explains how a customer might evaluate different operating modes and chose an appropriate one for their application. Especially for complex or novel functions, this type of document is very important.

Nordic does not currently have this type of documentation for the nRF51 family.

Let me highlight two examples.

The PPI is a novel method of supporting inter-peripheral communications. I've worked with microprocessors for 40 years, and I have never seen anything like it. It is brilliant. Please pass on my comments to the person who invented it. That being said, the reference material is insufficient in making clear how it should be used. If we were talking about a UART, anyone with experience has seen it before, and so will be familiar with the functionality, and expected behavior. Since the reference manual is devoid of examples, the supplied documentation is not enough. At a minimum there should be a detailed example that give REAL register addresses and values and draws a schematic of what the example does. Figure 16 is far too abstract. What is needed are actual values for things like CH[0].EEP, CHEN, CHG[n], CH[n].TEP etc for a worked example. Saying that there are examples *.c supplied is not enough, as the only way to figure out what is going on is to reverse engineer the code. That's what I had to do to get an understanding of how the PPI worked. I shouldn't have to go to that much effort.

The WDT has 8 reload request registers. Again, this is something I have not seen before. (maybe I haven't been using the right chips?). Anyway, here is an example of how the documentation fails to inform:

(this is from the snippet you referred to)

"To reload the watchdog counter, the special value 0x6E524635 needs to be written to all enabled reload registers. One or more RR registers can be individually enabled via the RREN register."

So, does this mean that if 3 are enabled, all 3 MUST be loaded with the special value to cause a reload, or is it any of the 3 can be loaded with the special value to cause a reload?

Don't say look at the examples, and reverse engineer the intent, because I can't find any.

Again, the problem here is that the documentation is reference only, with some ambiguity. What is missing is any explanation of why there are 8 reload registers, and how the chip architects expected them to be used.

I bet these RR registers get cleared when the reload occurs, but the documentation does not say that. In fact given the current documentation, it could be interpreted as once the RR have the special value loaded, the reload operation just keeps occurring, which I know is silly. A well explained tutorial on the WDT and how it is expected to be used, especially the multiple RR registers would resolve this.

Bug report for DevZone: After posting a message that includes formatting such as BOLD or Italics, if you then edit the message, the formatting is lost. See your messge to me where the Italic formatting was lost and now just shows as the tags.

I hope you understand I am not being critical, but rather highlighting an opportunity to better inform customers of how these chips operate and how best to to program them.

RE: comprehension question Timer

Audun — Thu, 01 Aug 2013 11:05:30 GMT

Thanks for you feedback, Philip. We're always trying to improve. Having understandable and informative examples and documentation is considered important for us.

That being said, there are fairly high-level descriptions of the PPI system and the different peripherals in the Reference Manual. Especially section 9.1 (Peripheral interface functional description) gives an overview of the peripherals and how PPI connects them. There's a functional description section for each peripheral in the reference manual. Snippet from WDT description (section 19.1.1): "[i]The watchdog has 8 separate reload request registers which shall be used to request the watchdog to reload its counter with the value specified in the CRV register. To reload the watchdog counter, the special value 0x6E524635 needs to be written to all enabled reload registers. One or more RR registers can be individually enabled via the RREN register[/i]"

RE: comprehension question Timer

Audun — Thu, 01 Aug 2013 11:04:51 GMT

Thanks for you feedback, Nils. We're always trying to improve. Having understandable and informative examples and documentation is considered important for us.

RE: comprehension question Timer

Philip Freidin — Thu, 01 Aug 2013 07:33:18 GMT

Hi Nils, (and Håkon)

I agree about the documentation, especially about the GPIOTE, PPI, Tasks and Events is insufficient. The problem is that it is reference material only.

The example code helps, but because of complexity, it is not clear what is specific to a function (such as PPI) and what is required because of the example application. No explanation of why functions are used the way they are is given in the examples.

What is really needed is a tutorial document with a detailed discussion of how these things work, and how the resources should be used. The situation with the PPI is particularly bad, because I think it is unique to the nRF51 products.

Another section in desperate need of an explanation and rationale is the WDT registers RR0..7.

Hey, Håkon , if you guys want to write a tutorial on these functions, I would be delighted to proof read them from the point of view of an end user/developer.

RE: comprehension question Timer

Philip Freidin — Thu, 01 Aug 2013 07:17:34 GMT

Hi Nils,

I don't have any sample code of the round robin scheduler that I can share.

But I have attached my code for setting up RTC1 for a 1ms interrupt, with two 32 bit counters for milliseconds and seconds since the "beginning of time" .

To build the scheduler, you would add the timer_variables and bool stuff after line 73.

You can use either of the two 32 bit counters to do some other neat things in your code, like this:

[b] temp = RTC1_Milliseconds; while(RTC1_Milliseconds < (temp+37)) {} // wait here for 37 ms

temp = RTC1_Seconds;
{
    // lots of stuff goes in here that takes a long time to execute
}
printf("Execution time in seconds:  %6d\n", RTC1_Seconds - temp);[/b]

The example code supplied refers to one of my header files, which must also be included in routines that use this stuff. the only relevant lines to this example in the header are:

[b]extern uint32_t RTC1_Milliseconds; extern uint32_t RTC1_Seconds; [/b]

Enjoy.

RTC1_ms_timer.c

RE: comprehension question Timer

Nils Minor — Wed, 31 Jul 2013 18:40:38 GMT

Hi,

thank you for your answers, you helped me pretty much with understanding how to use the timers. Philip do you have any sample Code, i think i will use one timer like you did it.

I think my biggest problem is understanding how the chips work. I read what gpiote, ppi, tasks and events mean. But i didn't understand how to use them or how they work together.

And when i want to programm something like a button i use gpiote but why?

I think this is preety important for programming the chip, knowing how this works. Maybe you can help me or know some good stuff that i can read.

best regards Nils :)

RE: comprehension question Timer

Philip Freidin — Wed, 31 Jul 2013 14:29:53 GMT

Hi Nils,

I often use the following approach as a very simple round-robin scheduler, with tasks that have to run at different rates.

I do the following for things that need timers of greater than 1ms. I set up a timer to generate an interrupt every 1 ms. I have a uint32_t timer_variable for each of my repetitive tasks. I have a flag (bool) for each task.

In the interrupt routine, I increment all the timer_variables, and test each one to see if it is at its max value, and if it is I set the bool for that timer_variable (task), and reset the timer_variable. So I can have some thing happening every 10 ms or 10000ms or any other repeat duration. The interrupt routine then exits.

In the main code is a loop forever block that checks the bool values, and if any are set, the appropriate task is run and the bool is reset. Obviously, you need to be careful how long these routines run, and what the total execution time is.

One of these timer_variable could be setup to count to 1000 and the task then runs once per second. The task could implement a clock & calendar.

RE: comprehension question Timer

Audun — Wed, 31 Jul 2013 07:40:06 GMT

Hi Nils,

as you say, there are 3 Timers available on the nRF51822. In addition there are 2 RTC's. The Timers use the 16 MHz clock (HFCLK) , while the RTC's use the 32 kHz clock (LFCLK).

When the softdevice is enabled it reserves one Timer and one RTC (in addition to other HW resources). That leaves your application with 2 Timers and 1 RTC. For PWMs you would typically use a Timer, while timekeeping is usually done with an RTC.

If you have multiple tasks that require millisecond-resolution timing, you can look into the SDK component app_timer. App_timer uses the RTC and facilitates timed events. For example: you want to read a sensor every 10 ms, do some processing every 100 ms, and then run a 3 second timeout for something.

To summarize: the Timers are quite generic and can be connected to different peripherals to perform different functions.It's up to your application to make sure the Timers and RTCs are allocated (and multiplexed if needed) to the different tasks you want to perform.

RE: comprehension question Timer

Nils Minor — Wed, 31 Jul 2013 07:06:13 GMT

No one have an idea? :)