BTW, I think you asked the wrong question. For example, I personally
would have fed the NMEA messages into a NMEA channel on D-BUS, allowing
any application to subscribe to the message flow. But to get that
answer the question is about sharing messages, not about sharing serial
ports.
That ass
On Wed, 2009-12-30 at 18:45 +1100, Del wrote:
> > USB serial ports are easy and cheap: 1 serial port per consumer
>
> Yeah, in this case that wasn't going to work because the object on the
> end of the serial port is (a) expensive and (b) susceptible to the sort
> of voltage drops that can be ca
USB serial ports are easy and cheap: 1 serial port per consumer
Yeah, in this case that wasn't going to work because the object on the
end of the serial port is (a) expensive and (b) susceptible to the sort
of voltage drops that can be caused by parallelising serial ports.
--
Del
Babel Com
Terry Dawson wrote:
Del wrote:
Does anyone have a solution to this problem?
This might do what you want:
http://freshmeat.net/projects/conserver
Although it could be overkill for what you want to do.
It does the job, though.
I found a simple solution for the specific case that I was afte
On Wednesday 30 December 2009 08:12:13 slug-requ...@slug.org.au wrote:
> Hi, Del. Have you considered a hardware solution using a one-to-many
> transceiver? I never heard of a such a thing but I am sure it either
> exists or can be built. I don't know if your clients are remote
> (other location
Del wrote:
Does anyone have a solution to this problem?
This might do what you want:
http://freshmeat.net/projects/conserver
Although it could be overkill for what you want to do.
It seems a pretty simple exercise to write a small daemon program that
opens a serial port, and listens for in
Hi, Del. Have you considered a hardware solution using a one-to-many
transceiver? I never heard of a such a thing but I am sure it either
exists or can be built. I don't know if your clients are remote
(other locations) and that is why you are using TCP?
Software solution: I'd write a program
> "del" == del writes:
del> Martin Visser wrote:
del> I can create a listener on one of the FIFOs above like this:
del> socat -u /tmp/r1 TCP-LISTEN:2,fork,reuseaddr
del> However I still hit the same issue -- the first client connects
del> to port 2 and gets the data, the second li
Martin Visser wrote:
Del,
I just did a simple test, that might help you to a solution
1. Used mkfifo to create 3 pipes "mkfifo /tmp/r1;mkfifo /tmp/r2;mkfifo
/tmp/r3;"
2. Used "tee -a" to write a copy of data to each of these - "(while [ 1
]; do date; sleep 1; done ) | tee -a /tmp/r1 | tee -a /
Del,
I just did a simple test, that might help you to a solution
1. Used mkfifo to create 3 pipes "mkfifo /tmp/r1;mkfifo /tmp/r2;mkfifo
/tmp/r3;"
2. Used "tee -a" to write a copy of data to each of these - "(while [ 1 ];
do date; sleep 1; done ) | tee -a /tmp/r1 | tee -a /tmp/r2 | tee -a
/tmp/r3
Del wrote:
Hi,
Does anyone have a solution to this problem?
I have a serial port (connected to a GPS at 4800 baud). I have
multiple processes that need to read from that serial port. I need
all of the processes to read the same data, essentially creating a one
way chat from the serial por
Hi,
Does anyone have a solution to this problem?
I have a serial port (connected to a GPS at 4800 baud). I have multiple
processes that need to read from that serial port. I need all of the
processes to read the same data, essentially creating a one way chat
from the serial port to all pro
12 matches
Mail list logo
