Sign in
Search piclist
Subscribe to piclist
piclist by Keywords
12F675 | 16F628 | 16F84 | 16f877 | 16F877A | 16F88 | 18F458 | ADC | AVR | Bootloader | CAN | CCS | CRC | EAGLE | EEPROM | ICD | ICSP | IDE | JDM | LED | Macros | Microchip | MPLAB | PCB-CAD | PIC10F | Pic12f675 | PIC16F84 | PIC16F84A | PIC16F877 | PIC18 | PIC18F452 | PicBasic | PICC | PICSTART | PWM | RS-485 | RS232 | SMT | SPI | UART | USART | USB | Wireless | Wisp628 | Xilinx
Ads
Discussion Groups
Discussion Groups | Piclist | Re: Re: 12F675 Startup Problems
A discussion group for the PICMicro microcontroller. Also called the Microchip PIC, this list is dedicated to the use and abuse of this fine, simple, microcontroller. Close to topic posts are welcome, ie. general electronics.
Re: Re: 12F675 Startup Problems - dlc - Dec 8 10:43:40 2007
And that start bit depends upon the the stop bit of the previous
byte. The longer the string transmitted, the more time drift has to
have an effect. I admit that my experiences have to do with _reading_
async serial using the RC oscillator where my bit-banged serial reader
is likely more affected by drift than a hardware UART reading any serial
that I'm transmitting.
DLC
smxcu wrote:
> --- In p...@yahoogroups.com, dlc wrote:
>
>>I have run serial comms at 9600 baud and lower using Microchip internal
>>RC oscillators quite successfully for years. The secret is to keep
>
> your
>
>>dialog length very short, one or two bytes at a time so that clock
>
> drift
>
>>won't affect your data much.
>>
>>DLC
> Hi DLC,
>
> I must stress here that it is not the length of the packet that
> compensates for the use of an inaccurate oscillator but the start bit
> of each character sent. The leading edge of the start bit is what
> causes the receiver to reset its timer. This happens for every
> character that is sent. Keeping the packets short has no effect on
> this re-sync.
>
> Regards
> Sergio Masci
>
> http://www.xcprod.com/XCSB
> .
>
> to unsubscribe, go to http://www.yahoogroups.com and follow the instructions
>
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
byte. The longer the string transmitted, the more time drift has to
have an effect. I admit that my experiences have to do with _reading_
async serial using the RC oscillator where my bit-banged serial reader
is likely more affected by drift than a hardware UART reading any serial
that I'm transmitting.
DLC
smxcu wrote:
> --- In p...@yahoogroups.com, dlc
>
>>I have run serial comms at 9600 baud and lower using Microchip internal
>>RC oscillators quite successfully for years. The secret is to keep
>
> your
>
>>dialog length very short, one or two bytes at a time so that clock
>
> drift
>
>>won't affect your data much.
>>
>>DLC
> Hi DLC,
>
> I must stress here that it is not the length of the packet that
> compensates for the use of an inaccurate oscillator but the start bit
> of each character sent. The leading edge of the start bit is what
> causes the receiver to reset its timer. This happens for every
> character that is sent. Keeping the packets short has no effect on
> this re-sync.
>
> Regards
> Sergio Masci
>
> http://www.xcprod.com/XCSB
> .
>
> to unsubscribe, go to http://www.yahoogroups.com and follow the instructions
>
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
Re: 12F675 Startup Problems - smxcu - Dec 9 8:51:53 2007
--- In p...@yahoogroups.com, dlc wrote:
>
> And that start bit depends upon the the stop bit of the previous
> byte. The longer the string transmitted, the more time drift has to
> have an effect.
This is not correct. The stop bit is there to ensure that there is a
level transition between the last data bit and the start bit of the
next byte. Some USARTs will flag an error if the stop bit is not seen
(called a framing error). What happens next depends on the particular
USART.
When the protocol does not include a stop bit, the start bit is
useless and sync bytes need to be injected into the data stream to
allow synchronization. This is the synchronous mode of the uSart as
opposed to the asynchronous mode of the usArt. In synchronous mode
there are no start or stop bits.
Microchip uses the term 'synchronous mode' to mean a serial port with
an external clock e.g. SPI and I2C
> I admit that my experiences have to do with _reading_
> async serial using the RC oscillator where my bit-banged serial reader
> is likely more affected by drift than a hardware UART reading any
serial
> that I'm transmitting.
Asynchronous bit timing is always synchronized with the leading edge
of a start bit (any and all). I would advise you to consider this in
your next bit-banged serial reader.
Regards
Sergio Masci
http://www.xcprod.com/XCSB
.
to unsubscribe, go to http://www.yahoogroups.com and follow the instructions
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )
>
> And that start bit depends upon the the stop bit of the previous
> byte. The longer the string transmitted, the more time drift has to
> have an effect.
This is not correct. The stop bit is there to ensure that there is a
level transition between the last data bit and the start bit of the
next byte. Some USARTs will flag an error if the stop bit is not seen
(called a framing error). What happens next depends on the particular
USART.
When the protocol does not include a stop bit, the start bit is
useless and sync bytes need to be injected into the data stream to
allow synchronization. This is the synchronous mode of the uSart as
opposed to the asynchronous mode of the usArt. In synchronous mode
there are no start or stop bits.
Microchip uses the term 'synchronous mode' to mean a serial port with
an external clock e.g. SPI and I2C
> I admit that my experiences have to do with _reading_
> async serial using the RC oscillator where my bit-banged serial reader
> is likely more affected by drift than a hardware UART reading any
serial
> that I'm transmitting.
Asynchronous bit timing is always synchronized with the leading edge
of a start bit (any and all). I would advise you to consider this in
your next bit-banged serial reader.
Regards
Sergio Masci
http://www.xcprod.com/XCSB
.
to unsubscribe, go to http://www.yahoogroups.com and follow the instructions
(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )