I am building a Nixie clock and now have PCBs, 200V power supply, Pic as serial chips, a main pic and a DS1307 board as the actual timekeeper. Now debugging this lot is a nightmare and after spending two days checking and rechecking boards, code, I2C and serial communications (Definitely no Oxford comma!!). I finally found out where my problem lies (apt word). Here's a screenshot of XC8 which is paused in the debugger. The array NixieA should contain 128,2,16,1,64 then zeros, now look at the bottom, it contains 128,2,15,1,52. How can an array held in ROM get corrupted. Answer, it can't. After some investigation, it turns out that XC8 doesn't like leading zeroes. If you do var=016 then var will contain 15. How is anyone supposed to work with such bug ridden software.
Thank you Microchip for wasting two days of my life. I despair,
Mike.
Edit, going for a few pints to calm down. I may be gone a while.
Sorry, I stand corrected. I was reading the above on my phone and couldn't see the image. However, I still thought the convention was 0x, 0o and 0b for other than decimal but having said that, I don't think I've ever used octal in my life. Problem solved.
Sorry, I stand corrected. I was reading the above on my phone and couldn't see the image. However, I still thought the convention was 0x, 0o and 0b for other than decimal but having said that, I don't think I've ever used octal in my life. Problem solved.
Good posts!!! It's always better to use Hex when programming.... It must be something that's come over from HiTech..
I have just had a really bad issue with "sprintf"..... XC8 brings in "doprint.c" optimised to suit the vargs[]'s.... Tred carefully or you'll be crying before Santa gets here......
Just had another..... This time it was my fault... in simulation the ADC results were correct, but the return value was wrong...
This shouldn't have taken me so long to fix..
C:
int GetfromADC(int channel)
{
unsigned int ret = 0;
ADCON0 = 0x01 | (channel<<2);
DelayUs(100);
GO = 1;
while(GO)
ret = (int)ADRESH<<8 | ADRESL;
return ret;
}
Just had another..... This time it was my fault... in simulation the ADC results were correct, but the return value was wrong...
This shouldn't have taken me so long to fix..
C:
int GetfromADC(int channel)
{
unsigned int ret = 0;
ADCON0 = 0x01 | (channel<<2);
DelayUs(100);
GO = 1;
while(GO)
ret = (int)ADRESH<<8 | ADRESL;
return ret;
}
I left it open so I could see who would be the first to call me a numpty!!! There is nothing wrong with the compiler or the code.. It was a simple syntax error that I just didn't see...
The code wasn't waiting for the ADC to complete!!!!! A simple semicolon error... I posted it so others can see that a simple error can bring turmoil.... As I said, I was convinced the compiler wasn't upgrading the byte ADRESH to an int...