Showing results for 
Search instead for 
Did you mean: 
Showing results for 
Search instead for 
Did you mean: 

The PTC Community email address has changed to Learn more.

Using the C SDK to Deliver Data to ThingWorx from a Raspberry PI

No ratings

This document attached to this blog entry actually came out of my first exposure to using the C SDK on a Raspberry PI. I took notes on what I had to do to get my own simple edge application working and I think it is a good introduction to using the C SDK to report real, sampled data. It also demonstrates how you can use the C SDK without having to use HTTPS. It demonstrates how to turn off HTTPS support.

I would appreciate any feedback on this document and what additions might be useful to anyone else who tries to do this on their own.



I want through the document and explored the steps, nice job.

I have run this example from another source but you can always learn something new.

Thanks for putting this out there.

See my  general  comments below

Putty or Remote desktop can be useful  alternatives when accessing the PI.

For me the  build took a while which could be I was running putty  … I also had to actually remove the executable from the release folder to make sure it built on one occasion and then you find it useful to remove before the build starts.

I think it would be useful to mention the need to set TW_HOST in main.c as localhost will not work

#define TW_HOST "yourhost"

I did it a little different in   twLinux.h

//#define TW_TLS_INCLUDE "twAxTls.h"

#define TW_TLS_INCLUDE "twNoTls.h"

#define NO_TLS

Which I believe means you don't have to set

tls->validateCert = FALSE;

tls->isEnabled = FALSE;

Also after running  I think looking at the Monitor  to see the unbound remote thing  is running is useful. This confirms you have connected.

Small point the PIDataCollector1 example code attached has an error on line 43 - need to remove the x


It was a cool idea getting the board temp from the PI nice!  I did know about that - useful if you have no sensor 🙂

my value was  103.2 F

Just to round things off I created a Thing called  PIDDataCollector1 and used the managed bindings allowing me to see the values.

Steve GW

Thanks! This is great info.

I will incorporate it.


In the zip file for this example is an entity file you can import to create a PIDataCollector1 Thing. It will save you having to remote bind the BoardTemperature property.

I updated the attached files with Steve's suggestions.

If you get any errors about no support for the -m32 switch during compile, use gcc-linux-arm-hwfpu instead of gcc-linux-arm-hwfpu for your platform. I started seeing this error on Raspberry PI 2.

Hello Bill,

thank you very much for your detailed explanation pdf - file!

I already get a connection with the StreamSensor Example running with the C SDK on my remote Linux Client. I was able to vizualize the example values in my thingworx UI running on my windows server. I build everything within the terminal on my linux system.

Now I am trying to adapt the sending of values with the C SDK with my own values from another project. For this purpose I am using Eclipse.

If I try to build your example or the SteamSensor example in Eclipse, I get following problems:

I add all include paths.

After that I get build errors because of unknown types for DATETIME, TW_ADDR_INFO, TW_DIR, TW_MUTEX and TW_SOCKET_TYPE.

I am missing some some includes or Linker Commands.

Thank you very much!

In the near future, we will be supporting Eclipse for C SDK development directly in the SDK download but until then let's work through your specific problem.

It would be helpful if you could post your specific compile and linker errors but I will guess at what the problem for now. The C SDK has to compile on many platforms ranging from a desktop system running Windows all the way down to an arm based processor running linux such as a Raspberry PI. Unfortunately, services such as time, networking, and threading functions are different on each of these platforms. A description of these cross platforms services is in src/twOSPort.h which may allow you to compile but the actual implementation for your target platform is in one of the many .c files in the porting directory. Failing to include the appropriate one for the platform you are building for will cause linking to fail. This is managed for you in the Makefies for the C SDK but could be absent from your Eclipse project.

If you are building in windows, I suggest you make sure to include src/porting/twWindows.c in your project. It has the implementations for the symbols you mention for the Windows platform.

Thank's for your response Bill.

I agree with you that I have to read the specific build information from the make file.

I've done the following include paths in Eclipse, because header files were not find recursively.










​I also added the lib paths:

Libraries (-l)


​Library search path (-L)


​In the Linker Command I also added:

-l/usr/include/tw-c-sdk/build/obj/gcc-linux-.x86-64/debug -libTw

​The specific compiler error is:

"unknown typename 'x' " where x stands for the DATETIME, TW_MUTEX etc. I mentioned above.

Thank you Bill!

I just found out that one solution for the unknown type names could be done in the twOSPort.h in /src/porting.

In the #include area there's one #include TW_OS_INCLUDE

I commented it out and put in the twLinux.h, where I can find all the defines for TW_MUTEX etc.

I think that's the first step for solving the error messages. After this include Eclipse doesn't display this error messages.

Thank you for your guide, Bill. It really helps!

This guide is getting a little out of date. New versions of the C SDK, 2.0 and greater should be build using the cmake tool ​ . for more information on how to do this consult the readme that comes with the download.

Version history
Last update:
‎Dec 31, 2015 12:59 AM
Updated by:
Labels (2)