Discussion on how to do REALLY fast comms with the prop
pedward
Posts: 1,642
So I've been thinking about how to do REALLY fast serial. The fastest code right now is 10Mbits, because it takes 8 clocks for 1 bit. The problem is that you need to do a test, then rotate carry left. I was thinking that using the timer in capture mode might solve the test problem, but I haven't struck on exactly the right way.
So here's the pseudo idea:
Counter is setup in capture mode, it accumulates when the bit is high, not when low. Ideally I want to use the PHS register as the data source in an operand. I was thinking perhaps chaining 2 counters together would work, one captures high, the other low, so you capture each bit state.
The trick is what FRQ value to use to get what you want. If the counter did multiplication/bit shifting instead of accumulation, it would be trivial.
Here's something that popped in my head: Let's say we are receiving 32 bits, we need $FFFF_FFFF / 32 as the accumulation value, then the PHS of one counter will bit shift, giving us the bit position. Then we have the value in the other CTR.
Hmm, one counter setup to count from 0 to $FFFF_FFFF in 32 * 4 clocks, or $FFFF_FFFF >> 7
I dunno, I'm just mulling ideas, perhaps this might trigger an aha! moment for someone else and they see the missing part? The best case speed is 20Mbps with 1 COG. You could probably sync 2 or more COGs with a hubop to get them 1 clock cycle or 2 out of phase, in the code, since there are no alignment ops or NOPs to do this.
So here's the pseudo idea:
Counter is setup in capture mode, it accumulates when the bit is high, not when low. Ideally I want to use the PHS register as the data source in an operand. I was thinking perhaps chaining 2 counters together would work, one captures high, the other low, so you capture each bit state.
The trick is what FRQ value to use to get what you want. If the counter did multiplication/bit shifting instead of accumulation, it would be trivial.
Here's something that popped in my head: Let's say we are receiving 32 bits, we need $FFFF_FFFF / 32 as the accumulation value, then the PHS of one counter will bit shift, giving us the bit position. Then we have the value in the other CTR.
Hmm, one counter setup to count from 0 to $FFFF_FFFF in 32 * 4 clocks, or $FFFF_FFFF >> 7
I dunno, I'm just mulling ideas, perhaps this might trigger an aha! moment for someone else and they see the missing part? The best case speed is 20Mbps with 1 COG. You could probably sync 2 or more COGs with a hubop to get them 1 clock cycle or 2 out of phase, in the code, since there are no alignment ops or NOPs to do this.
Comments
To answer your question, I don't have numbers for arbitrary distances between prop chips at this speed.
<FWIW> I have not played this much with the counter yet, just used it in the ADC master clock generator. </FWIW> That being said, it may depend upon your definition of bit rate. i.e. continuous, burst, simple bit rate independent of the actual bytes/s. That is theoretically, you could set up a counter as the master syncronous clock for all cogs on the chip, and then use syncronous transfer to achieve a 120Mb/s transfer rate for a 4 bytes sent as a single 32bit stream. Closer to reality would be an average rate accounting for the processing even if it is only one or two instructions to move the value from the counter to a register or the other way for transmit. Could do full duplex between different cogs if careful with pins used for xmit and rcv. four cog transfer paralleled could possibly achieve 560MB/s burst with handling of the values between each transfer reducing the AVERAGE rate of transfer. Going off chip, again counter and multiple cogs could do some nice tricks, but the hardware is beyond my level of doing.
Just more odd ideas,
Frank
That was almost exactly what was rotating through my brain! It's the A&B plus the "maintenance". I was thinking of rotating PHS, but it was the A&B that makes the magic! Thanks!