May I suggest ... updating XC8 and MPLAB X. I hear ya on not wanting to=20 change (I'm frozen in 2010 with the CCSinfo.com C compiler and MPLAB8=20 for another project) but I have lost a number of hours doing workarounds=20 for what looks all the world like XC8 compiler bugs (free mode) and=20 there are clear bugs in MPLAB X. The V1.33 of XC8 fixed numerous things, the 1.34 mid-feb release is more=20 minor improvements. This according to release notes, there isn't a list=20 of shame bug fixes for each release. One problem that I think is MPLAB is when stepping and watching=20 variables (with the cursor "popup" anyway) sometimes the values seem=20 wrong and various if () branches don't go the way they should. In my=20 project anyway the disassembly view doesn't work, and I have to use the=20 "program memory" view, and variables named there are NOT the ones being=20 used as I step. I think XC8 is being smart about mapping two variables=20 to the same address if they will never be simultaneously used, and this=20 is confusing MPLAB. But I'm not totally sure. It is clearly broken=20 though, I've been tempted to do a screengrab video showing the fail and=20 posting somewhere, it is basically not acceptable for professional tools=20 to be like this. But... more time spent not developing to do that. Anyway. All this is definitely worse than TI's IDE system. So any improvements Microchip makes should be installed, imho. When=20 this project ships I may do a freeze. Note that you can install=20 different XC8 versions (I have 4 or 5 at this point) and choose which to=20 use in your project preferences, so it is possible to keep updating=20 XC8/MPLAB X and not have old working code become broken with a new=20 version of XC8. That's a long aside, but what I've been dealing with in the last month. For what you're doing, as other posters have said it is pretty=20 definitely an integer range issue. Multiplying a 16-bit int by=20 (255/100) requires either a different overall approach or using=20 fixed-point math. If performance/memoryspace isn't an issue, you can=20 always use floats... int16_t encper =3D (uint16_t)( ((float)encval) * (100.0f/255.0f) + 0.5f); the compiler *should* change the (100.0f/255.0f) into the equivalent=20 constant and do this line of code with a single multiply; I like to=20 leave it more "spelled out" for clarity. Adding 0.5f makes the=20 conversion from float to uint16_t be a rounding vs. a floor if that is=20 desired. (probably irrelevant for UI related things like this.) Note that floats can be 24-bit or 32-bit, dig thru project options...=20 XC8 global options, XC8 linker, memory model category. 24bit is=20 definitely faster, smaller program memory requirements, and good enough=20 for anything nonprecision like this. I'm sure some people on piclist will cringe at this, and I certainly=20 have done fixed-point to avoid floats entirely for performance and/or=20 program memory space reasons, but the fastest way to get to done with=20 low risk of undetected bugs is the best approach for most projects. OTOH, if you have time, doing fixed-point math learnin' and=20 experimentin' is valuable and recommended. It is probably 100 times=20 faster than floats on any model of PIC barring some high-end thing with=20 floating point hardware I know nothing about... FWIW... J Josh Koffman wrote: > Hi all, > > I'm trying valiantly to continue with my work on my encoder project, > despite now being on the road. Though I definitely pulled out my > PICkit3 and test board yesterday and did a bit of debugging at 35,000 > feet! > > My current problem is that a simple math equation doesn't seem to work. I= t is: > int16_t encper =3D (encval/255) * 100; > > encval is also an int16_t, and defined elsewhere in the code. I know > it is holding a value, as directly after the line of code above, I > display both variables on an LCD display. The encval variable > increments or decrements along with encoder movement. encper however, > remains at 0...always. It shows as 0 in the watch window as well. > > I am not currently on the latest version of XC8, as the current one > seems to be working and I try to avoid Microchip updates until I have > to upgrade due to a bad experience many years ago. That said, it might > be that I need to update my tools. > > However before I do that, can anyone else think of a reason why this > might not be working? > > Thanks! > > Josh > --=20 http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .