Ok, I did some timing tests with the emulator, and Mini is correct, one gets a lower frequency. I noticed the period of the code I gave was about 62.5uS, not the 55.5uS the "calculators" showed. I guess it is due to the actual instruction length within the interrupt routine itself.
So, like I said, trial and error will produce results. I should have listened to myself....
In the simulator, a value of 160 for TRM0 seems the closest to 9000Hz...
Ok, I did some timing tests with the emulator, and Mini is correct, one gets a lower frequency. I noticed the period of the code I gave was about 62.5uS, not the 55.5uS the "calculators" showed. I guess it is due to the actual instruction length within the interrupt routine itself.
So, like I said, trial and error will produce results. I should have listened to myself....
In the simulator, a value of 160 for TRM0 seems the closest to 9000Hz...
Hello Everyone,
Here are result test code by Sagor, please find attached picture.
As well advice Sagor I tried added NOP then I got my frequency is more better, I trying before to added delay for blink led on PORTA.0 but I got result the frequency to lower is around 7.xxxx then I tried to added NOP in simulation on Proteus the frequency is 8.9xxx you can try simulate the project as well as attached.
I am happy, because my first test yesterday and today I got the frequency are stable, I had checked on Frequency counter and also I checked on my Digital Multimeter Sanwa CD771.
And the frequency nearly exactly at 9Khz, but if you wanna to give me some advice please re-code/change my file, once again all the code from Sagor, I am just beginner in Oshonsoft.
Both 2 capacitor I use on crystal is 22Pf (SMD) on real hardware.
My first test at yesterday I set my programmer or debugger on HS not XT, yesterday I am use the programmer K128 and today I am use the MiniPro.
I check again my frequency counter result is 9.0092 Khz......well very stable.
To get an absolute accurate time from an interrupt-driven counter with a software reset, add (or subtract, whichever it is with the setup in use) the calculated time value to the counter register rather than just writing a fixed value.
It looks to be count up, so subtract the constant.
eg.
movlw 161
subwf tmr0,1
(That's off the top of my head, so check the instructions are correct - and the 161 is just an example from one of your posts).
That method gets around any "overspill" count before the interrupt routine starts; eg. if it's already counted up another 3 or 8 cycles, the new value is automatically 3 or 8 higher etc.
Just make sure there are no higher priority interrupts, or disable interrupts completely around the add/subtract part.
It changes the setting constant slightly to a software-set value, but you can get the best result by trial and error.
If you need an intermediate frequency when toggling a bit at each interrupt you can use two slightly different constants and swap those on the basis of the toggle bit.
That changes the duty cycle fractionally but allows better frequency control.
Also do the counter update as the first thing in the interrupt routine, before any conditional instructions, to minimise cycle-to-cycle variations (other than the alternate toggle count).
If you are using a counter that self-resets or reloads via the device hardware at the set value, software delays can only cause jitter and not any accumulative frequency error so you do not get the same type of problem.
If your device does not have that but has eg. a serial port you not need, you can possibly use a combination of the baud rate generator and adjusting character bit lengths to produce an interrupt at appropriate intervals as each (dummy) character send is completed.
And the frequency nearly exactly at 9Khz, but if you wanna to give me some advice please re-code/change my file, once again all the code from Sagor, I am just beginner in Oshonsoft.
......................
With this method and 8.000 MHz oscillator you can't get it better than ~ 9.009 kHz by adding NOP instructions.
Needed cycletime is 111.111... us and the nearest integer is 111, which gives 9009.01 kHz
Edit: 9.00901 kHz