Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
Per Westermark
06/16/10 05:38
Read: 572 times
Sweden


 
#176722 - Timing just depends on OS and where the data is sampled
Responding to: Oliver Sedlacek's previous message
With the user-space UART API in Windows, I get 32ms timing resolution (this is the normal timeslice length for the Windows scheduler) which can be a problem for faster protocols that are character-based and not packet based, or that is running concurrent transfers.

Running kernel-space drivers in Linux or running MS-DOS (or writing a driver for Windows), it's possible to handle timing with magnitudes better resolution, making it easy to keep track of individual characters in full-duplex transfers. An ISR isn't limited by the timeslice granularity of any OS, but just by how long the OS or other drivers may block interrupts from getting serviced. A PC with a PCI board with two or four UART is a very good solution. And having way more RAM - and also disk - means it can not only detect received characters or toggled handshake signals with good resolution. It can also save very large logs for later post-processing.

I also have access to PPC-based embedded platforms where I can turn off the FIFO and process the data for two external ports directly in the ISR. No significant difference from a PC, except that they are more the size of a small network switch and consumes way less power than a PC.

List of 23 messages in thread
TopicAuthorDate
Serial Port monitor software      David Good      06/15/10 13:42      
   Docklight      Rob Klein      06/15/10 14:00      
      I use...      Michael Karas      06/15/10 20:49      
   monitor and control      Juergen Christoph      06/16/10 02:14      
      br@y terminal??      Jerson Fernandes      06/16/10 02:31      
         But that's "just" (sic?) another terminal, surely?      Andy Neil      06/16/10 03:25      
      RE: Portmon from Sysinternals      Andy Neil      06/16/10 02:35      
         "pi" cable and two serial ports to log rx and tx      Per Westermark      06/16/10 03:23      
            OK for simple data logging...      Andy Neil      06/16/10 03:27      
               timing etc is just a question of program and OS      Per Westermark      06/16/10 03:56      
            Command-response sync?      Oliver Sedlacek      06/16/10 04:41      
               Don't blame windows here!      Andy Neil      06/16/10 05:14      
                  Don't blame the driver or the adapter      Justin Fontes      06/17/10 14:58      
                     Eh?      Andy Neil      06/17/10 16:42      
                        Huge FIFO because max baudrate also much higher      Per Westermark      06/18/10 02:49      
                  USB-Windows-drivers      Oliver Sedlacek      06/18/10 08:01      
                     Digressing: Multiple USB-to-Serial      Andy Neil      06/18/10 08:24      
                        Digressing Further...      Michael Karas      06/19/10 06:57      
                        Nice      Oliver Sedlacek      06/21/10 02:10      
                           RE: It's a shame I can't tell the service guys what to buy      Andy Neil      06/21/10 02:28      
               8052-based analyser      Andy Neil      06/16/10 05:18      
               Timing just depends on OS and where the data is sampled      Per Westermark      06/16/10 05:38      
      Scripting for development and testing      David Good      06/18/10 10:10      

Back to Subject List