Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Pulling my hair out with XC8, again.

Status
Not open for further replies.

Pommie

Well-Known Member
Most Helpful Member
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.

XC8_crap.png


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.
 
Last edited:

Cicero

Active Member
Not a bug, putting a 0 in front makes it think its an octal number.
  • Octal 2 = Dec 2
  • Octal 16 = Dec 14
  • Octal 1 = Dec 1
  • Octal 64 = Dec 52
 
Last edited:

Pommie

Well-Known Member
Most Helpful Member
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.

Thanks,

Mike.
 

Cicero

Active Member
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.

Thanks,

Mike.
No worries mate. I've been caught by this myself before.

As far as I know, its only octal which just magically assumes things with its leading 0's. Everything else needs the usual number conventions.
 

Ian Rogers

User Extraordinaire
Forum Supporter
Most Helpful Member
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......
 

Mike - K8LH

Well-Known Member
Hey, Mike (Pommie), you're not alone. I experienced that same "gotcha" some time ago (using MPLAB 8.x)...

Happy Holidays... Cheerful regards, Mike
 

Ian Rogers

User Extraordinaire
Forum Supporter
Most Helpful Member
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 was convinced it was the compiler.....
 

Cicero

Active Member
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 was convinced it was the compiler.....
So what was the problem, the different types? Signed and unsigned?

Presume GO is cleared in some other interrupt.
 

Ian Rogers

User Extraordinaire
Forum Supporter
Most Helpful Member
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...
 
Status
Not open for further replies.

Latest threads

Top