Beau's High Speed Communicatiosn & timeout

simonl

Hi All,

I'd like to add a receive timeout to Beau Schwabe's high speed comm's but wondered if anyone's already done that?

I was thinking of adding the following wherever Beau has waitpeq or waitpne:

              mov   timeout,#noOfCycles/8
:loop         test   bitmask,INA wz
        if_z  djnz   timeout,#:loop

...but wouldn't this mess-up the start bits?

I guess I could need to mod' the TX part to make the start bits longer (I think the above is 12 clock cycles per test, whereas Beau's code is only 10?)

Anyways, just checking before I get stuck in.

David B

Since there are multiple cogs available, can't you do a timeout check completely independently of the waiting cog?

Another cog could check for a timeout, then just kill the waiting cog.

Beau Schwabe

simonl,

Before you get too into the High Speed Communication, You might want to check out Jeff Ledgers (Oldbitcollector) latest post in the "Graphics Slave Propeller Platform Module" thread.

http://forums.parallax.com/showthread.php?131638-Graphcs-Slave-Propeller-Platform-Module&p=999693&viewfull=1#post999693

I re-visited the front end of both the Transmitter and Receiver to make it a little less ambiguous and to help with SYNCing between the two... Previously the Receiver had to be up and running before the Transmitter began sending data. This is no longer the case. With a simple added hand-shaking scheme on the front end the Transmitter waits for an acknowledgement from the Receiver (Ready to receive) before transmitting the data.

Attached are the Latest High Speed TX and RX programs.

simonl

Hey thanks @Beau, I'll try to digest what you've done there, and what you and OBC are up to with Pixel Blaster too - looks neat.

My end goal is to use this as the basis of Propeller Token Bus (PTB) - a cut-down implementation of something like ARCNET. I'm hoping to create a single cog Tx/Rx object, allowing multi-master and deterministic comm's between (up to) 255 Prop's.

The need for timeout (instead of waitpXX) was to cope with node insertion/removal, but I might just leave that out of the first attempt - assuming that all nodes will be present and with hard-coded addresses too.

Thanks again for posting.

simonl

Finally getting some time to work on this (maybe another hour!)

@Beau: Was there any reason why you chose 14bits for DataAddress? I can envisage using ( a modified version of ) HSp2pTX to bootload destination Propellers, but believe that would need 15bits.

Also, if I have > 2 Propellers on the transmission line, will each of them having the 330 Ohm pull-down be a problem? I'm guessing that it will, as the more I add the greater the pull-down on the line. Equally, will placing a 22 Ohm resistor between each chip cause transmission to fail?

Thanks in advance.

Beau Schwabe

"Beau: Was there any reason why you chose 14bits for DataAddress?" - mainly because there were two address fields and I simply divided them down the middle. 14+14+ 4 bits for the control code fills up the 32 available bits.

"Also, if I have > 2 Propellers on the transmission line, will each of them having the 330 Ohm pull-down be a problem?" - This object is mainly designed to get data from one Propeller to another, so multiple Propellers have not been tested. The problem you will run into is in the handshaking that goes on with the RX Propeller when the TX Propeller is ready to send something.

simonl

Thanks Beau,

I'm planning on using the guts of your code as the basis for a token passing system - I'm calling it Propeller Token Bus - so the handshaking will be different. I was just concerned that adding the 330 Ohm & 22 Ohm resistors for each additional Propeller would change the signal characteristics enough to stop the system working.

When I get some more time I'll just give it a try :-)