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: Robert Adsett on 22 Jun 2010 15:42 On Jun 22, 7:09 am, Tauno Voipio <tauno.voi...(a)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
From: Vladimir Vassilevsky on 22 Jun 2010 15:57 Robert Adsett wrote: > On Jun 22, 7:09 am, Tauno Voipio <tauno.voi...(a)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
From: robertwessel2 on 22 Jun 2010 19:44 On Jun 22, 8:47 am, "Boudewijn Dijkstra" <sp4mtr4p.boudew...(a)indes.com> wrote: > Op Tue, 22 Jun 2010 13:09:52 +0200 schreef Tauno Voipio > <tauno.voi...(a)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...(a)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 ! 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).
From: -jg on 22 Jun 2010 21:54 On Jun 22, 9:33 pm, "Rowan Sylvester-Bradley" <ro...(a)sylvester- bradley.org> wrote: > - I'm therefore best to use a simple free standing PCB with a > microprocessor with a RTC and two serial ports capable of flexible baud > rates. One runs at 62,500 baud and receives the characters from the RS485 > bus. The other runs at 115,200 baud or higher and sends to the PC. The > receive interrupt handler receives the bytes, timestamps them and writes > them into a buffer. The main program reformats the bytes and timestamps in a > form suitable for the PC and writes them into an output buffer. The send > interrupt handler sends them to the PC. Avoiding the PC as the timer is a good idea, but you maybe able to simplify your Dual-UART code, if you simply arrange to SEND one 115200 Bd byte, every 100us. That gives you 11.52 bit times, or 1.52 stop bits with parity. ( > 1 stop bit is a good idea if running continual streams anyway) Code is then very simple, and time is implicit : IF the RS485 has data THEN send it on, with parity set, ELSE send a time-check value, with parity unset. Simple place counting at the Bucket arrival rate gives you the time to 0.1ms, and you can go better if you use the time-values to indicate actual arrival times. (tho you can't quite tag every byte with 8 bits, but could tag every byte to 4 bits, to resolve to 6.25us, getting close to the best possible start bit precision, and finer than the likely host TxClock) Each incoming 16 byte block, can contain up to 10 RS485 bytes and 6 time stamps, and has a time-width of 1.6000ms. -jg
From: Paul Keinanen on 23 Jun 2010 01:29
On Tue, 22 Jun 2010 16:44:24 -0700 (PDT), "robertwessel2(a)yahoo.com" <robertwessel2(a)yahoo.com> wrote: >On Jun 22, 8:47�am, "Boudewijn Dijkstra" ><sp4mtr4p.boudew...(a)indes.com> wrote: >> Op Tue, 22 Jun 2010 13:09:52 +0200 schreef Tauno Voipio � >> <tauno.voi...(a)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...(a)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 ! 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). Since the OP required receive only capability, configure the actual data network with 2 stop bits and the monitoring receiver with 1 stop bit. In asynchronous mode, the synchronization occurs at the leading end of the start bit, defining the sampling point in the middle of the actual data bits. With a clock frequency error, the sampling point moves away from the middle of the bit and in the worst case falls into the next/previous data bit. With two stop bits transmitted, there is a larger distance between the start bits of two bytes. When the receiver expects only one stop bit, the actual sampling point for the first (and only) stop bit can fall outside the actual first start bit transmitted into the second stop bit transmitted. This is quite OK and the receiver enters the idle state, waiting for the next proper start bit. |