Timing Diagrams

parsko

All,

I am having problems with timing diagrams.· This has been a source of frustration over the past year or so.· I am not an EE, so I don't know how to interpret these diagrams.· When it comes to working with a microcontroller, these timing diagrams are necessary.· When trying to get new hardware setup, these diagrams seem required.

I am trying to create hardware specific objects.· If I need an MCP3001 ADC, I can call the MCP3001 ADC object, knowing that the [noparse][[/noparse]Timing] is okay, and I need only apply the settings I need, and voila!

Would anyone be willing to explain how to apply the timing diagrams to SPI communication?

Has this been explained before in a laymen manner even a dude like me can understand?

Many thanks!

-Parsko

Post Edited (parsko) : 7/24/2006 7:46:02 AM GMT

Mike Green

Well, you're right, timing diagrams can be complicated. The ones you've posted have a lot of lines on them, but let's think about three items ... 1) Anything called "setup", 2) Anything called "hold", 3) Clocks in general

1) Circuits take a certain time for data to propagate through them. There may be a bunch of logic between the package pins and the piece of logic that says internally that the device is addressed and this takes some time for signals to get through and become stable when a change occurs. Usually, there's a pulse (like ALE in your first diagram) that says "There, you've got your address, now act on it". The setup time is the minimum time that must be allowed for all the necessary circuitry to do its thing prior to the start of the pulse. What this means for you is that you have to put the necessary data (address bits, maybe read/write direction, etc.) on the Propellor pins at least Tsetup before you change the ALE pin from zero to one (which signals to the device that the address information is present). The easiest way to do this is to copy the information to the appropriate output pins, use WAITCNT to wait Tsetup, then change ALE from zero to one.

2) Similar to Tsetup, there's usually a T-hold. Again, circuits take some time to act and Thold is the time you have to leave the data on the pins of the device after you've told the device "here it is". For many modern devices, you'll notice that the hold time is zero for a lot of the signals where there is a hold time, but not always. In the case of your first diagram, the setup and hold times are in relation to the zero to one change in ALE. Again, you can use WAITCNT after the ALE zero to one change to guarantee the hold time, then you can change the output pins any way you want.

3) Most devices you'll be interested in are clocked. This means that there's one or more pins that provide timing, sometimes at regular intervals. In your first diagram there's a signal labeled "clock" that provides this regular timing, but there are also pulses like "ALE" and "START" that also clock specific actions in the device. All of these have minimum (and sometimes maximum) time widths. In the first diagram, it looks like both ALE and START are about the same width as a complete clock cycle, but there doesn't seem to be any direct relationship between the ups and downs of the clock and the other signals. This probably means that you could use one of the COG counters to generate a clock of the required speed, then use WAITCNT to guarantee the minimum timings for the pulse widths and the setup and hold times.

Does this help any? Sometimes you can make up a written list of what has to happen in what order, then add the time requirements from line to line where they exist.

parsko

Mike,

Yes, this helps. A few days ago I was on my way to Zwarte Cross in eastern Netherlands. It's a couple hour ride, and I had a really good Saturday with my Prop, so I was thinkin...

I have done extensive "theorectical" work on the Prop, reading like crazy. I have only recently been applying this knowledge. On that car ride, I had a lightbulb moment. I realized the importance of why Parallax recommends a command like "some_object.start(25,26). This is the startup sequence of said object (assuming it starts some external hardware like an ADC). Then, you would have the rest of the important commands, such as "some_object.read_out", "some_object.read_in" etc...

Your thoughts have further reinforced this paradigm in my head. You have made me realize that mose peripherial hardware will act in a similar manner, meaning that once you diagnose the timing diagram, the "sequences" should be pretty staightforward. BUT, one reason I have asked is because I keep readiing in the datasheets that rising edges and falling edges are imporant to take into account on different hardware. Is there a chance you could enlighten me a little on this point?

Thanks,

-Luke

PS- I can't wait to get home to start coding this. I know I am going to have a miserable time, and I'm looking forward to it!

Mike Green

For the kinds of things you are likely to work with, rise and fall times are not going to be an issue. They both are transition times (low to high and high to low). If the driver/source of the signal is too slow, the pulse edge/transition might spend too long a time "in the middle" - in the voltage range defined as the boundary between low and high. Often circuits can be unstable in this region and may oscillate or switch back and forth between sensing a low and a high state even though the input hasn't changed. A minimum rise/fall time is intended to prevent this. Circuits have some delays and the input circuit of a device can only react so fast. If the rise/fall time is faster than that, it can't oscillate in the transition region.

If the driver/source of the signal is too fast, it may cause ringing. The circuit (including the connecting wires) acts as a resonant circuit (capacitor/inductor combination) that is "excited" by the energy of the pulse edge. If this ringing is strong enough, it can cause false triggering of the input circuit. The output pulse edges can be slowed down by adding a small capacitor across the output.

The Propellor's outputs are fast enough for pretty much any device you might use (on the order of a few nanoseconds). They are fast enough to potentially cause ringing. If you keep connections short (a few inches) and straight (not curled up into loops), you are unlikely to have problems. Devices meant to be connected over longer distances (like servos or serial/SPI/I2C devices) usually have input circuitry or timing that is designed to be resistant to ringing.

Paul Baker

In clocked protocols (I2C, SPI etc), the edges of the clock indicate important states. One edge is the transition edge, when data transitions from value to another, this is when the transmitting device alters the value on the data line to the next bit. The other edge is the hold edge, where the data is stable and the value is sampled by the receiver. In your second diagram, the falling edge of the clock is the transition edge, and the rising edge is the hold edge.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
...