How to use PC serial port to control my circuit?

I want to control my home-made board by RS232.

Can I do that? Do I have to write my own driver? Can I use the exsisting serial.sys? How? Any example of using RS232 to control the circuit? where can I find the document for the serial.sys? for example: IOCTLs, etc.

where can I find the timing for TD/RTS/DTR?

My circuit: _________ ________ | | | |__OUT1 _____ | | | |__OUT2 |___4(DTR) ____| |____SCLK___| |__OUT3 DB-9|___3(TD) ____|MAX237 |____DIN____|Max4820|__ ... |___7(RTS) ____| |____CS_____| |__ ...

----- | | | |__ ... | | | |__OUT8 --------- ---------

Reply to
yong
Loading thread data ...

Forget the RTS, DTR, etc. lines - stick to RxD, TxD and GND. That's all that's needed for modern systems. Use a MAX232 or similar RS-232 chip to interface between the card's TTL-level logic and the PC's RS232 port.

As for software, it depends entirely on what processor you have on your board, what operating system you have on the PC, what programming languages you want to use, what experiance you have, and of course what you actually want to transfer across the interface. If you are using Windows, you need to look at the Win32 api for the comms functions. If you are using *nix, you access the serial port like any other file. Alternatively you could use Python and pyserial, in which case the os-dependant details are hidden from you, or you could use third-party software for whatever other development tools you want to use.

Reply to
David Brown

Only if you have drivers at both ends that do flow control by means of XON/XOFF. - RM

Use a MAX232 or similar RS-232 chip to interface

Reply to
Rick Merrill

can you translate this to english. And what is that circuit?

Reply to
Bobsprit

Huh? It looks to me like he's bit-banging an SPI interface (sync serial with a chip-select). I don't see how you can do that with RxD, TxD and GND.

--
Grant Edwards                   grante             Yow!  .. this must be what
                                  at               it's like to be a COLLEGE
 Click to see the full signature
Reply to
Grant Edwards

Yes

Yes

No

Many are available, but not the way you have it shown.

Search for 8250 on google

The Max4820 is a SPI?-/QSPI?-/MICROWIRE?-compatible serial interface. That means the SCLK line and the DIN line must be syncronized together.

I think you have some more homework to do.

You may want to google for SPI/parallel port code.

Reply to
hamilton

Nonsense.

Yes he can. There are ioctl() calls (under Linux anyway) that can be used to control DTR, RTS, and TD. He can make those pins do anything he wants.

Looks like it should work to me.

What OS?

It will work fine they way he has it drawn.

It would probably be easier to use a parallel port, but a serial port will work just fine.

--
Grant Edwards                   grante             Yow!  My haircut is totally
                                  at               traditional!
 Click to see the full signature
Reply to
Grant Edwards

I think that it will work but it's a bit tedious to toggle DTR/RTS to drive SPI. I only found this page which isn't PC code.

formatting link

If all you want to do is to drive relays from your PC you might as well put in an AVR or PIC then you'd have some useful inputs too.

Peter

Reply to
moocowmoo

RTS/DTR can be very useful though, e.g. for resetting a microcontroller, or providing a small amount of power.

You can mess with the serial port in Visual Basic using the MSCOMM32 control.

Reply to
Mike Harrison

If all you want to do is drive a few relays, use the parallel port.

Reply to
Mike Harrison

all

Rick -

You don't need any flow control if the receiver on each end is guaranteed to be able to process incoming bytes faster than the transmitter can send. And that's almost always the case when dedicated hardware is receiving the data, or even with software involved as long as the software baby-sits the receiver. It's when software only wants to check the Rx buffer once per second, e.g., that flow control and receiver buffering may be needed. Don't forget how slow RS-232 is.

Robert

Reply to
Robert Sefton

I am glag at least one person understands SPI.

The TD pin on a uart is Asynchronous, which means you have a START bit and a STOP bit.

Where do these bits fit in the Max4820 data stream ??

Also the DIN pin MUST be synchronized with the SCLK pin.

Will serial.sys or ioctl() do that for you ???

Reply to
hamilton

"Guaranteed?" I have never seen it! E.G. debugging! E.G. data stream says, ""

It also depends on whether you have a big enough buffer, and a FIFO, and a double buffered UART, and suppose there is indeed only one(1) stop bit and only 1 buffer, and you're running at 115kbaud ... then what? I don't believe in "guaranteed" :-)

I wish! I once got burned (figuratively) at 9600 baud with a key pad scanner that output 2 codes for a keypress and 2 codes for a release, no xon/xoff, push/release in 0.1 sec produced 4 codes which overran the buffer (in the UART) because the code was off and running on the "press"! Nicely fixed with FIFO (which has it's own issues when you get to the interrupt processor!).

Rick Merrill

Reply to
Rick Merrill

In any hard real time system, you _must_ respond within the available time. Otherwise the program or device is faulty. Period.

Debugging any real time system can be quite problematic, often you have to rely on post mortem dumps. You can not use breaks and then continue single stepping etc.

If you are using simple bit banging at 115k2, you have 8.6 us time to process the character. If that is not enough, you have to drop the line speed.

The idea of using FIFOs in any real time application is problematic, if there is not an absolute certainty that the average speed is obtained within a well defined time.

For instance in this case it would be advantageous to use a single character FIFO to store the received character after reception, in this case for up to 86 us if 8N1 characters are used at 115k2. There is no risk that a new character is received sooner than 86 us after the previous one.

If the 86 us time frame is not enough for processing a single character, a 16 character FIFO is usable only if each message is less than 16 characters long and there is a well defined pause between the frames. If this is not possible, then the line speed must be dropped.

In general, FIFOs and flow control are usable only in non-realtime applications when the primary goal is maximum throughput without any timing constraints.

Paul

Reply to
Paul Keinanen

The O/P is in control of the software at the PC side, and of the software and hardware on the board. That means he can choose the speeds and write the software to do what he needs. Any modern PC is capable of continuously receiving at the maximum PC Uart speed of 115.2 kbaud, and any modern 8-bit micro (with a hardware uart rather than a software one) running at at least a few megahertz can also receive at that speed - all it needs is an interrupt routine feeding a ring buffer. Issues such as the length of telegrams or buffers should be handled at the protocol level. Similarly, issues such as errors, timeouts and retries are handled by the protocol level. Trying to do hardware handshaking complicates the electronics enormously (microcontroller uarts do not have hardware handshaking).

Reply to
David Brown

Ah, I didn't look too closely at the circuit he'd given. I also assumed that he was trying to do something sensible and possible like a UART interface rather than attempting bit-banging using the PC's comms port.

what

COLLEGE

Reply to
David Brown

interface

or providing a small amount

control.

Yes, they are great for that (and in particular, RTS is very useful for controlling the direction of a RS-485 driver). I was just trying to simplify things a bit for the O/P.

Reply to
David Brown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.