Hi,
maybe i have a silly question, but i didn't programm timers before. I know how they work. But how is it possible that there are only three Timers in the 51822 and so many parts of the programm part (PWM,BLE,GPIOTE...) which need a timer? How can i organize my timers?
and is it possible to run one timer and write a function like "get_actual_time" which gives me the time in the moment i call the function?
Best reagards, Nils :)
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.
Thanks for you feedback, Nils. 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]"
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]"
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.
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
