Daisy Chain and Handshake

[gstro]

Most everyone is familiar with the implementation of the daisy chain discovery but I wanted to provide more detail and solicit some feedback on the implementation.

Here is a diagram of 5 blocks to show their connections:

A gif animating a new block connection is shown below The steps are outlined here:

• For this, a new block is considered a slave and an existing block is considered a master.
• Though the lines from_left and from_below are typically inputs for a slave block, they are initialized as outputs to signal whichever block supplied it power (master from left or below).
• It cycles between from_left and from_below signals until a response is read on the s_clk and s_di lines.
• This initiates a custom handshake meant to filter noise and unintended signals.
• After the handshake has completed, the slave block receives its vector (through traditional software SPI).

Finally, I've included a timing diagram of that custom handshake:

My first code for the daisy chain ran this whole process with a different handshake. It worked most of the time, but it wasn't very robust. I haven't yet implemented the new handshake but will be working on that soon. I suppose that will be the true test -- how well it works on hardware -- but I wanted to propose this updated handshake to the rest of the group, including @erebuslabs and @profroyk, to see if there were any glaring issues. Are there important notes to keep in mind when switching a pin like this, other than allow for plenty of time?

[gstro]

FINALLY GOT IT

So the chaining structure and algorithm are solid, but I had to make some adjustments to the actual handshake. The updated version looks pretty similar but requires the master to acknowledge the pin-switch by pulling the corresponding SELECT low with DATA low and then providing a CLOCK pulse. This allows the other slave block to witness the handshake but not complete the sequence, thus returning to toggling its SELECT lines. Ultimately, I had to allow a bit of extra time for that switch, as well as keep (better) track of the triggering lines.

A logic analyzer snapshot of two blocks receiving the vector (0, 1) is shown below: To Above Block

To Right Block

1. Shown first is the slave blocks toggling on the m_t_above and m_t_right lines (connected to slave blocks' from_below and from_left pins respectively)
2. Next the m_t_above line, acting here initially as a master input and slave output, triggers the m_data and m_clk to go high, starting the handshake.
3. From this, the slave m_t_above line is triggered low, and the master m_data and m_clk follow.
4. Next, the slave block again brings the m_t_above line high, waits for a brief period, then releases the pin as an output, and changes it into an input aka from_below.
5. The master block registers that rising edge, adds its own short delay, and changes its m_t_above from input to output, and then sinks the current to output a low.
6. Finally, the master block pulses the m_clk with m_data and m_t_above held low. This completes the handshake and allows the master to send then its vector to the slave over traditional SPI w/ a select that idles low.
7. The whole sequence is repeated when the other slave returns to toggling the m_t_right line (its from_left), allowing both blocks to receive the same vector and increment appropriately.

Some features:

• _Completely hot-swappable_ - plug and unplug as you want. Important design goal.
• Both blocks _identified in under 1 second_. These are software clock signals and can likely be sped up a reasonable amount. (Though the sight of a large chain of LEDs lighting up as this sequence spreads would be cool).
• _Deterministic_ - The algorithm acts as a state-machine and will advance the handshake states in a predictable way and retry after failures.

I will try cleaning up the code a bit and integrate with the global bus on the proto-blocks soon. The passed vector will simply replace the hardcoded address values so it shouldn't be a big task. Thanks @htylo and @Debrant for talking it through with me. And thanks again @profroyk for the logic analyzer, it was a big help.