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
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 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.