in reply to Re: TCP Socket and Serial Port
in thread TCP Socket and Serial Port

None of it, it's an Atmel Risc Microcontroller (µC). It's connected via UART and i'll send data to it and the µC 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 µC. In some situations the µC send a lot of data in a short time and in others some little packets in 1 hour.

Replies are listed 'Best First'.
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]

      The µC 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]

        In a nutshell, use a single thread for communicating with your serial port. Set up two Thread::Queues: one for inbound commands; one for outbound responses.

        When one of your clients sends a command, post it to the inbound queue.

        Have your another thread monitor the outbound queue and forward a copy of each thing it dequeues to every connected client.

        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]
      oh, sorry, all tcp-clients could send a command, and the µC 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 µC. thanks in advice
[reply]

In Section Seekers of Perl Wisdom