Em 16/04/2014 19:22, Jan-Erik Soderholm escreveu:
> smplx wrote 2014-04-16 23:56:
>>
>> On Tue, 15 Apr 2014, Matt Bennett wrote:
>>
>>> On Mon, April 14, 2014 10:04 pm, Larry Bradley wrote:
>>>> Just got one the other day.
>>>>
>>>> They use the internal RC oscillator. The 24F chip has a basic 8 mHz
>>>> clock, rated at 0.25% accuracy, I think. There is an on-board PLL for
>>>> the USB port that gets you higher clock rates.
>>> The internal FRC on the PIC24FJ64GB002 is +1%, -1.25% max, 0.25% typica=
l.
>>> This usually isn't good enough for asynchronous comms- while it may wor=
k
>>> *most* of the time, you need to be aware that it could get out of spec.
>>> The rule of thumb I use is that the baud rate error could be 10x the cl=
ock
>>> error (since there are 10 bit-times in a standard N81 serial stream).
>> Not to rain on anyone's parade, but you can get reliable async comms wit=
h
>> low accuracy clocks if you send ***LESS*** bits. Just don't use the top
>> bits of each byte and pack your message into the bits you can rely on
>> (the lower ones).
>>
>> Regards
>> Sergio Masci
>>
> Or, if seen with serial eyes, the first 4 bits after the startbit. :-)
>
> You could even send a byte bit-by-bit in the first bit of 8 separate
> bytes sent after each another. .-)
>
> And make sure not to signal "framing" or "overrun" errors back
> to the application! :-)
>
> Jan-Erik.


Not efficient but could work.

Send the first 4 bits =3D value ( 4 times the same 1 bit or 2 times 2
different bits or 1 time 4 different bits, depending on the allowable
baud-rate error) and the last 4 bits =3D 1, so you would never get a
framing error.

Leave some idle time between transmitted bytes to allow for TX-side
baud-rate faster than RX-side baud-rate so the RX side will always
receive a valid stop-bit.

Isaac

--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.