??? 10/10/08 14:55 Read: times |
#158956 - An Alternative... Responding to: ???'s previous message |
Since you seem to want to consider doing an MCU to MCU communications link with software and just a couple of wires between the two then there is another scheme to consider. Instead of using SPI with its open ended clocking from Master to Slave there is another scheme that I have used countless times that is completely rate adaptive between the two. I've designed the adaptive interface into PC to PC applications, PC to MCU, MCU to MCU, and PC to custom hardware in FPGA. Rate adaptive transfer is nice to use because it is even possible to go out to incredible cable lengths (as long as suitable hardware interface is used) and the communications can still function correctly.
There can be variations to the implementation scheme but the most straight forward one is to have two lines used for handshaking and two more for data bits transfer. Signal directions are one handshake line each way and one dara line each way. The master signals to slave that a data bit is ready by putting a bit on its data line and the changing the state of the handshake line. The slave eventually sees the handshake line level change and takes in the data bit from the data line. The slave answers back "got that bit" by then toggling the state of the return handshake line. The master does not take action for the next bit until it has recognized the return handshake line state change. Thus the handshake for each bit is complete and interlocked. It is possible in the scheme for the slave to return data back to the master by placing that data on to the return data line before toggling the return data line. Transfers can be synchronized through use of a separate slave select wire or the two handshake lines can be defined to be in an idle state when both high or both low and then a special starting signal pulse can be used to signal start of transfer. Michael Karas |
Topic | Author | Date |
SPI slave | 01/01/70 00:00 | |
high speed? | 01/01/70 00:00 | |
sory for late replay. | 01/01/70 00:00 | |
SPI clock | 01/01/70 00:00 | |
not sure.. | 01/01/70 00:00 | |
the worst possible approach | 01/01/70 00:00 | |
SPI Slave Response | 01/01/70 00:00 | |
further explanation? | 01/01/70 00:00 | |
Fixed speed | 01/01/70 00:00 | |
SPI Timing Diagrams | 01/01/70 00:00 | |
UART Mode 0 - SPI like Serial Shif register | 01/01/70 00:00 | |
uhm | 01/01/70 00:00 | |
to joe | 01/01/70 00:00 | |
your point? | 01/01/70 00:00 | |
you can't fail with software master | 01/01/70 00:00 | |
Unanswerable! | 01/01/70 00:00 | |
really? | 01/01/70 00:00 | |
Intended for/usable for not always identical | 01/01/70 00:00 | |
consideration? | 01/01/70 00:00 | |
Some Questions | 01/01/70 00:00 | |
whichever you choose | 01/01/70 00:00 | |
low cost? | 01/01/70 00:00 | |
if you do not use an interrupt | 01/01/70 00:00 | |
polling? | 01/01/70 00:00 | |
bits/s not packet size | 01/01/70 00:00 | |
speed? | 01/01/70 00:00 | |
bits/s not packet size! | 01/01/70 00:00 | |
500ms? | 01/01/70 00:00 | |
here | 01/01/70 00:00 | |
Yes - I agree | 01/01/70 00:00 | |
issues | 01/01/70 00:00 | |
UART! | 01/01/70 00:00 | |
Not complex - just requiring low baudrate | 01/01/70 00:00 | |
kind of rcorrect | 01/01/70 00:00 | |
Complexity contra recommendable | 01/01/70 00:00 | |
answer | 01/01/70 00:00 | |
as i said | 01/01/70 00:00 | |
lots of them | 01/01/70 00:00 | |
mcu with spi, right here in the thread![]() | 01/01/70 00:00 | |
CodeArchitect. ? | 01/01/70 00:00 | |
no | 01/01/70 00:00 | |
ahhh | 01/01/70 00:00 | |
simulating SS? | 01/01/70 00:00 | |
Interrupts are slower than tight polling | 01/01/70 00:00 | |
wow | 01/01/70 00:00 | |
all about worst-case | 01/01/70 00:00 | |
thanks... | 01/01/70 00:00 | |
missed interrupts | 01/01/70 00:00 | |
correct me.. | 01/01/70 00:00 | |
Fast interrupts | 01/01/70 00:00 | |
thanks... | 01/01/70 00:00 | |
An Alternative... | 01/01/70 00:00 | |
Some Descriptive Information | 01/01/70 00:00 | |
AT89LP2052 has HW SPI | 01/01/70 00:00 |