Re: TCP Socket and Serial Port

Your code is fundamentally flawed.

It is flawed in many ways -- for example: what do you think you are achieving by having 1 && in your while loops?:

while( 1 && $serialport ne "" && $errorwithserial == 0 ) {
...
    while( 1 && $errorwithserial == 0 ) {
[download]

-- but the fundamental error is the concept of having multiple, concurrent clients holding two-way conversations with a single serial port. That simply cannot work.

It is possible to envisage having a thread that polls all possible information from the serial port connected device and caching that information in shared memory. And then having multiple, concurrent clients connect and query (subsets of) that information from the shared cache.

Whether that makes sense really depends upon:

ie. number of possible commands or distinct queries?

the 'shelf-life' of that information.
Does the queried information change hourly? Or every microsecond?
the volume of traffic.
ie. the number and frequency of the client connects and the number of commands per connection.

A little more information regarding the overall aims of the program -- eg. what is an "AVR"? I looked it up and two possibilities stood out: 1) Audio/video receiver; 2) AVR reactor, a German prototype pebble bed reactor.

With the former, I cannot see the point of multiple clients connection to my HiFi.

With the latter, I terrifies me that any one would allow multiple connections to a "reactor". Even if it is not of the nuclear variety.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?

Comment on Re: TCP Socket and Serial Port Select or Download Code

Replies are listed 'Best First'.
Re^2: TCP Socket and Serial Port by wiredrat (Acolyte) on Jan 10, 2012 at 16:35 UTC
None of the two options. He is trying to send commands to an AR Drone. AVR is part of the hardware. BTW, you should note that the AR Drone software has already opened the serial port. So It is also adviseable to kill the drone control software before trying to run this script. Everytime you omit 'use strict;' a $kitetn becomes undef.	[reply]
Re^3: TCP Socket and Serial Port by BrowserUk (Patriarch) on Jan 10, 2012 at 17:16 UTC
He is trying to send commands to an AR Drone. AVR is part of the hardware. Hm. Couldn't he have told us that? That probably just makes my point. What is going to happen if you have multiple pilots trying to concurrently control a UAV? If this is related to Occupy Wall Street protestor Tim Pool has configured one that he calls an occucopter, for citizen-surveillance of police. "We are trying to get a stable live feed so you can have 50 people controlling it in series. If the cops see you controlling it from a computer they can shut you down, but then control could automatically switch to someone else." , the the keywords in there are "in series" which are completely missing from the OP. In that case, you'd want a queue of in-bound clients ready to take over when the current client 'drops off'. Emminently doable, but not the way the OP is approaching the problem. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. The start of some sanity?	[reply]
Re^2: TCP Socket and Serial Port by FlyingEagle (Initiate) on Jan 10, 2012 at 19:50 UTC
None of it, it's an Atmel Risc Microcontroller (湣). It's connected via UART and i'll send data to it and the 湣 answers. I couldn't tell u anything about the traffic it depends on the count of TCP-clients and the count of commands they send to the 湣. In some situations the 湣 send a lot of data in a short time and in others some little packets in 1 hour.	[reply]
Re^3: TCP Socket and Serial Port by BrowserUk (Patriarch) on Jan 10, 2012 at 21:26 UTC
The problem remains: if you have two clients that each send a command to the uC in quick succession, how do you know which client to send what output to? If you can answer that question, then what you are trying to do may be possible. If not, the best you could do is serialise the communications. Ie. a) Accept one client connection; b) read its command; c) send it to the uC; d) retrieve the results; e) send them back to the client; f) disconnect that client; loop back to a. More fundamentally, will the uC even look for a second command before it has returned all the output from the first command? If not, there is no point trying and no point in using threads. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. The start of some sanity?	[reply]
Re^4: TCP Socket and Serial Port by FlyingEagle (Initiate) on Jan 11, 2012 at 23:31 UTC
The 湣 send a Command back, which is sendet to all clients. all clients know what to do with this information. my problem are not the clients itself as much more: how to communicate correctly between the main thread, the tcp thread and the serial port (=serial thread in my test-case). regards	[reply]
Re^5: TCP Socket and Serial Port by BrowserUk (Patriarch) on Jan 12, 2012 at 02:17 UTC
Re^4: TCP Socket and Serial Port by FlyingEagle (Initiate) on Jan 10, 2012 at 23:19 UTC
oh, sorry, all tcp-clients could send a command, and the 湣 answers and ALL tcp-clients get them. so all tcp-clients are on the same state. the risk of simultaneously send from tcp-clients is nearly zero or if greater zero it's not the biggest problem. first of all i want to have a stable conncetion, both tcp and serial, than i could (maybe) built in some restrictions for the 湣. thanks in advice	[reply]