Communicating with make controller via C/C++
Up to Devices and Hardware
Hi
I am trying to communicate with the make controller using c/c++, after some research I found the oscpack package (http://www.audiomulch.com/~rossb/code/oscpack/) which made my life a little bit easier. During testing, I found that the make controller does not reply on the same socket it received the data from, am I right? If yes, that means anyone who wishes to write a program to communicate with the make controller needs to write a server program to receive data from the make controller , right?
Thank you,
mrizk
yes I am communicating via UDP (since acording to my knowledge communicating with the board through osc using TCP is not enabled), and I noticed that i should bind a UDP server to the port to listen for the incoming connection, the problem is that my application is multithreaded and each thread sends/receive a different message to/from the board via a different socket (For example: there is a thread that recieves all the time the sensors distance, and another one to control the motors). And I can not bind more than one thread to the same port. I guess I am stuck and I need to do extra work
, I would appreciate it if any one can suggest a solution.
Are you hoping to interface via OSC or otherwise?
If you're interested in OSC and using Qt for C++, you can have a look at the mchelper code, and you can always look at the firmware code for examples in C. There are also OSC libraries for C/C++ out there, although I haven't personally used any. A quick google will probably turn up things like
Sorry for making you google, but I was just wondering if thier was an officially endorced solution, like the library for C#. Do the OSC libraries include the functions like UsbPacket(); or is that a different library specifically for the MC?
I'm using Visual C++ .NET if that helps.
No worries. But yeah, there's not an officially sanctioned C/C++ library - but the ones mentioned above seem to have worked for lots of people. I can't comment on exactly how they work, as I have not used them. You'll probably find they're geared mostly towards use with Ethernet, not USB, as that tends to be the de facto transport for OSC code out there in the world.
Ok. So OSC is almost like a DAQ-type protocol?
Also, is the C# library available here that includes OSC a non-standard version since it does include UsbPacket(); ?
It's not non-standard - OSC does not specify the transport, just the protocol. UDP is the transport that most people adopted when implementing OSC, since it's pretty simple.
And there's unfortunately a lack official specification for using OSC in stream-based transports (like USB or TCP). Since everything arrives neatly in one packet in UDP there's no need to delimit packets - the MakingThings OSC USB code uses the SLIP protocol to delimit packets, as was advised by the guys at CNMAT, fathers of OSC.

