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 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.
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
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 :)
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.
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 :-)
Thanks again, Philip. Your feedback is appreciated :)
