On Wed, Apr 16, 2014 at 08:33:40PM -0300, Isaac Marino Bavaresco wrote:
> 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 fo=
r
> >>>> the USB port that gets you higher clock rates.
> >>> The internal FRC on the PIC24FJ64GB002 is +1%, -1.25% max, 0.25% typi=
cal.
> >>> This usually isn't good enough for asynchronous comms- while it may w=
ork
> >>> *most* of the time, you need to be aware that it could get out of spe=
c.
> >>> The rule of thumb I use is that the baud rate error could be 10x the =
clock
> >>> 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 w=
ith
> >> low accuracy clocks if you send ***LESS*** bits. Just don't use the to=
p
> >> 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.
>=20
>=20
> Not efficient but could work.
>=20
> 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.
>=20
> 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.
>=20
> Isaac

I did something in the same ballpark for my one way 16F1XXX family of
bootloaders. I wanted:

1) Reliable operation
2) Autobaud detection
3) Ability to operate on any input pin

I used the 3BP protocol that's implemented on the Parallax Propeller serial
loader. It's a reduced bit density, inverted, self clocking, autobauding pr=
otocol
that packs 3 data bits into each transmitted character. Each of the three
data cells are encoded with a start and stop bit:

start/data/stop

3 data bits are encoded by using the standard start and stop bits for the
first and last cell respectively, and programmatically generating the
others. So the data stream (S: Start, s: stop, #: data bit):

S1sS2sS3s

ends up being a 7-N-2 async serial encoding. The extra stop bit gives the
controller some time to process the received byte.

Since the start bit and stop bit have differing polarities, high for start
and low for stop with inverted EIA-232, there's a guaranteed clock
transition in each 3 bit cell.

The system is autobauded by sending a minimum of 128 0/1 data pairs. The
priming code measures the length of the bit cell by averaging the length of
the high data transitions. This average time puts the bit reader right in
the center of the data bit from the start of the start bit.

The protocol looks for a start flag of a minimum of 8 consecutive zero data=
 bits
after priming. Actual data transmission starts with the first 1 data bit
after the zero flag.

It's rock solid with the PIC 16F1XXX internal oscillator because the timer
is reset with each and every start bit. Works up to 115.2K with no
problems.

It doesn't require a hardware serial port to use.

BAJ

--=20
Byron A. Jeff
Chair: Department of Computer Science and Information Technology
College of Information and Mathematical Sciences
Clayton State University
http://faculty.clayton.edu/bjeff
--=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
.