Code compiles fine on Teensy++2 but generates compiler errors on Teensy3

Status
Not open for further replies.
H

Headroom

Well-known member
Now that I have the WIZ820io hardware cooperating with the Teensy3 (at least for now) I was hoping not to run into too many software incompatibilities.

I've been using the EthernetBonjour and ArdOSC libraries on a Teensy++2 in a project and was hoping to be able to transfer the code to the Teensy3, but that seems not so trivial. The code compiles and runs fine on the Teensy++2 and does not generate any compiler warnings or error messages. When compiling the same code just switching the board over to the Teensy3 it produces this error message:

/Users/Peter/Desktop/Arduino/libraries/EthernetBonjour/utility/EthernetCompat.cpp: In function 'void ethernet_compat_write_data(int, uint8_t*, uint8_t*, uint16_t)':
/Users/Peter/Desktop/Arduino/libraries/EthernetBonjour/utility/EthernetCompat.cpp:124:25: error: cast from 'uint8_t* {aka unsigned char*}' to 'uint16_t {aka short unsigned int}' loses precision [-fpermissive]
make: *** [Libraries/EthernetBonjour/utility/EthernetCompat.cpp.o] Error 1

I know that there seems questionable type casting involved, but am at a loss of how to fix it as my C++ knowledge is developed enough to use the EthernetBonjour library but not to re-write it. I have a similar issue with the ArdOSC library that was included in previous versions of Teensyduino. Works fine on a Teensy++2 but produces a compiler error message.

Some help would be very appreciated!
 
This is due to the size of int and pointers. On AVR platforms like Teensy 2.0 and Arduino Uno, int/unsigned are 16-bits (and pointers also). On Arm platforms like Teensy 3.0 and Arduino Due, the int/unsigned data types are 32-bits (and pointers also). If the code is casting pointers to uint16_t, you likely want to change the type to uintptr_t. You might need to include <stdint.h> if uintptr_t is not defined by the standard header files included the IDE.
 
Michael,

Your advice was spot on! Thank you very much. Not only does it compile but the OSC Bonjour service successfully registered on the network.
 
I'm glad to hear it. Size of int/long/pointer is one of the things you have to look out for in moving code from one system to another. In general, you want to use types like uint16_t when you either want to match an externally defined storage layout or you want to save storage to use the smallest storage needed to hold the data. For sizes of arrays, etc. you want to use the size_t type. As I mentioned before, for pointers that are needed to be converted to integral types, you want to use uintptr_t.
 
Here's another problem that I find even more elusive:

./Libraries/ArdOSC/OSCMessage.cpp.o: In function `OSCMessage::flush()':
/Applications/Arduino 1.5.2.app/Contents/Resources/Java/libraries/ArdOSC/OSCMessage.cpp:61: undefined reference to `operator delete(void*)'
./Libraries/ArdOSC/OSCMessage.cpp.o: In function `OSCMessage::setArgData(char, void*, unsigned char, bool)':
/Applications/Arduino 1.5.2.app/Contents/Resources/Java/libraries/ArdOSC/OSCMessage.cpp:160: undefined reference to `operator new(unsigned int)'

Aren't "new" and "delete" part of the C++ standard libraries ?

Again, the code compiles fine for a Teensy++2
 
You should use the newer and much better OSC library for any new projects. ArdOSC is older, doesn't implement all the OSC data types, and appears to be no longer maintained.
 
I know and eventually will!

In the meantime I am stuck with this problem that I would like to have an answer for, perhaps for the learning experience.

The answer Michael gave above would serve as a perfect example of the kind of answer I am looking for.
 
At a guess I would suspect it is may be another instance of a different sized integer (i.e. the header file defines new/delete for an integer type different than the use in OSCMessage.cpp). Unfortunately, while I am a C expert, I don't really know the ins and outs of C++. It is kind of weird that you are using the file name foo.cpp.o instead of foo.o. Perhaps the IDE doesn't grok .cpp files as much as other suffixes.

Another explanation if you are using makefiles, is if you have the standard c++ library before the OSCMessage object, and there was no reference to new (unsigned int) and free before that. The linker by default only scans libraries/objects in a single direction, and does not go back to previous libraries. There are options to group libraries together and repeat scanning for entrants for people that can't get the ordering correct.

This is likely a case where posting the whole source file would be a good idea.
 
This is likely a case where posting the whole source file would be a good idea.
Click to expand...

Posting the complete source code for a problem is ALWAYS a good idea. Complete source and details to reproduce the problem saves everyone a lot of time.

That's why the forum has this stick message, which is seems few people read :(
 
Michael (and Paul),

Thanks for the replies. I'll check into that before I post the code. The Arduino sketch itself is rather short and only served as an example. As this is a ArdOSC related error I assume I'd have to post that as well. Before I spend too much time trying to fix this perhaps as Paul suggested replacing ArdOSC with the OSC library is a better use of time.
 
Status
Not open for further replies.
Back
Top