Skip to main content
19 events
when toggle format what by license comment
Jun 7, 2023 at 20:07 answer added PStechPaul timeline score: 1
Jun 7, 2023 at 14:47 vote accept RickyBoy
Jun 7, 2023 at 10:09 comment added RickyBoy @PStechPaul: I would LOVE to be using a debugger. I tried to use the MPLAB debugger with my PICkit 3. But I had a horrible time. Some sort of error at every step. I went through all the steps in the Microchip docs, including their troubleshooters and got nowhere. On fora the best answer I could find was "your chip may not have debugging capabilities". At that point I went back to the sledgehammer approach and thought I would postpone using a debugger until I felt like learning more. Perhaps that will be my next cry for help in this forum!!
Jun 7, 2023 at 0:00 comment added PStechPaul You might try using the software simulator to track the cause of the problem. The PICkit hardware debugger could be used as well.
Jun 6, 2023 at 19:32 answer added glen_geek timeline score: 4
Jun 6, 2023 at 18:32 comment added RickyBoy Changed type long to unsigned short - results unchanged. YELLOW_LED still close to 1kHz, but RED_LED still @ 3.9kHz instead of 5kHz that I thought I would see. But nonetheless I'm grateful for the insight, thanks. I'm struggling to see why YELLOW behaves close to expected, but RED is far off.
Jun 6, 2023 at 18:10 comment added RickyBoy OK, that's a very insightful comment... better, I infer, to use types int or smaller instead
Jun 6, 2023 at 17:53 comment added Jens This is an 8 bit MCU and you use variables of type long, which need 4 memory read cycles to fetch the value. But the interrupt code may modify such a value in the middle of a read access of the main loop. Such variables must be declared as "volatile" and the access in the main thread must be surrounded by disable and enable interrupt calls.
Jun 6, 2023 at 17:08 comment added RickyBoy Only remaining puzzle is why RED_LED blinks at 3.9kHz instead of 5kHz (conjecture in question was wrong)?
Jun 6, 2023 at 16:50 comment added RickyBoy Correction: TIMER_RESET_VALUE = 158
Jun 6, 2023 at 16:40 comment added RickyBoy And disabling the prescaler and setting TIMER_RESET VALUE = 206 improves the frequency of YELLOW_LED to 975 Hz which is 2.5% off which should be fine. I can only increase the clock frequency on this chip externally.
Jun 6, 2023 at 16:36 comment added RickyBoy @glen_geek. OK I found in datasheet that value of CMCON on POR/any reset is 0x00. Which by inference from your comment, is default active. Therefore, yes, setting CMCON = 0x07 has solved the problem.
Jun 6, 2023 at 16:04 comment added RickyBoy @glen_geek, I was trying to figure something like that out from the datasheet but couldn't find it explicitly. Will try...
Jun 6, 2023 at 16:03 comment added RickyBoy OK regarding (1)... in fact I believe there are two off-by-one problems... In the main while() loop I have been careless at when the YELLOW_LED is switched. I have forced it to switch when time_count == 4. This brings the frequeny of YELLOW_LED to 950 Hz (not sure if that's good enough but it's an explanation) Maybe there's some slippage in the instruction cycle as well? I will try disabling the prescaler. Regarding TMR0, it of course makes a small difference but I need to go back to the theory to know exactly what is the correct value.
Jun 6, 2023 at 15:55 comment added glen_geek Is this a chip where the comparator is active by default? If you want RA1 to be a digital I/O, you might try disabling the comparator...CMCON=0x07. Haven't used this chip, so am unsure - this addresses the constantly-ON RED LED.
Jun 6, 2023 at 15:37 comment added Hearth I'd write that as an answer, but I don't think I can help with 2), so it'd be an incomplete answer.
Jun 6, 2023 at 15:29 comment added RickyBoy Ah! Could be! With prescaler at 1:2 you're right, I recall there should be an adjustment of 1. Let me try...
Jun 6, 2023 at 15:21 comment added Hearth Could 1) be an off-by-one error?
Jun 6, 2023 at 15:11 history asked RickyBoy CC BY-SA 4.0