Let's Make Robots!

Serial Com. the right way?

 

Hi Guys.

Ive been using alot of UART communication between my panda II and bluetooth, and from pc, vice versa.

But always pretty simple things, like sending a text. waiting for it, then maybe reply back..

But i just started on a small robot project, and i control my servos via bluetooth from my computer. (Virtual serial port, to my itead BT shield).

And i just send text commands like "up" "down" "left" "right" "stop" to control my servos.

but i now plan to add a ultra sound range finder (Paralax "Ping)))").

And now im thinking, that i maybe should optimize the way i do this... since i might want to transmit and recieve, motor control, servo's, cammands from and to ping, and so on.

So is there some guidelines on how i should transmit and recieve data, so i wont collide data? whitch i guess will happen if i just start sending text back and forth with no form of control?

 

Hope this question makes sense :)

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

You should be able to send information in both directions with no problem.  USB and serial can handle it fine (usually) and as far as I know bluetooth can as well.  If I am wrong I'm sure someone will point it out.  In any case, you might as well do it.

So theres no need to worry about multiple threads maybe trying to write to the serial connection at the same time?

Ah, you didn't say anything about threads.  That's a different ballgame altogether.  If windows or whatever is on the panda will let two threads open the serial port at once, you will have to handle multiplexing the data yourself.  Do you actually mean threads?  Or do you mean one program on each end of the connection?

 

Well the panda is going to run threads, at least thats the way i use to do it...
But if my serial port i a public static, and opened in main program.
And then written to from different threads. will that then cause problems still?

else ill have to rethink the design. 

If you write to the same serial port from different threads without some mutual exclusion device (semaphore, mutex, etc) you will have problems.  I have never used C# and don't know how it handles threads, but any multithreaded language should have synchronization capabilities (mutex, semaphore, whatever).  If you have one communication thread and have the other threads send packets to it, that thread can handle all the details on both ends.  That's pretty much how a TCP/IP stack works.