Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

[SOLVED] getting ascii wrong ascii characters!

Status
Not open for further replies.
adnan_merter

adnan_merter

Full Member level 3
Joined
Jan 23, 2008
Messages
160
Helped
6
Reputation
12
Reaction score
6
Trophy points
1,298
Location
The most beautiful city of the world
Activity points
2,526
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:

Code: 
#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:

Code: 
#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
 

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.
 

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,

Code: 
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
 

FvM said:
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.
Click to expand...

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

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

It's sufficient to mask out the eight bit:
Code: 
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.
Click to expand...

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.
 
Last edited:

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 :

Code: 
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;
}
 

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.
 
  • Like
Reactions: rglcr

    R

    rglcr

    Points: 2
    Helpful Answer Positive Rating
Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top