Bit Shifting Fail...

[notpike]

Hi!

I need some help...

I'm still working on the jukebox app and I discovered that my encoding function I tested on my computer isn't porting well over well to the MSP430. The function encode() found in firmware/apps/jukebox.c on my fork (Link Bellow) works to create a 16byte uint8_t array so the message may be transmitted. As of right now it won't take any commands larger then 0x80. I believe the problem lies at line 175 where the command and it's inverse are added to the decodeMsg stack. To me It looks like when this happens everything prior to the command gets pushed off the stack. I'm new to C so guidance would be a appreciated. Also beers will be on me for the maintainers. ;)

==Comparing both functions, Left my computer, Right MSP430== https://twitter.com/IfNotPike/status/1181604887588532224?s=20

==My Fork== https://github.com/notpike/goodwatch/blob/jukebox/firmware/apps/jukebox.c#L175

[travisgoodspeed]

Some bugs are described in the warning messages of version 577ca7bf4f3b9a47b19aec3e9dad5109f3d47181 of your branch, and the last one is your problem.

pinInput

apps/jukebox.c: In function ‘pinInput’:
apps/jukebox.c:298:2: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
apps/jukebox.c:301:2: warning: suggest parentheses around assignment used as truth value [-Wparentheses]

The bug here is that the = operator is assignment, while == is comparison.

// PIN Input
void pinInput() {
    if(pinChar[5] == ' ') {  //This is fine.
        pinChar[5] = lastch;
        pin = (lastch - '0') * 100;
    } else if(pinChar[6] = ' ') {  //Should be ==.  Always called when pinChar[5]!=' '.
        pinChar[6] = lastch;
        pin += (lastch - '0') * 10;
    } else if(pinChar[7] = ' ') { //Should be ==.  Never called because the above clause is.
        pinChar[7] = lastch;
        pin += (lastch - '0');

        if(pin <= 255) {          // User can't input a number greater then 255
            pinFlag = 0;
        } else {                  // User goofed, try again
            pinChar = "PIN     ";
        }
    }
    lcd_string(pinChar); // Update screen
}

jukebox_keypress

apps/jukebox.c: In function ‘jukebox_keypress’:
apps/jukebox.c:325:9: warning: implicit declaration of function ‘jukebox_packettx’ [-Wimplicit-function-declaration]
apps/jukebox.c: At top level:
apps/jukebox.c:336:6: warning: conflicting types for ‘jukebox_packettx’ [enabled by default]
apps/jukebox.c:325:9: note: previous implicit declaration of ‘jukebox_packettx’ was here

This isn't a big problem, but be sure to declare void jukebox_packettx() before it is called to silence the warning.

encode

apps/jukebox.c: In function ‘encode’:
apps/jukebox.c:211:15: warning: ‘encodeMsg’ may be used uninitialized in this function [-Wuninitialized]

This is the culprit, I think! In C, when you declare a local variable without a value, the variable remains at whatever used to be on the call stack. And this will differ significantly between your amd64 desktop and your MSP430 watch.

Initialize it to zero, and you should see the same behavior between your desktop and the watch.

uint8_t encodeMsg=0;

Others

The use of size_t as a type for bit and bitSize doesn't seem to be a problem here, but recall that the size will change between your machines. Better to make it uint8_t or uint16_t to keep things consistent between the platforms.

[notpike]

Cool thank you!

I think at this point I should just buy the keg! Until we meet IRL. :D

[travisgoodspeed]

No problem, neighbor. Please let me know whether that worked, and close this issue if it solved your problem.

[notpike]

Hi again, Unfortunately declaring a value for encodeMsg did not fix the problem...

HOWEVER!! I believe I fixed the issue by changing the data type of jukebox_commands[32] from uint8_t to uint32_t so it matches the data type of decodeMsg. There's two bitwise operations being preformed using values from jukebox_commands and decodeMsg in encode() and I think it didn't like the type miss match. More testing is required but I believe I'm on the right path now. I will close this ticket after testing with a live receiver.

Thanks! :D

[notpike]

Tested and that was the problem!