Having trouble with TTL port

[Gene F]

I have written the following code for talking to the TTL port. When I run the code on the EDUBot it works great I then try it on the Robot controller and I don't get any characters coming in. I have placed my SensorInitializePort() in the User_Initialization () routine and my SensorPackRead () routine in the Default_Routine() in the respective projects.

Note: If this is hard to read because of the tabs being removed by the forum I have attached the files in word format.
// Definition of the data structure and routines for reading the sensor pack

#ifndef __sensors_h_
#define __sensors_h_

#define STX (0x02)

typedef union
{
struct Data_tag
{
short xPos;
short yPos;
short PosError;
unsigned char DDCompas;
char AngleError;
unsigned char NullByte;
};
char chars[9];
} SensorPackType;

extern SensorPackType Sensors;

void SensorInitializePort (void);
void SensorPackRead (void);



#endif







#include "ifi_aliases.h"
#include "ifi_default.h"
#include "ifi_utilities.h"
#include "sensors.h"
#include "printf_lib.h"
// Added by Gene
#include <usart.h>
#include "delays.h"

SensorPackType Sensors;

/************************************************** *****************************
* FUNCTION NAME: InitializeSensorPort
* PURPOSE: Opens the serial port 2 for communicating with the scensors at
* 19.2k baud, 8 bits, no parity, one stop bit, and no flow control.
* CALLED FROM: user_routines.c
* ARGUMENTS: none
* RETURNS: void
************************************************** *****************************/
void SensorInitializePort (void)
{
Open2USART(USART_TX_INT_OFF &
USART_RX_INT_OFF &
USART_ASYNCH_MODE &
USART_EIGHT_BIT &
USART_CONT_RX &
USART_BRGH_HIGH,
128);

Delay1KTCYx( 50 ); /* Settling time */
}

/* Code to read Bills device. */
/************************************************** *****************************
* FUNCTION NAME: ReadSensorPack
* PURPOSE: Talks to the sensor pack to read the current data
* CALLED FROM: user_routines.c
* ARGUMENTS: none
* RETURNS: void
************************************************** *****************************/
void SensorPackRead (void)
{
int i, j;
RCSTA2bits.CREN = 1; // Re-enable the receiver
// Send an STX to the sensor pack to tell it to send the data
putc2USART(STX);

// Loop for the number of characters in the sensor pack data
for ( j = 0; j < 8/*sizeof(SensorPackType)*/; j++ )
{
// Wait a finite amount of time for the next character to arrive.
for ( i = 0; i < 20000; i++ )
if ( DataRdy2USART())
break;

// If a character arrived (we didn't timeout)
if ( i != 20000 )
{
// Grab the next charcter from the USART ant place it in our data structure
Sensors.chars[j] = getc2USART();
}
else
{
// If it failed then clear any possible errors
RCSTA2bits.CREN = 0; // Disable the receiver
RCSTA2bits.CREN = 1; // Re-enable the receiver
printf("Rx Fail DataRdy = %d\n",(int)DataRdy2USART());
}
}
RCSTA2bits.CREN = 0; // Disable the receiver
printf("x=%6d,y=%6d,pe=%6d,dd=%4d,ae=%4d\n",
Sensors.xPos,
Sensors.yPos,
Sensors.PosError,
(int)(unsigned char)Sensors.DDCompas,
(int)( char)Sensors.AngleError );

}

[Dave Flowerday]

Gene,
What kind of problems are you having? We've been struggling with the TTL port all week. From what we can tell, whenever we transmit something out the TTL port, we see garbage input on the RX side. When monitoring it with an oscilloscope, it looks like a signal is actually being generated on the RX pin. We tried grounding the RX pin, thinking maybe it was just noise from the TX, but that didn't work - we still saw garbage coming in. I'd have to doublecheck with one of our other engineers, but I believe that when we're not transmitting, we don't see junk on the serial port, but we're also not able to receive anything valid either.

Is this anything like what you've been seeing? We sent off an email to Innovation First about this problem last night to see what they have to say.

[Gene F]

Dave,
We have an external device that responds to our sending of an STX char. When viewed with the o-scope we see our transmission on the tx line and see the device's response on the rx line. We did notice that when there is nothing connected to the rx line that looks like it is being driven close to the tx line. That is because the rx line is high impedance. once we connected it to the other device we didn't see any crosstalk. Our basic problem is that we never get the DataRdy2USART() routine to report TRUE indicating a character is in the receive buffer. Also reading the buffer without waiting for the DataRdy2USART() gives us garbage, not what the other device sent.

I too have sent an email to Innovation First. They have sent one reply but didn't solve the issue. I have sent them my code for review and am waiting on another reply. I will post again after they respond.

[Astronouth7303]

Yeah, and it seems like on all the other pins, gnd is power and vice versa. Go figure

[Gene F]

I talked to the guys from Innovation First late in the day. They say my code looks like it should work. They say when they hang a RS232 converter on the TTL port that they are able to talk and listen through that port. They vowed to continue to investigate why I'm having trouble on Monday.

I'll keep you posted.

[Dave Flowerday]

Originally Posted by Gene F

I talked to the guys from Innovation First late in the day. They say my code looks like it should work. They say when they hang a RS232 converter on the TTL port that they are able to talk and listen through that port. They vowed to continue to investigate why I'm having trouble on Monday.

We received a similar response. We'll be investigating it more this weekend as well so we'll let you know if we make any progress.

[Joe Ross]

Is it possible that what you are seeing is inverted from what you want? In the RS232 spec, 1 is -3 to -25 volts and 0 is +3 to +25 volts. However, for TTL serial ports there is no standard. In some +5v is 1 (as normal ttl) and in others 0v is 1 (taking the lower votage as 1, like RS232). Some microprocessors have settings for standard and inverted serial ports, I don't know if the PIC has that, or if the other device you are interfacing with does.

[Dave Flowerday]

Originally Posted by Joe Ross

Is it possible that what you are seeing is inverted from what you want? In the RS232 spec, 1 is -3 to -25 volts and 0 is +3 to +25 volts. However, for TTL serial ports there is no standard. In some +5v is 1 (as normal ttl) and in others 0v is 1 (taking the lower votage as 1, like RS232). Some microprocessors have settings for standard and inverted serial ports, I don't know if the PIC has that, or if the other device you are interfacing with does.

We don't even have anything hooked up to the TTL port currently. We're just trying to understand why we're receiving stuff when it's unconnected. Noise or bleedover is the most likely cause, so we grounded the RX pin which should cancel anything like that out. However, even with the pin grounded, we still see data on the RX pin when watching it on the scope. Tomorrow we'll be trying it on our backup controller to see if the same condition exists on both or not.

Thanks anyway for the ideas, though...

[Gene F]

Dave,
We have already tried two different controllers with the same result. We played today with trying all the different modes thinking that possibly there was a documentation error. No Luck! What we see on our RX pin is typically an echo of the TX but with one or two bits changed very definatrely driven by the micro. We have tried several different output characters and the pattern of which bits are switched seems to vary with the value we send but we could not decern a pattern. It is possibe that the wrong pin is mapped out to RX on that port but I can't think of what function would match what we are seeing.

Have you learned any more?

[InnovationFirst]

The likely cause of both of your problems with the TTL serial port is because the RX pin is configured as an output, instead of an input. We will be releasing new default code shortly which will correctly configure it for you. Until then, you must manually configure the Rx as an input and the Tx as an output. Microchip's Open2USART function does not do this for you.

Apparently we already do this in the Mini RC initialization, which is why your sensorpack worked on the Mini RC, Gene. But on the FRC they are both set as outputs, which is why you are seeing high impedance on the Rx line, and then getting that crosstalk noise.

To fix the problem for now, just add these two lines to your initialization code:
TRISGbits.TRISG1 = 0;
TRISGbits.TRISG2 = 1;

In the upcoming default code change, this will be done automatically.

Regards,
The Firmware Team
Innovation First, Inc.

[Gene F]

Thanks David!

Tried it last night and it works great! We put the two lines you suggested before the Open2USART call. We had tried changing the port direction register for the receive on Saturdaay with no luck, but we were doing it after we had called Open2USART. Do you know if order is important with these two operations?


Gene