Monitor RS232 comms with millisecond resolution
rowan.bradley
and timestamping each byte with a resolution of at least 1ms (preferably
finer)? I can only find cheap or free programs with less resolution, or
very expensive solutions, often involving special hardware.
I only need to monitor one port, and I don't need to send any characters
(actually I'm snooping on an RS485 bus).
I'm prepared to use an old PC with a "real" serial port, run MSDOS, Linux
or whatever other OS will do the job, use some sort of microprocessor to
capture the data (preferably one I'm familiar with, such as 8051 family or
PIC) or anything else so long as it's quick and cheap. I just need to get
the job done, preferably tomorrow!
If possible I'd like it to run at a non-standard baud rate (62,500 baud).
Thanks - Rowan
---------------------------------------
Posted through http://www.EmbeddedRelated.com
Grant Edwards
> Anyone know the quickest or easiest way of recording a serial data
> stream and timestamping each byte with a resolution of at least 1ms
> (preferably finer)? I can only find cheap or free programs with less
> resolution, or very expensive solutions, often involving special
> hardware.
>
> I only need to monitor one port, and I don't need to send any
> characters (actually I'm snooping on an RS485 bus).
>
> I'm prepared to use an old PC with a "real" serial port, run MSDOS,
> Linux or whatever other OS will do the job, use some sort of
> microprocessor to capture the data (preferably one I'm familiar with,
> such as 8051 family or PIC) or anything else so long as it's quick
> and cheap. I just need to get the job done, preferably tomorrow!
Greeleaf used to sell a serial data analyzer program for DOS. It even
came with a Y-cable so that you could monitor two data lines. In my
experience, it's either that or something hardware-based. If you find
a good solution let us know.
> If possible I'd like it to run at a non-standard baud rate (62,500 baud).
--
Grant
Tim Wescott
> Anyone know the quickest or easiest way of recording a serial data stream
> and timestamping each byte with a resolution of at least 1ms (preferably
> finer)? I can only find cheap or free programs with less resolution, or
> very expensive solutions, often involving special hardware.
The problem is in the limitations of Windows (and most flavors of Linux
as well). The underlying assumption when talking to a serial port is
that (a) the hardware will queue up some of the data for you, and (b)
the user just wants to download porn from the internet, and doesn't
particularly care about the exact timing of the bits. Even users that
are nutcases and want to download stuff from the internet that _isn't_
port _still_ just want to check out the latest political flame on their
technical newsgroups, and don't much care exactly what millisecond the
period at the end of the sentence arrived.
So the driver is optimized to catch every bit of those jpegs that your
wife would rather you didn't download, but has no effort whatever put
into actually timing the arrival of the latest byte. In fact, the best
that you can do without extraordinary effort is for whatever user-space
application is running to log the time that it processes the bytes --
and that's not very precise at all.
Hence the special hardware...
> I only need to monitor one port, and I don't need to send any characters
> (actually I'm snooping on an RS485 bus).
>
> I'm prepared to use an old PC with a "real" serial port, run MSDOS, Linux
> or whatever other OS will do the job,
MSDOS and a custom program would give you your best bet on a PC, but
it'd have to be dedicated hardware, not running in a window or a virtual
machine or anything.
> use some sort of microprocessor to
> capture the data (preferably one I'm familiar with, such as 8051 family or
> PIC) or anything else so long as it's quick and cheap.
With something like a PIC or an 8051 it's much easier -- don't have any
other software running, have a _really fast_ loop that polls the serial
port, and log the time (I'm assuming it's a processor with at timer)
that the data arrives.
Note that this is basically what you'd have to do on the PC, as well.
> I just need to get
> the job done, preferably tomorrow!
The technically best solution would probably be an FPGA that logs the
arrival time of each byte, and stores a queue of bytes and timestamps --
good gawd, what a pain that would be!
But in the mean time, you either need to luck out big time, or start
flogging PIC software.
> If possible I'd like it to run at a non-standard baud rate (62,500 baud).
Depending on the UART, a PIC may be a help here, too.
--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com
Paul Probert
sells (has an ftdi chip on it). Then get a dev board with an atmega128
(or any micro with 2 serial ports). Hook up the rs485 to a transceiver
such as a 75176, then to one of the micro's serial ports. The other port
you connect to your usb board. Write a small program that receives the
bytes, adds the timestamp, then writes it out over the second port
(which you can run at a few hundred kilobaud to keep up). On the pc
side, my favorite way to do it is to write a python program, using
pyserial to read the port. This can easily keep up with 1 megabaud on a
reasonable PC.
This system would be able to generate the timestamp within a few
microseconds of the byte's arrival, limited by your micro's (and C
compiler's, if you use C) interrupt latency.
Paul Probert
Chris Burrows
news:EpmdnWB348YFOIPR...@giganews.com...
> Anyone know the quickest or easiest way of recording a serial data stream
> and timestamping each byte with a resolution of at least 1ms (preferably
> finer)?
How much data do you need to store at a time?
>, use some sort of microprocessor to
> capture the data (preferably one I'm familiar with, such as 8051 family or
> PIC)
If I was doing it I would use a low-cost (< $100) off-the-shelf ARM
development board - but that is because I could program it much more quickly
and easily than an 8051 or a PIC as I already have most of the code written.
> or anything else so long as it's quick and cheap.
define 'cheap'
> I just need to get
> the job done, preferably tomorrow!
>
Doesn't sound too difficult - unless I'm missing something?
> If possible I'd like it to run at a non-standard baud rate (62,500 baud).
>
I'm not certain that is possible with what I have in mind but am optimistic.
--
Chris Burrows
CFB Software
Astrobe: ARM Oberon-07 Development System
http://www.astrobe.com
Paul Keinanen
<rowan@n_o_s_p_a_m.sylvester-bradley.org> wrote:
>
>I'm prepared to use an old PC with a "real" serial port, run MSDOS, Linux
>or whatever other OS will do the job, use some sort of microprocessor to
>capture the data (preferably one I'm familiar with, such as 8051 family or
>PIC) or anything else so long as it's quick and cheap. I just need to get
>the job done, preferably tomorrow!
You can get quite accurate time stamps by disabling the UART FIFO and
assuming you are on a Pentium or newer processor with the RDTSC
instruction, read the Time Stamp Counter in the Rx interrupt routine,
first put the received byte in the software Rx queue, followed by 8
bytes from the TSC.
On the user mode side, read 9 bytes at a time, the first being the
actual byte received, the rest the time stamp. To convert the TSC to
milliseconds, you have to know (or measure) the CPU clock frequency.
With the UART FIFO disabled, the maximum baud rate depends on the
interrupt latency of the system, e.g. for how long the interrupts are
disabled. Also some peripherals (such as graphic cards, ethernet or
IDE controllers) may effectively block interrupts for a long time,
however, the situation has improved a lot since the 1990's.
D Yuniskis
rowan.bradley wrote:
> Anyone know the quickest or easiest way of recording a serial data stream
> and timestamping each byte with a resolution of at least 1ms (preferably
> finer)? I can only find cheap or free programs with less resolution, or
> very expensive solutions, often involving special hardware.
>
> I only need to monitor one port, and I don't need to send any characters
> (actually I'm snooping on an RS485 bus).
Are you actually interested in *every* byte or just "certain"
bytes (e.g., are you looking at, perhaps, the timing of *messages*?)
> I'm prepared to use an old PC with a "real" serial port, run MSDOS, Linux
> or whatever other OS will do the job, use some sort of microprocessor to
> capture the data (preferably one I'm familiar with, such as 8051 family or
> PIC) or anything else so long as it's quick and cheap. I just need to get
> the job done, preferably tomorrow!
If you can find something that you can easily write / deploy code
on, this is a one page program.
> If possible I'd like it to run at a non-standard baud rate (62,500 baud).
IIRC, a "real PC" will give you problems hitting 62,500.
I think the baud rate clock is fed from too low of a frequency
to give you enough precision to hit "any" baudrate you want
(esp at higher rates, obviously)
Jon Kirwan
<rowan@n_o_s_p_a_m.sylvester-bradley.org> wrote:
>Anyone know the quickest or easiest way of recording a serial data stream
>and timestamping each byte with a resolution of at least 1ms (preferably
>finer)? I can only find cheap or free programs with less resolution, or
>very expensive solutions, often involving special hardware.
>
>I only need to monitor one port, and I don't need to send any characters
>(actually I'm snooping on an RS485 bus).
>
>I'm prepared to use an old PC with a "real" serial port, run MSDOS, Linux
>or whatever other OS will do the job, use some sort of microprocessor to
>capture the data (preferably one I'm familiar with, such as 8051 family or
>PIC) or anything else so long as it's quick and cheap. I just need to get
>the job done, preferably tomorrow!
>
>If possible I'd like it to run at a non-standard baud rate (62,500 baud).
I'm not sure an IBM PC uart can run at that rate. I think
57600 is doable, though. Something that bothers me about
your request is this 1ms resolution. At 62500 bps, one stop
and one start, this is 6250 cps. That works out to 160us per
character. Yet you don't seem to __require__ better than 1ms
resolution? (I do read you saying that you'd like better.)
Okay. None of that really helps. The IBM PC is everywhere,
so I understand that desire. But I don't think you can nail
the rate at 62500. If you can use 57600, I think that works
on the PC. There is a 16-bit timer on the PC. It doesn't
interrupt fast enough for you, but you can read it when the
characters arrive. So if you use DOS, write in assembly
code, can accept the 57600 bps rate, then it's doable. I
keep new boxes of DOS 5.0 laying about and 80386 and 80486
machines here with nice ISA buses, just for doing stuff like
this. But you may not have them. And new PCs seem to be
avoiding RS-232 ports more and more.
USB would barely get you by (one of those USB to RS-232
things), as I believe the max 'pace' is 1ms there. (I don't
know USB that well, but I disagree with Paul on this subject
unless you dig _really_ deep into the USB VxD level of
stuff.) In general, I don't know how closely you can track
it through through the HID driver and all of the Windows
layers. I'd probably avoid it, imagining the work there to
be way too much to bite off for too little potential.
Which gets to either someone's device you can buy -- you've
already looked -- or else something you pony up. I'd wire
something up from crap I have around here. Some don't have
the level shifters, but you are only looking to receive, not
send, so you can easily use a BJT and a few resistors there
(cheap and easy.) Software is extra, of course.
If you did have one of those USB-RS232 units and could wire
up to it (I got one included in the $24 MSP430 Chronos kit I
bought, for example), you might choose a micro with two UARTS
and wire one of them to the USB-RS232 connector and send
serial data in that direction that includes the received
characters and their time stamps for logging onto the PC and
wire the other one to monitor your 62500 bps line. Add time
stamps and send to the USB side. Not too much software that
way and you have a huge data logger, then. (You didn't
mention how much data must be logged, which is yet another
potential problem.)
Jon
Oliver Betz
>Anyone know the quickest or easiest way of recording a serial data stream
>and timestamping each byte with a resolution of at least 1ms (preferably
>finer)? I can only find cheap or free programs with less resolution, or
>very expensive solutions, often involving special hardware.
So you already checked all solutions listed on
http://wiki.oliverbetz.de/owiki.php/TerminalPrograms ?
Another possibility is http://www.tech-tools.com/dv_main.htm - it's
able to record and decode serial data and of course the resolution is
several orders of magnitude better than you require. Not cheap but a
good logic analyzer is often useful.
Oliver
--
Oliver Betz, Munich
despammed.com is broken, use Reply-To:
Paul Carpenter
rowan@n_o_s_p_a_m.sylvester-bradley.org says...
> Anyone know the quickest or easiest way of recording a serial data stream
> and timestamping each byte with a resolution of at least 1ms (preferably
> finer)? I can only find cheap or free programs with less resolution, or
> very expensive solutions, often involving special hardware.
Everything depends on many factors some of which are
1/ Do you want relative timestamp from power up or first byte received?
2/ Do you want linked timestamp (actual time) to some time stamp
reference (even one system's time clock)?
3/ With later mentioned 62500bps, your accuracy could end up +/-1ms
4/ Are you timestamping each byte, or a block of data?
5/ Are you timestamping the
- line start bit falling edge, middle or effective end
- line Stop bit effective rising edge, middle or effective end
- Byte coming out of a UART (with hardware latency from start bit)
effectively Data Ready flag, which becomes skewed even with two
or more bytes from double buffering or FIFOing and
software/interupt latency.
- Start/middle/end of any message block
6/ How much data are you expecting to capture per second/min
7/ How large a time stamp range do you need, i.e. do you need one that
runs for minutes, hours, days or longer. This affects the overhead
of any timestamp, the bigger it is the more to process. Also the more
bytes that have to be timestamped the larger the dataset.
> I only need to monitor one port, and I don't need to send any characters
> (actually I'm snooping on an RS485 bus).
>
> I'm prepared to use an old PC with a "real" serial port, run MSDOS, Linux
> or whatever other OS will do the job, use some sort of microprocessor to
> capture the data (preferably one I'm familiar with, such as 8051 family or
> PIC) or anything else so long as it's quick and cheap. I just need to get
> the job done, preferably tomorrow!
>
> If possible I'd like it to run at a non-standard baud rate (62,500 baud).
Using and external device will make getting that baud rate easy, how big
your data set is, the time stamp data has to be affects how much storage
buffering of data and in turn potentially latency for timing as recording
gets bigger. If on a PC the act of updating screen or saving some of the
data to disk could impact on recording timing on a heavily loaded link.
If you must timestamp every byte, I would consider a seven bit relative
time stamp between bytes, with MSB set as 1. Full time stamp always to
have MSB set to 0, thus huge amount of data set can saved if you need
a 4 byte or larger timestamp for the whole dataset. If time delta
greater than 127 steps, send full time stamp.
Even at 62500 bps, you are potentially storing 6250 bytes/second, with a
four byte timestamp on ech byte you are then storing 5 x as much data
EVERY second. This of course increases to 9x as much for 8 byte
timestamp. So your data storage, buffering and processing requirements
increase drastically for an external unit.
Mean while in a PC storing data to disk could cause gaps in time stamp
accuracy, depending on how good the disk drivers and hardware actually
are.
> Thanks - Rowan
>
> ---------------------------------------
> Posted through http://www.EmbeddedRelated.com
>
--
Paul Carpenter | pa...@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate
Stefan Brröring
> and timestamping each byte with a resolution of at least 1ms (preferably
> finer)? I can only find cheap or free programs with less resolution, or
> very expensive solutions, often involving special hardware.
>
> I only need to monitor one port, and I don't need to send any characters
> (actually I'm snooping on an RS485 bus).
>
> I'm prepared to use an old PC with a "real" serial port, run MSDOS, Linux
> or whatever other OS will do the job, use some sort of microprocessor to
> capture the data (preferably one I'm familiar with, such as 8051 family or
> PIC) or anything else so long as it's quick and cheap. I just need to get
> the job done, preferably tomorrow!
>
If you only want to analyse a serial data stream and if you are sure,
that the bits are correct, you can simply read the data with a PC.
I don?t think, that you need a microcontroller.
The simplest way is, you take the B wire (or D-) of the RS485 signal and
connect it via a 1K resistor with the RXD* line of the PC and the GND
line of your RS485 Device with the GND-Line of the PC-Com-Port. This is
electrically not ideal, but should normaly work. But You should not
connect the TXD* line (the one, where you see about -8V) of the PC to
the RS485 bus.
A better solution of course would be the use of a RS485 tranceiver which
is used only in read-mode, e.g. max485.
Now take a simple program, e.g. in Turbo-Pascal under DOS or Delphi
under Windows and record the data.
For a one-cannel solution, i would prefer delphi. For a two-channel
solution, where i need the timing between the two signals, it might be
better in DOS.
With some experience in serial communication, this should be done in
about half an hour.
With MSDOS or Windows, you can use every baudrate that is a
factor/divider of 115200.
best regards
Stefan DF9BI
Stef
Much cheaper and possibly enough for this job:
http://www.saleae.com/logic/
--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)
I'm having a tax-deductible experience! I need an energy crunch!!
Paul Carpenter
stef...@broering.de says...
Without changing system timing, MSDOS won't give you 1ms resolution
only 1/18.5 Hz. Not sure about all forms of Windows and system clock
resolution.
> best regards
>
> Stefan DF9BI
Grant Edwards
>> If possible I'd like it to run at a non-standard baud rate (62,500
>> baud).
>
> IIRC, a "real PC" will give you problems hitting 62,500.
> I think the baud rate clock is fed from too low of a frequency
> to give you enough precision to hit "any" baudrate you want
> (esp at higher rates, obviously)
You're right. A "standard" motherboard UART can't do 62.5K. It can do
57.6K and 115.2K, but nothing in between.
--
Grant Edwards grant.b.edwards Yow! I'm ANN LANDERS!!
at I can SHOPLIFT!!
gmail.com
Vladimir Vassilevsky
Grant Edwards wrote:
> On 2010-06-21, D Yuniskis <not.goi...@seen.com> wrote:
>
>
>>>If possible I'd like it to run at a non-standard baud rate (62,500
>>>baud).
>>
>>IIRC, a "real PC" will give you problems hitting 62,500.
>>I think the baud rate clock is fed from too low of a frequency
>>to give you enough precision to hit "any" baudrate you want
>>(esp at higher rates, obviously)
>
>
> You're right. A "standard" motherboard UART can't do 62.5K. It can do
> 57.6K and 115.2K, but nothing in between.
Load good old DOS, set up PC timer interrupt and do bit banging. You can
i/o at the standard LPT port as fast as ~1.5MHz or so.
Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com
WangoTango
I kind of scanned through he replies and I don't think I saw this
mentioned.
*IF* you don't have much data to dig through, or you have lots of time
on your hands, you can use a logic analyzer and get ns resolution if you
want. Many of them have settings to mark a channel as a serial input of
differing type, UART, I2C, SPI and so on, and then mark the data up
appropriately. All you need is access to the logic side of the
transceiver, or the logic signals for on board busses. I am only
mentioning it because I have used it for a very similar purpose. So, the
software the comes with the Digi View from Tech Tools will let you set
multiple inputs up as serial data with any baud rate and combo of start
and stop bits, parity and so on, and display the massaged data bytes
with full timing info available on every level transition, including the
start bit.
Jim
d_s_klein
Have you seen this: <http://www.232analyzer.com/232default.htm> ??
According to their hype, "All monitoring modes available in
232Analyzer software come with timestamps in milliseconds."
RK
Paul Keinanen
<rowan@n_o_s_p_a_m.sylvester-bradley.org> wrote:
>If possible I'd like it to run at a non-standard baud rate (62,500 baud).
Typically the UART requires a clock that is 16x the baud rate, thus,
for 62.5 kBaud, the crystal frequency would have to be multiple of 1
MHz.
Take some ISA/PCI UART board and replace the crystal (oscillator) with
one that oscillates on some exact MHz close to the original frequency
and adjust the divisor accordingly.
Anders
This little widget has proven *very* valuable to me:
http://www.saleae.com
I do a lot of communications development/debugging, and this thing is
FANTASTIC (no, I'm not affiliated with Saleae - just a happy customer ;)
</A>
Rowan Sylvester-Bradley
- 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.
- I could possibly do it on a PC with MSDOS, but I would effectively be
programming it as a microprocessor.
- The standard ISA or motherboard serial port can't do 62,500 baud.
- 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.
So long as the PC can keep up, either because the baud rate is high enough
or because there are sufficient gaps in the incoming data for the buffers to
empty (in practice the data comes in short bursts with gaps between so with
decent sized buffers this won't be a problem).
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...
Thanks again for a valuable discussion - Rowan
Peter Greuter
Le Tue, 22 Jun 2010 10:33:29 +0100, "Rowan Sylvester-Bradley"
<ro...@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.
Kind regards from France
Peter Greuter
--
my oldies at http://www.teaser.fr/u/pgreuter/albumel.htm
Tauno Voipio
> Hello
>
> Le Tue, 22 Jun 2010 10:33:29 +0100, "Rowan Sylvester-Bradley"
> <ro...@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 (even less from the old
1.8432 MHz crystal).
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.
--
Tauno Voipio
tauno voipio (at) iki fi
gnuarm
The "A" side of the differential signal should be the inverted signal just
so it will work with single ended signals.
Rick
Rich Webb
<ro...@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...
There are a wide variety of capabilities in the domain of USB logic
analyzers. Be sure to read the specs on the Saleae and ensure that it
can support the tasks you want to use it for. For example, its input
voltage range is -0.5 to 5.25 V. It may become unhappy if it's connected
directly to a +/- 7 (or +/- 12!) RS-232 line.
--
Rich Webb Norfolk, VA
Hans-Bernhard Bröker
> I am surprised that nobody reacted to this statement : as always it
> depends a lot on the programs involved !
It does, but not quite as much as you think it does.
> But for instance under
> MS-DOS it is possible to reprogram the baudrate divider of a
> typical 16X50 UART
Of course it is. But that doesn't lift restrictions given by the quartz
the UART runs off. Ever wondered where those strange numbers like
115200, 57600, etc., come from? They're integer dividers of the PC's
original quartz frequency of 1.8432 MHz, divided by 16 for oversampling.
62500 Baud is not, and no achievable baud rate is anywhere near enough
to get working communication.
Stef
gnuarm <spamgoeshere4@n_o_s_p_a_m.yahoo.com> wrote:
>>
>>The simplest way is, you take the B wire (or D-) of the RS485 signal and
>>connect it via a 1K resistor with the RXD* line of the PC and the GND
>>line of your RS485 Device with the GND-Line of the PC-Com-Port. This is
>>electrically not ideal, but should normaly work. But You should not
>>connect the TXD* line (the one, where you see about -8V) of the PC to
>>the RS485 bus.
>>
>
> 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
--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)
Repel them. Repel them. Induce them to relinquish the spheroid.
-- Indiana University football cheer
Rich Webb
<ste...@yahooI-N-V-A-L-I-D.com.invalid> wrote:
>In comp.arch.embedded,
>gnuarm <spamgoeshere4@n_o_s_p_a_m.yahoo.com> wrote:
>>>
>>>The simplest way is, you take the B wire (or D-) of the RS485 signal and
>>>connect it via a 1K resistor with the RXD* line of the PC and the GND
>>>line of your RS485 Device with the GND-Line of the PC-Com-Port. This is
>>>electrically not ideal, but should normaly work. But You should not
>>>connect the TXD* line (the one, where you see about -8V) of the PC to
>>>the RS485 bus.
>>>
>>
>> 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
Some of the blame for the confusion certainly rests with the standards
body. I've got a copy of a 1978 version of the RS-422A spec where the
drivers ("generators") are clearly drawn and labeled as
|\
| \------A
| \
---| /
| /o-----B
|/
just like the usual datasheet symbols from Maxim et al. Following normal
conventions this would imply that "A" is non-inverting and "B" is
inverting.
But since UARTs universally (?) idle with a mark-high, and since the
*text* of the standard states that "the A terminal ... shall be negative
with respect to the B terminal for a binary 1 (MARK or OFF) state," the
*inverting* output really should have been "A."
So, basically, we're screwed.
Chris Burrows
news:Qr%Tn.64576$h57....@newsfe22.iad...
> Thanks for all the helpful replies. I'm coming to the following
> conclusions:
> - 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.
Regards,
Chris Burrows
CFB Software
http://www.cfbsoftware.com
Andrew Jackson
>> 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
Grant Edwards
> 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
Boudewijn Dijkstra
<tauno....@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> 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.
> (even less from the old
> 1.8432 MHz crystal).
>
> 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.
>
--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/
(remove the obvious prefix to reply by mail)
Grant Edwards
> Hello
>
> Le Tue, 22 Jun 2010 10:33:29 +0100, "Rowan Sylvester-Bradley"
>
> ....
>
>> - 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
David Brown
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.
Grant Edwards
[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!!
Stef
Grant Edwards <inv...@invalid.invalid> wrote:
> On 2010-06-22, Stef <ste...@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.
Andrew Jackson
>> 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.
>
> 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
Peter Greuter
Le Tue, 22 Jun 2010 14:03:01 +0000 (UTC), Grant Edwards
<inv...@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 ;-)
Robert Adsett
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
Vladimir Vassilevsky
Robert Adsett wrote:
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.
robert...@yahoo.com
>
>
>
>
>
> > On 22.6.10 1:35 , Peter Greuter wrote:
> >> Le Tue, 22 Jun 2010 10:33:29 +0100, "Rowan Sylvester-Bradley"
>
> >> ....
>
> >>> - 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).
-jg
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
Paul Keinanen
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.
robert...@yahoo.com
> On Tue, 22 Jun 2010 16:44:24 -0700 (PDT), "robertwess...@yahoo.com"
You still need to be adequately synchronized for each data bit. While
doubling up the stop bit might net you some extra slack on the stop
bit, the prior (data or parity) bit still has to be sampled not-too-
near its edge.
Besides, your idea puts the slack in the wrong place. With the
available (x18) divider, the receiver will be running too fast, and
will be sampling the stop bit too early - lengthening the stop bit
doesn't actually help. If you used a x19 divider, the extra slack
might help in detecting the stop bit (since the slack will now add in
the helpful direction because the receiver will be running too slow),
but you'll be even farther off center for the preceding parity/data
bit.
But still, if the OP can guarantee the accuracy of the sender's clock
(to rather better than the RS-232 standards), it should be possible to
receive the stream with a x18 divider.
Paul Keinanen
At 62.5 kbit/s the bit time is 16 us, thus +/-8 us error from the
nominal sampling point from the middle of the bit period would be
allowed.
Assuming startbit+8 data bits + 2 stop bits transmitted, the Rx sample
point for the last data bit could be theoretically +8 us after the
transmitted bit period midpoint. The transmitted midpoint is
8+8x16=136 us from the start of the start bit. The worst case Rx
sample point would be at 136+8=144 us, corresponding to 8.5 Rx clock
times, i.e Rx clock period of 16.94 us or 59028 bits/s. The sample
point for the 1st stop bit would be 9.5 bit times from the start bit
at 160.94 us, well before the next transmitted start bit at 176 us (or
later).
Clearly 57600 bits/s would be out of question.
Those calculations assume nominal clock frequencies and extreme steep
edges.
>Besides, your idea puts the slack in the wrong place. With the
>available (x18) divider, the receiver will be running too fast, and
>will be sampling the stop bit too early - lengthening the stop bit
>doesn't actually help. If you used a x19 divider, the extra slack
>might help in detecting the stop bit (since the slack will now add in
>the helpful direction because the receiver will be running too slow),
>but you'll be even farther off center for the preceding parity/data
>bit.
With 18.432 MHz crystal divided by 19 and then applying the internal
UART x16 oversampling would produce 60632 bits/s Rx bit rate.
>But still, if the OP can guarantee the accuracy of the sender's clock
>(to rather better than the RS-232 standards), it should be possible to
>receive the stream with a x18 divider.
In the real world, the RS-232 parts are supposed to be slew rate
limited, causing ISI, which of course limits how far from the nominal
sample point you can go. Especially any noise in the start bit edge
detection will also add error to the Rx sample points along the data
bits. However, the original poster was talking about RS-485 network,
in which even slew rate limited drivers are good for at least 250
kbit/s, thus the edges would be rather sharp.
Meindert Sprang
news:9pe3269vevlnos3fn...@4ax.com...
> At 62.5 kbit/s the bit time is 16 us, thus +/-8 us error from the
> nominal sampling point from the middle of the bit period would be
> allowed.
Funny, all the discussions about baudrates and errors. I'd use an ISA COM
card and simply replace the crystal... done it, works like a charm. Only 5
minutes work.
Meindert
Ignacio G. T.
> On Jun 20, 4:34 pm, "rowan.bradley"<rowan@n_o_s_p_a_m.sylvester-
> bradley.org> wrote:
>> Anyone know the quickest or easiest way of recording a serial data stream
>> and timestamping each byte with a resolution of at least 1ms (preferably
>> finer)? I can only find cheap or free programs with less resolution, or
>> very expensive solutions, often involving special hardware.
>>
>> I only need to monitor one port, and I don't need to send any characters
>>
>> or whatever other OS will do the job, use some sort of microprocessor to
>> capture the data (preferably one I'm familiar with, such as 8051 family or
>> PIC) or anything else so long as it's quick and cheap. I just need to get
>> the job done, preferably tomorrow!
>>
>>
>> Thanks - Rowan
>>
>> ---------------------------------------
>> Posted throughhttp://www.EmbeddedRelated.com
>
> Have you seen this:<http://www.232analyzer.com/232default.htm> ??
>
> According to their hype, "All monitoring modes available in
> 232Analyzer software come with timestamps in milliseconds."
>
> RK
Just be aware that ms resolution does not mean ms precision!
--
Saludos.
Ignacio G.T.
Grant Edwards
> Since the OP required receive only capability, configure the actual
> data network with 2 stop bits and the monitoring receiver with 1 stop
> bit.
That's assuming that:
1) The OP can change the configuration of the data network. [If that
were the case, why not just change it to 57600 or 115200?]
2) The OP has a UART with an 18MHz clock instead of the standard
1.8MHz clock.
I'd bet both of your assumptions are false.
--
Grant Edwards grant.b.edwards Yow! I'm definitely not
at in Omaha!
gmail.com
Jon Kirwan
Hehe. But this means you actually _have_ something with an
ISA bus on it!! These days... well.
I keep an older 80386DX and 80486DX machine around (three,
actually) all nicely sporting lots of ISA slots. Also have
proto ISA boards I can use to slap up an easy custom circuit
on. No way could do that with PCI.
My 80486DX boots up Win98SE at 33MHZ and 64Mb RAM (with an
external cache made from discrete static rams) faster than my
WinXP boots on a 2.94GHz cpu. I actually prefer to use it,
too.
On your point, yes. A crystal change on any of the usual
spate of old ISA boards would easily solve the problem.
Forgotten lore.
Jon
Grant Edwards
> On Wed, 23 Jun 2010 14:13:14 +0200, "Meindert Sprang"
><m...@NOJUNKcustomORSPAMware.nl> wrote:
>
>>"Paul Keinanen" <kein...@sci.fi> wrote in message
>>news:9pe3269vevlnos3fn...@4ax.com...
>>> At 62.5 kbit/s the bit time is 16 us, thus +/-8 us error from the
>>> nominal sampling point from the middle of the bit period would be
>>> allowed.
>>
>>Funny, all the discussions about baudrates and errors. I'd use an ISA COM
>>card and simply replace the crystal... done it, works like a charm. Only 5
>>minutes work.
>
> Hehe. But this means you actually _have_ something with an
> ISA bus on it!! These days... well.
Then use a PCI card.
> On your point, yes. A crystal change on any of the usual
> spate of old ISA boards would easily solve the problem.
> Forgotten lore.
It works for PCI cards as well.
--
Grant Edwards grant.b.edwards Yow! An Italian is COMBING
at his hair in suburban DES
gmail.com MOINES!
Jon Kirwan
<inv...@invalid.invalid> wrote:
>On 2010-06-23, Jon Kirwan <jo...@infinitefactors.org> wrote:
>> On Wed, 23 Jun 2010 14:13:14 +0200, "Meindert Sprang"
>><m...@NOJUNKcustomORSPAMware.nl> wrote:
>>
>>>"Paul Keinanen" <kein...@sci.fi> wrote in message
>>>news:9pe3269vevlnos3fn...@4ax.com...
>>>> At 62.5 kbit/s the bit time is 16 us, thus +/-8 us error from the
>>>> nominal sampling point from the middle of the bit period would be
>>>> allowed.
>>>
>>>Funny, all the discussions about baudrates and errors. I'd use an ISA COM
>>>card and simply replace the crystal... done it, works like a charm. Only 5
>>>minutes work.
>>
>> Hehe. But this means you actually _have_ something with an
>> ISA bus on it!! These days... well.
>
>Then use a PCI card.
>
>> On your point, yes. A crystal change on any of the usual
>> spate of old ISA boards would easily solve the problem.
>> Forgotten lore.
>
>It works for PCI cards as well.
I like ISA and simpler software.
Although I understand reflection wave principles, clock line
skew and serpentine clock lines, and the like, I very much
appreciate being able to use simple logic, wire-wrapping
techniques, and custom circuit design with the ISA bus. It
is a low-tech bus that can be reached by hobbyists. PCI, and
not merely because of the hardware but also because of other
aspects (plug and play), out of reach of most hobbyist tools
and skills.
And I also understand the desire to get rid of the south
bridge, chipset side-band channels to support ISA DMA over a
bus that simply cannot and does not support ISA DMA timing
requirements, interrupt mapping, and so on. It's pretty
obvious this was a huge source of continuing chipset bugs and
needed testing regimes, as well.
But I like ISA.
Jon
Grant Edwards
> On Wed, 23 Jun 2010 21:04:55 +0000 (UTC), Grant Edwards
>>>>Funny, all the discussions about baudrates and errors. I'd use an ISA COM
>>>>card and simply replace the crystal... done it, works like a charm. Only 5
>>>>minutes work.
>>>
>>> Hehe. But this means you actually _have_ something with an
>>> ISA bus on it!! These days... well.
>>
>>Then use a PCI card.
>>
>>> On your point, yes. A crystal change on any of the usual
>>> spate of old ISA boards would easily solve the problem.
>>> Forgotten lore.
>>
>>It works for PCI cards as well.
>
> I like ISA and simpler software.
>
> Although I understand reflection wave principles, clock line
> skew and serpentine clock lines,
And swapping out the buad-rate clock oscillator on a PCI serial card
requires no understanding of any of that.
> and the like, I very much appreciate being able to use simple logic,
> wire-wrapping techniques, and custom circuit design with the ISA bus.
> It is a low-tech bus that can be reached by hobbyists.
We're not talking about building a card from scratch. We're talking
about taking an off-the-shelf serial card and swapping out the xtal
oscillator.
> PCI, and not merely because of the hardware but also because of other
> aspects (plug and play), out of reach of most hobbyist tools and
> skills.
Swapping in a 2.00MHz oscillator for a 1.843MHz oscillator on a PCI
card requires _exactly_the_same_ skills as doing it on an ISA card.
> And I also understand the desire to get rid of the south bridge,
> chipset side-band channels to support ISA DMA over a bus that simply
> cannot and does not support ISA DMA timing requirements, interrupt
> mapping, and so on. It's pretty obvious this was a huge source of
> continuing chipset bugs and needed testing regimes, as well.
I have absolutely no idea what any of that has to do with this thread.
--
Grant Edwards grant.b.edwards Yow! Mary Tyler Moore's
at SEVENTH HUSBAND is wearing
gmail.com my DACRON TANK TOP in a
cheap hotel in HONOLULU!
Jon Kirwan
<inv...@invalid.invalid> wrote:
>On 2010-06-23, Jon Kirwan <jo...@infinitefactors.org> wrote:
>> On Wed, 23 Jun 2010 21:04:55 +0000 (UTC), Grant Edwards
>
>>>>>Funny, all the discussions about baudrates and errors. I'd use an ISA COM
>>>>>card and simply replace the crystal... done it, works like a charm. Only 5
>>>>>minutes work.
>>>>
>>>> Hehe. But this means you actually _have_ something with an
>>>> ISA bus on it!! These days... well.
>>>
>>>Then use a PCI card.
>>>
>>>> On your point, yes. A crystal change on any of the usual
>>>> spate of old ISA boards would easily solve the problem.
>>>> Forgotten lore.
>>>
>>>It works for PCI cards as well.
>>
>> I like ISA and simpler software.
>>
>> Although I understand reflection wave principles, clock line
>> skew and serpentine clock lines,
>
>And swapping out the buad-rate clock oscillator on a PCI serial card
>requires no understanding of any of that.
Agreed. I just took Meindert's comment regarding an ISA
board and ran with it. :P
>> and the like, I very much appreciate being able to use simple logic,
>> wire-wrapping techniques, and custom circuit design with the ISA bus.
>> It is a low-tech bus that can be reached by hobbyists.
>
>We're not talking about building a card from scratch. We're talking
>about taking an off-the-shelf serial card and swapping out the xtal
>oscillator.
We could be, but I expanded Meindert's comments in a
different direction for the pure pleasure of doing so.
Threads are sometimes like that.
>> PCI, and not merely because of the hardware but also because of other
>> aspects (plug and play), out of reach of most hobbyist tools and
>> skills.
>
>Swapping in a 2.00MHz oscillator for a 1.843MHz oscillator on a PCI
>card requires _exactly_the_same_ skills as doing it on an ISA card.
Not so. I'm looking right now at two such cards, one ISA and
one PCI. The ISA board has a large, socketed crystal module.
The PCI a tiny, SMT unit. The skills required for modifying
one is much different (and the tool tips required, too.) It
_may_ be the case, but not necessarily so as these two boards
easily illustrate to me.
>> And I also understand the desire to get rid of the south bridge,
>> chipset side-band channels to support ISA DMA over a bus that simply
>> cannot and does not support ISA DMA timing requirements, interrupt
>> mapping, and so on. It's pretty obvious this was a huge source of
>> continuing chipset bugs and needed testing regimes, as well.
>
>I have absolutely no idea what any of that has to do with this thread.
Then you are lost to what I've been saying. Which is fine.
That happens, as well.
Jon
robert...@yahoo.com
> On Wed, 23 Jun 2010 21:04:55 +0000 (UTC), Grant Edwards
>
>
>
>
>
> >On 2010-06-23, Jon Kirwan <j...@infinitefactors.org> wrote:
> >> On Wed, 23 Jun 2010 14:13:14 +0200, "Meindert Sprang"
> >><m...@NOJUNKcustomORSPAMware.nl> wrote:
>
Just slap something like a PLX 9052 on your PCI board. The front side
handles the PCI, the back side is ISA.
Jon Kirwan
I still can't just wire-wrap the PCI bus side of it. 1.5"
+/- 0.1" clock line, serpentined, 2ns clock skew at 33MHz and
1ns at 66, etc. I suppose pre-built boards with chips down
and the ISA back-side might do it. But this, again, is
getting way over my hobbyist toolset. If there is a problem
with the PCI bus, I simply don't have the tools to diagnose.
They are kind of expensive, too.
Also, no plug-and-play, required PCI transaction support and
registers to deal with, etc. ISA is __very__ easy. Add PCI,
even if only on a corner of it, and complexity goes ^^^ up.
I'm glad to keep the older machines around for hobby playing.
They work VERY well, even to this day. And Win98SE licensing
fits my model and boots _very_ quickly, well.
Jon
David Brown
ISA has also always been out of the reach of the hobbyist. While there
is no doubt that it is simpler to design an ISA card than a PCI card, in
the days of ISA it was hard to make such a card. Information about the
bus wasn't as easily available (no Google), and even if you knew how to
do it, the design of a card was not insignificant. But the biggest
hurdle for a hobbyist would be testing - you need an expendable spare
computer to test your card, because of the high risk of frying the whole
machine. These days you can get a cheap PCI bus computer for very
little, and second-hand ones for practically nothing. When ISA was the
main bus, a spare computer was a big investment.
Meindert Sprang
news:8715265o00dgu3msi...@4ax.com...
> Not so. I'm looking right now at two such cards, one ISA and
> one PCI. The ISA board has a large, socketed crystal module.
> The PCI a tiny, SMT unit. The skills required for modifying
> one is much different
Once you've done it a couple of times, you wonder why you ever made such a
fuss about it :-)
Bu then again, I am an embedded software and hardware guy....
Meindert
Meindert Sprang
news:4c23020b$0$4113$8404...@news.wineasy.se...
> ISA has also always been out of the reach of the hobbyist. While there
> is no doubt that it is simpler to design an ISA card than a PCI card, in
> the days of ISA it was hard to make such a card. Information about the
> bus wasn't as easily available (no Google), and even if you knew how to
> do it, the design of a card was not insignificant.
I designed a few cards back in the 90's. Information was not hard to come
by, Intel provided the spec, IIRC, and as long as you
double-triple-quadruple checked the power connections, the only serious
thing that could happen is that your computer locked up when the card was
inserted. And even that actually never happened to me. The hardest thing for
me was to find a decent mechanical specification to make it fit into every
computer case..
Meindert
Jon Kirwan
<m...@NOJUNKcustomORSPAMware.nl> wrote:
>"Jon Kirwan" <jo...@infinitefactors.org> wrote in message
>news:8715265o00dgu3msi...@4ax.com...
>> Not so. I'm looking right now at two such cards, one ISA and
>> one PCI. The ISA board has a large, socketed crystal module.
>> The PCI a tiny, SMT unit. The skills required for modifying
>> one is much different
>
>Once you've done it a couple of times, you wonder why you ever made such a
>fuss about it :-)
:) I have put some effort into it, before.
>Bu then again, I am an embedded software and hardware guy....
Well, there is that. I am only a hobbyist on the hardware
side.
Jon
Jon Kirwan
Are you just in a contrary mood, today? No other explanation
is possible.
Out of reach??? Hardly. But I suppose it depends upon what
is, is. :)
>While there
>is no doubt that it is simpler to design an ISA card than a PCI card, in
>the days of ISA it was hard to make such a card.
IBM, itself (and I know this because I still have them here),
sold very cheap proto boards for the ISA bus as far back as I
can recall. Very beautiful boards, too. I believe I paid
close to $30 for each. 1984/1985.
>Information about the
>bus wasn't as easily available (no Google),
Hogwash.
I still have my technical reference multi-volume binder set
from IBM with __complete__ documentation. Very complete.
Complete BIOS listings, with comments, included, and
schematics as well. I used these routinely for hobby
playing.
They were available in 1983 and IBM sent regular updates as
new boards came out. For example, volume 3 includes a
section I used called "IBM Personal Computer General Purpose
Interface Bus Technical Reference," that is dated August
15th, 1984. Part number 6138155. (It wasn't called ISA,
then, of course.)
Subsequent to this, there were some books out (latish, but
for late-comers quite good all the same) that appeared. As a
supplement book to those who didn't have access to IBM's
manuals (a shame), Edward Solari's books were a great help.
His AT book first came out circa 1989/1990, memory serving.
And then of course MindShare's multi-editions (my shelf copy
here is the 3rd edition) on the ISA (and other buses.)
Personally, I used the rather complete IBM information early
on and liked Solari's contribution. MindShare was fine, but
came too late.
>and even if you knew how to
>do it, the design of a card was not insignificant.
Trivial, for trivial projects. I think so, anyway. Plus,
IBM provided, on their proto boards, a complete, laid out
7400 series style decode section. So I guess maybe I just
had it too easy.
>But the biggest
>hurdle for a hobbyist would be testing - you need an expendable spare
>computer to test your card, because of the high risk of frying the whole
>machine. These days you can get a cheap PCI bus computer for very
>little, and second-hand ones for practically nothing. When ISA was the
>main bus, a spare computer was a big investment.
Since I do NOT consider myself to be anything other than a
hobbyist in electronics -- barely that -- and since I already
know just how darned easy this was for me when I knew far,
far less than I do now about it, I don't know at all where
you are coming from. Or, at least, I simply didn't find all
the struggles you suggest.
And by comparison with PCI??? No discussion.
I used tools developed for PCI at Intel. I know how much
they paid for them. And I know what including PCI on the
Pentium did to "mom and pop" motherboard manufacturers, too.
(Intel staff told me this was an internal goal, in fact.)
I won't even debate it. Not worth the trouble.
Jon
Jon Kirwan
IBM provided __complete__ documentation. I always felt like
I had enough. And that goes back to late 1983 and early
1984. So long before 1990, when Solari's book on the AT
arrived. I did terrible things, risky things, and didn't
have any trouble to speak about. Just the usual. I avoided
the 'mechanicals' issue by simply using the excellent and
relatively cheap (in fact, they were less expensive than
3rd-party sources [Jameco, later] which were much inferior
and more expensive, to boot) IBM prototype boards. These
were perfectly built, bus interface already laid out, and
slick as heck to use. No troubles. And that was 1985/1986.
And by that time EPROMs that were clearly fast enough for the
bus were rather readily available to a meager hack like me.
(BIOS extension.)
Jon
David Brown
I suppose it all depends on what you define as "hobbyist".
Finding a source for the documentation, and buying it (assuming these
manuals were priced similarly to a lot of other comparable technical
information) would take a lot of effort and money.
It may also be as simple as you being lucky in finding these prototype
boards from IBM. Imagine a hobbyist who hadn't found out about these
and wanted to make an ISA card.
>
>> But the biggest
>> hurdle for a hobbyist would be testing - you need an expendable spare
>> computer to test your card, because of the high risk of frying the whole
>> machine. These days you can get a cheap PCI bus computer for very
>> little, and second-hand ones for practically nothing. When ISA was the
>> main bus, a spare computer was a big investment.
>
> Since I do NOT consider myself to be anything other than a
> hobbyist in electronics -- barely that -- and since I already
> know just how darned easy this was for me when I knew far,
> far less than I do now about it, I don't know at all where
> you are coming from. Or, at least, I simply didn't find all
> the struggles you suggest.
>
You are /far/ beyond what I would consider a hobbyist - you have a lot
more knowledge and experience, and put a lot more time and money into
your electronics, than I would classify as hobbyist. Amateur, perhaps
(if you don't get paid for it), but I don't expect you would have
difficulty getting a job as an electronics engineer.
I am not saying that making an ISA board was too hard to do - merely
that the investment required was at the level of "small professional"
rather than "hobbyist".
> And by comparison with PCI??? No discussion.
>
All the information about PCI that you could want is a few google
searches away, as are plenty of example designs to get you started. And
you can buy an Altera Max II PCI evaluation board within a hobby budget
($150), including software drivers. So playing around with PCI is
certainly practical for hobbyists - though I agree that making your own
PCI board is well out of reach, even for a small professional company.
Jon Kirwan
<da...@westcontrol.removethisbit.com> wrote:
><snip>
>Finding a source for the documentation, and buying it (assuming these
>manuals were priced similarly to a lot of other comparable technical
>information) would take a lot of effort and money.
It wasn't hard. I'm not certain anymore, but I believe I
first heard about the information either in a magazine or
through the materials received when purchasing. I do
remember getting a price and part number to order from IBM,
by phone, and then simply writing a check and mailing it off.
It wasn't a lot of money, either. Especially considering
that the IBM PC/AT, 6MHz and 20Mb hard drive, was priced at
$5495, memory serving. If you could find a way to peal that
much out of your wallet, the manuals weren't even on the
radar scope.
My recollection is that the "lot of effort and money"
amounted to about 1 day's effort (which I don't consider 'a
lot') and the money wasn't even noticed. I didn't have to
think longer than a few seconds, I believe. And when I
received the material and the continuing supported updates to
it, I only felt lucky that I'd taken the trouble. Never once
thought about the expense of it. Must have been very small
compared to the PC/AT cost, which itself was 'painful' enough
to me. I am almost certain I might have not bothered, had
the manual cost more than a couple hundred bucks. But I'm
not sure, anymore. Just my 'sense' from memory.
>It may also be as simple as you being lucky in finding these prototype
>boards from IBM. Imagine a hobbyist who hadn't found out about these
>and wanted to make an ISA card.
When I wanted prototyping boards, the ONLY supplier ANYWHERE
in the world that I could find was IBM. And I darned well
knew I couldn't pony up the cost to hire a board house back
then. Not then. They were WAY too expensive and my
knowledge was near zero about ordering such a beast, anyway.
I looked for alternatives, at the time, thinking that IBM had
to be 'expensive' and that I might find less expensive
alternatives. None existed that I could find. No one else
had done it, yet. That came later.
And when they eventually did finally arrive (from Jameco?),
they were obvious garbage. So I never looked back. There
was no comparison.
I wasn't lucky, except for the fact that I was lucky that IBM
cared enough to actually create something like this and sell
it. There just wasn't anyone else around, so no choice and
no luck. Anyone else actually looking and bothering to call
IBM would have discovered the same thing I did, I think. They
didn't hide the fact. They just didn't push it with
advertising. You had to ask, that's all.
Anyone sensible should have been that diligent. I don't
count myself special that way.
><snip>
>You are /far/ beyond what I would consider a hobbyist - you have a lot
>more knowledge and experience, and put a lot more time and money into
>your electronics, than I would classify as hobbyist. Amateur, perhaps
>(if you don't get paid for it), but I don't expect you would have
>difficulty getting a job as an electronics engineer.
I've never hired out a single hour of time as an electronics
engineer and don't believe I'd be competent enough to do so,
either. Comprehensiveness is what is required for
professional services and I can't deliver that. I know some
things, but am terribly spotty elsewhere.
I started out as a hobbyist and that's what I imagine I am.
'Amateur' would work about as well as a word for it, though
I'm not sure there is a difference that amounts to anything.
>I am not saying that making an ISA board was too hard to do - merely
>that the investment required was at the level of "small professional"
>rather than "hobbyist".
I'm a hobbyist. Honest.
>> And by comparison with PCI??? No discussion.
>
>All the information about PCI that you could want is a few google
>searches away, as are plenty of example designs to get you started. And
>you can buy an Altera Max II PCI evaluation board within a hobby budget
>($150), including software drivers. So playing around with PCI is
>certainly practical for hobbyists - though I agree that making your own
>PCI board is well out of reach, even for a small professional company.
This 'inaccessability' for even small professional companies
is the center of my point. ISA is not only accessible to
smaller professionals, but to hobbyists too. And wire-wrap
_and_ sockets work nicely!!
Jon
Jon Kirwan
>peal
peel
... oh, well.
Jon
Mel
> I suppose it all depends on what you define as "hobbyist".
>
> Finding a source for the documentation, and buying it (assuming these
> manuals were priced similarly to a lot of other comparable technical
> information) would take a lot of effort and money.
>
> It may also be as simple as you being lucky in finding these prototype
> boards from IBM. Imagine a hobbyist who hadn't found out about these
> and wanted to make an ISA card.
Active (must have been them, can't imagine where else I'd have got them
then) sold boards with the appropriate edge connector and traces for typical
interface chips -- then a huge wire-wrap area.
Personal Computer Technical Reference had full schematics for the PC side of
the interface. Mine was off the shelf from a bookstore in Boston.
Admitted, the farther from MIT, the harder they were to find. They were
more scarce in Toronto.
And my first MIDI adaptor was a kit from a technically-aware hole in the
wall called Computer Parts Galore.
Mel.
David Brown
> On Thu, 24 Jun 2010 11:07:50 +0200, David Brown
> <da...@westcontrol.removethisbit.com> wrote:
>
>> <snip>
>> Finding a source for the documentation, and buying it (assuming these
>> manuals were priced similarly to a lot of other comparable technical
>> information) would take a lot of effort and money.
>
> It wasn't hard. I'm not certain anymore, but I believe I
> first heard about the information either in a magazine or
> through the materials received when purchasing. I do
> remember getting a price and part number to order from IBM,
> by phone, and then simply writing a check and mailing it off.
> It wasn't a lot of money, either. Especially considering
> that the IBM PC/AT, 6MHz and 20Mb hard drive, was priced at
> $5495, memory serving. If you could find a way to peal that
> much out of your wallet, the manuals weren't even on the
> radar scope.
>
I guess it is this more than anything else that puts ISA out of the
range of hobbyists to my mind - you don't mess around with putting
home-made cards into a $5500 computer unless you are happy to risk
damaging it, or you are /very/ confident of your abilities. Either way,
you are not a hobbyist.
Hobbyists who wanted to connect a card to a PC gave them an RS-232
interface or a parallel port connection - just like these days they give
them a USB connection or an Ethernet port (or possibly a RS-232 connection).
Grant Edwards
>>Swapping in a 2.00MHz oscillator for a 1.843MHz oscillator on a PCI
>>card requires _exactly_the_same_ skills as doing it on an ISA card.
>
> Not so. I'm looking right now at two such cards, one ISA and
> one PCI. The ISA board has a large, socketed crystal module.
> The PCI a tiny, SMT unit.
That's a characteristic of those two particular boards. It's not a
characteristic of ISA vs. PCI bus.
> The skills required for modifying one is much different (and the tool
> tips required, too.) It _may_ be the case, but not necessarily so as
> these two boards easily illustrate to me.
Replacing an SMT oscillator is really quite trivial. It's easier than
replacing the non-socketed, through-hole parts on most ISA boards.
--
Grant Edwards grant.b.edwards Yow! ... the HIGHWAY is
at made out of LIME JELLO and
gmail.com my HONDA is a barbequeued
OYSTER! Yum!
Jon Kirwan
<inv...@invalid.invalid> wrote:
>On 2010-06-23, Jon Kirwan <jo...@infinitefactors.org> wrote:
>
>>>Swapping in a 2.00MHz oscillator for a 1.843MHz oscillator on a PCI
>>>card requires _exactly_the_same_ skills as doing it on an ISA card.
>>
>> Not so. I'm looking right now at two such cards, one ISA and
>> one PCI. The ISA board has a large, socketed crystal module.
>> The PCI a tiny, SMT unit.
>
>That's a characteristic of those two particular boards. It's not a
>characteristic of ISA vs. PCI bus.
Which doesn't injur my point at all.
>> The skills required for modifying one is much different (and the tool
>> tips required, too.) It _may_ be the case, but not necessarily so as
>> these two boards easily illustrate to me.
>
>Replacing an SMT oscillator is really quite trivial. It's easier than
>replacing the non-socketed, through-hole parts on most ISA boards.
With good tools for SMT available. I recently _did_ after 30
years finally purchase my very first fine tip for attempting
such work. But for 30 years, this would have been a disaster
had I tried, while through hole is something I am quite long
since used to handling.
Of course, none of this is about my earlier point regarding
ISA vs PCI for hobbyists. Itself, of course, nothing about
the earlier thread. So we are far out to field now.
Jon
Jon Kirwan
<da...@westcontrol.removethisbit.com> wrote:
>On 24/06/2010 13:11, Jon Kirwan wrote:
>> On Thu, 24 Jun 2010 11:07:50 +0200, David Brown
>> <da...@westcontrol.removethisbit.com> wrote:
>>
>>> <snip>
>>> Finding a source for the documentation, and buying it (assuming these
>>> manuals were priced similarly to a lot of other comparable technical
>>> information) would take a lot of effort and money.
>>
>> It wasn't hard. I'm not certain anymore, but I believe I
>> first heard about the information either in a magazine or
>> through the materials received when purchasing. I do
>> remember getting a price and part number to order from IBM,
>> by phone, and then simply writing a check and mailing it off.
>> It wasn't a lot of money, either. Especially considering
>> that the IBM PC/AT, 6MHz and 20Mb hard drive, was priced at
>> $5495, memory serving. If you could find a way to peal that
>> much out of your wallet, the manuals weren't even on the
>> radar scope.
>
>I guess it is this more than anything else that puts ISA out of the
>range of hobbyists to my mind - you don't mess around with putting
>home-made cards into a $5500 computer unless you are happy to risk
>damaging it, or you are /very/ confident of your abilities. Either way,
>you are not a hobbyist.
Oh, cripes. I have nearly destroyed a _new_ $2,000 piece of
equipment back around that time merely because I hadn't
realized that the ground plug on one properly designed piece
of test equipment I was using might cause a hot-side short to
the IBM Model 85 electronic typewriter which didn't have such
a plug and was plugged in reverse-wise. Nicely destroyed a
power supply board, which I had to repair.
There is no question I was barely a hobbyist, if that, at the
time. And yes, I was willing to take risks with my money
because I wanted to learn, too. I did what I knew to do to
avoid throwing money in the dumpster or killing myself, but
I'm quite certain I didn't do as much as those smarter than
me did. I made plenty of mistakes as I went. And I have had
zero formal training here, by the way. Even to this day.
I don't know why you want to imagine I'm something I know I'm
not. But there it is.
>Hobbyists who wanted to connect a card to a PC gave them an RS-232
>interface or a parallel port connection - just like these days they give
>them a USB connection or an Ethernet port (or possibly a RS-232 connection).
I used those, too. For example, in the above typewriter case
I was scoping out the reed relay signals so that I could
figure out how to turn it into a printer. I then designed
and programmed by own 8031 board, with EPROM, and rat-nest
wired the thing across the reed relays and brought out a
ribbon cable to the tiny proto box I had. There, I used 1488
and 1489 level shifters with the 80C31 and a serial port to
the PC for use as a printer. Worked first time (after fixing
that power supply board in the electronic typewriter that I'd
wrecked.) But this was almost around the same time when I
also did my first proto board that plugged directly into that
$5500 PC/AT. And I was barely any smarter at that point and
nearly as likely to destroy something there, too.
You learn by screwing up and then reinforce the stuff you did
learn well, by succeeding.
And I'm still a hobbyist.
Jon
Fred
said:
>>If possible I'd like it to run at a non-standard baud rate (62,500 baud).
>
>I'm not sure an IBM PC uart can run at that rate.
It could if you're willing to change the crystal on the UART card...
Jon Kirwan
wrote:
Yeah. I think that has been mentioned in this thread
about... 20 times already?
And have you actually done this on a modern PC?
In any case, I haven't looked recently, but few PCs these
days seem to sport RS-232 or RS-485 ports. For those that
may, high integration on the board may not make it it so
easy. I believe the ones old enough to actually have a south
bridge probably use a super I/O chip or have it integrated
into the south bridge along with the APIC and perhaps have
some divider used to get the "pc standard" rates created. It
all has to look like an ISA dohicky or old software won't
work right. PCI boards also exist and they have drivers that
are probably Windows-standard, too, but then that is a whole
other thing to worry about and I'm not sure how the WinOldAp
or NTVDM emulates the old chips into the DOS boxes.
It's been a long time since I looked, but unless I heard
directly from someone who has achieved this with a new PC
system, I'd be skeptical of a claim about it being easy to
do.
Maybe someone has and can fill us in about it.
Jon
Fred
said:
>On Thu, 24 Jun 2010 21:27:15 -0700, Fred <fu...@hotmail.com>
>wrote:
>
>>Last time on comp.arch.embedded, Jon Kirwan <jo...@infinitefactors.org>
>>said:
>>
>>>>If possible I'd like it to run at a non-standard baud rate (62,500 baud).
>>>
>>>I'm not sure an IBM PC uart can run at that rate.
>>
>>It could if you're willing to change the crystal on the UART card...
>
>Yeah. I think that has been mentioned in this thread
>about... 20 times already?
I only saw one other mention; somehow I missed the other 19.
>And have you actually done this on a modern PC?
Not on a PC motherboard, but I have done it on an expansion card.
>In any case, I haven't looked recently, but few PCs these
>days seem to sport RS-232 or RS-485 ports.
Just the other day I bought a 2-port RS-232 PCI expansion card. Cost
me $17 at a local retail store, but you can get the same card online
for ~$12.
>It's been a long time since I looked, but unless I heard
>directly from someone who has achieved this with a new PC
>system, I'd be skeptical of a claim about it being easy to
>do.
>
>Maybe someone has and can fill us in about it.
The card I just bought has a normal-looking, through-hole-mounted
crystal on it. Even a software guy like me could swap it out.
Jon Kirwan
wrote:
>Last time on comp.arch.embedded, Jon Kirwan <jo...@infinitefactors.org>
>said:
>
>>On Thu, 24 Jun 2010 21:27:15 -0700, Fred <fu...@hotmail.com>
>>wrote:
>>
>>>Last time on comp.arch.embedded, Jon Kirwan <jo...@infinitefactors.org>
>>>said:
>>>
>>>>>If possible I'd like it to run at a non-standard baud rate (62,500 baud).
>>>>
>>>>I'm not sure an IBM PC uart can run at that rate.
>>>
>>>It could if you're willing to change the crystal on the UART card...
>>
>>Yeah. I think that has been mentioned in this thread
>>about... 20 times already?
>
>I only saw one other mention; somehow I missed the other 19.
I believe I saw several different people mention the
possibility and more still accepting the point and referring
to it.
>>And have you actually done this on a modern PC?
>
>Not on a PC motherboard, but I have done it on an expansion card.
The comment of mine that you quoted was "I'm not sure an IBM
PC uart can run at that rate." Note that I wasn't discussing
expansion cards.
>>In any case, I haven't looked recently, but few PCs these
>>days seem to sport RS-232 or RS-485 ports.
>
>Just the other day I bought a 2-port RS-232 PCI expansion card. Cost
>me $17 at a local retail store, but you can get the same card online
>for ~$12.
I wasn't discussing expansion cards.
>>It's been a long time since I looked, but unless I heard
>>directly from someone who has achieved this with a new PC
>>system, I'd be skeptical of a claim about it being easy to
>>do.
>>
>>Maybe someone has and can fill us in about it.
>
>The card I just bought has a normal-looking, through-hole-mounted
>crystal on it. Even a software guy like me could swap it out.
I wasn't discussing expansion cards.
Jon
Stefan Brröring
> Without changing system timing, MSDOS won't give you 1ms resolution
> only 1/18.5 Hz. Not sure about all forms of Windows and system clock
> resolution.
>
>
Yes, if you use the standard timer of MSDOS. But you can use an com1:
read interrupt. To get 1ms resolution, all you need is a clock. I think,
you could use com2: tx interrupt to increment a counter which could be
used as a timer which is faster than 1/18,5 Hz.
Stefan
Paul Keinanen
<pa...@pcserviceselectronics.co.uk> wrote:
>In article <4c1f3dc4$0$3314$8e6e...@newsreader.ewetel.de>,
>stef...@broering.de says...
>> With MSDOS or Windows, you can use every baudrate that is a
>> factor/divider of 115200.
>
>Without changing system timing, MSDOS won't give you 1ms resolution
>only 1/18.5 Hz. Not sure about all forms of Windows and system clock
>resolution.
Why bother with the MSDOS clock ?
On most Pentium and later processors contained the 64 bit Time Stamp
Counter register, which was incremented every clock cycle. You may
have to find out what the actual CPU clock frequency was, but that
should not be too hard.
Check availability of this counter and the availability of the RDTSC
(ReaD Time Stamp Counter) instruction using the CPUID instruction.
Vladimir Vassilevsky
Paul Keinanen wrote:
>>>With MSDOS or Windows, you can use every baudrate that is a
>>>factor/divider of 115200.
>>
>>Without changing system timing, MSDOS won't give you 1ms resolution
>>only 1/18.5 Hz. Not sure about all forms of Windows and system clock
>>resolution.
>
>
> Why bother with the MSDOS clock ?
>
> On most Pentium and later processors contained the 64 bit Time Stamp
> Counter register, which was incremented every clock cycle. You may
> have to find out what the actual CPU clock frequency was, but that
> should not be too hard.
>
> Check availability of this counter and the availability of the RDTSC
> (ReaD Time Stamp Counter) instruction using the CPUID instruction.
Any PC since beginning till our days has 8253 (or compatible), clocked
from 14.318MHz/12 ~ 1.193MHz. It can be used for the accurate time
measurement. Leave channel#0 at the division ration of 65536 as it is,
set channel#2 to 65535, don't touch channel#1 as it was used for memory
refresh in the old times. You can measure time intervals up to an hour
with the resolution of one tick of 1.193MHz. It works for any version of
DOS up to Windows XP. Vista and Win7 won't let you into the ports.
Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com
Grant Edwards
Be warned: if you have a dual/multi-core machine, MS Windows does _not_
keep the TSC values of the cores synchronized. You have to lock to a
single core the code that's reading the TSC if you want to get useful
data.
--
Grant
Stefan Brröring
>>
>> On most Pentium and later processors contained the 64 bit Time Stamp
>> Counter register, which was incremented every clock cycle. You may
>> have to find out what the actual CPU clock frequency was, but that
>> should not be too hard.
>>
>> Check availability of this counter and the availability of the RDTSC
>> (ReaD Time Stamp Counter) instruction using the CPUID instruction.
>
> Any PC since beginning till our days has 8253 (or compatible), clocked
> from 14.318MHz/12 ~ 1.193MHz. It can be used for the accurate time
> measurement. Leave channel#0 at the division ration of 65536 as it is,
> set channel#2 to 65535, don't touch channel#1 as it was used for memory
> refresh in the old times. You can measure time intervals up to an hour
> with the resolution of one tick of 1.193MHz. It works for any version of
> DOS up to Windows XP. Vista and Win7 won't let you into the ports.
>
Sounds good. I am not so familiar with this type of programming on a pc.
Its also a long time since i read technical documents about this. The
trick with the com-tx int which was used as a timer, was about 25 years
ago mentioned in an article in a german computer magazine (MC or C´t).
There was also a description of the hardware components of a pc. I
think, it was in May 1985 or so.
I only used the articles to write programs for the com-port under
turbo-pascal at that times. Nowadays, i do microcontroller programming
and a bit Delphi.
Best regards
Stefan