MSP430G2553 Serial communication interface (hyperterminal) using RS485 electrical characteristic

Have you tried putting a breakpoint at "UCA0TXBUF = tx[i++];" ? Does it ever execute it?

Sir,

i kept the  breakpoint at  UCA0TXBUF = tx[i++] in Tx ISR...........it is getting executed as soon as iam sending "a" character from hyperterminal........and for the rest character's it will not execute..........(in rx ISR i kept condition like to respond only when u receive "a")

Also sir When iam putting breakpoint as shown in coloured.....in rX ISR

// UART0 RX ISR
#pragma vector=USCIAB0RX_VECTOR
__interrupt void USCI0RX_ISR (void)
{ 
  
  if (UCA0RXBUF == 'a')                        
  {

P2OUT = 0x01;
    i = 0;
    IE2 |= UCA0TXIE;
   // while (!(IFG2&UCA0TXIFG));    // USCI_A0 TX buffer ready?
    UCA0TXBUF = tx[i++];
   
  }
}

after putting break point if iam typing character "a" from hyperterminal...then when going step by step through IAR,it is going at transmitter ISR i.e

#pragma vector=USCIAB0TX_VECTOR
__interrupt void USCI0TX_ISR (void)
{ 
 
   //if (i <= count+9)
    UCA0TXBUF = tx[i++];
  //else
    if (i >= count+9)
    IE2 &= ~UCA0TXIE;   // Disable USCI_A0 TX interrupt

}

and in that way my transmitter buffer is getting data from tx[i]........

hope i answed your question.......if any clarification required just let me known...iam really stuck and getting no where out.....please help.

Thank Yoy

Regards

Rahul

Rahul,

I reviewed your configuration and could not find anything obviously wrong. The only comment I have is that your setup is based on examples that communicate directly to the PC and not through a RS485 interface. As an attempt to understand the problem, I would put delays between the receiving and sending of the bytes. It could be that the shifting of direction in your RS485 is not fast enough to transmit the byte. You could even be getting a false start bit caused by that switching.

Thanks for your reply sir..

what i got is you are asking me to put some delay before switching RS485 transceiver IC in transmitter mode.. am i right? Since i am switching my transceiver IC after i receiver character from my hyperterminal i.e in RX ISR....so i will try putting delay in RXISR ...is that Ok Sir?

Sir i have also tried to communicate with hyper terminal  with RS485 to USB converter......in this case my micro controller is not able to receive the character from hyper terminal...as in previous case ( with rs485 to rs232 converter ,iam atleast able to receive a character from hyper terminal to micro controller)...why is it so?

Also when i opened this converter rs485 to USB , i found that it again contain RS485 tranceiver IC........

in my PCB iam able to control the direction of tranceiver through software...but when comes to this converter how they are controlling?

Iam sorry sir iam asking so many question..but iam totally messed up :-(

any suggestion will be helpful...

Regards

Rahul

Sir,

To provide delay between receiver and transmitter switching  can i use   __delay_cycles(1000); ?

Thanks

Regards

Rahul

Rahul,

1. Yes, the loop delay_cycles should work for providing the necessary delay.

2. You need to make sure the data direction in your RS485 is working and properly setup. You should put a breakpoint at the time you are sending a character from the micro to the PC and make sure the voltage at the pin is correct (a simple multimeter should do the job for you).

Rahul Gupta said:

Also when i opened this converter rs485 to USB , i found that it again contain RS485 tranceiver IC........in my PCB iam able to control the direction of tranceiver through software...but when comes to this converter how they are controlling?

Timing/handshake problems with RS485 are similar to the collision problems on the old BNC Ethernet connections. And require software suipport on both sides.
Sometimes, RS232s RTS/DSR (which do not exist on RS485) are used to control the direction of the transceiver, and are controlled by RS485-aware software. Which HyperTerm isn't.

In this case Rahul is using one of the Rs232/485 interfaces (SN65HVD10) and he has tied up driver and receiver pins together to an I/O pin, thus allowing full control of data direction through the target micro. The only concern is that enough time is given between receiving and transmitting, though the application should always be listening. Upon command, the application should wait for idle bus for typically 3.5 data words (data plus start and stop bits) before sending anything -- that is at least popular in many master / slave protocols such as Modbus. Without that delay the timings could be affected and the ring of the pulse when switching directions could trigger a false start bit (I learned it the hard way).

Sir thanks for the reply....

can you tell me whats the solution for above problem????

Whether the above  is not possible with hyperterminal???

Thank You

Regards

rahul

Sir,

I had provided delay at receiver ISR also......[ __delay_cycles(1000) ]...

but it doesn't worked out......

whether this delay is sufficient?

What else can i do sir?

Thank You

Regards

Rahul

Sir i have checked this converter (rs485 to rs232)....

Here they are using HEF4093BT andTL062CP ........

thank you

rahul

Rahul,

I can guarantee you this should work with hyperterminal. The next step is to eliminate the receiving routine, that you know it is working, and focus on the transmission. Set the direction for your RS485 high all the time and transmit a character every so often. Measure the voltage on the direction pin and confirm it is high. Send a character at 1-second intervals. Make sure the character is in ASC code, so if for instance you are trying to send the letter "A" use decimal 65.

Lenio Cacula said:

In this case Rahul is using one of the Rs232/485 interfaces (SN65HVD10) and he has tied up driver and receiver pins together to an I/O pin, thus allowing full control of data direction through the target micro

unfortunately, RS485 does not implement a 'bus free' detection.

i agree, that a time of 3.5 data words (35 bits) can be considered an idle line condition. However, this is only safe if all peers control their transceiver.
If one of the transceiver uses an auto-direction, this usually does not know the baudrate, so it will release the line >10 bits after the last high->low transition on its RS232 side. Counted for the lowest supported baudrate.
So the 'timeout' for an auto-direction transceiver that supports 9600Bd is >1ms. If used for 115200Bd, this means that 11 idle bytes are sent after the last real byte. If the other peers start sending after 3.5 bytes (= 300µs), this will cause a bus collision.

My own RS232/RS485 transceiver has its own MSP, doing an autobaud detection on both sides, RS232 and RS485, so the transceiver chip is properly switched. And even different baudrates are possible (of course the average throughput is limited to the lower baudrate).

However, besides the transceiver timing, there is also the problem of bus termination and signal reflections. worst case, a peer might detect its own last data bit as start bit of an incoming transmission.