I'm in the process of defining the protocol to be used from some 'local area' sensors to a PIC processor. In short, this will be PIC-to-PIC communication over a one-way optoisolated interface.
The sensors will be relatively dumb on the communication - that is, they're just going to set there and read whatever they're reading, and then emit a datastream basically consisting of 32 bits of sensor data, repeated at a fairly high rate. I'll probably add some sort of checksum byte as well, etc...
Normally I'd just use fairly low-bitrate async serial for this, and I may still end up back there, but the problem is that often I won't have the luxury of a hardware async port for the receiver. So I'd like to make sure that whatever coding method I use, that it is fairly easy to decode using either an interrupt-on-change type of routine or something similar which doesn't take a lot of cycles on a fairly busy 'host' PIC. The actual bitrate can be relatively low - even a few hundred bits/second should be fine.
I've been looking around and other than async, it looks like manchester encoding might be an option, but I also wouldn't be surprised if i've missed something else.
I'm asking this under the [PIC] tag as I am specifically hoping to find something which is PIC-processor friendly.
I think Manchester would generally be the weapon of choice. If
you don't have enough INT or IOC pins multiple inputs can be
dealt with under timer interrupts. It's all basically waiting and
sampling
I was actually thinking interrupt on change and looking at a timer - realize that there's some potential leading edge noise issues there....
On 8/16/2011 5:18 AM, IVP wrote:
>> manchester encoding might be an option
> I think Manchester would generally be the weapon of choice. If
> you don't have enough INT or IOC pins multiple inputs can be
> dealt with under timer interrupts. It's all basically waiting and
> sampling
>
> Joe
I once developed a protocol that used pulse width encoding to transfer data and power over a single pair of wires. A 90% high pulse was a zero, a 95% high pulse was a one, and an 85% pulse was a special start-of-frame marker so that the receiver would know where the message started in what was a continuous stream of bits. I used the hardware CCP to measure the width of the low-going pulses at the receiver. The bit rate was a scorching 205 bits per second. The system worked perfectly over several hundred feet of cable.
Since, unlike me, you don't need to send power over the same wires, you could use more easily discriminated pulse widths to make the system more jitter-proof so that other activities on the PIC don't mess things up for you. Another nice thing is that the sender can idle the line at any point, even in the middle of a message, by just leaving it in the inactive state.
>
>
> decode using either an interrupt-on-change type of routine or something
> similar which doesn't take a lot of cycles on a fairly busy 'host'
> PIC. The actual bitrate can be relatively low - even a few hundred
> bits/second should be fine.
>
> I've been looking around and other than async, it looks like manchester
> encoding might be an option, but I also wouldn't be surprised if i've
> missed something else.
>
> I'm asking this under the [PIC] tag as I am specifically hoping to find
> something which is PIC-processor friendly.
>
Lost somewhere in the sands of time was an interesting serial protocol used
on TI graphing calculators. There's plenty of good reference material on
Google, but it basically worked like this:
Two bidirectional lines with pull up resistors. The sender starts by pulling
one line low, the receive end acknowledges by pulling the other line low.
They both release and start again. Zero's and ones were signified by which
line the sender pulled low.
Works _very_ well in a busy processor since every bit waits for an ack. Data
rate could be quite high with the addition of interrupts if so inclined.
Opto isolation may be more challenging, but seems workable.
I've always been surprised this hasn't found it's way into more
applications.
I've used both Manchester and MFM techniques. Of these, the MFM was by far the easiest to implement.
My MFM protocol uses 25% duty cycle pulse as a logic zero and a 75% duty cycle pulse as a logic one. My normal protocol uses a period of no data as the strobe (load) signal. That is: a retriggerable timer keeps being reset while data is being received. When the timer expires, the current data packet is accepted as complete.
The protocol originated from way back in the '80s when I was sending bit-mapped 7 segment data to remote LED displays. This was all CMOS logic - no fancy micro anywhere in sight. I just carried the protocol along as I went from CMOS logic to Motorola 680x / hc11, then to PICs.
The downside is that the bandwidth required is about double that of Manchester encoding. For the slow, wired or optical bitstreams that I frequently use, its simply not a problem.
Like Manchester encoding, MFM is tolerant of bit rate errors. A logic zero can increase its pulse width to almost the 50% point without error, a logic one can decrease its pulse width to almost 50% without error. This has allowed simple (and inexpensive) RC clock and timing networks in my very early designs.
Note that the protocol is not limited to byte-sized packets. The early bit-mapped 7-segment data I started using this with used 32 bit packets at about 500 bits/sec, the Pyro control system we used to manufacture (and still being used to this day) uses 160 bit packets @ 25K bits/sec, the rectifier monitoring system we build for Dow Chemical uses 25 bit packets @ 4096 bits/sec. The Dow stuff used to be implemented in 16-macrocell PLDs (Intel 5C060 / Altera EP610) but are now done with 16F676 PICs.
dwayne
At 03:55 AM 8/16/2011, Forrest Christian wrote:
>I'm in the process of defining the protocol to be used from some 'local
>area' sensors to a PIC processor. In short, this will be PIC-to-PIC
>communication over a one-way optoisolated interface.
> Lost somewhere in the sands of time was an interesting serial protocol used
> on TI graphing calculators. There's plenty of good reference material on
> Google, but it basically worked like this:
> Two bidirectional lines with pull up resistors. The sender starts by pulling
> one line low, the receive end acknowledges by pulling the other line low.
> They both release and start again. Zero's and ones were signified by which
> line the sender pulled low.
>
> Works _very_ well in a busy processor since every bit waits for an ack. Data
> rate could be quite high with the addition of interrupts if so inclined.
> Opto isolation may be more challenging, but seems workable.
Yes, I learned about it when I bought a TI-83. I figured it is a very useful protocol to use between PICs, and it is self synchronising, so clock speeds are don't care.
> I've always been surprised this hasn't found it's way into more
> applications.
Just been listening to the link that Harold Halliken posted with the piece on Patent Trolls ... it's probably patented somewhere ...
Em 16/8/2011 13:52, Denny Esterline escreveu: {Quote hidden}
>>
>> decode using either an interrupt-on-change type of routine or something
>> similar which doesn't take a lot of cycles on a fairly busy 'host'
>> PIC. The actual bitrate can be relatively low - even a few hundred
>> bits/second should be fine.
>>
>> I've been looking around and other than async, it looks like manchester
>> encoding might be an option, but I also wouldn't be surprised if i've
>> missed something else.
>>
>> I'm asking this under the [PIC] tag as I am specifically hoping to find
>> something which is PIC-processor friendly.
>>
>
> Lost somewhere in the sands of time was an interesting serial protocol used
> on TI graphing calculators. There's plenty of good reference material on
> Google, but it basically worked like this:
> Two bidirectional lines with pull up resistors. The sender starts by pulling
> one line low, the receive end acknowledges by pulling the other line low.
> They both release and start again. Zero's and ones were signified by which
> line the sender pulled low.
>
> Works _very_ well in a busy processor since every bit waits for an ack. Data
> rate could be quite high with the addition of interrupts if so inclined.
> Opto isolation may be more challenging, but seems workable.
>
> I've always been surprised this hasn't found it's way into more
> applications.
>
> -Denny
Interesting. It could be called "Wiegand with acknowledge". It seems
really very useful.
Em 16/8/2011 14:23, .....alan.b.pearceKILLspam@spam@stfc.ac.uk escreveu:
>> Lost somewhere in the sands of time was an interesting serial protocol used
>> on TI graphing calculators. There's plenty of good reference material on
>> Google, but it basically worked like this:
>> Two bidirectional lines with pull up resistors. The sender starts by pulling
>> one line low, the receive end acknowledges by pulling the other line low..
>> They both release and start again. Zero's and ones were signified by which
>> line the sender pulled low.
>>
>> Works _very_ well in a busy processor since every bit waits for an ack. Data
>> rate could be quite high with the addition of interrupts if so inclined.
>> Opto isolation may be more challenging, but seems workable.
> Yes, I learned about it when I bought a TI-83. I figured it is a very useful protocol to use between PICs, and it is self synchronising, so clock speeds are don't care.
>
>> I've always been surprised this hasn't found it's way into more
>> applications.
> Just been listening to the link that Harold Halliken posted with the piece on Patent Trolls ... it's probably patented somewhere ...
The patent is probably expired or expiring, this model was released 15
years ago. The protocol hopefully may be even older.
planet.eon.net>
