What is different here is that we are using the recovered _receive_ clock to set up the timing constants for our transmission. Actually, in this case the timing constants are timing variables :-) Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software) ----- Original Message ----- From: Martin Hill To: Sent: Wednesday, September 27, 2000 6:54 AM Subject: Re: [PIC]: Asynchronous comms on PIC 12ce519 > I used this exact method for doing a radio link, except that a 1 was > trasmitted as 10 and a 0 was transmitted as 01, basically it just > transmitted lots of 10 sequences to estblish the clock, then sent a > zero to signify start of data. Samples were taken in both halves of > the data transmission with a best of three method, and it was > checked that one was a 1 and one a 0. If there was an error it > aborted the transmission. This was used to transmit sections of > about 64 bytes at a time, and given that the system knows each bit > of data will contain a transition in the middle it makes clock > recovery easy. > > Regards > > Martin > > > > > > > There is one technique that can result in reliable serial comms with an RC > > > oscillator: Use the receive bit timing to establish the transmit bit > > timing. > > > > > > Assume that the device is polled by a PC. Make the poll command start with > > > 0xAA or 0x55 (ie: lots of bit transitions). The target PIC simply > > determines > > > the high-to-high or low-to-low time and divides it by two to compute the > > bit > > > time. I suggest using high-to-high or low-to-low rather than high-to-low > > or > > > low-to-high because there may be unequal rise and fall times depending on > > > the hardware implemention. > > > > > > If the target recomputes the timing on every poll it can handle any > > > reasonable swing of RC clock frequency with Vdd, temperature, day of the > > > week or the phase of the moon. > > > > > > Bob Ammerman > > > RAm Systems > > > (contract development of high performance, high function, low-level > > > software) > > > > > > ----- Original Message ----- > > > From: Spehro Pefhany > > > To: > > > Sent: Tuesday, September 26, 2000 3:10 PM > > > Subject: Re: [PIC]: Asynchronous comms on PIC 12ce519 > > > > > > > > > > At 09:21 AM 9/24/00 -0400, you wrote: > > > > >The original question deals with clock error vs. reliability of the > > link. > > > > > > > > > >I chose to ignore the inherent sampling error due to a non-commensurate > > > > >baudrate/clock rate specifically because the clock rate is no longer > > > > >accurately specified. > > > > > > > > > >Again, assuming you have a fast enough (nominal) clock to sample the > > > signal > > > > >appropriately, and assuming that you actually sample when you should > > (ie: > > > > >you're not buried in some other code at the sample point), then the RC > > > clock > > > > >error vs. baud rate will cause exactly the same problems at any baud > > > rate. > > > > > > > > And the "characterized" not guaranteed clock frequency can be off by > > > almost > > > > 8.75% (low) or 7% (high) over the temperature range at 5V (worse at > > 2.5V). > > > > (page 87, table 13-3). > > > > > > > > So, in 10 bit times (at the beginning of the 11th bit) you can be off by > > > > almost > > > > the entire bit. Well, if you only want to communicate with a PC or > > other > > > > accurate UART, only do it on a workbench at 5V supply, and don't care > > much > > > > about reliability, you can probably get away with it for a few units or > > a > > > few > > > > hundred units. > > > > > > > > Personally, I think it to be irresponsible design, since some units will > > > very > > > > likely fail to work when used over any reasonable temperature range. > > > > > > > > I say- put in the fifteen cent 3-pin resonator, lose the two port pins > > and > > > > make > > > > a reliable product! > > > > > > > > Best regards, > > > > > > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > = > > > > Spehro Pefhany --"it's the network..." "The Journey is the > > > reward" > > > > speff@interlog.com Info for manufacturers: > > > http://www.trexon.com > > > > Embedded software/hardware/analog Info for designers: > > > http://www.speff.com > > > > Contributions invited->The AVR-gcc FAQ is at: > > > http://www.bluecollarlinux.com > > > > > > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > = > > > > > > > > -- > > > > http://www.piclist.com hint: The PICList is archived three different > > > > ways. See http://www.piclist.com/#archives for details. > > > > > > > > > > > > > > -- > > > http://www.piclist.com#nomail Going offline? Don't AutoReply us! > > > use mailto:listserv@mitvma.mit.edu?body=SET%20PICList%20DIGEST > > > > > > > > > > -- > > http://www.piclist.com#nomail Going offline? Don't AutoReply us! > > use mailto:listserv@mitvma.mit.edu?body=SET%20PICList%20DIGEST > > > > > > -- > http://www.piclist.com#nomail Going offline? Don't AutoReply us! > use mailto:listserv@mitvma.mit.edu?body=SET%20PICList%20DIGEST > > -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! use mailto:listserv@mitvma.mit.edu?body=SET%20PICList%20DIGEST