Fixed the bug where stepThroughDataPatterns didn't work at higher data bit lengths. I should have wrote tests! There were two problems:
firstPattern and lastPattern were 16bit variables. So if you try to stick a 32-bit number in there, it would truncate the top 16 bits. I fixed that by changing those to uint32_t.
In doing the math for lastPattern, I take the number 1, then shift it left n times for an n bit pattern. Then so if your pattern is 4 bits, I shift the number 1 to the left 4 times to give you 0b10000. Then I subtract one to make it 0b1111 (the highest 4 bit number). However, when I use the number 1, the compiler assumes it's an int (16 bits), so it thinks it is 0b0000000000000001. If you try to shift that to the left 30 times, it shifts right of the number, so you're left with all zeros. So I need to tell the compiler that 1 should be represented as a 32 bit number (0b00000000000000000000000000000001). I could do that by saying ((uint32_t) 1 ) to "cast" it as a uint32_t, but there is a shorthand way of doing that: 1UL. The UL suffix means "this number is an unsigned long". Different compilers call 32 bit numbers different things, but the 8-bit XC8 compiler calls 32 bit numbers "longs" (16 bits are "ints" or "shorts", 8 bits are "chars", 64 bits are "long longs").
Also, FYI I was able to use some of the debugger's features to figure out what was happening:
I set a breakpoint at line 100 (click on the number 100 at the left of the code to set a breakpoint on that line). Then I ran the debugger on the simulator. You could do the same via the simulator or via the PK4 on the actual hardware.
I pulled up the variables window by going to Window -> Debugging -> Variables. This window has some variables already in it that are relevant near your breakpoint. If it doesn't have the variable you're interested in, you can right click on a variable and say "New Watch".
If the value of the variable isn't showing up, make sure the checkbox is checked for the variable. Dumb feature. Gets me every time.
I was able to see that "lastPattern" was set to 0 and was an unsigned short. That was my clue!
I might write some tests so I don't send you any more buggy PRs!
Dude. That last description was pretty technical haha. I read ul as Uber long and then was sad when I saw the real meaning. Although long long bright me back.
Fixed the bug where stepThroughDataPatterns didn't work at higher data bit lengths. I should have wrote tests! There were two problems:
((uint32_t) 1 )
to "cast" it as a uint32_t, but there is a shorthand way of doing that:1UL
. The UL suffix means "this number is an unsigned long". Different compilers call 32 bit numbers different things, but the 8-bit XC8 compiler calls 32 bit numbers "longs" (16 bits are "ints" or "shorts", 8 bits are "chars", 64 bits are "long longs").Also, FYI I was able to use some of the debugger's features to figure out what was happening:
I might write some tests so I don't send you any more buggy PRs!