It’s the same identical compiler that gets installed. However compiling on a 64-bit system without properly defined types can cause problems.
well, I’m at a complete roadblock then for this.
Only possibly solution is to add the -m32 flag to GCC, but … The request to add the ability for users to control the compiler through flags has been on the table since 2010 and yet they’ve done nothing to implement. Or if they have done something, they have nothing to show for. So yeah, for this specific project, you may simply be stuck to using a 32-bit system.
Someone asked me to check sizes of int and long on the compiler, via sizeof(int) and sizeof(long) - they both turned out to be 4. So I wonder if that’s part of the problem.
That’s why you should change those ints to proper types. For the long you can change it to an int32_t (or if it’s an unsigned long , change it to uint32_t
I actually did that. int-> int16_t, long-> int32_t, long long -> int64_t and so forth. Came out with the same results in the IR code. (int16_t reported 2, int32_t reported 4 as it should be)
Depending on what you’re compiling for, an Arduino int can be either an int16_t or an int_32. It’s the reason I hate the way they’re assuming what you need or want to use. I will always specify which one I need, and not let the IDE guess for me. I don’t know what the Teensy does though.
I only have a MEGA2560 with me right now, and this is what I get:
Size of Arduino INT: 2
Size of Arduino long: 4
Size of int8_t: 1
Size of int16_t: 2
Size of int32_t: 4
What processor is on the Teensy? It’s possible that it’s getting compiled in as an int32_t instead of int16_t thanks to the way the IDE chooses what it thinks you want.
I just figured it out.
The 32-bit machine was set to 96Mhz (Overclock), while the 64-bit machine was set to 72Mhz. Change that to 96, and BAM. fixed.
Now I feel especially annoyed, but hey, documenting for posterity.