Sign in to follow this  
Followers 0
n_K

MPLABX XC16 bug?

3 posts in this topic

Right, I don't know if I'm being stupid or what but I'm reading the time from an RTC chip via I2C and storing it in an array, and then processing it as below... For some reason, Data[8] shows the seconds fine but Data[0] always shows 0, but I can't really see why? Am I doing something wrong or is this a bug?

while (i < 7)
{
IdleI2C();
Data[i] = ReadI2C();
++i;
}

Data[8] = Data[0] & 0b01111111;
Data[0] = Data[0] & 0b01111111; //Seconds
Data[1] = Data[1] & 0b01111111; //Minutes
Data[2] = Data[2] & 0b01111111; //Hours
Data[3] = Data[3] & 0b00000111; //Days
Data[4] = Data[4] & 0b00111111; //Date
Data[5] = Data[5] & 0b00011111; //Month
Data[6] = Data[6] & 0b00011111; //Year
Data[7] = Data[7] & 0b00011111; //Control

Data[0] = ((Data[0] & 0b01110000)>>4)*10 + (Data[0] & 0b00001111);
Data[1] = ((Data[1] & 0b01110000)>>4)*10 + (Data[1] & 0b00001111);
if ((Data[2] & 0b01000000) == 0b01000000)
{
    //24 hour
    Data[2] = ((Data[2] & 0b00110000)>>4)*10 + (Data[2] & 0b00001111);
}
else
{
    //12 hour
    Data[2] = ((Data[2] & 0b00010000)>>4)*10 + (Data[2] & 0b00001111);
}
Data[4] = ((Data[4] & 0b00010000)>>4)*10 + (Data[4] & 0b00001111);
Data[5] = ((Data[5] & 0b00010000)>>4)*10 + (Data[5] & 0b00001111);
Data[6] = ((Data[6] & 0b11110000)>>4)*10 + (Data[6] & 0b00001111);
Data[8] = ((Data[8] & 0b01110000)>>4)*10 + (Data[8] & 0b00001111);

sprintf(Bob, "%d%c", Data[2], 128);
LCDWriteString(&Bob);
sprintf(Bob, ":%d%c", Data[1], 128);
LCDWriteString(&Bob);
sprintf(Bob, ":%d%c", Data[0], 128); //Always shows 0
LCDWriteString(&Bob);
sprintf(Bob, ":%d%c", Data[8], 128); //Shows seconds correctly
LCDWriteString(&Bob);
sprintf(Bob, ":%d%c", Data[0], 128); //Again, always shows 0
LCDWriteString(&Bob);
LCDPosition(2); //Goes to 2nd line
sprintf(Bob, " %d%c", Data[3], 128);
LCDWriteString(&Bob);
sprintf(Bob, ":%d%c", Data[4], 128);
LCDWriteString(&Bob);
sprintf(Bob, ":%d%c", Data[5], 128);
LCDWriteString(&Bob);
sprintf(Bob, ":%d%c", Data[6], 128);
LCDWriteString(&Bob);
sprintf(Bob, ",%d%c", Data[8], 128);
LCDWriteString(&Bob);
LCDPosition(1); //Goes back to first line

Share this post


Link to post
Share on other sites

Yet another bug, this program seems like complete and utter shitware. It's noted for being a C compile, right, I'd call it a BASIC interpretor that ****s up as soon as you throw anything mediocre at it.

DayNumToDay(Data[3], &Bob);
sprintf(Bob, "%s%c", Bob, 128);
LCDWriteString(&Bob);

Works, outputs 'Sun'. The LCDWriteString() routine outputs each character until it finds 128, I was trying with sizeof but it appears that MPLAB doesn't like it for some stupid pathetic reason or other.

DayNumToDay(Data[3], &Bob);
sprintf(Bob, " %s%c", Bob, 128);
LCDWriteString(&Bob);

Doesn't, it messes up the LCD completely and I have to put an 'if (i < 8)...' inside the LCDWriteString otherwise (I presume) it endlessly prints out spaces and never gets to the 128 character. Now, I have absolutely NO IDEA WHAT the addition of a SINGLE SPACE character would do this.

Bob is defined as unsigned char Bob[10];

The only thing I can think is that after the 4th byte it skips to a completely different memory location, which is a complete and utter ****ing joke.

So please someone, enlighten me as to how I'm going wrong or if it's just better to dump this (so far) pathetic 4gb waste of complete tosh into the trashcan and be rid of it forever?

Share this post


Link to post
Share on other sites

I'm unsure of why the code in your first post does not work. It looks like you do the same things to Data[8] that you do to Data[0]. Try simulating the code on your computer using a known-good compiler (like GCC or Clang) by creating a ReadI2C() that gives you some output you would expect from your RTC chip. It will probably also be fairly easy to replace LCDWriteString() with puts() for the purpose of your simulation too. If it still doesn't do what you expect, you can at least run it through GDB to figure out why. If the simulation works right then it might be a compiler bug; you can submit a bug report to Microchip using their ticket system at http://support.microchip.com. Submitting the code to reproduce the bug (and the probably the simulation too) will probably get you a faster response.

As for your second problem, I have also encountered many bugs with sprintf() and family in Microchip's compilers (HI-TECH C for the PIC18F and XC16 for the PIC24F). One I remember in particular caused my program to freeze indefinitely (crash?) every time I tried to printf() a float using "%f". However every time I tried to output the same variable using "%x" it worked. The other floating point format specifiers are not supported by Microchip's printf() (I.E. "%F", "%e", "%E", "%g", "%G"). Although XC16 is based on GCC, its standard library is not based on glibc - its Microchip proprietary - and therefore has many bugs. I recommend that you report the bug to Microchip, including code necessary to reproduce it.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0

  • Recently Browsing   0 members

    No registered users viewing this page.