Propeller DEMO : (14.5 Meg Baud) High Speed Prop-to-Prop Serial Communication
Beau Schwabe
Posts: 6,568
NEW 12/12/2007
14.5 Meg Baud Upgrade
Ok, beta testers... I have run this DEMO and tested over 100 Billion data Bits with no Transmission Errors over the distance of 10 feet from one Propeller to another Propeller.
Here is a beta release before I place it in the object exchange. ...· Enjoy!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 12/12/2007 6:27:49 AM GMT
14.5 Meg Baud Upgrade
Ok, beta testers... I have run this DEMO and tested over 100 Billion data Bits with no Transmission Errors over the distance of 10 feet from one Propeller to another Propeller.
Here is a beta release before I place it in the object exchange. ...· Enjoy!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 12/12/2007 6:27:49 AM GMT
787 x 746 - 114K
Comments
I'm picturing two props linked by their propplug port with a slightly modified cdrom audio cable... heh..
Thanks for this!
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just getting started with Propeller?
Propeller Cookbook
PropDOS
One question: did you have the two props running off the same clock, or were they using independent clocks? If they're using independent clocks, drift may become an issue with this circuit. Assuming 1% drift, you might be out of phase by 34 ns by the time you reach the stop bit. That will be more than the 25 ns margin you have from the starting edge (actually less, since there's a sampling setup time involved).
If it's possible to skew the sampling by one cycle so you're in the middle of the bit, that would give you more margin.
I was thinking of something similar earlier, but with only one start bit, and more than one 32 bit word before the stop bit
Hmmm... two waitpne's in a row should take 10 cycles, positioning the "sampling point" right in the middle of 100ns bit cells... smart!
I even considered a faster version, where a long would be compiled into a series of set/clear tx bit, that way a 20mbps data rate can be achieved for transmission; and a wasteful sampling of one bit to cog long would also allow 20mbps reception.
David, I would not worry - even if both crystals/oscillators had 100ppm error, worst case error would be 200/5000000 which means you'd have to have 25,000 consecutive bits before you drifted one bit cell worth.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
I am trying to figure out the practical implications of this data rate... for instance does 8.42 Mega baud mean that I need 4 lines connecting two Props to transfer raw data at NTSC rates?
A bit off topic, BUT my RadioShack got a shipment of Parallax parts yesterday... in about 20 seconds I had my new Memsic 2125 running your demo code. (I'm still trying to figure out if I can separate tilt and acceleration without anything else[noparse]:)[/noparse]
Rich
Thanks David
The Props are running off of independent clocks. ...And sampling does happen in the middle of the "instruction" bit (see below).· At 10 feet of ribbon cable the signal did not appear to show any significant "edge-rounding" due to capacitive/resistive effects of the cable. Within roughly 10nS, any edge distortion had stabilized to one rail or the other. I consider an unshielded, 10 foot connection to be excessive, and your signal will only improve with closer, shielded connections.
The tolerance of the 5MHz crystal on the Propeller is +/- 30 PPM which translates to +/-480 PPM after the X16 PLL. Even at 80MHz, an error of +/-38,400 (<-- 480 PPM X 80 = 38,400) pulses is better than 0.001% error. If each LONG transmission takes 3800nS that's 304 Clocks (<-- 3800nS / 12.5nS = 304 Clocks) ... multiplied by a 0.001% error, that's 0.304 or approximately 1/3rd of a single clock pulse.
Bill Henning,
Thanks Bill
"Hmmm... two waitpne's in a row should take 10 cycles, positioning the "sampling point" right in the middle of 100ns bit cells... smart!"
You get the idea, but it's not in the center of the 100nS bit cells.... break up the 100nS Bit Cells so that 50nS samples the bit, while 50nS Shifts and rotates the value into the Buffer.
In the first 50nS, the sampling is in the middle because of the 2 cycle offset (2 x 12.5nS = 25nS) of the 10 cycles required from the·waitpne and waitpeq instructions.
"I even considered a faster version, where a long would be compiled into a series of set/clear tx bit, that way a 20mbps data rate can be achieved for transmission"
I thought of something like that as well, but the overhead time required to read, and self modify the code to allow 50nS transitions would not allow the same "packet speed"·as I am currently achieving. (1k Longs in approximately 4mS)
rjo_,
Thanks Rich
The 8.42M baud is not a continuous data stream,· it is sent in·bursts much like standard Serial practices.· I·Suppose that you could use 4 COGS pointing to different memory address ranges for a burst throughput of 33.68 MHz.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 11/29/2007 5:19:58 PM GMT
Just out of curiosity, as I've wanted to ask a few things like this, but what about temperature changes etc, would any external effects change the accuracy?
Cos I've·been·thinking about a byte burst data mode, for propgfx too.
rjo_ you could always wait til prop2 and do it at double ntsc speed, in a year or two [noparse]:)[/noparse]
Post Edited (Baggers) : 11/29/2007 5:28:59 PM GMT
Ok, so this is an extreme... While one Prop was at room temp, I held a lighter·to the crystal of the other Prop until it was too hot to touch... still no packet errors.
Note:· It doesn't account for any temperature variations of the Prop itself though... but if the time base remains stable, then so should the rest as long as the code is·able to run.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Nice one though [noparse];)[/noparse]
as I was thinking of doing an 8bit data burst mode, in transfering data to the PropGFX, and as you've used different clocks for both props, then I'll take that as it's a pretty secure way to do it [noparse];)[/noparse]
Should get a decent amount of data throughput with 8bit transfers [noparse]:)[/noparse]
Oh, another question for you Beau, or anyone in the know for that matter.
RDLONG takes 7+ cycles, say 7 for example, eg, it caught it when the hub was ready for it.
then doing an ADD would add another 4
and a DJNZ back to the RDLONG would add another 4... would that then make the RDLONG hit 7 cycles? or would it be more?
also more code inbetween rdlongs, eg
RDLONG blah2,blah
ADD blah,#4
MOV OUTA,blah2
' where you would now be allowed a RDLONG ( if above question is correct at 7 cycles )
mov something,else
xor justtobe,different
' these two instructions above would be replacing your allocated hub slot
sub onefrom,theother
add thisto,that
' two more instructions for padding again, then
RDLONG blah2,blah
' would this RDLONG take 7 cycles, or would it be different, since the two replacement ones ( mov and xor ) would have taken 8 cycles, and not 7. ?
Hope you can clarify this for me,
Cheers.
Baggers.
By next year I'm going to want HD not NTSC[noparse]:)[/noparse] There is a LunarXprize with our names on it[noparse]:)[/noparse]
So, what we do now for NTSC... will work later for HD. Either way, you are going to have to get cracking on this, I have already started spending the money.
Rich
Take a look at this link to answer some of your questions...
http://forums.parallax.com/showthread.php?p=692360
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Cheers,
Baggers.
The last time I designed a comms circuit was years ago; we had to have clock recovery, 8b/10b encoding, etc., and were stressing a lot of components beyond their limits. (It was a technology feasibility demonstration... lots of one-offs and such which never would have worked as-is for mass production!)
Tried to get this working last night but, alas, nothing I tried was error free - in-fact I was very lucky if I got only about 25% errors!
My set-up:
Prop1: PropStick with 5MHz xtal acts as Tx.
Prop2: Prop' on breadboard with 10MHz xtal acts as Rx. This has TV attached - I modified your code to work with TV_WText, and changed the clk/freq settings to
I tried Tx/Rx connection using a) 10cm jumper wire, and b) 1.5m Cat5e cable.
Observations:
1. With no wire connecting Tx - Rx I was seeing error count increment by one approx. every 1sec.
2. With Tx/Rx connected, errors incremented much faster.
3. I tried different waitcnt values (line 86 in Tx), but this only appeared to affect the rate of error incrementing!
4. Tx/Rx connection using Cat5e cable produced faster error increments than the short jumper wire.
I've attached copies of the code I'm using (if I've done it right!), in case anyone else wants to try this with TV. <edit> Updated to fix unequal buffers and waitcnt. </edit>
I'm guessing that the problem's down to the mis-match of xtals? Gave up trying at 02:00 this morning (!), but will try again with another 10MHz xtal'd Prop' this evening.
What would be the best way to add some flow control?
Anyways; great work
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
Post Edited (simonl) : 12/4/2007 5:05:19 PM GMT
Also, if your·setting the clock this way·on one Propeller, it should probably be set the same way on the other Propeller
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Yup - GNDs connected.
Not sure I understand the 2nd point; my Tx Prop has a 5MHz xtal, so setting _clkmode & _xinfreq as above wouldn't be valid, would it?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
In the TX... the waitcnt(800+cnt)· ... should be much higher ... I originally used .... waitcnt(800_000+cnt)
I'm scoping the signal·right now... I will look into it
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Why you have diferent Buffer sizes on TX/RX ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
I'm pretty sure I had 800_000 and equal buffer sizes during testing - but then it was in the early hours...
I'll be sure to try again tonight.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
I double checked...
The file you posted has 800 instead of 800_000 ... with your TV modification and 512 Packets on the receive side, the minimum number without generating errors seems to be about 520_000.
Sapieha,
I thought that this was odd also... However, as long as the TX is sending more packets than the RX is receiving you should be ok. The "extra" Packets in this case are simply ignored.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Yeah, I _think_ that's just because I didn't save the versions in step (oops!), but I'm sure I had them in step during testing - I'll try again tonight.
As for the _xinfreq & _clkmode; I've used those settings OK on previous object tests, but do you think that might be causing bit sync problems?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
Probably... I did have a 10MHz·around here somewhere, but I can't find it at the moment.
Edit :
Test1 - TX=10MHz RX = 5MHz - tested OK
Test2 - TX=5MHz RX = 10MHz - tested OK
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 12/4/2007 4:52:01 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
"Hmmm, OK; what did you use for _xinfreq & _clkmode?"
The same settings you had... Attached is a modified version of the code you sent for both RX and TX.
From the time I started it about an hour ago, it's reached over 2.5 Billion Bits with no Errors.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
Turns out that it's the PC to Prop' connection that caused the errors! I discovered that if I touched the DB9 connector everything started working, so I disconnected the PC serial cable and all's fine.
Does anyone know why this might be? I'm guessing it's something to do with earthing, but haven't a clue why.
My set-up:
Mains - 4-way socket strip -+- wall-wart - TV -------+ | | +- wall-wart -+-+ | | | | | | GND| |+3.3V |(TV lead) | | | | | +-n---+ | | | | RxProp----+ | | +---+ | | | | | | | | | | | |(Com1) | +-n---+ | | | | TxProp--+ | | +---+ | | | | | | (Com2)| | | -------+ | | / | +- wall-wart - Laptop---------+<edit>
BTW:
With a packetsize (PS) of 512 I saw a throughput of about 627Kbps; with PS set to 1024 I saw about 700Kbps - great work Beau
Also, I found the minimum waitcnt values were as follows: PS = 512, waitcnt = 520_000; PS = 1024, waitcnt = 735_000.
</edit>
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
Post Edited (simonl) : 12/5/2007 12:05:27 PM GMT
Glad that you got it working!
With three different wall-warts, the likely hood of creating a ground loop, shouldn't but might increase... One thing to do would be to check the ground potentials from each supply with a DMM (Digital Multi Meter) without anything connected to see if·there are any noticeable differences.... Ideally, they should all read 0V, but under a typical circumstance, I would expect small voltage variances measuring between the output GND connections.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
This is still work in progress.· Using only 1 COG for the Transmitter, and 1 COG for the Receiver, 14.5 Mega Baud Communication Packets can be achieved.
With slight modification to the "Transmitter" (using 1 COG) and "Receiver" (using 2 COGs ; 180 deg out of phase) 29 Mega Baud communication packets should
be achieved through the current implementation of 4 - I/O pins
The current demo sends pseudo random Packets with a length of 32768 bits in approximately 2.25mS (<-14.5Mega Baud) at a repetition rate of 174 Hz
effectively providing a constant throughput of 5.7 Mega Baud.· Keep in mind that the 174 Hz is deterministic of the overhead required for the display and
Packet confirmation.· Also, the demo provides a "real time" visual representation of the Transmitter's I/O state displayed on the·Receiver screen.
Enjoy!!
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 12/12/2007 7:06:59 AM GMT
The sender looks nice, but is not very realistic. When you have other cogs manipulating output pins, you cannot happily ROL outa contents... you need 5 instructions...
rol buff,#4
mov temp1.buff
and temp1,#PIN0_4_MASK
and OUTA,#PIN0_4_MASK
or OUTA,temp1
or did I miss something ?
EDIT: I DID miss something, see below.... ***
Post Edited (Ale) : 12/12/2007 8:21:11 AM GMT
Nononono, I'm mistaken... the problem is not that DIRA is not unique, it is unique per cog, and does not reflect the other cogs' status. Niether do OUTA, they are all OR'ed together and independent, and they only contain the value written, not all the OR'ed values. Very clever. Understood.
Beau, do not worry.
Baggers: Thanks for the rethinking...