0
\$\begingroup\$

I'm blocked because of an issue that is causing a lot of time loss. I've created a function to get the LSB and another one to get the MSB.

char get_LSB (int n){
    
    unsigned char lsb = (unsigned)n & 0xFF; // mask the lower 8 bits
   return lsb;
}

char get_MSB (int n){  
    unsigned char msb = ((unsigned)n >> 8 );// shift the higher 8 bits
   return msb;
}

It doesn't work as when I call the function get_LSB or get_MSB I get a result different from what I expected. Let's check the following example:

void main() {
              TRSISC = 0x00;
              PORTC = get_LSB(100);// function should return 100 but returns 68
              Delay_ms(5000);
              PORTC = get_MSB(360); // should return 1 but returns 0
}
\$\endgroup\$
10
  • \$\begingroup\$ The function are OK (except that I would suggest to change the parameter type to unsigned). You have some problem with testing. get_MSB(360) should be returning 0x68 - probably the result that you believe it is returning for get_LSB(100). Please tell us how do you read out the results. \$\endgroup\$
    – Eugene Sh.
    Mar 17, 2021 at 14:54
  • \$\begingroup\$ Why should get_MSB(360) return 0x68? It should return 0x01. \$\endgroup\$
    – jusaca
    Mar 17, 2021 at 15:00
  • 1
    \$\begingroup\$ be careful, the return value is a char, which is different from a signed char and from an unsigned char, this is unspecified. To be clearer i suggest to use unsigned char or even better uint8_t if your compiler has it. As commented however it seems a base 16 misunderstanding \$\endgroup\$ Mar 17, 2021 at 15:01
  • 2
    \$\begingroup\$ @jusaca You are right, 0x68 is the LSB, not MSB. Sounds like the program presented is different from the one that is flashed and run. Or there is a misinterpretation of the results. \$\endgroup\$
    – Eugene Sh.
    Mar 17, 2021 at 15:05
  • 1
    \$\begingroup\$ @hilmar 100 = 0x64 not 0x68 \$\endgroup\$
    – Arsenal
    Mar 17, 2021 at 16:15

2 Answers 2

1
\$\begingroup\$

Try these:

unsigned char get_LSB (int n)
{    
    unsigned char lsb = (unsigned char) (n & 0xFF); // mask the lower 8 bits
    return lsb;
}

unsigned char get_MSB (int n)
{  
    unsigned char msb = (unsigned char) (n >> 8);// shift the higher 8 bits
    return msb;
}
\$\endgroup\$
4
  • \$\begingroup\$ This really should not change any behavior \$\endgroup\$
    – Eugene Sh.
    Mar 17, 2021 at 15:27
  • \$\begingroup\$ Did you try it? When writing a UTF8 function, time ago, I had a similar problem which I solved it by using unsigned chars. \$\endgroup\$ Mar 17, 2021 at 15:32
  • \$\begingroup\$ Sorry, missed the return type change. This will make it different in some cases. But should not lead to the results the OP is presenting though. \$\endgroup\$
    – Eugene Sh.
    Mar 17, 2021 at 15:36
  • \$\begingroup\$ @EnricoMigliore by doing this, It works perfectly :). Thank you very much. \$\endgroup\$
    – Legend27
    Mar 17, 2021 at 18:28
1
\$\begingroup\$

Using PORTC to check the functionality of your function is going to cause multiple issues.

For example it is a 7 bit register with bit 3 missing. Then RC4 and RC5 are not under complete control of the PORTC alone, the USB peripheral has control over it. And they can only be used as input, so the state depends on the USB or the voltage at the pin, but never on what you write to the PORTC register.

So that means, that bits 3, 4 and 5 are all not what you write to them (likely 0).

So for your 100 the result would likely be (100 & 0xC7) which happens to be 68.

This problem does not explain however why your get_MSB returns an unexpected 0 instead of a 1.

Make your life easier by not using peripheral registers to check that a function returns the right value. If your debugger is horrible and does not allow to step into a simple

if (100 == get_LSB(100))
{
   volatile unsigned char dummy = 0U;
}

You could instead toggle a pin (which you know you can measure and works correctly).

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.