The MCU runs at 32.768 kHz because:May I ask why you are running on a 32khz clock?
If it were my project, I'd use the 32khz crystal to drive the time keeping.The MCU runs at 32.768 kHz because:
- I'm using the MCU as a clock/calendar itself. That frequency generates an interrupt exactly every two seconds when using an external oscillator and setting Timer1 as the system clock source. The MCU counts the total seconds elapsed since 01/01/1970 (Android compatible) to determine the actual date/time. Writing the code to translate said total seconds to a formatted date/time string accounting for leap years, etc. was hard, hard work. The code also translates from the formatted date/time string back into total seconds.
- I'm trying to draw the minimum amount of power possible, to maximize battery life. That's one of the reasons why I decided not to use an external clock/calendar chip.
- The application itself does not need more speed than that for it to work reliably.
I already tried doing that, to get a one second interrupt instead of two seconds. But after performing some thorough testing, I found that the timekeeping accuracy was affected. Using said technique made the clock lose about 4 seconds per day.I have also usually used the internal OSC and used a 32.768 Khz XTAL for TIM 1 T!OSC, using timer1 as a 15 bit one sec timer when it rolls over (pre-set 16th bit)..
Then you have an error in your code. 32768 counts of a 32.768 kHz clock is 1s. No matter how you count it.I found that the timekeeping accuracy was affected. Using said technique made the clock lose about 4 seconds per day.
Definitely ... but I tested it many times and tried different techniques. I found that the only way to keep accuracy was not to interfere with the Timer1 counter ... perhaps the trick is to adjust said counter in synch with something else? ... Unfortunately, I didn't have the time to explore all the possibilities.Then you have an error in your code.
Yes! Don't interfere with it. Just let it roll over and issue the interrupt.not to interfere with the Timer1 counter
now there's a thought ... thanks for the suggestion, I'll give it serious considerationOr use the CCP in compare mode for different timings.
It worked!The symbol table (and the labels) should be loaded automatically for debug builds. To include labels for 'production' builds i.e. using Clean and Build Main Project, you need to tell it to load symbols in Project Properties under 'Loading' for the active configuration.
View attachment 301603
Hope that helps.
J

Generally: save the sign of both numbers, convert each to positive (if negative), multiply or divide, then keep or change sign based upon the original signs.I've hit a bump (not a wall, though) in my understanding ... I have now found a case in which I have to work with negative numbers. Joey once told me to "deal with it", and that's exactly what I've been trying to do. But my head's been spinning around the subject of multiplication.
Subtracting a large number from a small one is easy enough. The result will be given in 2's complement by my PC16 MCU.
i.e. if I were to subtract 0x15 from 0x0A, the result is F5, which in binary is 1110101. The signed 2's complement of this number, in decimal notation, is -11
Adding and subtracting using this method is straightforward and uncomplicated. Even dividing by two by shifting to the right is also easy, all one has to do is keep the original value of the leftmost bit to preserve the number's sign.
But for instance, how does one multiply a negative number by a positive one? I know that the result will be negative, but when I try to use @Papabravo 's algorithm things don't seem to work.
Many thanks, Joey. I was thinking along the same line ... it's just that I was wondering if there was a simpler and more straightforward way ... you've confirmed there's not, so deal with it I now will.Generally: save the sign of both numbers, convert each to positive (if negative), multiply or divide, then keep or change sign based upon the original signs.
One "trick" is to XOR the sign bits to predetermine the sign of the result.Many thanks, Joey. I was thinking along the same line ... it's just that I was wondering if there was a simpler and more straightforward way ... you've confirmed there's not, so deal with it I now will.
The XOR part I had already figured out. As for your second point, baby steps, Joey ... working with floats is not yet in my horizon.One "trick" is to XOR the sign bits to predetermine the sign of the result.
And, if you're dealing with IEEE floats, the binary representation is the same regardless of sign. This makes multiply and divide easier and faster.