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 CCS Technical Support

#USE RS232 with ERRORS flag

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



Joined: 30 Oct 2007
Posts: 566
Location: Ottawa, Ontario, Canada

View user's profile Send private message

#USE RS232 with ERRORS flag
PostPosted: Thu Apr 18, 2013 8:29 am     Reply with quote

Device: PIC24HJ128GP306
Compiler: 4.132

I just noticed this in the CCS documentation under the #use RS232 help section:

****************
Warning:
The PIC UART will shut down on overflow (3 characters received by the hardware with a GETC() call). The "ERRORS" option prevents the shutdown by detecting the condition and resetting the UART.
****************

So, what does CCS mean by "resetting" the UART? I am asking because I am in fact getting somewhat odd behaviour once in a while with my UART.

Sometimes, I will get the #INT_UART1E interrupt and then some other times I will get some weird stuff going-on like the UART just stops responding but then will re-start responding, sometimes my PIC will reboot etc.

So, what does CCS mean by "resetting the UART"? If this is the case, should I re-issue the #use RS232 command?

My UART speed is 115200 bps (I *have* to use this seed) and my PIC oscillator frequency is 36.864MHz (in my .h, I do this: #use delay( crystal = 36864000, clock = 73728000 )).

Thanks,

Benoit
temtronic



Joined: 01 Jul 2010
Posts: 9245
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Thu Apr 18, 2013 1:38 pm     Reply with quote

From what I understand, CCS adds a chunk of code to 'reset' the hardware UART due to overrun conditions( the buffer is only 2 or 3 bytes).
I've never looked at the actual code they create but it is necessary to always add 'errors' to use RS232(...options...) whenever you use the internal hardware UART.
I currently play with the PIC18F46K22 and can use both UARTS at 115K200 24/7 without any communications problems.

Others can probably give a detailed analysis of what's going on..all I know..is always add 'errors' !!

hth
jay
Ttelmah



Joined: 11 Mar 2010
Posts: 19546

View user's profile Send private message

PostPosted: Thu Apr 18, 2013 2:40 pm     Reply with quote

You clear the CREN flag, then re-enable it. They copy the error flags into the RS232_ERRORS variable, then do this.
This doesn't change any of the UART settings.
Basically if you use the hardware UART, you _must_ either have ERRORS set, or do the same proceedure yourself if the OERR, or FERR flags are set. If not the UART will become hung.
The proceedure is described in the data sheet.

Best Wishes
benoitstjean



Joined: 30 Oct 2007
Posts: 566
Location: Ottawa, Ontario, Canada

View user's profile Send private message

PostPosted: Fri Apr 19, 2013 7:44 am     Reply with quote

Sorry my ignorance but unless I haven't seen it in the CCS compiler, *how* do I clear and set the CREN flag? And I never programmed using the assembly code so I don't know how to do this.

Thanks,

Benoit
Mike Walne



Joined: 19 Feb 2004
Posts: 1785
Location: Boston Spa UK

View user's profile Send private message

PostPosted: Fri Apr 19, 2013 8:13 am     Reply with quote

Quote:
Sorry my ignorance but unless I haven't seen it in the CCS compiler, *how* do I clear and set the CREN flag? And I never programmed using the assembly code so I don't know how to do this.

Use "ERRORS" and the CCS compiler should do it all for you.
With other 'C' compilers you have to do it for yourself.
The microchip manual has all the details.
The CCS manual shows how to use assembler if you absolutely HAVE to.

Quote:
Sometimes, I will get the #INT_UART1E interrupt and then some other times I will get some weird stuff going-on like the UART just stops responding but then will re-start responding, sometimes my PIC will reboot etc.

When you're getting weird behaviour, add some diagnostics to test for possible causes.

Mike
asmboy



Joined: 20 Nov 2007
Posts: 2128
Location: albany ny

View user's profile Send private message AIM Address

PostPosted: Fri Apr 19, 2013 9:08 am     Reply with quote

is done for you - as the following is called after every attempt to get rs232 chars.

.................... #use rs232(baud=38400, xmit=PIN_C6, Rcv=PIN_C7,ERRORS )
00C2: BTFSS F9E.5
00C4: BRA 00C2
00C6: MOVFF FAB,1F // RCSTA
00CA: MOVFF FAE,01 // RCREG
00CE: BTFSS 1F.1
00D0: BRA 00D6
00D2: BCF FAB.4 //RCSTA RCREN =toggle to re-enable receiver
00D4: BSF FAB.4 // the errors magic code snip
00D6: GOTO 00F8 (RETURN)

and since the KBHIT is set BEFORE an overflow occurs - your code , if written to USE KBHIT , will always try to read, hence call this bit of CREN fixer.
it becomes a can't fail situation with or w/o #INT_RDA buffered or not.

thats a powerful CCS feature that is not automatic in other compilers.
Ttelmah



Joined: 11 Mar 2010
Posts: 19546

View user's profile Send private message

PostPosted: Fri Apr 19, 2013 11:26 am     Reply with quote

If you did need to do it yourself, then you would just define a bit variable as:

#bit CREN=getenv("BIT:CREN")

and then set this to 'FALSE' to disable this, then TRUE to enable it. However you don't want to do this unless the error bits are set, so you end up writing exactly the same code as CCS already does for you with 'ERRORS'.
Let the compiler do it's job. This is something CCS does very well.

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