Re: [Flightgear-devel] Serial port programming question ...
Curtis Olson wrote: This is a little off topic, but I don't know where else I can find a stronger knowledge pool. :-) I am working on some code that needs to read and write from a serial port and has to write vast quantities of data ... Curtis, I wouldn't use threads, but a whole separated process. Use circular buffers in shared memory to transfer data, and semaphores to coordinate data transfers in/from these buffers. That way your main process only needs to do non-blocking memory to memory transfers. The serial coms process can handle all the quirks of the protocol, create separate Tx and Rx threads if necessary, decide when to drop data, block itself when needed etc. One of the advantages of using a separate process vs threads in the main application is fault isolation. (1) The unavoidable crashes during development may bring down only this process, allowing you to continue by restarting only this part and not the whole application. The same applies if you want to try a different version. Stop the subprocess, start a new one. Hope this helps, Roberto Waltman. (1) I worked for a company whose coding standards required a manager's waiver to use threads, because of the difficulties of debugging complex multi-thread applications where every thread can corrupt global data. And the fault isolation. -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Serial port programming question ...
Hi Jacob, Thanks for the reply, I've got a couple options to consider so hopefully I can get something that works here pretty quickly. Best regards, Curt. On Fri, Aug 27, 2010 at 10:44 PM, Jacob Burbach jmburb...@gmail.com wrote: I know I can use select() to check if the file descriptor is ready for a write(), but that would still not be a way to determine if the file descriptor is ready for the size of my particular write() and ensure that my write() will return in a timely fashion ... it seems like it would still leave me open for potential trouble or potential unwanted time delays. I'm no expert and can't answer all your questions or give best design advice...but. If your using non blocking IO and select signals a write is available, then that write should always return in a timely fashion. Like you said there though, select won't tell you how much can be written, nor does the write call guarantee it will write everything you give it. As usual when doing non-blocking asynchronous type stuff, it will be up to you to do the book keeping and send any remaining data in subsequent writes. Though I seem to recall there may be some ioctl calls available that actually tell you how much data is ready for reading or writing on a file descriptor, but can't recall off hand...may well be platform/os/arch specific. cheers -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Serial port programming question ...
Hi Roberto, Thanks for the reply and the suggestions. I'm very nervous about giving myself a threading waver too! :-) I am leaning towards an independent process/app to handle just the serial comms and exchange that will communicate via some IPC mechanism with my main application. There are some messy aspects no matter how I proceed. - If I leave things as is, I have to live with some long program pauses and because this is a real time sensing and control application, that leads to some less than optimal results at time. On the plus side I keep a straight linear application that is easy to understand and maintain. - If I go with a threaded solution I maintain potential portability to embedded systems that are not unix based and perhaps only support a single process (with multiple threads.) But of course all the pitfalls of threads and long term maintainability apply. And there are many misunderstandings of threads and what they can do. I've seen times that a thread blocking on IO can block the entire application anyway. Certainly a thread that crashes or executes a bad instruction will kill the entire application. - If I go with a separate application, I push myself towards linux based systems only, or systems with advanced kernels that support multiple concurrent processes. There are also so possible messy startup issues to think through (I have to start multiple processes rather than a single process, although one process could launch the other I suppose.) I also have to decide what IPC mechanism to use ... I like the idea of using sockets, partially due to existing available socket communication mechanisms already built into my code and it fits the FIFO nature of my task pretty well. I spew data packets out and I don't care if random packets are dropped or corrupted (as long as an appropriate amount get through for the bandwidth of my serial link.) And the return data is infrequent commands which might be more appropriate as a stream socket connection (which I already have support for in my code.) Best regards, Curt. On Sat, Aug 28, 2010 at 7:23 AM, Roberto Waltman f...@rwaltman.com wrote: Curtis Olson wrote: This is a little off topic, but I don't know where else I can find a stronger knowledge pool. :-) I am working on some code that needs to read and write from a serial port and has to write vast quantities of data ... Curtis, I wouldn't use threads, but a whole separated process. Use circular buffers in shared memory to transfer data, and semaphores to coordinate data transfers in/from these buffers. That way your main process only needs to do non-blocking memory to memory transfers. The serial coms process can handle all the quirks of the protocol, create separate Tx and Rx threads if necessary, decide when to drop data, block itself when needed etc. One of the advantages of using a separate process vs threads in the main application is fault isolation. (1) The unavoidable crashes during development may bring down only this process, allowing you to continue by restarting only this part and not the whole application. The same applies if you want to try a different version. Stop the subprocess, start a new one. Hope this helps, Roberto Waltman. (1) I worked for a company whose coding standards required a manager's waiver to use threads, because of the difficulties of debugging complex multi-thread applications where every thread can corrupt global data. And the fault isolation. -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Serial port programming question ...
This is a little off topic, but I don't know where else I can find a stronger knowledge pool. :-) I am working on some code that needs to read and write from a serial port and has to write vast quantities of data ... to the point that the line is fully saturated or close to it as I can get. I have to read *and* write to the port. I don't care so much if I drop some data once in a while. I have been trying to avoid threads in this code to keep things simple and linear, so I have been using non-blocking IO. However, as I read through the available serial programming documentation, it is becoming more and more clear that non-blocking serial IO seems to refer primarily to the read() operation and the write() operation has different semantics. What I am finding with my actual code is that the write() operation can sometimes take a long time, even on a file descriptor that is configured for non-blocking IO. My main loop runs at 50hz (0.02 seconds per iteration) but I am seeing some serial port writes that can take 0.2 or 0.3 seconds and every once in a while the whole thing gets stopped up and my whole write blocks (including the entire application) until the other end stuffs at least another character up the pipeline in my direction. This situation is starting to become unacceptable. The quick answer I know would be to spawn off a pthread and handling the serial IO in a separate thread. But I am trying to avoid adding threads to this code like a person might try to avoid knee replacement surgery. I know I can use select() to check if the file descriptor is ready for a write(), but that would still not be a way to determine if the file descriptor is ready for the size of my particular write() and ensure that my write() will return in a timely fashion ... it seems like it would still leave me open for potential trouble or potential unwanted time delays. Does anyone have any thoughts or suggestions. The programming environment is linux, the code is actually being developed primarily to run on a gumstix embedded processor, but of course the more portable, the better. Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Serial port programming question ...
I know I can use select() to check if the file descriptor is ready for a write(), but that would still not be a way to determine if the file descriptor is ready for the size of my particular write() and ensure that my write() will return in a timely fashion ... it seems like it would still leave me open for potential trouble or potential unwanted time delays. I'm no expert and can't answer all your questions or give best design advice...but. If your using non blocking IO and select signals a write is available, then that write should always return in a timely fashion. Like you said there though, select won't tell you how much can be written, nor does the write call guarantee it will write everything you give it. As usual when doing non-blocking asynchronous type stuff, it will be up to you to do the book keeping and send any remaining data in subsequent writes. Though I seem to recall there may be some ioctl calls available that actually tell you how much data is ready for reading or writing on a file descriptor, but can't recall off hand...may well be platform/os/arch specific. cheers -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
