RS232 hardware flow control problem?

[xxopiumxx]

greetings,

I am working in a developer board (from mcelectronics - ARG) with a PIC18F4550. It has an RS232 level converter incorporated (max232cpe).

My configuration FUSES are:

[Ttelmah]

What crystal do you have?.
The chip supports a _maximum_ crystal frequency of 25MHz. It can be _clocked_ up to 48MHz with the PLL. You are telling the setup though that you have a crystal running at 48MHz....
Guessing you have a 20MHz crystal (PLL5 implies this), so change the delay to say:

#use delay(clock=48MHz)

Best Wishes

[xxopiumxx]

Yes, indeed I have a 20MHz crystal.
I've tried to set it as you advise me but it doesn't work either :(

Is there some specific code in order to manage the hardware flow control?

[ezflyr]

Hi,

How are you testing this? In other words, how do you know it's not working?

You should connect your development board to a PC, and run a terminal program like Realterm, or Hyperterminal to test your serial comms. Look carefully at the cabling (PIC Dev. Brd-to-PC) to ensure that the TxD pin on the development board (coming from the MAX232) is connected to the RxD pin on the PC.

Use putc or printf to transmit some data. Put this statement inside a while() loop to send it repeatedly so you don't miss anything. Be sure that flow control on the PC software is not enabled.

If you still can't make it work, post a link to the schematic for your board.

Edit: Also post a copy of your test program. This should be a complete and compilable program that demonstrates your problem!


John

[Ttelmah]

You need to verify that the chip is actually running, _and running at the right frequency_, before looking at the RS232 at all. Just toggle a pin that is _not_ connected to anything, at a slow rate like one per second, and test this with a meter/scope, or LED (with a current limiting resistor). Only Once you know you have the chip running, and at the right speed, try to move forwards to RS232.
Now on the flow control, to use this, you _must_ find out how these lines are wired. One will normally be an output, and the other an input.
You say the serial pins are correctly connected, but are you _sure_ which is TXD, and which RXD on the board?. You should not need flow control, provided this is turned off in whatever software you use to look at the data.
Try powering up the unit without a PIC at all, and check that pin C7, is being pulled 'up' to 5v, while pin C6 is floating. This would confirm the connections are the right way round. You should similarly find that one of the two handshake lines is floating, and the other is driven. This then tells you which is which. Normally if you don't need flow control, you can connect one to the other.

Best Wishes

[xxopiumxx]

I've tested the pins powered but without the PIC as you advise me:

RC7 -> aprox 5v
RC6 -> aprox 0v
RA3 -> aprox 5v
RA2 -> aprox 0v

also I've, with the help of an ohmmeter, checked the connections one by one as shown =

I've tried to get it running with the *c, also attached, with the Windows Hyperterminal configured at baudR 115200 8 bits N 1 N; but nothing happens.

Thanks for all the help.

[bkamen]

Are the chargepump caps actually missing from the hardware per your schematic?

If they are, receive to the PIC will work great, but TX from the PIC will not.

-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D

[Ttelmah]

Obvious other things leaping out:

1) No MCLR connection to the PIC. You need the NOMCLR fuse.....

2) No ground connection to the DB9. Pin5.

3) Unfortunately, without knowing whether a device is wired as DTE, or DCE, you can't know which is the transmit pin or receive pin on the connector.

4) Er. Wrong pins... You have the PIC TX, going to T1IN on the MAX232, but the corresponding 'out' pin T1OUT, is not connected to the DB9. The TX pin on the DB9, is connected via the second buffer to pin A2 on the PIC, which is not the serial output....

5) On the supposed 'handshake', you have pin 7 (RTS) connected to A3 on the PIC, but then no drive to generate CTS back to the device, so you can't generate a handshake even if you wanted to.....

Best Wishes

[xxopiumxx]

I will study more specifically the problem; and work according to your advices.
One million thanks for the help; and if I have news I will commit them.

[12Lapointep]

Shouldn't the RTS and CTS line be way easier to control than this? For example, I am using a PIC18F67J94 and I am setting up my port as follow:
// RS-232 Serial Port setup
#USE RS232(BAUD=115200, UART3, BITS=8, PARITY=N, ERRORS, RECEIVE_BUFFER = 8, CTS = PIN_D3, RTS = PIN_D2, FLOW_CONTROL_MODE, STREAM=RS232)
I have an interrupt service routine for #INT_RDA3 that is being called. The main problem is that errors and characters are getting lost in the buffer. Anyone could help me with this?

[Ttelmah]

You cannot have CCS's buffering _and_ an interrupt routine. CCS implements their _own_ serial interrupt when receive buffering is enabled. Your choices are have no CCS buffering, then you have to control RTS/CTS, or let CCS handle these and do not have an interrupt routine yourself.

They create a routine (global interrupts have to be enabled by you - they don't tell you this), and this handles the receive buffer.

I have to ask 'why' you would want to have your own interrupt code, when they are already buffering the data for you?.

[shirke]

Hi,
I try to use RS232 flow control with RDA interrupt, but it doesn't work. Can you show me some examples how can I use it?
_________________
shirke

[Ttelmah]

INT_RDA has nothing to do with flow control...

It is saying 'a character has been received' (past tense). Flow control has to happen _before_ characters are received, or before they are transmitted.....

The simplest form is RTS/CTS flow control. Here the receiving device asserts it's RTS, when it is able to receive data. The RTS connects to the CTS on the other device (and vice versa for the other direction). Each device simply tests it's CTS input _before_ sending data. Note _sending_. There is no change to the receive handling at all, except that if the flow control is being used to prevent buffer overflow, the receiving device will turn off it's RTS line when the buffer is perhaps 3/4 full. You have to allow significant space, since in most cases the flow control will not stop data immediately. PC's will typically send up to perhaps 16 characters after their CTS input goes off....

So the first question is why are you using flow control?. If this is because the other end 'needs it', then your receive code need not change at all. All you need to do is test the CTS input, and stop sending your data when this goes inactive. If however you need it because data is arriving too fast for the PIC to handle, then you need to set a flag in the RTS interrupt handler when the buffer count gets to a particular point (often called the 'high water mark'), and turn off your RTS output when this happens. Then enable this again when there is significant space in the buffer (low water mark).

[shirke]