Sign in

username:

password:



Not a member?

Search Comp.Arch.Embedded



Search tips

embedded by Keywords

68HC11 | 68HC12 | 8051 | 8052 | ARM | ARM7 | Asic | AT91 | AT91RM9200 | Atmel | AVR | AVRStudio | Bootloader | CFP | CompactFlash | Cygnal | Cypress | Dataflash | DSP | eCos | EEPROM | Embedded Linux | Emulator | Endian | Ethernet | Firewire | FPGA | Freescale | GCC | GNUARM | GSM | H8 | HDLC | I2C | Infineon | Interrupts | Java | JTAG | LCD | LED | LPC2000 | MCU | Microchip | MMC | MPLAB | MSP430 | PC104 | PCB | PCI | PCMCIA | PowerPC | Rabbit | RS232 | RS485 | RTOS | SBC | SDRAM | Sensor | SPI | STK500 | UART | UML | USART | USB | Verilog | VHDL | VxWorks | Xilinx

Ads

Discussion Groups

Discussion Groups | Comp.Arch.Embedded | How accurate/tolerant is the PIC USART clock rate?

There are 11 messages in this thread.

You are currently looking at messages 10 to 11.

Re: How accurate/tolerant is the PIC USART clock rate? - CBFalconer - 17:24 21-08-06

"p...@hotmail.com" wrote:
> Wolfgang Mahringer wrote:
>
... snip ...
>>
>> Obvioulsy, you should ensure that your last transmitted
>> bit is not more than a half bit time away.
>>
>> But, believe me, please do yourself a favour and use
>> the correct clock frequency.
> 
> That is not my problem.  I intend to use the PIC USART as expected. 
> My questions were about its capabilites to connect effectively with
> a source I do not control.  There appears to be very little technical
> data available on the PIC website aboiut the guts of the USART.

Then you might indulge in some experiments.  A worst case would be
some sort of pattern when the last tranmitted bit is opposite to
the stop bit.  You can connect the PIC USART to a test UART, and
supply that UART with a continuous stream of the worst cast
pattern.  UARTs generally have an independent clock input pin, so
all you need do is vary that frequency about the nominal until
errors appear.  Measure that frequency.  That will give you an
accurate picture of the tolerance available, but not the noise
rejection.

In fact, you should be able to make the PIC itself generate the
test clock.  That will keep it locked to the actual PIC frequency. 
This, of course, will require that that clock is considerably lower
than the main PIC clock, which should be no problem.

-- 
Chuck F (c...@yahoo.com) (c...@maineline.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>; USE maineline address!





previous | 1 | 2