That snip is not going to help a lotWould be better to post your whole thing.
That snip is not going to help a lotWould be better to post your whole thing.
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
Hello Steve,
It looks like the problem was not in the code itself oir not only in code. I do not know for sure where are my mistakes and where are software glitches. Some time ago I contacted Melabs support that my USB programmer programs something wrong and one of the ports I use do not work. (I programmed a batch of chips, soldered and sealed them and they all were bad. Same code programmed by ICD3 was good. I was advised to reset the programmer to factory defaults which I did and it helped. This time I am suffering from unstabile results and really started nervous because I could make a change in a good code, then reverce the change and the code no longer worked. Finally I read my just programmed MCU (programmed using Melabs USB programmer) then read it using Picstart plus and learnt that instead of INTOSCIO it was configured for external clock! (Although it was for sure IUNTOSCIO at the time of programming) Chnging the setting and rerecording the code back into the same MCU (now using Picstart plus) gave a working MCU. Resetting programmer into defaults fixed the problem, but I know for sure that it was in the defaults before. Also I have some screenshots where Melabs programmer says verification ok, then I read the MCU (with same Melabs programmer) and it is empty. Resetting to defaults (which was already reset some time ago change fixed the problem). I have a styrong feeling that I am not going to use that programmer any more as I do not want to reset it every time before programming...
Now I hope that if I change programmer (both hardware and software to Microchip ones) I will have to fight only my mistakes, and all glitches I had were related only to the programmer, not to compiler or assembler...
regards,
Alexey
I never experimented many weird compiler behaviour since I use PicBasic Pro myself, and I use it since over 10 years. Most of the time I got Error Code #18 to #24... which are located 'round 18 to 24 inches behind the keyboard
I can't comment Melabs programmer I don't have it, but I do have PicStart Plus & PicKit 2 (and others). Both gave and still give me good results.. But yeah, I heard a lot of weird programmer behaviour here and there.
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
Hi Steve,
I thought I replied yesterday but do not see the post so I repeat (my post about the subroutine above is also only half of the whole text) it looks my computers are having a strike...
Yes, sure most of the time my problems are "Code 18 to 24"Fortunately you, Darrel and other people are very helpful here. This time I actually started panic because of unstabile results and I am very glad that it was not my absolute stupidity, it was just some stupidity multiplyed by hardware glitch. At least it is now a bit more relaxing for me to know that my code was not absolutely wrong but just a bit wrong.
Again, thank you for help
Alexey
Hi Darrel,
Thank you very much for help!
Do I understand correctly that at other than 4 MHz frequency oscillator may affect interrupts? I mean is it affected at 8 MHz or you meant 32 kHz oscillator?
Best regards,
Alexey
The OSC frequency doesn't directly affect or interfere with interrupts.
Your original program was set up for 4Mhz, so any change in OSC frequency could affect the way your program handles the interrupts.
The main thing is selecting the correct oscillator mode (XT, HS) for your crystal.
DT
Bookmarks