Fast Prop to Prop Communication

Bobb Fwed · 2009-09-16 17:21

I am working on a way to send a grip of information quickly between two propellers. The program sends longs (not bytes) with only one start bit, and no terminating bit. Everything assumes the two propellers' clock cycles are +/- 0.5% of each other. But it goes really quick, and this is just the first day I've been able to work on it, so it will go faster once I figure out all the timing stuff.

The demo program (I have attached) is just testing the system between two pins and two cogs on one Propeller. The problem I am having is I am trying to send 32 longs, but the return is only showing 8 longs. I can't tell (with my cheap oscilloscope) if it is outputting all the information and it's not receiving it, or possibly the other way around.

Any help would be nice. As usual, I am sure it is something very simple, I just need more eyes looking at it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
April, 2008: when I discovered the answers to all my micro-computational-botherations!

Post Edited (Bobb Fwed) : 9/18/2009 5:55:11 PM GMT

jazzed · 2009-09-16 17:48

I'm using Propalyzer and a piggy-back Propeller chip (right now) for debugging this kind of thing.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

Propeller Tools

Bobb Fwed · 2009-09-16 20:35

OK, well, I got it to work, but I don't understand why.

MOV     txbidx, #31

is supposed to be

MOV     txbidx, #32

and

MOV     rxbidx, #31

works when it is

MOV     rxbidx, #64

.
But this looks like it would pull the whole thing out of symmetry. Maybe it is some other timing thing I am not seeing.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
April, 2008: when I discovered the answers to all my micro-computational-botherations!

Cluso99 · 2009-09-17 06:19

Bob: Beau has done some testing and code like this.
http://forums.parallax.com/forums/default.aspx?f=25&p=1&m=233212
Beau tested at 14.5Mb

I will look at your code later tonight when I swap laptops and post comments then.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Peter Jakacki · 2009-09-17 09:13

Bob, the tx data is coming out at around 2.4us per bit but your receive routine assumes that the data is coming in as fast as it can read it without waiting, or am I reading your code incorrectly?

*Peter*

P.S. The Propeller doesn't have interrupts but people do. I jumped the gun a little but it is transmitting properly it's just that the timing for the rx didn't look right (for 5MHz). But with all these interruptions I haven't been able to check it out. I am just setting some extra debug pulses to check what the rx is doing.

Post Edited (Peter Jakacki) : 9/17/2009 9:49:47 AM GMT

Peter Jakacki · 2009-09-17 10:31

Bob,

Did you spot the typo in the original?

PUB waitrx
                
  REPEAT UNTIL rxbuffer                                 ' wait until _something_ is put into the first long of the buffer
  waitcnt(constant((12 * 32 + 20) * (BUFFER_SIZE - 1)) + cnt) ' wait for rest of info to be transfered @12 cycles per bit
  longmove(@rxvalue, @rxbuffer, BUFFER_SIZE)            ' I would like to get rid of this
  longfill(@rxbuffer, 0, BUFFER_SIZE)                   ' clear for next use (again, I will find a way to remove this)
  RETURN @rxvalue                                       ' not used, but will be needed once it is an object

*Peter*

P.S. Changed back to 32 longs for both rx and tx - example

                        MOV     rxbidx, #buffer_size

P.S. Removing the nop and unrolling the rx loop while increasing the buffer to 256 longs will transfer 1K bytes in around 1ms = 1MB/sec. (tested)
The equivalent at 10 bits per byte end-to-end would be 10.48M baud.

Post Edited (Peter Jakacki) : 9/17/2009 2:01:37 PM GMT

Bobb Fwed · 2009-09-17 14:33

I have a new(er) version that has it unrolled (if you noticed in the comments I talked about that -- I had it that way so if I made changes I only had to make one). The new version will also allow you to put info in the TX buffer and then send a command as to when to send it. And I also put the PASM buffer size as a declared long so the buffer can be more than 255 longs long (255 * 2 for the RX < 511). I will post it as soon as I fix an issue with it.
But the basic execution still functions the same, and the RX loop is still twice the value of the TX...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
April, 2008: when I discovered the answers to all my micro-computational-botherations!

Peter Jakacki · 2009-09-17 14:45

Yeah Bob, I do the same with temporary stuff in the code and I noticed your comments so I decided to try it. I am trying some single-mode fiber on one of my designs next week so this might be a good test. I only need relatively slow speed comms over a distance of up to 15kms. I decided to play with your code because I had been meaning to get around to testing some high-speed 32-bit asynch coms just as you have done.

*Peter*

Bobb Fwed · 2009-09-17 23:24

Well, this morning, after my computer blew up, I got a new one up and going, then our internet went out. I now have a new(er) computer and faster (more reliable) internet after AT&T came by and fixed some bad wiring. So I haven't had a chance to work on the new version....

@Peter: I still don't see the typo. The new version works that function a bit differently, but I don't want to make the same mistake twice. Please do tell (maybe I meant to do whatever the typo is :-P).

@Cluso99: I will look at Beau's program, but according to my first tests I am getting 8.66 million bits per second (8.93Mbaud). I don't have a stop bit, I use Beau's "Start bit 2" instruction to load data. The rest is just management of overhead (which may change as I troubleshoot). So if he has me that beat, I may not need to reinvent the wheel, no matter how fun it it. This info is assuming I get this all to work anyway.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
April, 2008: when I discovered the answers to all my micro-computational-botherations!

Post Edited (Bobb Fwed) : 9/17/2009 11:29:20 PM GMT

kuroneko · 2009-09-18 00:06

Bobb Fwed said...
I will look at Beau's program, but according to my first tests I am getting 8.66 million bits per second (8.93Mbaud). I don't have a stop bit, I use Beau's "Start bit 2" instruction to load data. The rest is just management of overhead (which may change as I troubleshoot). So if he has me that beat, I may not need to reinvent the wheel, no matter how fun it it. This info is assuming I get this all to work anyway.

Don't give up so easily! Beau's driver provides 8.42Mbaud for the 1bit version, and 14,5Mbaud for the 4bit version. So there is still room for improvement. Admittedly there are faster 1bit drivers around but that's still no reason ...

Peter Jakacki · 2009-09-18 05:24

Bob, that typo was that you had bytemove and bytefill instead of longmove and longfill, that's all. I call that a typo not that it's that kind of typo but that it's not what you meant to type.

So I think the speed of this thing is way fast at 1 megabytes per second after I remove the tx nop and unrolled the rx loop.

*Peter*

Bobb Fwed · 2009-09-18 17:51

I have uploaded a new version (on the original post).

This one allows you to place the data in the buffer, then, at your leisure, send it. There is a SPIN RX command that has a watchdog. The original problem with the RX loop being twice as long as the TX loop has been resolved. The RX loop has been rolled out and the TX's NOP has been removed. And lots of minor changes.

After looking at Beau's program in a lot of ways we are, line-for-line, writing the exact same program. With a few difference (as said before[noparse]:)[/noparse] one start bit, no stop bit. The big difference (which should make mine faster -- please someone test them) is mine doesn't launch a cog every time it wants to send, it just provides the send command.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
April, 2008: when I discovered the answers to all my micro-computational-botherations!

Post Edited (Bobb Fwed) : 9/18/2009 5:56:43 PM GMT

VIRAND · 2009-09-18 18:26

Does the timer/PLL stuff have the capability to send and receive Quadrature Phase Shift Modulation?
Like QAM, can carry more bits than the pulse rate frequency.
How about duty cycle also?

Some of the hardware is faster than the software, for example the video generator, but that is output only.

Fast Prop to Prop Communication

Comments