Hi Mark, I only found this out because I read the C18 user manual. Something it has that I haven't seen before is a “long short” - a 24bit signed integer type! (also an unsigned long short too) I’ve made a spreadsheet which was the basis for the math. I will try with Mac gcc. Part of the fun is gcc (64bit) will have a vastly different idea of what an int is compared to C18 (8bit)! I’ll have to change data types between the two compilers. The “uint8_t” style declarations don’t seem to work - I haven’t found a C18 stdint.h header. I prefer these to remove this sort of ambiguity! I’ll let you know how that step goes. Edward
On 2/02/2017, at 7:23 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Edwards.
First I’ve heard of this, but it doesn’t surprise me.
Testing this sort of stuff is not particularly easy. What we have done in the past is put in a DIAG mode command to allow this function to be called with a given string parameter, and then to print the result. Then, we can script up something to feed in a bunch of input and see what the output is like. But, that does require physical hardware.
Perhaps also the function could just be run in a standalone C program on the mac? So long as the type sizes are the same, the results should be equivalent (perhaps with some float rounding differences in the original version).
Regards, Mark.
On 2 Feb 2017, at 4:38 AM, Edward Cheeseman <cheesemanedward@gmail.com <mailto:cheesemanedward@gmail.com>> wrote:
On 23/01/2017, at 8:12 PM, Edward Cheeseman wrote: I’ve started rewriting gps2latlon() to use a long long (64bit) integer multiply and divide. I see reference to SIM808 and 908 on an arduino shield, so I might have a look to see what they have done.
I totally overestimated the pic18F capability. So it turns out the C18, and for that matter, the XC8 compilers treat long long the same as long - 32bit.