Monitor RS232 comms with millisecond resolution

On 2010-06-22, Rowan Sylvester-Bradley <rowan@sylvester-bradley.org> wrote:

> One other thing I learned - the Saleae logic analyser looks a really 
> interesting device for a very good price - I think I may get one of
> those...

It does look like an excellent deal.  I was especially impressed that
they plan to support Linux.  It would be nice if it worked with lower
voltages (some projects I've worked with ran at <2V), but that might
be a bit too much to expect for the price.

-- 
Grant Edwards               grant.b.edwards        Yow! HELLO, everybody,
                                  at               I'm a HUMAN!!
                              gmail.com            

On 2010-06-22, Peter Greuter <spam1.greuter@free.fr> wrote:
> Hello 
>
> Le Tue, 22 Jun 2010 10:33:29 +0100, "Rowan Sylvester-Bradley"
><rowan@sylvester-bradley.org> a ?crit :
>
> ....
>
>> - The standard ISA or motherboard serial port can't do 62,500 baud.
>
> I am surprised that nobody reacted to this statement : as always it
> depends a lot on the programs involved !

No, it dosn't.

> But for instance under MS-DOS it is possible to reprogram the
> baudrate divider of a typical 16X50 UART by sending just two bytes to
> two output port registers after the initialisation sequence to get
> more than the standard baudrates.

Except there _is_ no divisor that will give you 62500.  The clock
input to a PC UART is 1.8432 MHz.  The baud clock needs to be 16x the
baud rate.

   Divisor      Baud

      1        115200
      2         57600
      3         38400
      4         28800
     ...          ...

Please explain how you write a divisor value of 1.8432 to the divisor
register.  

-- 
Grant Edwards               grant.b.edwards        Yow! Make me look like
                                  at               LINDA RONSTADT again!!
                              gmail.com            

On 22/06/2010 15:30, Andrew Jackson wrote:
>>> - Windows can't do what I want, or at least not without a huge amount of
>>> work trying to get the most accurate timestamps possible, and even
>>> then it
>>> would be only barely good enough.
>>
>> If accurate timestamps were your only concern on Windows that should
>> not be
>> a problem. On modern PCs it is fairly easy to implement a high resolution
>> timer with approximately microsecond resolution using the
>> QueryPerformanceCounter / QueryPerformanceFrequency Windows API
>> functions.
>
> That's not entirely true if you are using a multi-core CPU. You will
> need to lock the time-stamping thread to one particular core otherwise
> you may get differences between the time-stamps. This is because Windows
> doesn't synchronise the timestamp values between cores.
>
> You can also use the multimedia API (timeGetTime & friends) to get
> millisecond accuracy but you must then ensure that the thread says that
> it wants this sort of resolution with timeBeginPeriod. I've found
> though, that some machines only timestamp to 2ms even though 1ms has
> specified.
>
> Andrew

When you have multimedia playing, the OS changes the timer resolution. 
If you are relying on it, you have to be very careful about what else on 
the PC might be changing the resolution.

A bizarre consequence of this is that if you are using standard windows 
timer APIs, you can get more accurate timing as long as you play a movie 
on the machine...  Only in the windows world!


And at best, all you can get is a timestamp of when the call to the 
timestamp function took place.  You have no way of controlling the 
reaction time between a character coming into the uart, and your user 
code seeing that character.  Add to that the fact that your thread can 
be interrupted at any time, and pre-empted for unpredictable times (even 
if your thread is given "real time" priority), and you can't get any 
guarantees about the timing accuracy.  If you only need the timings to 
be mostly correct most of the time, it's probably okay to within about 
10 ms.  With commercial real-time addons for windows, you can get a bit 
more reliability and accuracy - probably in the 1 ms range (though I 
have never used such addons).

With Linux and a kernel with real-time enabled (many distro's enable it 
by default, I think, or at least have a real-time kernel in their 
repositories) will easily give you sub-ms sampling and accuracy.  Of 
course, it still won't let your PC uart handle the non-standard baud rates.

On 2010-06-22, Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:

[regarding RS485]

>> The "A" side of the differential signal should be the inverted signal just
>> so it will work with single ended signals.  
>
> Ah, the confusion of the A and B line that anyone who has ever done
> anything with RS485 has run in to and into which will run all who are
> going to use RS485 to eternity.
>
> Probably all due to a mistake in the original 75176, see for example:
> http://www.embeddedrelated.com/usenet/embedded/show/2056-1.php

If you're using products from two different vendors, then just hook it
up.  If it doesn't work, then switch the wires.  Seriously, the labels
on RS485 terminals might as well be random...

-- 
Grant Edwards               grant.b.edwards        Yow! I'm having a
                                  at               tax-deductible experience!
                              gmail.com            I need an energy crunch!!

In comp.arch.embedded,
Grant Edwards <invalid@invalid.invalid> wrote:
> On 2010-06-22, Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:
>
> [regarding RS485]
>
>>> The "A" side of the differential signal should be the inverted signal just
>>> so it will work with single ended signals.  
>>
>> Ah, the confusion of the A and B line that anyone who has ever done
>> anything with RS485 has run in to and into which will run all who are
>> going to use RS485 to eternity.
>>
>> Probably all due to a mistake in the original 75176, see for example:
>> http://www.embeddedrelated.com/usenet/embedded/show/2056-1.php
>
> If you're using products from two different vendors, then just hook it
> up.  If it doesn't work, then switch the wires.  Seriously, the labels
> on RS485 terminals might as well be random...

And if you ship RS485 equipment and write a manual, or write in-house
wiring instructions, put something along those lines in the manual
without making it sound too stupid. ;-)


-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

A mushroom cloud has no silver lining.

>> You can also use the multimedia API (timeGetTime & friends) to get
>> millisecond accuracy but you must then ensure that the thread says that
>> it wants this sort of resolution with timeBeginPeriod. I've found
>> though, that some machines only timestamp to 2ms even though 1ms has
>> specified.
>
> When you have multimedia playing, the OS changes the timer resolution.
> If you are relying on it, you have to be very careful about what else on
> the PC might be changing the resolution.

That is why you need to call timeBeginPeriod to "lock" the resolution to 
that which you require!

> A bizarre consequence of this is that if you are using standard windows
> timer APIs, you can get more accurate timing as long as you play a movie
> on the machine... Only in the windows world!

Wait until you play with WASAPI on Windows 7/Vista.

> And at best, all you can get is a timestamp of when the call to the
> timestamp function took place. You have no way of controlling the
> reaction time between a character coming into the uart, and your user
> code seeing that character. Add to that the fact that your thread can be
> interrupted at any time, and pre-empted for unpredictable times (even if
> your thread is given "real time" priority), and you can't get any
> guarantees about the timing accuracy. If you only need the timings to be
> mostly correct most of the time, it's probably okay to within about 10
> ms. With commercial real-time addons for windows, you can get a bit more
> reliability and accuracy - probably in the 1 ms range (though I have
> never used such addons).

That's correct: I wasn't defending Windows, merely pointing out some 
functions that might be appropriate.

> With Linux and a kernel with real-time enabled (many distro's enable it
> by default, I think, or at least have a real-time kernel in their
> repositories) will easily give you sub-ms sampling and accuracy. Of
> course, it still won't let your PC uart handle the non-standard baud rates.

No, but Linux would be a lot easier.  One could write a time-stamping 
line discipline, for example, fairly easily.

	Andrew

Hello
Le Tue, 22 Jun 2010 14:03:01 +0000 (UTC), Grant Edwards
<invalid@invalid.invalid> a &#4294967295;crit :

>Except there _is_ no divisor that will give you 62500.  The clock
>input to a PC UART is 1.8432 MHz.  The baud clock needs to be 16x the
>baud rate.
>
>   Divisor      Baud
>
>      1        115200
>      2         57600
>      3         38400
>      4         28800
>     ...          ...
>
>Please explain how you write a divisor value of 1.8432 to the divisor
>register.  

eventually my fault :-(

I read in the OP post "(actually I'm snooping on an RS485 bus)." 
so I thought about a (PCI) RS485 card.

The one I am using comes from VScom and has a high-speed option to
permit 921 600 bd so there must be a way to write 8 x 1.8432 
~15 to some registers but I didn't find the corresponding API in
their manual :-(  I found only the sentence :

"The 16C950 UART used on the H-series cards has some hardware
option to get very high bit rates, up to 3.6 Mbps. Of course these
bit rates can not be used on RS 232, but there are other
advantages. The maximum serial speed is raised, so there are more
possible bit rates available in the usual range of RS 232
transmission. This allows to use some more rather unusual settings
for transmission rates, some special hardware may require." 

I think that other RS485 cards for PCs aren't either limited to 
115 200 bd, really low for RS485 ;-) 

My big fault : I didn't notice

> old PC with a "real" serial port

that probably means a standard RS232 port, may be even with a
INS8250 UART limited to 57 600 bd  ;-) 

Kind regards from France

Peter Greuter

On Jun 22, 7:09=A0am, Tauno Voipio <tauno.voi...@notused.fi.invalid>
wrote:
> MS-DOS in no solution, either. It uses BIOS for I/O, and the BIOS
> contains so long interrupt disables that the required timing
> resolution is not reliably available.

It would be highly unusual for a DOS based program to use the BIOS for
serial I/O.  I think MS-Kermit had the option to do so but it was not
the normal default.

A few would use the BIOS for setup, but serial I/O bypassed the BIOS
and was usually, but not always, interrupt driven.

Robert

Robert Adsett wrote:

> On Jun 22, 7:09 am, Tauno Voipio <tauno.voi...@notused.fi.invalid>
> wrote:
> 
>>MS-DOS in no solution, either. It uses BIOS for I/O, and the BIOS
>>contains so long interrupt disables that the required timing
>>resolution is not reliably available.
> 
> 
> It would be highly unusual for a DOS based program to use the BIOS for
> serial I/O.  I think MS-Kermit had the option to do so but it was not
> the normal default.
> 
> A few would use the BIOS for setup, but serial I/O bypassed the BIOS
> and was usually, but not always, interrupt driven.

You are right about very primitive support for the serial I/O in BIOS, 
and that it was (almost) never used. However Tauno mentioned long 
interrupt disables in the BIOS (for entire HDD sector transfer 
operation, for example) that could disrupt timing if you have to go 
through any MSDOS or BIOS function.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

On Jun 22, 8:47=A0am, "Boudewijn Dijkstra"
<sp4mtr4p.boudew...@indes.com> wrote:
> Op Tue, 22 Jun 2010 13:09:52 +0200 schreef Tauno Voipio =A0
> <tauno.voi...@notused.fi.invalid>:
>
>
>
>
>
> > On 22.6.10 1:35 , Peter Greuter wrote:
> >> Le Tue, 22 Jun 2010 10:33:29 +0100, "Rowan Sylvester-Bradley"
> >> <ro...@sylvester-bradley.org> =A0a crit :
>
> >> ....
>
> >>> - The standard ISA or motherboard serial port can't do 62,500 baud.
>
> >> I am surprised that nobody reacted to this statement : as always it
> >> depends a lot on the programs involved ! But for instance under
> >> MS-DOS it is possible to reprogram the baudrate divider of a
> >> typical 16X50 UART by sending just two bytes to two output port
> >> registers after the initialisation sequence to get more than the
> >> standard baudrates. The {COMMO} communication program by Fred P.
> >> Brucker included this possibility in the later version in the setup
> >> part.
>
> > Forget the PC.
>
> > 62500 bit/s needs a raw clock of 1.000 MHz, which is not available
> > by any integer divider from 18.432 MHz
>
> Dividing by 18 yields 1.024 which is only 2.4% off.


Which is problematically far off, unless you can guarantee that the
sender is no more than about 1.3% off in the other direction (slower
than spec).  Obviously if the sender is off in the same direction,
there's considerably more slack).