Monitor RS232 comms with millisecond resolution
in [Embedded]
|
Prev: MAKE UPTO $5000 PER MONTH! $2000 IN FIRST 20 DAYS!
Next: Dexcel Electronics Designs is Hiring in Chennai
From: David Brown on 22 Jun 2010 10:04 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.
From: Grant Edwards on 22 Jun 2010 10:05 On 2010-06-22, Stef <stef33d(a)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!!
From: Stef on 22 Jun 2010 10:22 In comp.arch.embedded, Grant Edwards <invalid(a)invalid.invalid> wrote: > On 2010-06-22, Stef <stef33d(a)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.
From: Andrew Jackson on 22 Jun 2010 10:28 >> 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
From: Peter Greuter on 22 Jun 2010 10:43
Hello Le Tue, 22 Jun 2010 14:03:01 +0000 (UTC), Grant Edwards <invalid(a)invalid.invalid> a �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 |