View previous topic :: View next topic |
Author |
Message |
benoitstjean
Joined: 30 Oct 2007 Posts: 566 Location: Ottawa, Ontario, Canada
|
#USE RS232 with ERRORS flag |
Posted: Thu Apr 18, 2013 8:29 am |
|
|
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
|
|
Posted: Thu Apr 18, 2013 1:38 pm |
|
|
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
|
|
Posted: Thu Apr 18, 2013 2:40 pm |
|
|
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
|
|
Posted: Fri Apr 19, 2013 7:44 am |
|
|
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
|
|
Posted: Fri Apr 19, 2013 8:13 am |
|
|
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
|
|
Posted: Fri Apr 19, 2013 9:08 am |
|
|
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
|
|
Posted: Fri Apr 19, 2013 11:26 am |
|
|
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 |
|
|
|