[SOLVED] getting ascii wrong ascii characters!

[adnan_merter]

getting wrong ascii characters!

hi all,
i have builded aa circuit that connects another device via rs232 and it works fine, so far everything alright

i can communicate the device with my computer by writing a simple program and it works fine too, no problem.
and i tried the same method with my pic, and a weird thing happened, some characters are received OK but most of them received 0x80 more, i mean character+0x80 for example pic is supposed to receive 0x41 but receives 0xC1 (0x42+0x80).

the more interesting thing is; when i simulate the same circuit in protheus is not fixed, so i decided this is not a problem about my design, it is about my pic.

i tried 16f877 and 18f2550 and nothing changed.
my fuse setting is:

#include <18F2550.h>
#device adc=8

#FUSES NOWDT                    //No Watch Dog Timer
#FUSES WDT1024                   //Watch Dog Timer uses 1:128 Postscale
#FUSES HSPLL                    //High Speed Crystal/Resonator with PLL enabled
#FUSES PROTECT                //Code not protected from reading
#FUSES NOBROWNOUT               //No brownout reset
#FUSES BORV20                   //Brownout reset at 2.0V
#FUSES NOPUT                    //No Power Up Timer
#FUSES CPD                    //No EE protection
#FUSES STVREN                   //Stack full/underflow will cause reset
#FUSES NODEBUG                  //No Debug mode for ICD
#FUSES NOLVP                    //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOWRT                    //Program memory not write protected
#FUSES NOWRTD                   //Data EEPROM not write protected
#FUSES IESO                     //Internal External Switch Over mode enabled
#FUSES FCMEN                    //Fail-safe clock monitor enabled
#FUSES PBADEN                   //PORTB pins are configured as analog input channels on RESET
#FUSES NOWRTC                   //configuration not registers write protected
#FUSES NOWRTB                   //Boot block not write protected
#FUSES NOEBTR                   //Memory not protected from table reads
#FUSES NOEBTRB                  //Boot block not protected from table reads
#FUSES NOCPB                    //No Boot Block code protection
#FUSES MCLR                     //Master Clear pin enabled
#FUSES LPT1OSC                  //Timer1 configured for low-power operation
#FUSES NOXINST                  //Extended set extension and Indexed Addressing mode disabled (Legacy mode)
#FUSES PLL5                    //Divide By 5(20MHz oscillator input)
#FUSES CPUDIV1                //System Clock by 1
#FUSES USBDIV                   //USB clock source comes from PLL divide by 2
#FUSES VREGEN                   //USB voltage regulator enabled

#use delay(clock=48000000)

and my rs232 configuration is:

#use rs232(baud=300,parity=E,xmit=PIN_C6,rcv=PIN_C7,bits=7,STOP=1, stream = TARIFF,SAMPLE_EARLY)

i hope i could tell my problem clearly,
thanks

 

[FvM]

I guess, the answer is somehow in the (unusal) selection of 7-bit mode for the UART. Curiously, usual PICs don't expose a 7-bit mode at all. Any reason for selecting it?

If I understand right, bits=7 will select a software UART with CCS.

 

[upand_at_them]

Is your PC configured for 7E1? I always use 8N1. And 300 baud is really slow, man.

 

[adnan_merter]

thanx for your help guys, as i guess the 7 bit is the problem. pic adds one bit logic high at the beginning of ascii code,

i just write a if loop to solve the problem so far it works,

unsigned char get_chr()
{

     MsgChr = fgetc(TARIFF);
     if(MsgChr>0x7F)
        {
           return MsgChr-0x80;
        }
     else
           return MsgChr;
}

but any suggestion or another way will be appriciated

thanks

 

[jayanth.devarayanadurga]

bits = 8 for 8 bit transmission.

 

[adnan_merter]

I guess, the answer is somehow in the (unusal) selection of 7-bit mode for the UART. Curiously, usual PICs don't expose a 7-bit mode at all. Any reason for selecting it?

If I understand right, bits=7 will select a software UART with CCS.

is it possible to use software uart to send or receive 7 bit data?

 

[FvM]

Yes, it's possible. But the 8th bit is meaning less in 7-bit communication. Possibly you need to mask it out.

 

[paulfjujo]

hello,

i don't know CCS, but with C18 i was facing with the same problem,
and the only way was to write my own Uart software
to handle the Even parity.

 

[FvM]

It's sufficient to mask out the eight bit:

MsgChr = fgetc(TARIFF) & 0x7f;

The conditions are still not clear. Do you send and receive both in 7-Bit configuration? If so, the CCS software UART seems to set the eight bit on it's own. I must confess that I never used 7-bit format with CCS C, so I can't say if it's the case.

i don't know CCS, but with C18 i was facing with the same problem,
and the only way was to write my own Uart software
to handle the Even parity.

As said, PIC18 UART doesn't support 7-bit mode. So you'll neid to receive in 8-bit frame when using the hardware UART. The stop or an optional parity bit are received as MSB and must be discarded. Another conclusion is that you can't receive 7-bit with no parity and one stop bit continuously, because the next frame starts when a stop bit is expected.

 

[paulfjujo]

hello,

you can see an example (source C18) on my web page , subject "EDF teleinfo"
use of USART2 link at 1200,E,7,1

in receive interrupt, remove parity bit

if(PIR3bits.RC2IF) // si une interruption arrive
{
c2 =Read2USART() & 0x7F ; // enleve la parite paire
...


and for sending :

void Init_UART2_TeleInfo(void)
{
// init 1200,E,7,1  10Mhz avec IT en rx
// voir para 18.5 spec sheet DS41159B page 186
Open2USART( USART_TX_INT_OFF &
USART_RX_INT_OFF &       // interrupt  NON armee
USART_ASYNCH_MODE &
USART_CONT_RX &
//USART_SINGLE_RX &
USART_EIGHT_BIT &        // use of 7 bits 8em bit =Parite
#ifdef OSCILLATEUR_INTERNE
USART_BRGH_LOW,207  // 16Mhz interne
#else
USART_BRGH_LOW,129   
#endif
);

void Put_RS_P2(char unCar)
{ 	while(Busy2USART()); 
   	TXSTA2bits.TX9D=parite(unCar);
    TXREG2=unCar;
    }

int parite(unsigned char x)
{
 unsigned char b;
   b=x;
   b ^= b >> 4;
   b ^= b >> 2;
   b ^= b >> 1;
   return b & 1;
}

 

[adnan_merter]

thanks for your useful answer my friends,
the problem has been solved.
the solution is simple

i just used software uart instead of hardware !!!

CCS C compiler creates an inline function for 7E1 communication but pic dosnt have an internal uart module creating 7E1 comm.