8-bit MicrocontrollersのトピックRe: Baud rate selection using internal clock for ESCI

Baud rate selection using internal clock for ESCI

pallav — Sat, 08 Apr 2006 16:38:04 GMT

Hi,

plz guide how will i be able to configure my esci module for RX/TX @ 19200 or 9600 baud , i want to use internal clock. plz tell me the configuration details req.also if it is possible to get 0%error bauds using internal clock or not.

thanks & regards

Pallav aggarwal

Re: Baud rate selection using internal clock for ESCI

peg — Sat, 08 Apr 2006 19:28:12 GMT

Hi Pallav,

The baudrate is simply just divided from the bus clock

baudrate = BUSCLK/16*BR

with high buss clockrates and lower baudrates you can usually get pretty accurate baudrate. To give the exact answer we need to know the actual device as the ICG's vary between devices.

BR Peg

Re: Baud rate selection using internal clock for ESCI

pallav — Sat, 08 Apr 2006 21:16:31 GMT

i am using qb4 device plz suggest all the setting with procedure ..

thanks and regards

pallav

Re: Baud rate selection using internal clock for ESCI

peg — Sun, 09 Apr 2006 12:45:52 GMT

Hi Pallav,

OK, so its more difficult than usual.

baudrate = busclk/64*BPD*BD*(PD+PDFA)

so if you use the fastest internal clock of 12.8MHz which gives a buss of 3.2MHz.

Then you use BPD = 1, BD = 1 and PD = 5 and PDFA = 31/32.

This gives a baudrate of 9687.5 (0.91% high)

When you trim the 12.8MHz osc use a trim 5 lower than suggested which will give you 1% low.

Now you get 9590.6 baud (0.1%low)

You have lots of possibilities here, I would suggest a spreadsheet.

Fudging the clock might screw up other clock related tasks also!

BR Peg

Re: Baud rate selection using internal clock for ESCI

bigmac — Sun, 09 Apr 2006 22:08:24 GMT

Hello Pallav & Peg,

The calculation of ESCI baud rate for the QB devices, as shown in the data sheet, seems rather convoluted to me - I think it can be done somewhat more simply and directly.

Firstly, the required overall division ratio DIV is given by either (Bus_freq/Baud_rate) or (CGMXCLK/Baud_rate) as determined by CONFIG2 setting. Since CGMXCLK is four times Bus_freq, CGMXCLK would be used as the baud rate source for higher baud rates - either 4.0 MHz (default), 8.0 MHz or 13.2 MHz for the internal oscillator.

There are two registers that control baud rate division, the baud rate register (SCBR) and the prescaler register (SCPSC). For the relatively high baud rates using the internal oscillator, and for better flexibility, the prescaler register might generally be used alone, and the baud rate register set for unity division ratio (SCBR = 0). However, there is one special case for CGMXCLK = 8 MHz that may be a useful - 9600 baud should be achieved with reasonable accuracy, using the settings SCBR = 0xC0 and SCPSC = 0.

For the more general case using the prescaler, the modified formula would be
DIV = 2*SCPSC + 64 where SCPSC is the value contained in the SCPSC register, (and assumes BPD = 1 and BD = 1).

So to directly calculate the register value SCPSC = (DIV-64)/2;
The minimum limits on this formula (for the prescaler to be operational) are
SCPSC >= 32 and DIV >= 128.

For example, 19200 baud for CGMXCLK = 4.0 MHz, DIV = 208 (the nearest even number), and SCPSC = 72 (0x48). This gives 19231 baud. Of course, if the calculated SCPSC value should exceed 255, SCBR register will need to be changed (from zero) to further divide the baud clock, and reduce the required SCPSC value.

As far as adjustment of the trimming value for the external oscillator, it will need to be adjusted for the correct nominal frequency. But further adjustment beyond this to manipulate the precise baud rate may be misplaced if the nominal baud rate is within one percent of the correct value.

Bear in mind that there can be +/-2 percent variation of internal clock frequency over temperature and supply voltage range. I am somewhat reluctant to use the ESCI with the internal oscillator for this reason, especially if both ends of the serial link would be subject to similar uncertainty (and could potentially move in opposite directions), or where the design needs to be robust.

I wonder if it would be possible to devise a auto-calibration scheme, perhaps using the arbiter module, to sense the timing of the incoming data stream as a reference. This could permit errors to be determined, and minor corrections to be made "on the fly". Maybe someone has already done this.

Regards,
Mac

Message Edited by bigmac on 04-10-200601:11 AM