UART - Serial Port

Archive
1

Ok, another Serial Port question.

This might start a debate but it’s a general programming practice question…

Is it ok or acceptable to have more than one event in different parts/threads of the program to send UART/Serial Port data.

I have a Main .Net Forms application I am getting together (thanks Chris for the joystick example again), which receives a Temperature reading from the Panda and displays it on the Form.

Well on the Panda side I have just a Temp thread that sends that data.

I guess I would like to send other commands back to the Main Computer form, but maybe in a different thread.

For example, I have a thread now that sends the Temperature data, I would also like to send an update every so many seconds or maybe on demand from the computer that the Panda is still “OK”, basically a ping event saying the Panda is still reading.

So basically I would like to have a different thread that says, “Everything is OK” as desired.

I realize, from code it shouldn’t matter, but I was just wondering what others my think having multiple “Send” Serial Port events throughout a program.

I do realize that I should only have one “Receive” event and just parse and push the data around as needed.

Any feedback would be great.

Mike in MN

FYI, the “Are you OK” or “Ping” to the Panda is part of the bigger picture for the Underwater ROV project I am building. In the event that a receive command isn’t trigger so or something of that nature I plan on having an automatic surface method trigger. The “Computer” asking if everything is “OK” would be something of a status field on the form. Just in case I lose connection, or there is a communication break down.

2

Yes it is okay but it is better if you use lock
http://msdn.microsoft.com/en-us/library/c5kehkcz(VS.71).aspx

3

So in reading over the “Lock” at bit…

Is the reason to use lock during the particular thread that is processing a Serial Port “write” mostly so nothing interrupts that process, like say an “event” trigger?

Mike in MN

4

it is a mechanism of locking shared resources in multi-threaded system. There are hundred of articles on the web that would explain this better that I would

5

cncmike - any time you have multiple threads, you cannot tell when one will be interrupted and another will begin. So if no other thread is writing to the serial port, you do not need to use lock.

But if multiple threads are writing, its entirely possible that while writing a thread is interrupted and another thread begins writing. Take for example two buffers: “Hello World” and “This is a test.” If you begin writing Hello World, but it is interrupted by another thread which starts to write, the output could be “Hello This is a World test.” A basic example, but one which would obviously cause problems :slight_smile:

As Gus said, there are plenty of articles online about locking/shared resources in multi-threaded systems which will do a better job explaining, but that is a simple example of how a serial port could become an issue.

6

Depending on how you are sending the data to the Serial port, you may want to use a queue. For instance if you were just logging data, not looking for a full transactions, you could avoid the problems associated with locking threads by having each thread populate a queue and having the serial port dequeue the message.

7

This is all interesting…I will do some reading.

Thanks for the directions!

Mike in MN

8

I just posted a demonstration of how to use queues for multiple output producers. It is FEZ on the NETMF platform!!
Here is the link : http://www.fezzer.com/project/171/serializing-output-from-multiple-threads

9

Dave,

Cool, I will take a look at it when I get some time.

Mike in MN

10

Dave,

Sat down before bed here quick and ran your code, it’s a cool little thing (stepping through the code in VS rocks!)

I think I am gonna use this example in my little project, I think it will work perfect for my multiple serial port sending parts.

Thanks!

Mike in MN

11

@ Dave : Queue is not thread safe, is less likely to have problems in a one-consumer scenario but you should use locks or, better, a blocking queue : http://www.fezzer.com/project/107/blocking-queue/

12

@ randoom: Thanks for the timely warning.

I would definitely use the blocking queue. My snippet was meant to be a simple example. Honestly I had not checked the implementation of Queue to make sure it was thread safe (in the other RTOSes I have used, it either was or we overloaded the definition to make sure that it was) The ramification of using queue in any environment where there could potentially be more than one consumer could be disastrous and extremely difficult to debug.,

13

ok, boys, it seems like I have some more reading to do, but as always, thanks for the direction.

I did debug the heck out of that queue example, looks like I will play with the new one also.

I will be using it for serial, so I better start getting all my serial outputs figured out and try some of these things.

Thanks,

Mike in MN

14

You should be able to replace Queue in my example with the blocking-queue and be good to go.

15

Thanks Dave,

Because I am still learning, it takes a bit for me to put stuff together to try things. While I could use Debug.Print or Messagebox.Show(in the full .NET) they get rather boring.

So I will wait until I get my next temp sensor and tie in another sensor with the FEZ and implement another Textbox in the full .Net form I am playing with to display it.

Thanks though, with out all your guys help on here, I would still blindly be surfing the net trying to learn this stuff.

Mike in MN