JMC - see end - historical memories :-)

> 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?


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 ;-)


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