Searching \ for '[EE] serial communication between MCUs using two p' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/io/serials.htm?key=serial
Search entire site for: 'serial communication between MCUs using two p'.

Exact match. Not showing close matches.
PICList Thread
'[EE] serial communication between MCUs using two p'
2006\09\16@142546 by Xiaofan Chen

face picon face
Sometimes we need to exchange data between two MCUs through opto
coupler (or magnetic coupler from Analog Device). If both side have SPI or
I2C or UART, then we will normally use these resources. However we may
not have these features (or they have better things to do), then we might
think of using  two port pins for serial communication(software UART).

Here is once question, if we need relative high speed, say to transmit
8 bytes of data (64bits) continuously per 1ms (>=64kbps). We might also
need to use certain encoding method so that it is more immune to noise. Is
this easily doable with small MCUs like small PIC16Fs running the internal
RC oscillator of 8MHz or 4-clock-per-instruction 8051s running at 20MHz
crystal? Is it easily doable with an MSP430 with internal calibrated 16Mhz
oscillator (single clock per instruction but clock tolerance is +/-5% over
all temperature)? Will this kind of serial communication make the MCU
fully occupied?

Regards,
Xiaofan

2006\09\16@153659 by John Chung

picon face
Internal oscillation should not be relied on for
accuracy. In one AVR example, it used a 32,768 crystal
to tune the main clock. When I ramp up to a higher
baud, I got garbage. In the document it claims that it
can improve accuracy and reduce error for a given baud
rate when certain clock osc is being used. You may
want to look at AVR ATmega 169P for some clue. The
subtitle should be "Examples of baud rate settings".

John

PS: Tuning it may be a hassle........



--- Xiaofan Chen <spam_OUTxiaofancTakeThisOuTspamgmail.com> wrote:

{Quote hidden}

> --

2006\09\16@223657 by Denny Esterline

picon face
> Sometimes we need to exchange data between two MCUs through opto
> coupler (or magnetic coupler from Analog Device). If both side have SPI or
> I2C or UART, then we will normally use these resources. However we may
> not have these features (or they have better things to do), then we might
> think of using  two port pins for serial communication(software UART).
>
> Here is once question, if we need relative high speed, say to transmit
> 8 bytes of data (64bits) continuously per 1ms (>=64kbps). We might also
> need to use certain encoding method so that it is more immune to noise. Is
> this easily doable with small MCUs like small PIC16Fs running the internal
> RC oscillator of 8MHz or 4-clock-per-instruction 8051s running at 20MHz
> crystal? Is it easily doable with an MSP430 with internal calibrated 16Mhz
> oscillator (single clock per instruction but clock tolerance is +/-5% over
> all temperature)? Will this kind of serial communication make the MCU
> fully occupied?
>
> Regards,
> Xiaofan

There are several approaches to this. As others have mentioned RC oscillators are not usually stable enough for async serial, but there are plenty of clocked protocols that are workable with RC oscillators. But here's the problem - an 8Mhz PIC is chugging along at 2 MIPS. 2 million/64k leaves about 31 instructions per bit time. Probably not enough to do anything else useful. Find a way to reduce your data needs or get a bigger proccessor.

-Denny



2006\09\17@095227 by Xiaofan Chen

face picon face
On 9/16/06, Denny Esterline <.....firmwareKILLspamspam@spam@tds.net> wrote:
>
> There are several approaches to this. As others have mentioned
> RC oscillators are not usually stable enough for async serial,
> but there are plenty of clocked protocols that are workable with
> RC oscillators. But here's the problem - an 8Mhz PIC is chugging along
> at 2 MIPS. 2 million/64k leaves about 31 instructions per bit time.
> Probably not enough to do anything else useful. Find a way to
> reduce your data needs or get a bigger proccessor.
>

I understand that a small PIC probably does not fit the requirement.
I need to use internal oscillator and a small MCU due to space constraint.
So it seems quite doable to have customized 2-pin half-duplex communication
with a faster MCU like a 20MHz 4-clock 8051 and a 16MHz single-clock
MSP430.

Do you have some examples of "clocked protocols"? My idea is to
embed the clock into the data bits. For example, 1000 will represent "0"
and 1111 will represent "1". The first rising edge is the sync signal.
Does this sound okay?

Regards,
Xiaofan

2006\09\17@121205 by Denny Esterline

picon face
{Quote hidden}

No matter how you encode it that's still a LOT of data to be receiving continuously on a microcontroller. Ask yourself what your going to do with it - you don't have RAM enough to store it - you don't have time enough to do math with it. Look for ways to reduce that data. One example is the NEMA datastream from a GPS unit, it sends out data continually, but most applications simply ignore it and parse out a few relevant details.

Your example above is a possible protocol, probably workable. But notice that you now require several transitions per bit, obviously this requires several more instructions per bit. Even on a 16MIPS MSP430 that's about 250 instructions per bit time. Sounds like a lot, but when you add some looping and jumps to handle protocol bit stuffing, you don't have a lot of free time left.

For other suitable protocols head to your nearest search engine with phrases like "self clocking serial" or "Manchester encoding". You'll find many - here's the wikipedia page on Manchester http://en.wikipedia.org/wiki/Manchester_encoding it's a little sparse but it's a good start.

-Denny


2006\09\17@143237 by Xiaofan Chen

face picon face
On 9/17/06, Denny Esterline <.....firmwareKILLspamspam.....tds.net> wrote:

> No matter how you encode it that's still a LOT of
> data to be receiving continuously on a microcontroller.
> Ask yourself what your going to do with it - you don't have
> RAM enough to store it - you don't have time enough to
> do math with it. Look for ways to reduce that data.
> One example is the NEMA datastream from a GPS unit,
> it sends out data continually, but most applications simply
> ignore it and parse out a few relevant details.

Oh yes the data is continuing dump to the backplane bus and the
upper applications will simple ignore the data unless a COS (change
of state) happens.

The original design uses SPI communication and the data rate
is actually higher and the main MCU will receive the data
from ADC or send out data to DAC and do all the filtering
and some processing of the data. I was thinking of using an ARM7
for the application.

However SPI will require 3 or  4 wires and I will need too many
opto couplers because of the isolation requirement. So I am thinking of
using serial communication. Looks like this is doable but pretty risky.
I might be able to reduce the data to 3 bytes instead of 4 bytes.

Maybe I will forget about using small PICs/MSP430s/AVRs and get
Silicon Lab parts which does have all what I want (16bit ADC,
SPI, hardware UART).

2006\09\17@211215 by Jinx

face picon face
> "Manchester encoding"

As I understand it, encoding in Manchester would double the
number of data bits, but the data could be sent fairly quickly if
the transmitter and receiver's clocks are close enough for the
duration of the packet. However, if the clocks are that close
then you could probably make up some non-self-clocking
protocol that involved a test transmission to align the receiver

A project I'm working on uses Manchester via a radio link. The
transmitter, a 12F675 @ 4MHz, takes 116us to prepare one
8-bit byte of data for transmission as 16 bits of Manchester, and
then there's the shifting out on top of that. On that basis, 8 bytes
@ 8MHz would take at least 464us for the conversion + shifting
out + loops

The following is the Manchester conversion. I don't need speed
in this particular application, as each bit is held for 1ms, but I'd
be interested in a quicker method for future reference

;Data to convert is in W
;Result is in manch_hi and manch_lo

do_byte  movwf   temp0           ;save data byte
        movlw   .8
        movwf   cnt0            ;8 bits per byte

man_loop rlf     temp0           ;test bit
        skpnc
        goto    bit_1

;Bit to convert is 0, put 01 into manchester bytes

        clrc
        rlf     manch_lo
        rlf     manch_hi
        setc
        rlf     manch_lo
        rlf     manch_hi
        goto    dec_loop

; Bit to convert = 1, put 10 into manchester bytes
;
bit_1    setc
        rlf     manch_lo
        rlf     manch_hi
        clrc
        rlf     manch_lo
        rlf     manch_hi

dec_loop decfsz  cnt0            ;do for 8 bits
        goto    man_loop

2006\09\17@222211 by Mike Singer

picon face
Xiaofan Chen  wrote:
> Sometimes we need to exchange data between two MCUs through opto
> coupler (or magnetic coupler from Analog Device).


Why not through CS8900 ETHERNET CONTROLLER?


MS

2006\09\17@223717 by Xiaofan Chen

face picon face
On 9/17/06, Mike Singer <EraseMEznatokspam_OUTspamTakeThisOuTgmail.com> wrote:
>
> > Sometimes we need to exchange data between two MCUs through opto
> > coupler (or magnetic coupler from Analog Device).
>
> Why not through CS8900 ETHERNET CONTROLLER?
>

Because the backplane is not using Ethernet. The adoption of
Industrial Ethernet is actually very slow even now there are
seems to be more and more interests. Still the dominant
fieldbus is Profibus/DeviceNet/Foundation FieldBus/MODBUS/...

2006\09\17@224208 by Kelly Kohls

picon face
Jinx,

>I don't need speed in this particular application, as each bit is
>held for 1ms, but I'd be interested in a quicker method for future
reference

How about this...

do_byte  movwf   temp0           ;save data byte
        movlw   .8
        movwf   cnt0            ;8 bits per byte

        clrf    manch_lo        ;
        clrf    manch_hi

man_loop movlw   1               ;assume we need a 01 pattern
        rlf     temp0           ;test bit
        skpnc                   ;is the bit set?
        movlw   2               ;yes, need a 10 pattern

        iorwf   manch_lo        ;combine with other bits

        rlf     manch_lo        ;make room for next time
        rlf     manch_hi
        rlf     manch_lo
        rlf     manch_hi

dec_loop decfsz  cnt0            ;do for 8 bits
        goto    man_loop

Warning, this code is not tested.  I wrote this while watching the
Cowboys-Redskins game.

Kelly Kohls, N5TLE
Bedford, TX

2006\09\17@224243 by Xiaofan Chen

face picon face
On 9/17/06, Jinx <joecolquittspamspam_OUTclear.net.nz> wrote:

> A project I'm working on uses Manchester via a radio link. The
> transmitter, a 12F675 @ 4MHz, takes 116us to prepare one
> 8-bit byte of data for transmission as 16 bits of Manchester, and
> then there's the shifting out on top of that. On that basis, 8 bytes
> @ 8MHz would take at least 464us for the conversion + shifting
> out + loops
>

Thanks a lot. I think you mean "4 bytes @ 8Mhz will take at least
464us". This is actually not bad at all.

Regards,
Xiaofan

2006\09\17@225402 by Jinx

face picon face
> 8 bytes @ 8MHz would take at least 464us for the conversion
>
> Thanks a lot. I think you mean "4 bytes @ 8Mhz will take at least
> 464us". This is actually not bad at all.

Didn't you have 8 bytes to transfer ? 1 byte @ 4MHz takes 116us
to prepare, so I figured

(116us / (8MHz/4MHz)) * 8 = 464us

Then you have 128 bits to shift out in 536us max. I'm not sure if
you could even do that given the looping and individual bit testing

2006\09\17@225649 by Jinx

face picon face
> Warning, this code is not tested.  I wrote this while watching
> the Cowboys-Redskins game

Good Grief ! That was the half-time show - "A Salute To
Low-Level Data Transfers" ?

2006\09\17@233913 by Jinx

face picon face
> How about this...

I think, by my little bit of testing (and head full of other things),
it's about the same. And <1:0> seem to be missed. Plus for
non-18F you have to add a clrc before each rlf pair

But apart from that Mrs Lincoln, how was the play ?

;-)

But hey, thanks for having a go, and to be fair, you did say it
was untested. The method looks like it could save time, I'm
sure a tweak would do that


2006\09\17@234449 by Regulus Berdin

picon face
Kelly Kohls wrote:
>>I don't need speed in this particular application, as each bit is
>>held for 1ms, but I'd be interested in a quicker method for future
>
> reference
>
> How about this...

Hi Jinx/Kelly,

Unrolled manchester encoding, also untested.

;---------------------------------------
;Manchester encoding
; Input:        W
; Output:        manch_hi:manch_lo
; Cycles:        20 cycles
; by: Regulus Berdin (untested)

manch_encode:
       movwf        temp                ;save to temp

       movlw        B'01010101'        ;assume all bits are 0
       movwf        manch_lo
       movwf        manch_hi

       movlw        B'00000011'        ;setup invert mask
       btfsc        temp,0                ;test bit 0
        xorwf        manch_lo,f        ; invert code if 1
       btfsc        temp,4                ;test bit 4
        xorwf        manch_hi,f        ; invert code if 1
               
       movlw        B'00001100'        ;same as above, repeated 3 times
       btfsc        temp,1
        xorwf        manch_lo,f
       btfsc        temp,5
        xorwf        manch_hi,f

       movlw        B'00110000'
       btfsc        temp,2
        xorwf        manch_lo,f
       btfsc        temp,6
        xorwf        manch_hi,f

       movlw        B'11000000'
       btfsc        temp,3
        xorwf        manch_lo,f
       btfsc        temp,7
        xorwf        manch_hi,f
       
       return

regards,

Reggie
http://www.microelektronics.com

2006\09\18@001413 by Jinx

face picon face

> Unrolled manchester encoding, also untested.
>
> ;---------------------------------------
> ;Manchester encoding
> ; Input: W
> ; Output: manch_hi:manch_lo
> ; Cycles: 20 cycles
> ; by: Regulus Berdin (untested)

That's pretty nifty, quick test with 00, 01, 55, AA, and FF is OK

Xiaofan's conversion would be ~ 200us (8 bytes), which makes
1/4ms more available for transmission

2006\09\18@030319 by Russell McMahon

face
flavicon
face
       JMC - see end - historical memories :-)

{Quote hidden}

Reading the original spec again, this sounds "easy enough" to do on
two pins with a clocked system if half duplex is acceptable. Using a
data pin and a clock pin completely frees you from timing constraints
and makes processor throughput the only speed constraint. As long as
the receiving end can deal with the data the sender can transmit as
fast as it likes. Pauses for eg acquiring a new data word or whatever
become immaterial. Clock stability becomes unimportant.

If you make one line open collector you can allow bidirectional
communications on the clock lead - and you are about to reinvent I^2C
:-). In fact, what you would end up with would be more flexible than
I^2C in this application as here is no addressing and the environment
is tightly defined.

If data is clocked when eg a high level is seen and the receiver must
see the clock go low before another data bit is sent then you have a
fairly foolproof scheme. Debounce could be by explicit timing but as
the data line is driven by a known device any edge glitches are liable
to be of well defined  duration and easily designed into the software
and quite likely will be automatically dealt with by inherent program
delays.
eg  / Loop until clock line goes / input data bit / has a well defined
minimum delay from the clock test read to the data input time and this
will probably be far longer than typical edge transitions. If not then
a 1 instruction delay can be added.

Depending on processor speed it MAY be possible to pass exceptions
without a bi directional port arrangement. eg if you usually always
lowered the clock before changing data or always changed data before
lowering the clock (both with implications which would need to be
looked at) then doing otherwise would signal an exception. This would
be available at any data level transition. Worst case is a long series
of all 1's or 0's but even this could be broken up by having a
protocol which inverted long sequences after a certain number of bits
or something similar.

The above largely assumes that the receiver is always ready and does
not ack each bit, but even this is not essential. In any normal
environment this should be entirely acceptable with error checking
being done at a block size and complexity that suits the application.

Whether it is doable with small uP's "like the PIC16F" depends on the
value of "like". ie it would help if the receiver could push received
data to a hardware stack during reception of a "block", although even
this depends on processor throughput. I long long long * ago made a
system that read data from 8 bit parallel reel to reel digital mag
tape at AFAIR 20,000 words per second using a 4 MHz (1 Mhz cycle,
usually 2 or 3 cycles per instruction ) MC6802 processor. The only way
to do this was to use the stack for data reception during a tape
block. It worked. (Telephone Exchange AMR tapes).

How much do you want to pay for such a subsystem ? :-)



       Russell

* About 1 "long" per decade ;-)


2006\09\18@083742 by Xiaofan Chen

face picon face
On 9/17/06, Jinx <@spam@joecolquittKILLspamspamclear.net.nz> wrote:
> > 8 bytes @ 8MHz would take at least 464us for the conversion
> >
> > Thanks a lot. I think you mean "4 bytes @ 8Mhz will take at least
> > 464us". This is actually not bad at all.
>
> Didn't you have 8 bytes to transfer ? 1 byte @ 4MHz takes 116us
> to prepare, so I figured

I only need to transfer 4bytes.

> (116us / (8MHz/4MHz)) * 8 = 464us
>
> Then you have 128 bits to shift out in 536us max. I'm not sure if
> you could even do that given the looping and individual bit testing
>
>

2006\09\18@105452 by Mike Singer

picon face
Xiaofan Chen  wrote:
> However SPI will require 3 or  4 wires and I will need too many
> opto couplers because of the isolation requirement. So I am thinking of
> using serial communication. Looks like this is doable but pretty risky.
> I might be able to reduce the data to 3 bytes instead of 4 bytes.


UART baud rates: 906 kbaud for MCP2150 and MCP2155 IrDA(r) Protocol
Stack Controller

UART Baud Rates up to 1 Mbps for dsPIC30F1010/202X

With appropriate IrDA transceiver you can communicate at almost 1 Mbps.

Is not it enough for your app?

Regards,
MS

2006\09\18@160144 by Xiaofan Chen

face picon face
On 9/18/06, Mike Singer <KILLspamznatokKILLspamspamgmail.com> wrote:
>
> UART baud rates: 906 kbaud for MCP2150 and MCP2155 IrDA(r) Protocol
> Stack Controller
>
> UART Baud Rates up to 1 Mbps for dsPIC30F1010/202X
>
> With appropriate IrDA transceiver you can communicate at almost 1 Mbps.
>
> Is not it enough for your app?

I am not using IrDA and I can not afford the space and current consumption
of dsPICs. I need a small MCU (perhaps 4x4mm) and it should consume
less than 5mA at the internal oscillator frequency. I've found some Silicon
Labs parts which fit the requirement (C8051F33x/35x).

Regards,
Xiaofan

2006\09\18@180606 by Mike Singer

picon face
Xiaofan Chen wrote:
> I am not using IrDA and I can not afford the space and current consumption
> of dsPICs. I need a small MCU (perhaps 4x4mm) and it should consume
> less than 5mA at the internal oscillator frequency. I've found some Silicon
> Labs parts which fit the requirement (C8051F33x/35x).

With C8051F330 you'll need to implement some custom high speed opto
protocol in software. It's not easy, as for me.

It would be better to get MCU with built in IRDA hardware, like
MSP430F2234 or some of Renessas MCUs.

Regards,
MS

2006\09\18@205837 by Xiaofan Chen

face picon face
On 9/18/06, Mike Singer <RemoveMEznatokTakeThisOuTspamgmail.com> wrote:
> Xiaofan Chen wrote:
> > I am not using IrDA and I can not afford the space and current consumption
> > of dsPICs. I need a small MCU (perhaps 4x4mm) and it should consume
> > less than 5mA at the internal oscillator frequency. I've found some Silicon
> > Labs parts which fit the requirement (C8051F33x/35x).
>
> With C8051F330 you'll need to implement some custom high speed opto
> protocol in software. It's not easy, as for me.
>
> It would be better to get MCU with built in IRDA hardware, like
> MSP430F2234 or some of Renessas MCUs.
>

Opto protocol? No, I guess you are in the wrong direction. I need opto
coupler for isolation. I am not doing any opto communication.

2006\09\20@075645 by Alan B. Pearce

face picon face
>There are several approaches to this. As others have mentioned RC
>oscillators are not usually stable enough for async serial, but
>there are plenty of clocked protocols hat are workable with RC
>oscillators. But here's the problem - an 8Mhz PIC is chugging along
>at 2 MIPS. 2 million/64k leaves about 31 instructions per bit time.
>Probably not enough to do anything else useful. Find a way to
>reduce your data needs or get a bigger proccessor.

rather than use an async or SPI/I2C type interface, is the interface that TI
used for their calculators. uses two pins on each device, is bi-directional,
is self clocking, doesn't depend on processor speeds (faster unit works at
slower processor pace) and can generally be done as a non-interrupt task.
See http://www.ticalc.org/pub/text/calcinfo/link86all.zip and
http://www.ticalc.org/pub/text/calcinfo/ti-prot.zip also has some hardware
info.

2006\09\20@172351 by Mike Singer

picon face
Xiaofan Chen  wrote:
> Opto protocol? No, I guess you are in the wrong direction. I need opto
> coupler for isolation. I am not doing any opto communication.

Yes, opto coupler for isolation, sorry.

MS

More... (looser matching)
- Last day of these posts
- In 2006 , 2007 only
- Today
- New search...