CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com
Software serial permanently receives NULLs [SOLVED]

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
aopg64



Joined: 17 Oct 2005
Posts: 28
Location: Hampshire, UK

View user's profile Send private message

Software serial permanently receives NULLs [SOLVED]
PostPosted: Wed Dec 01, 2010 8:08 am     Reply with quote
Hi folks,

Hopefully someone can tell me why this is happening and how to fix it because it's driving me mad!

Background:
I'm using an 18LF6723 with two hardware serial ports (GPS and GSM), a software serial port for debug i/o and a second software serial port for a wired link using an 8-bit protocol.

Compiler is V4.083

The debug i/o takes and gives ASCII text characters. This is working fine.

The second software serial port for the protocol just won't work in receive. I can send out protocol messages via the serial, but the serial RX fails.

The symptoms are that the kbhit() indicates that a character is available to be read. The fgetc() tries to get a character, and because there is none there it returns a NULL (0x00). If this happened once and then behaved after that, it would be okay, but next time round the loop kbhit() indicates a character again and fgetc() gets the NULL again. For ever and ever and ever...

It seems that the fgetc() character read doesn't clear the kbhit() 'flag'. As far as I can tell the software serial operates by detecting the start bit (drop to low) of the input character and then I guess the CCS subroutine takes over timing the rest of the bits in.

But using the oscilloscope on the RX line shows it is high (3v for this circuit) all the time. If I send a protocol message to it, I see the line drop to 0v for the bits of all the protocol characters. If I scope the first (behaving) software serial port I see the same physical behaviour.

A (much) shortened version of the offending bit of code and its compilation is below.


Code:


#use RS232(BAUD=BAUD_RATE_DIAG, XMIT=PIN_G3, RCV=PIN_G4, BITS=8, PARITY=N, ERRORS,RESTART_WDT,STREAM=WIRED)



121:               
122:               void WireLink_PutDataIntoGSM_Buffer(void)
123:               {
124:                  uint8 NewByte;
125:               
126:                  if ( kbhit(WIRED) )
 07C9C    B886     BTFSC 0xf86, 0x4, ACCESS
 07C9E    D003     BRA 0x7ca6
127:                  {
128:                     NewByte = fgetc(WIRED);
 07CA0    D7D7     BRA 0x7c50
 07CA2    C001     MOVFF 0x1, 0xace
129:                     // Blah, blah....put character into circular buffer....
130:                  }
131:               }
 07CA6    EFA0     GOTO 0x9540
132:               



The BTFSC seems to me to be the wrong logic 'skip if clear', surely as the RX line is high in quiescent it should be BTFSS? But the first serial port uses similar, though reversed (!kbhit()), logic and works ok.

I'm hoping this is some known or recognisable bug in either CCS or the 18LF6723 and someone has a workaround.

I've spent most of this morning searching the forum for a similar post but can't find anything similar or other point touched upon during other serial comms discussions that sounds similar.

Thanks in anticipation,

Nigel
_________________
No comment! (Can't think of anything interesting to say!)
aopg64



Joined: 17 Oct 2005
Posts: 28
Location: Hampshire, UK

View user's profile Send private message

PostPosted: Wed Dec 01, 2010 9:01 am     Reply with quote
Sorry folks,

Don't waste your time on this one!

As soon as I posted I thought I'd better check the schematic. Due to a misprinting and the reversing of jumpers randomly on the board I was putting the data in to the wrong pin!

It's still not working as wanted, but I'm no longer receiving infinite numbers of NULLs !!

Doh!

Nige
_________________
No comment! (Can't think of anything interesting to say!)
Ttelmah



Joined: 11 Mar 2010
Posts: 19401

View user's profile Send private message

PostPosted: Wed Dec 01, 2010 9:32 am     Reply with quote
Something is wrong though, because testing the input line, implies using a software UART, not a hardware UART. KBHIT on a hardware UART, tests the RC1IF/RC2IF bit to see if a character has already been received.

Looking at your RS232 definition, you are using the wrong pins. UART2, is on G2, and G1, not G3, and G4.
You are then using a software UART, which will almost certainly suffer from data corruption if interrupts are being used on the chip....

Best Wishes
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group