Using specified pins in serial port

[BeyondTheEye]

For an electronics project, I have to access the TxD, RTS and CTS pins of a serial port individually. Well, any 3 pins could be used, but those 3 are preferred.

All I've been able to find on the microsoft website are functions to access the serial port as a whole. Are there any functions available to put a specified pin HIGH or LOW?

[jonsca]

I wish I had a direct answer for you but some poking around yielded this thread which had a couple of good links. I don't know if it's what you're looking for or if you already ran across it.

[Ancient Dragon]

I'm trying to recall from some work I did 15 years ago. Seem to remember that all you do is xmit a single byte that contains the bit pattern you need. But then again, maybe not. SetCommStat() might do it for you.

[BeyondTheEye]

Thanks for the link. But it doesn't help too much for what I need. I've already read through most of it...

I'm attempting to load a hex file into an AT89S4051 microprocessor. It uses ISP(In System Programming) to load the program into the memory. Which comes down to sending a predefined byte sequence over serial connection to initate it.
The problem I'm having is it requires a clock signal sent from the PC as synchronisation, and a transmit/receive data line. For these data lines I can just use the WriteFile() and ReadFile() in the win32 API, but so far I havn't found a way of transfering a clock signal.

I was thinking of just sending 0/1's on a serial pin to create a clock. This is likely to be glitchy, and wastes processor power.
Alternatively, I could use the clocksignal in the UART hardware used for the RS232 protocol. However, so far I've been unable to find a way of transmitting this clocksignal over a serialpin.

[jonsca]

Just my 0.02 but it would probably save you the aggravation in the long run to use a chip programmer. From my cursory net search on it it looks like a lot of the programmers use USB these days so there are some decent device drivers out there. I was looking at this in particular that comes with Windows software but there are probably less expensive options.

[BeyondTheEye]

I normally would. But this is a project from university, and we've been given a program called ATMELISP to program the microprocessor using a self-made circuit.
I havn't managed to get it to work though, even with the teacher's help. Afterwards, I found out the program only has experimental support for the AT89S4051, so I looked into creating my own program to accomplish this.

So using a chip programmer isn't really an option, unless the teacher changes his mind about it...

[nezachem]

The problem I'm having is it requires a clock signal sent from the PC as synchronisation, and a transmit/receive data line. For these data lines I can just use the WriteFile() and ReadFile() in the win32 API, but so far I havn't found a way of transfering a clock signal.

I was thinking of just sending 0/1's on a serial pin to create a clock. This is likely to be glitchy, and wastes processor power.
Alternatively, I could use the clocksignal in the UART hardware used for the RS232 protocol. However, so far I've been unable to find a way of transmitting this clocksignal over a serialpin.

Can you elaborate, what this signal is supposed to synchronize? What frequencies are required, what accuracy?
AFAIK, the internal UART clock is not connected to any pin. To drive RTS and DTR use EscapeCommFunction.

[BeyondTheEye]

Can you elaborate, what this signal is supposed to synchronize? What frequencies are required, what accuracy?
AFAIK, the internal UART clock is not connected to any pin. To drive RTS and DTR use EscapeCommFunction.

As noted in the AT89S4051 datasheet:
1. Data shifts in/out MSB first.
2. MISO changes at rising of SCK.
3. MOSI is sampled at falling edge of SCK.
MISO being the sending line on the microprocessor end.
MOSI being the receiving line on the microprocessor end.

The clock signal is a consistent blockwave altering between 1 and 0. The microcontroller reads data when going from H to L, and send when L -> H.
I found out the RS232 protocol does send a clock signal, but only when using a DB-25 connector. Since I don't have such a port, I'd need to do the same using a DB-9 connector.

As for the frequency, I'd assume any of the usual baud rates for a serial port would work.

[nezachem]

OK, got the picture (hopefully). Correct me if I am wrong, you have to drive two lines and sample the third one.
If this is the case, I'd connect RTS to SCK, DTR to MOSI, and DSR to MISO.

[BeyondTheEye]

Not entirely sure what you mean by sampling, but they refer to it in the datasheet, so I guess you're on to it.

No problem using those pins in hardware, but I'm still a bit in the blue about the clock. Just sending altering 0/1's consistently doesn't seem like the right way to do it.

[Dave Sinkula]

Serial port, UART

[nezachem]

Not entirely sure what you mean by sampling, but they refer to it in the datasheet, so I guess you're on to it.

Sampling is a HW slang for reading.

No problem using those pins in hardware, but I'm still a bit in the blue about the clock. Just sending altering 0/1's consistently doesn't seem like the right way to do it.

It is exactly what you need to do.
To send:

For each bit to transfer,
    drive DTR to the bit value
    drive RTS high
    timeout for a few usecs
    drive RTS low
    timeout for a few usecs

To receive:

For each bit to transfer,
    drive RTS high
    read DSR
    timeout for a few usecs
    drive RTS low
    timeout for a few usecs

To fiddle with signals, use EscapeCommFunction For the exact timeout value refer to the datasheet.

[BeyondTheEye]

Just tried that approach, the oscilloscope said it was ~100 Hz. It's probably a bit off because the delays are a bit different from using a few bit operations.
Either way, it might work at this speed, but I kind of doubt it. I havn't got the microprocessor around to test it untill friday, so it'll just have to do.

[nezachem]

Just tried that approach, the oscilloscope said it was ~100 Hz.

It is ridiculously low. I'd suspect that the delays are implemented wrong (did you try not to delay at all?) May I see the code?

[BeyondTheEye]

Code:

char ConvertToHex(char c)
{
    if(c >= '0' && c <= '9')
        return c - '0';
    else if(c >= 'A' && c <= 'F')
        return c - '7';
    else
        return 0;
}

for(int i = 0; i < pcBuffer.size(); i++)
    if((pcBuffer[i] >= '0' && pcBuffer[i] <= '9') || (pcBuffer[i] >= 'A' && pcBuffer[i] <= 'F'))
    {
        char val = ConvertToHex(pcBuffer[i]);
        for(int j = 0; j < 4; j++)
        {
            if(val & 0x01 == 1)
                EscapeCommFunction(serial, SETDTR);
            else
                EscapeCommFunction(serial, CLRDTR);
            val = val >> 1;

            EscapeCommFunction(serial, SETRTS);
            for(int k = 0; k < 5; k++)
                ;
            EscapeCommFunction(serial, CLRRTS);
        }
    }

pcBuffer is a string read from a HEX-file. Since it uses ASCII code, it's transformed before sending.

I guess there's a few ways of making it faster, mostly with the conversion. Like creating an array of bits to send before actually starting transmission.

As a side note, I have only tested this at a low baud rate. Does the EscapeCommFunction use the baud rate or is it not used at all?

[nezachem]

Code:
I guess there's a few ways of making it faster, mostly with the conversion. Like creating an array of bits to send before actually starting transmission.

I don't think it matters. A conversion and bit extraction times are infinitesimal. The problem is somewhere else.

As a side note, I have only tested this at a low baud rate. Does the EscapeCommFunction use the baud rate or is it not used at all?

That's a question I don't have an answer to. Playing with baud rates would be an interesting experiment.

[BeyondTheEye]

That's a question I don't have an answer to. Playing with baud rates would be an interesting experiment.

Tried it at a higher baud rate, same result. Removing all functions other than EscapeCommFunction to set RTS L/H didn't change much either. Frequency was still around 100Hz.
I guess the EscapeCommFunction is just too slow to create a clock...

Any other ideas of going about it?