Quote:
Originally Posted by dcbrown
Dave,
All the stuff I've been doing is bi-directional so I'm constrained by the input delay on paired i/o lines. So yes, if you are only using SDO and don't care about SDI on the SPI interface then I guess you can quick clock just to get the shifted data out. I'd still put a scope on the line. I never got my stuff to work cleanly and looking at the output pulses guessed that it was becuase they looked more like slow rise sine waves than digital data/clock signals.
Might get away with 2t, which is still ~13%/86% levels?, if using schmitt trigger buffers (why did I say schottky?! before) to clean up the pulses.
|
It must have been late, because although I knew what you meant, I also gave credit to Schottky rather than Schmitt for the hysteresis you were referring to.
Yes, 2T should be ok, and 3T is conservative.
Quote:
Originally Posted by dcbrown
Line 1-6 are least filtered because they are the external interrupts lines also. So using them up could mean other issues pop up.
I was looking at using a small dual port ram and address blocking. Each co-processor would have their own dual-port ram chip but only part of the address space would be decoded - say 16 bytes. They would have their data lines tied together so the robot controller can access all the data but wouldn't know it was reading chunks from different chips. I was using the analog lines for the interface because that was one of the things I wanted to off-load to another processor anyway. Still bit banging, but bit banging bytes! At least that's the theory.
Bud
|
Whether we consider your dual port ram scenario, or something like an SPI communications path, it would probably be a good idea if one had ready access to a logic analyzer to make sure all of the timing requirements are met. Validating something like that with just a two channel storage scope can be time consuming and may not show you enough to recognize what the problem is.
For something like inter-processor communication, I'd suggest that using the TTL serial port and converting to RS-485 or RS-422 to make multi-drop inter-processor communication that much easier.
As long as one is careful, uses balanced/twisted pairs, properly terminates the line, and perhaps uses shielded (but low capacitance) cabling, there's no reason that the serial channel couldn't be run at the highest bit rate possible if low latency was a concern. A high bit rate approach likely means not handling serial communications via interrupt routines, which may be a good thing, or bad thing depending upon your overall design.
If latency isn't a large concern, then a more conservative bit rate like 9600 or 19200 would probably be better, and use interrupt routines to handle the serial port.
Above all, build a check byte or word into the protocol. CRC's are better, checksums are ok. I generally keep a count of discarded packets, and find a way to make things like that available for debugging.
This approach is something I've been considering to add sensors that would otherwise be more of a challange to add directly to the RC's I/O and/or to offload the RC by moving some data pre-processing on another CPU.
For serial debugging, I've used software products by "Front Line Test Equipment"
http://www.fte.com for about 15 years. Sometimes the simplicity of their old DOS based "Serial Test" product coupled with an old laptop, is easier than the complexity of the newer, Windows based stuff, but those products are very good as well, and you can build your own protocol decoders to make the display of your own serial protocol that much easier.
As I'm getting a bit far afield from the origional poster's question, I'll cut the async discussion here and if anyone wants to pick that up, a new thread is probably best.
Thanks,