How to use the NCO module- demo code

[asmboy]

I was asked about this privately, so for the record:
The NCO is pretty easy to use, and works fine with 4.141 IMHO.

Using the 16F1509 or its junior partners, here is a brief how-to:

[viki2000]

Hi,
I tested your code using compiler version 5.048 and has many compiling errors.

[viki2000]

I used PIC10F322 to test NCO.
Below is a working code tested with the real PIC10F322.

[viki2000]

I have question for you, hoping that you may help, because I remeber you are very good.
I use PIC10F322.
I need to turn on and off pin RA0 very precisely in a range 20us-255us and if it possible up to 10ms.. I have a lot of options and functions tested to do that, but I want to use NCO as replacement for Timer0.
If the output would have been RA2, then would have been very easy: just load new numbers in the registers of NCO and that’s all.
If the output would have been RA1 then I could redirect the RA2 signal with the help of CLC gates to RA1.
But I must use RA0.
Then I was thinking to use NCO as counter-“timer“ and generate an internal interrupt. In the interrupt subroutine I toggle the pin RA0 and load new numbers in NCO registers NCO1INCH and NCO1INCL. Of course in CCS there is only one number.

Here is the code tested, which generates only 150us on and 150 us off on RA0, and not 150us/100us as I would like:

[asmboy]

Dear VICKI2000

Let me politely point out that the demo file is for the
16F1509 NOT 16f509

your errors say :

[asmboy]

and as to your problem with the NCO_INT

what does your .LST file show being generated?

did you note that you DON'T have to explicitly clear
the int flag as CCS does it for you ?

and think about this:
with a 16mhz INTOSC setting - each clock I-cycle is 250nSec
so there are only 10 I-clocks available for everything
you need to do for making a 25usec output pulse.
View the list file !!!
The interrupt enter/exit overhead alone uses more than 10 cycles ........

[viki2000]

16F1509 indeed and not 16f509, was clear a mistake.
So I tried again with 16F1509 and unfortunately I still got errors:
https://drive.google.com/file/d/0BwXmKaSw75eKVkZacHN4Ym1WYWc

[viki2000]

Regarding the other program, I used “#INT_NCO1” because in CCS user manual page 58 (https://www.ccsinfo.com/downloads/ccs_c_manual.pdf) I have seen that should be the way how to call the function when the interrupt of NCO is triggered.
The function and the interrupt work.
My problem is the fast loading of the NCO1INCH and NCO1INCL with new numbers.

In parallel I have tried also another compiler, the XC8 v1.33 PRO with the next code:

[asmboy]

the posted demo program still compiles in 4.141

I found that it requires a semicolon at the end of line #7
for my version 5.042
it now compiles and runs as expected with that later version too.
-------------------------
lastly re your program :

I am glad that you have an output you find useful.

have you noticed the amount of JITTER on your
20/245us transititon waveform??
&&
are you pleased with it ?

BTW: this

if (!PIN_A0)

can be replaced with THIS

ELSE

and save some cycles

[asmboy]

and then this.
a seriously excellent programmer aka PCM_Programmer pointed this out to me:

when you wrote:

if (PIN_A0)
that is NOT going to work as you expect,
as you are just asking if a DEFINED CONSTANT compiler value (PIN_A0)
is true which unless it is defined as zero - it always is and will be.

what you want to code to detect an I/O pin change is
if (input(PIN_A0))
........
ELSE
........

[viki2000]

1) I tried one more time your first code and surprise, was compiled correctly without errors. I do not know why I got errors 2nd time. Here is the proof:
https://drive.google.com/file/d/0BwXmKaSw75eKQnpidkduNTBzb1k/view?pli=1
2) During my first trials I used „else“ for the second side as you suggested, but due to the other errors encountered I thought that “if()” may take different execution time than “else” and then the “off” and “on” are not as calculated. I was thinking that if I write the same instructions “if()” for “on” and “off”, in order to introduce the same delay, then it would be more precise relation between calculated values “on” and “off” and the measured rectangular signal. But now, after the XC8 code is working, I tried also with “else” as you pointed and works without any detectable additional delays/errors.
Regarding the jitter:
- Comes directly from RC internal oscillator, page 168 of the datasheet indicate +/-3% at 16MHz
http://ww1.microchip.com/downloads/en/DeviceDoc/40001585B.pdf
https://drive.google.com/open?id=0BwXmKaSw75eKZk5hcFFEQS01OGs
- I measured it directly on one PIC10F322 and I found when I have for example on=20us and off=255us programmed, then the real output is on=19.6-20us and off=254.4-254.8us, so the jitter is 0.4us. And that applies for any numbers used for “on” and “off” in the range 20us-255us. I do not think there is any other way to improve that no matter what and how the code is written as long as is related with the clock source which is RC internal.
- The spread of error obtained in precision of “on”/”off” signal is in fact wider up to 3% as datasheet mentions, when we consider different other manufactured PIC10F322 chips.
- Unfortunately I cannot use an external clock source this time, so I have to live with the internal RC.

3) Coming back to CCS code, I tried your suggestions with next code:

[viki2000]

Here are the last updates, not very promising.
The code below is working:

[viki2000]

I used one more time next code:

[viki2000]

Finally after some hours, there is light.
I replaced one by one the functions defined in the CCS complier with assembly code inspired from LST file of XC8.
The “set_nco_accumulator(0)” function was replaced with:

[asmboy]

This is some first rate self help.
Congratulations!!
Now you see why i asked you to focus on the jitter.

The main source of the excess instability is the process of jamming the
NCO register .
You are fortunately writing them in assembler in the correct order
per datasheet 20.1.4
BUT
the instability of doing it in CCS can very well be traced to excess overhead and only marginal time when NOT in the foreground code execution during a 5 us cycle.

You are bound to be spending almost 100% of your time in the ISR in reality.
And the ASM code just buys you some extra I-Cycles. ( that happen to be enough to smooth out the jitter)

if you DON't have a lot of other stuff to do - ie this is JUST a signal generator,
You might profitable code this as a TIGHT flag polling loop in MAIN() that watches the NCO INT FLAG ( with no interrupt at all) - and does what the ISR does , and explicitly clearing the NCO OVF flag at the end of the polling-handler code each time the flag is set.
The time spent testing the flag and finding it FALSE in a MAIN() polling loop will be far less than the entry setup code for the ISR as you use it now.

That should reduce jitter to the minimum value of the intosc source.