High Speed Asynchronous Comms...

ght_dak

There's been some discussion about the ability of the prop to do high speed serial comms.· Generally, the problem of leading edge detection is the culprit.

I've been playing around with the counters and wonder if they're not the solution.

Why·couldn't one use·the counter's logic·modes, nail APIN to the receive pin,·and use the PHSA value to determine the leading edge of the·start bit?· Assembly code would simply need to read PHSA within the start bit window and·use the PHSA value to determine when the leading edge of the bit was and, therefore, where the center of the rest of the bits·should be (within reasonable values considering the 1/80 MHz clock)

As an augmentation, using the B counter in duty cycle mode to drive the BPIN of the A counter, one could even be reasonably sloppy getting to the phsa register when reading the rest of the bits.

To see if the FDDI USB chip / Driver·can handle high rates, I did a cheap test today by nailing rx and tx together and using the PC to send and receive its own byte streams... I got distracted at 153600 baud... but there were no transmission·/ receive errors. (maybe this is a flawed test but it tested the driver speed... perhaps not the hardware).

Perhaps I'll code this up but I was wondering if anyone has done any work in this area before I started.· I didn't see anything using the search... but that doesn't always mean much.

-glenn

Mike Green

There's no need to use the counters. You're going to need to use assembly language anyway for speed. The functional sequence is just:

   waitpne                 wait for the leading edge of the start bit
   mov/add/waitcnt    take cnt and add 1/2 the bit time (in clock ticks), then wait
   test/jmp                verify at mid start bit that the start bit is still present
   waitcnt                  now we just have to sit in a loop waiting for a bit time
   test/mux/rol          sample mid bit and add bit into accumulating byte value
   test/jmp                or verify that stop bit is present

The bit time and 1/2 bit time in clock ticks is precomputed, so the leading edge detection and verification is maybe 15 clock cycles for the 1st 1/2 bit time and 13-14 cycles for the 2nd 1/2 bit time. That's roughly 350ns per bit or a bit less than 3MBaud for receive with an 80MHz system clock.

If you want to get fancy and sample multiple times in a bit time slot, taking the best 3 out of 4 or something like that, it would probably slow you down to 1MBaud. Doing parity checking or CRC checking adds a little bit. Copying data to hub memory rather than using a buffer in the cog's memory also slows things down a little from the 2+MBaud figure.

Post Edited (Mike Green) : 7/22/2007 10:16:33 PM GMT

hinv

Do you have any test code that I could run at those high speeds?

Mike Green

Not really. The read loop is very simple ... we're talking about less than 20 assembly instructions. The code surrounding it to do the setup and buffering and to display the status information and received data would be much more work than I'm willing to do at this time.

This is not fancy code we're talking about here! It is straightforward, but, like any testbed, is a lot of work to do so it's useful and easily controllable, etc.

Ariba

Have a look at ViewPort:
http://forums.parallax.com/showthread.php?p=652952

It communicates serial with 2 MBit/s full duplex with the PC and needs only 1 cog.

Andy