SPI Port on Robot Controller

[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.

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

[Dave K.]

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.

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,

[gnirts]

After the fourth post, I really don't understand what's going on here.

Where can I find an introduction to whatever topic is being discussed, especially the last few posts by dcbrown and Dave K.?

Thanks in advance,
Robinson

[Astronouth7303]

Originally Posted by gnirts

After the fourth post, I really don't understand what's going on here.

Where can I find an introduction to whatever topic is being discussed, especially the last few posts by dcbrown and Dave K.?

They've moved off into the technical details of how the controller is wired, the electronics involved, and some signal theory, I think. Not really "programming" anymore.

[dcbrown]

If you visit the IFI site and look for the pdf file:

http://www.ifirobotics.com/docs/anal...al--i-o-rc.pdf

It shows resistors and capacitors conditioning all the io pins of the robot controller. These are between the PIC18F chip and the external pins we can attach to. They're essentially a low pass filter, high frequency noise gets gobbled up by the capacitor. In almost all cases, programmers won't care that they are there... actually they will be happy because these automatically filter off glitches and debounce stuff and the like for you.

http://en.wikipedia.org/wiki/RC_circuit

When programming, if an external sensor sets a 1 or 0 on the input line of the controller, the PIC chip won't see that 1 or 0 for a while. How long it takes for the 0 to be seen as a 1 depends on the RC constant which introduces a delay expressed at tau (t). The wiki page shows the rise/fall times and how many (t) time periods it takes to reach a specific voltage percentage. Tau is R*C.

In practice all this means if you turned an output on and off and on and off etc. very quickly - nothing would happen externally, the on/off transitions are spaced too closely together.

Similarly, if there is an external sensor that is generating very small width pulses it is possible they could be missed because they were filtered off. We're talking 10us or so for inputs, less for outputs.

The whole purpose of the RC network filter in the first place is to take care of the ambient noise picked up on all the attached sensor cables. For the most part, programmers don't care... until. Until we try to use the digital io as a serial data line for communication. In that case we want to know how fast can we pump data bits out one of the digital lines without being filtered off.

The resulting "pulses" since they have long rise and decay times don't look like pulses at all when they are small - much more rounded. This can cause problems when interfacing to raw external digital logic parts which often have requirements of max rise/fall times. To clean them up you can use schmitt triggers which, ... well read the wiki:

http://en.wikipedia.org/wiki/Schmitt_trigger

Bud

[Dave K.]

Originally Posted by gnirts

After the fourth post, I really don't understand what's going on here.

Where can I find an introduction to whatever topic is being discussed, especially the last few posts by dcbrown and Dave K.?

Thanks in advance,
Robinson

The origional post questioned how to do SPI (a synchronous Serial Periphial Interface) with the Robot controller. At the time I responded, I didn't notice that the origional post was a few months old, but the origional question really hadn't been fully explored, so I thought that I'd follow up with a quick example of how one can build interfaces like that with some relatively simple code, and provided some example code that I thought others might find useful.

dcbrown followed up with the correct observation that the RC (resistor capacitor) filtering on the user I/O lines limit the transition rates of the lines, and related personal experience in trying to interface a dual port RAM to the controller for the purpose of tying the RC to one or more other co-processing computers.

Aside from some follow up discussion on the timing considerations one needs to consider, and how to analyze them, I expanded on DC's train of thought in tying co-processing or other I/O devices to the RC and suggested that using an async serial port is much easier to debug.

"chips" with SPI interfaces on them will typically accept moderate to high clock speeds (100's of kHz to several MHz) and can be a very convienent way to expand the capabilitys of a small microcontroller, such as the one used in the IFI RC, without tying up a lot of the I/O pins on the processor itself.

The RC is flexible enough that if you don't consider both the software as well as hardware ramifications when choosing how to interface a more complex periphial to the controller, then you may be setting yourself up for more work than you bargained for... especially if you don't have the proper tools (which could be hardware, software, or a combination thereof) to debug the problem.

dcbrown rightly raised the real world impacts that the hardware RC filtering IFI added were relevant to the discussion and highlight the fact that the software folks need to understand enough about the hardware to take such factors into considersation... likewise, hardware designers need to understand enough about the ramifications of their descisions such that the software doesn't become impossible to impliment.

The bottom line is that interfacing devices with SPI interfaces to the RC is both possible and practical as long as you are careful to consider all of the requirements.

If anyone is interested in more details related to interfacing an SPI device, we can go deeper into the details if you like.

I hope this helps...

[gnirts]

Thank you both for taking the time to explain this, dcbrown and Dave K.

Robinson