[solved] RS232 Serial - EB015 RTS / CTS Error - Help Needed

[dbasnett]

EB006 v6
SW1 - Fast
SW2 - XTAL
ICD2 / USB - USB
PSU / USB - PSU
LVP Selection - All three set for IO Port
Flowcode Pro v4.5.18.74
FlowKit connection - PC-->FlowKit In - FlowKit Out --> EB006 USB
Custom USB Device - Matrix PICmicro Programmer - v 1.0.0.6, 12/19/2007
CPU - PIC18F4580 - http://ww1.microchip.com/downloads/en/D ... 39637d.pdf
Extended CPU - disabled
Port A - Relay - EB038 - Low Nibble (RA0 - RA3) (optional)
Port B - Switches - EB007
Port C - RS232 - EB015 - J4=C, J5=1
Port D - LED - EB004
Port E - Sensor - EB003 - RE0 and RE1 (optional)

PC --- BreakOut Box --- J1 EB015 --- EB006

When the RS232 component has flow control disabled in Ext Properties it seems to assert RTS (CTS from the perspective of the PC), and I can communicate with my PC application regardless of the state of the PC RTS (CTS from the perspective of the EB006).

When the RS232 component has flow control enabled in Ext Properties it does not assert RTS (CTS from the perspective of the PC) until the PC asserts its RTS (CTS from the perspective of the EB006). IMHO this is an error. RTS (request to send) is a misnomer, and is best thought of as ready to receive. RTS indicates that the device raising the signal is ready to receive. This is obvious when you look at how DTE connects to DCE.

Code: Select all

   Pins
DTE  DCE
TX    RX
RX    TX
RTS   CTS
CTS   RTS

I tried to read / write the pins on port c using Out's to no avail.

I was surprised at the absence of the ability in the RS232 component to manipulate RTS / CTS. If I turn flow control on, and the RS232 component properly asserts RTS, and I had the ability to read CTS (the DTE device has RTS asserted) I could decide to send data or not. As it is today, if I have flow control on, all sends to the RS232 component block if the DTE has not asserted RTS.

Or, being a newbie I have missed something

Also on my wish list for the RS232 component is a command to send an array of bytes. The macro would be SendRS232Bytes and the parameters would be byte array and count. Trying to work with strings and byte values of 0 was a learning opportunity.

[dbasnett]

I'd be glad to be guinea pig for a new version of the RS232 component. I do a lot of RS232 programming on Windows.

[Spanish_dude]

You could make your own sendRS232String function :

Code: Select all

void SendRS232String(char *_string, char size)
{
    char i;

    if (size <= 0)
        return;

    for (i = 0; i < size && _string[i] != 0x0; i++)
    {
        SendRS232Char(_string[i]);
    }
}

This would be used as follows :

Code: Select all

void main()
{
    char size = 20;
    char string[size] = {0};

    // some code
    // put some data in the string

    SendRS232String(string, size); // or SendRS232String(&string[0], size)

    // some code
}

SendRS232Char Function name need to be replaced by the correct flowcode function name as I'm not sure It's the same as I have written.

[dbasnett]

Thanks for that. When I get better with C I'll give that a shot.

My biggest concern is RTS / CTS.

[dbasnett]

If I turned on hardware flow control in the component could I turn RTS on/off in C, and also check CTS in C? Does anyone have the code to do that?

[Sean]

When hardware flow control is enabled, the RS232 component controls the RTS pin - asserting the line when waiting for a received character, and releasing it then a character is received or the timeout period has elapsed.

When transmitting, the program waits for the CTS line to be asserted before sending each character.

The CTS input state and RTS output control are independent of each other and are only associated with the send and receive macros respectively.

Hardware flow control can be turned off in the component and performed in Flowcode by adding the appropriate I/O commands around the transmit and receive macro calls.

[dbasnett]

When hardware flow control is enabled, the RS232 component controls the RTS pin - asserting the line when waiting for a received character, and releasing it then a character is received or the timeout period has elapsed.

When transmitting, the program waits for the CTS line to be asserted before sending each character.

The CTS input state and RTS output control are independent of each other and are only associated with the send and receive macros respectively.

Hardware flow control can be turned off in the component and performed in Flowcode by adding the appropriate I/O commands around the transmit and receive macro calls.

Please bear in mind that I have been Flowcod'ing for less than a month, and doing RS232 communications since the early 70's. I understand that most RS232 communication today ignores the control lines, and how I found Matrix was because you provided some control signals, namely RTS / CTS!

My application needs RTS / CTS flow control, though that part of the code hasn't been written in the attached file. The part of the code that needs to run independent of the RS232 state also hasn't been written yet(trying to walk before running).

The problem is that if I turn flow control on in the RS232 component (which I will need), the EB006 application stops at the first send waiting for the PC to assert RTS (CTS at the EB006 end). Without the ability to check CTS I have no way of not sending if the PC is not attached.

So all I really need is the ability to check CTS.

Thanks for replying, the time lag makes progress slow.

[Sean]

With hardware flow control enabled, the RS232 component confirures the selected CTS line as an input.
The input can also be read at any point in the flowchart by using an input icon or switch component connected to the same pin.
Neither will cause a conflict with RS232 component.

[dbasnett]

With hardware flow control enabled, the RS232 component confirures the selected CTS line as an input.
The input can also be read at any point in the flowchart by using an input icon or switch component connected to the same pin.
Neither will cause a conflict with RS232 component.

I thought I had tried that, but I'll give it a try when I get home from college. Thanks for all of your help.

[dbasnett]

So it took me a little while to figure out which value indicated what and whether to have hardware flow control enabled.

With flow control enabled and this check (PortC value) and 16 = 16 means the PC has NOT raised RTS.

Works great most of the time!!!!!!!!!!!

But, there is an opportunity between the time CTS is checked and the read or write occurs when this fails.

[Sean]

You can use the input icon in its 'Single Bit' mode (using the radio buttons below the port selector) to isolate the CTS pin (Port C, Pin 4 in this case) and return the logic level directly (1 or 0). The same result can be achieved by using a switch component connected to the pin.

The time delay between reading the port pin and sending a character to the uart should be a few microseconds at most. Is the state of the CTS line likely to change in this interval, without any data being exchanged?

[dbasnett]

I'll give you that it is not likely, but it is possible. If you agree that it could happen then this can, IMHO, only be addressed by modifying the RS232 macros, or we are left with a maybe situation. That is normally not a good place to be in the computer business.

[Sean]

All the devices we have tested seem to be capable of dealing with the occasional character that gets transmitted at the instant the CTS is removed.

Most devices seem to be simply managing their input queues, and remove CTS during transmission of the character that causes the buffer to become full (probably during the stop bit), or completes a transaction, so the following characters are held back correctly.

Devices that can asynchronously enter prolonged busy states appear to have extra buffer capacity provided to allow occasional, individual characters to 'slip through' (the character can be seen being echoed back when communications resume). The occasional race condition with the CTS line seems to be unaviodable and to have been catered for.

Do you have an application where these conditions are not met?

[dbasnett]

"Most devices seem to be simply managing their input queues, and remove CTS during transmission..." As written today my application is not queuing the data, but I should / will do that and tighten the loop of how bytes are sent.

I am curious about what "remove CTS during transmission" means?

If the RS232 macros accepted an additional parameter, something to the effect of Ignore CTS, this would not be an issue ever.

I think I have seen this happen once, but I could probably develop a test application to test worst case.

[Sean]

By "remove CTS during transmission" I simply meant de-asserting CTS (as seen by the Flowcode code) during transmission of a data stream. This usually happens conveniently between bytes, but has been seen to happen in the middle of a byte with some devices.

The Flowcode RS232 component code (with flow control enabled) checks CTS and controls RTS on a byte-by-byte basis. The worst case reaction to de-assertion of CTS will be the transmission of one extra byte - which should be allowed for in the receiving device.

Similarly, most of the UARTs in the microcontrollers targetted by Flowcode contain small hardware buffers (2 or 4 bytes) that can allow a slight overrun of incomming data after the RTS line has been de-asserted.

These small allowances seem to be sufficient to overcome any problems caused by flow control reaction delays.

[dbasnett]

So say I send a string of 128 characters, checking CTS before the call to the RS232 macro. Sometime between the time that the macro sends the first character, but before the last, CTS is de-asserted. It looks to me like the macro blocks in that case, which is what I don't want to happen.

[Sean]

The flow control for the RS232 component is character based, so transmission of a long message will stop within 1 character of CTS being de-asserted.

If you need flow control to be message based (allowing a full message to be transmitted after the first character has been accepted), the component flow control should be turned off and the CTS pin test preformed at the start of a message transmission in the main flowchart, using input icons or the switch component. The Flowcode RS232 component will not test the CTS line in this case and will transmit all characters sent to it.

If flowcontrol is turned off, output icons or the LED component can be used in the flowchart to control an RTS line, if required.

[dbasnett]

For some reason I interpreted something said earlier to mean that to test CTS, hardware flowcontrol needed to be enabled.

I'll give that a try when I get home from school.

Thanks again.

[Sean]

Enabling flow control causes the RS232 component to automatically test the pin allocated to the CTS function before each character transmission.

If flow control is disabled, the CTS signal (as seen by the microcontroller) from an external device can be connected to any available pin and read as a basic input.

This should allow alternative modes of operation to be created directly in Flowcode.

[dbasnett]

That worked! Thanks for all of your help.