[FYI] single wire high speed serial link (updated 20110514)
kuroneko
Posts: 3,623
Inspired by [thread=99222]this thread[/thread] and because I have a thing with counters I came up with a proof of concept driver which receives a long (32bit) in 38 instructions over a single wire (32 for the actual bits including assembly and 6 for maintenance).
Transmitter
Nothing to see here really, the value to be sent is rotated in front of the output bit in OUTA. Data format is 2 start bits (1/0), 32 bits payload and 1 stop bit (0).
Receiver
CTRA runs in 25% duty single-ended mode and delivers the gate pulse (one pulse every 4 cycles). CTRB runs in logic A&B mode (A is the gate pulse and B is the incoming data). The useful side effect is that FRQB is now accumulated into PHSB every 4 cycles if the incoming data bit is 1. However, this also means we have to adjust FRQB every 4 cycles to present the correct bit pattern which is done by simply shifting it down.
The attached source itself contains both subroutines and a simple test which starts one cog and tells it to transfer a given value. Then it starts another cog which receives the value and compares it against an expected value. As I develop on the Hydra, successful transfer will light up game pad 0 (the LED that is).
Update 20101124: I was kind of fed up with the inaccuracy of single pulse sampling so I borrowed some code from the [thread=125046]Countiplier[/thread] and rewrote the link driver. It's now happy with a single pin for the receiver and doesn't suffer from internal chip delays. My demoboard just finished a successful run sending a complete LFSR (2.6 hours @80MHz) over the link. Code is attached.
Update 20110209: Added a more ready-to-use demo archive (proplink). Removed unreliable implementation (still available on request).
Update 20110514: Increased net transfer rate. Also, moved this thread from POC to FYI.
- The receiver requires 2 pins, one for the actual data, another for a counter controlled gate pulse.
- The result is ready for consumption in PHSB and ATM not stored anywhere else.
- The transmitter is happy with a single output pin.
Transmitter
Nothing to see here really, the value to be sent is rotated in front of the output bit in OUTA. Data format is 2 start bits (1/0), 32 bits payload and 1 stop bit (0).
Receiver
CTRA runs in 25% duty single-ended mode and delivers the gate pulse (one pulse every 4 cycles). CTRB runs in logic A&B mode (A is the gate pulse and B is the incoming data). The useful side effect is that FRQB is now accumulated into PHSB every 4 cycles if the incoming data bit is 1. However, this also means we have to adjust FRQB every 4 cycles to present the correct bit pattern which is done by simply shifting it down.
The attached source itself contains both subroutines and a simple test which starts one cog and tells it to transfer a given value. Then it starts another cog which receives the value and compares it against an expected value. As I develop on the Hydra, successful transfer will light up game pad 0 (the LED that is).
Update 20101124: I was kind of fed up with the inaccuracy of single pulse sampling so I borrowed some code from the [thread=125046]Countiplier[/thread] and rewrote the link driver. It's now happy with a single pin for the receiver and doesn't suffer from internal chip delays. My demoboard just finished a successful run sending a complete LFSR (2.6 hours @80MHz) over the link. Code is attached.
Update 20110209: Added a more ready-to-use demo archive (proplink). Removed unreliable implementation (still available on request).
Update 20110514: Increased net transfer rate. Also, moved this thread from POC to FYI.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps (SixBladeProp)
· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz
Now, must PIN_CxD (clock/4) be made an output to work? I am wonderng if there is an internal connection, or does it have to definately go out onto the pin to work?
Going to have to work a way to do send and receive in the same cog. Then I only have to get a protocol for more than 2 props - easy to do with delays - just send a couple of bits for an address, etc, a few stop bits for the other end to handle, then spit out the 32 bits. Could be multiple 32 bits with stops in between. No need to resync with tied oscillators.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps (SixBladeProp)
· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz
However, as you said it wastes a pin (I tried it just in case there was an internal connection) :-(
So I guess I have 3 choices
* Kuroneko's method - fastest 20Mbps and wastes a pin
* Beau's method - next fastest 10Mbps
* Baggers' method - FullDuplex at 1.7Mbps?
The first two are simplex - i.e. they can't send and receive at the same time.
Maybe I have to use a pair of pins and Baggers method, and if a large block is needed then upgrade on the fly to Kuroneko's for the block and step back down.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps (SixBladeProp)
· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz
The choice between baggers method and Kuroneko's method should be tested using two subroutines.
The first encapsulates baggers method. The second invokes Kuroneko's method.
Starting off with baggers method and reaching some inflection point to call Kuroneko's method will simplify testing.
Then a sliding window can be coded switching between the two methods depending on baudrate.
Perhaps I will code all three ( including Chips method ), and make the determination myself.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
Can anyone provide a link to "Baggers' method"? Being able to pump data between a PC and a USB Protoboard at 1Mbps full duplex (1.5Mbps if the USB chip supports it?) would be NICE.
Marty
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lunch cures all problems! have you had lunch?
Post Edited (Lawson) : 6/3/2009 9:46:52 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.com
“Before you criticize someone, you should walk a mile in their shoes. That way when you criticize them, you are a mile away from them and you have their shoes.” - Jack Handey.
This doesn't mean that 20Mbaud receivers are impossible, just a bit more expensive in terms of h/w
a 0 in this context doesn't mean it's not there, it's just too short to be noticed by the active clock edge.
So in other words, under some corner cases that should be documented in an errata, it does not do what it says on the tin?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"
The video generator can be used to generate bitstreams between 2Kbps and 128Mbps (assuming you can feed the WAITVID that fast). 1-32 bits per WAITVID - fire & forget. The only problem I can see is it doesn't stop sending bits even if your code doesn't do a WAITVID. So great for streaming, not so good for intermittent data transmission.