How to disable EUSART

[Yves]

I cant find in the manual the Declare to disable Eusart. I have seen it in some code but cannot find it anymore. Thank you.

Yves

[trastikata]

I cant find in the manual the Declare to disable Eusart. I have seen it in some code but cannot find it anymore. Thank you.

Not sure why do you need it, the serial port is disabled by default. But to disable or enable it, you can use the SPEN bit in RCSTAx register.

[top204]

By default, a USART is not enabled in a microcontroller, until its SFRs are manipulated.

If the USART declares are used in a program, the USART will still not be enabled, but as soon as a USART command is used in a program, it triggers the compiler to create the setup code for the USART's Baud rate and PPS (Peripheral Pin Select) for suitable devices.

Disabling a USART is not as straightforward as it may seem, and some devices do not fully disable the USART with their assigned enable/disable bits, as I have found quite a few times, and sometimes the whole SFRs need to be cleared, then re-loaded in a specific sequence when the USART is enabled again, especially when PPS (Peripheral Pin Select) is involved. So it is very device dependent on how it is accomplished because of device querks. So is not part of the compiler's language to disable a USART once it has been enabled.

On a recent project using a PIC18F26K40 device, I created a small program that used HRSin and HRsout with the pins and Baud set up Declares in place that matched the project's settings, and looked at the assembler code (Press the F2 key after a successful compile) for the compiler's calculations and SFR loading for the device operating at 64MHz, with a 9600 Baud rate and using PORTC.6 and PORTC.7 as the TX and RX pins. The assembler code that the compiler produced for the USART1 setup was:

Code Select Expand

; UART1_ACTUALBAUD = 9592.33
; UART1_BAUDERROR = 0.08
    bsf BAUD1CON,PP_BRG16
    movlw 0xA0
    movwf SP1BRG
    movlw 0x01
    movwf SP1BRGH
    movlw 0x20
    movwf TX1STA
    movlw 0x90
    movwf RC1STA
; CONFIGURE HRSOUT1 PPS
    movlw _PPS_FN_TX1
    movff WREG,RC6PPS
; CONFIGURE HRSIN1 PPS
    movlw 0x17
    movff WREG,RX1PPS

So then I set about creating two procedures based upon the compiler's calculations and layout to disable and enable the USART at the same Baud and using the same PPS pins:

Code Select Expand

'--------------------------------------------------------------------
' Enable the USART1 peripheral for 9600 Baud at 64MHz operation
' Input     : None
' Output    : None
' Notes     : TX pin is PORTC.6. RX pin is PORTC.7
'             Actual Baud is 9592.33 at 64MHz operation
'             Baud Error is 0.08% at 64MHz operation
'
Proc USART1_HW_Enable()
    BAUD1CONbits_BRG16 = 1
    SP1BRG  = $A0
    SP1BRGH = $01
    TX1STA  = $20
    RC1STA  = $90
    PPS_Unlock()                    ' Unlock PPS
    RC6PPS = PPS_FN_TX1             ' Configure USART1 TX PPS
    RX1PPS = Pin_C7                 ' Configure USART1 RX PPS
EndProc

'--------------------------------------------------------------------
' Fully disable the USART1 peripheral
' Input     : None
' Output    : None
' Notes     : None
'
Proc USART1_HW_Disable()
    BAUD1CONbits_BRG16 = 0
    SP1BRG  = 0
    SP1BRGH = 0
    TX1STA  = 0
    RC1STA  = 0
    PPS_Unlock()                    ' Unlock PPS
    RC6PPS = $00                    ' Set the TX pin back to digital mode
EndProc

With the PIC18F26K40 device, I found that clearing the specific bits of the TX1STA and RC1STA SFRs was not enough to fully disable the USART when the unit was in sleep mode, and found I had to clear, virtually, all of the peripheral's SFRs to make it fully disabled, and the compiler's internal USART calculations did the job for me to find the values to re-enable it. Slightly OTT (Over The Top), but in the project, it was very important to fully disable all the peripherals not required when asleep, in order to keep the sleep current as low as possible, then re-enable them, ready to operate when the device woke up again.

The above sequence of SFR manipulations will change from device to device, but the compiler helps as much a it can when the assembler code is looked at, because it has dedicated functions inside it that try their best to cater for all the twists and turns and changes that microchip have accomplished in making the same periperphal operate on different devices.