Bug in set_uart_speed (18F2525 and 18F2431)

[jlvern_]

CCS PCH C Compiler, Version 3.221, 24699 16-mars-05 09:57


#define XTAL 10000000
#defie BAUDS_HOST 19200
//------------------------------------------------------------------------
// Directives CCS
//------------------------------------------------------------------------
// pas de sleep apr�s le programme
#build(NOSLEEP)
// Les registres de direction NE SONT PAS modifi�s � chaque entr�e/sortie
#use fast_io( a )
#use fast_io( b )


// Indique la base de temps pour les calculs de temporisations
#use delay( clock = XTAL, RESTART_WDT )
// Sp�cifie les lignes d'interfaces s�rie et la vitesse de modulation
#use rs232( baud= BAUDS_HOST, xmit=PIN_C6, rcv=PIN_C7,stream=HOSTPC )


1) 18F2525
.................... set_uart_speed( BAUDS_HOST );
07EC: BSF FB8.3
// False : FB8.3 is BRG16 (for 16 bit timer) not BRGH
// BRG16 need to be 0 and BRGH is in TXSTA (0xFAC)
07EE: MOVLW 81
07F0: MOVWF FAF
07F2: MOVLW 26
07F4: MOVWF FAC


1) 18F2431
// 18F2431 is a different chip : BAUDCON is NOT at the same place
.................... set_uart_speed( BAUDS_HOST );
07EC: BSF FB8.3 // False : FB8 is ANSEL0 !!!
07EE: MOVLW 81
07F0: MOVWF FAF
07F2: MOVLW 26
07F4: MOVWF FAC

[Ttelmah]

Your comments relating to the first chip, are wrong.

1) 18F2525
.................... set_uart_speed( BAUDS_HOST );
07EC: BSF FB8.3
// False : FB8.3 is BRG16 (for 16 bit timer) not BRGH
// BRG16 need to be 0 and BRGH is in TXSTA (0xFAC)

What do you mean 'false'. This sets the system to use the 16bit BRG counter. Though it makes no difference in this case, the compiler defaults to doing this. There is nothing 'wrong' with enabling the 16bit counter, it is legitimate on all chips supporting it. BRG16, does not 'need' to be 0.

07EE: MOVLW 81
07F0: MOVWF FAF
07F2: MOVLW 26
07F4: MOVWF FAC
This sets BRGH, as well as enabling the transmitter.

The value being put into the BRG, results in 19230Hz, for the clock rate you list.
The only fault, is that the code does not clear the high byte of the BRG register. This is potentially dangerous if this has become set...

The second example, is unfortunately fairly typical. Microchip, have become more prone to 'shuffling' registers between chip models than they used to, and sometimes the compiler lags and uses the wrong registers. When the EUSART first appeared, for the first few compiler versions, you either had to program it yourself, or tell the compiler to treat it as a USART.
Just bug report this to CCS. They'll typically fix this in a couple of days.

Best Wishes

[Guest]