Shop OBEX P1 Docs P2 Docs Learn Events
Clocking questions for Serial Input and Output — Parallax Forums

Clocking questions for Serial Input and Output

Cluso99Cluso99 Posts: 18,066
edited 2013-05-19 17:24 in Propeller 2
I am looking at USB timing for Full Speed (12Mbps)...

I anticipate that I can use the video counters to output a serial stream using a counter setup to shift out at 12Mbps - is this correct?

It appears that the SNDSER and RCVSER only work at the full clock rate (60MHz on the DE0 & DE2) - is this correct?

Can the SDRAM hardware run at anything other than the P2 clock frequency (ie can I use a counter to provide the clock)?

Is there any other P2 hardware assist I can use to aid in sending/receiving serial bit streams?

Comments

  • pedwardpedward Posts: 1,642
    edited 2013-05-18 16:21
    Cluso99 wrote: »
    I am looking at USB timing for Full Speed (12Mbps)...

    I anticipate that I can use the video counters to output a serial stream using a counter setup to shift out at 12Mbps - is this correct?
    You could use the counters, but not the video circuit. Kuroneko wrote a nice high speed serial driver for the P1 that does this, SHL PHSB, #1 is the magic.

    It appears that the SNDSER and RCVSER only work at the full clock rate (60MHz on the DE0 & DE2) - is this correct?

    Yes.

    Can the SDRAM hardware run at anything other than the P2 clock frequency (ie can I use a counter to provide the clock)?

    No, same restrictions as SNDSER.

    Is there any other P2 hardware assist I can use to aid in sending/receiving serial bit streams?

    That is one of the laments that Chip had about the design, the lack of time to put in a proper SerDes in the P2.

    You can transmit single cycle with the SHL PHSB, #1 instruction and you can receive with 2 cycles using GETP WC and RCL D, #1
  • AribaAriba Posts: 2,682
    edited 2013-05-18 17:21
    PHSA/B are not register mapped on P2, so SHL PHSB,#1 is not possible. We will see if there are other tricks when we have the description of the counters.

    For USB you need to shift out the bits to two pins at the same time, one inverted, one not inverted. And you should also generate the stuff-bits in real time while you shift the bits out, otherwise the handling of the USB-packets gets complicated.

    With 160 MHz this should be not a problem, but FullSpeed with 60MHz is a challenge. I think with the FPGA we are limited to LowSpeed.

    Serial output with the Video hardware is possible, it just needs to go thru the DACs.

    Andy
  • Cluso99Cluso99 Posts: 18,066
    edited 2013-05-18 18:13
    pedward wrote: »
    re: Is there any other P2 hardware assist I can use to aid in sending/receiving serial bit streams?

    That is one of the laments that Chip had about the design, the lack of time to put in a proper SerDes in the P2.
    Unfortunately, it could have been done quite simply (as I mentioned quite a few times) with a counter option to clock IN instead of clocking OUT. This is not a full SerDes (as everyone was after), just a simple clock in method. Alternately, permitting the SNDSER/RCVSER to use an internal counter for the clocking would have worked.
    Perhaps the VGA would have been a little more complex since I don't think we can read back the registers that output the data.
    Ariba wrote: »
    PHSA/B are not register mapped on P2, so SHL PHSB,#1 is not possible. We will see if there are other tricks when we have the description of the counters.

    For USB you need to shift out the bits to two pins at the same time, one inverted, one not inverted. And you should also generate the stuff-bits in real time while you shift the bits out, otherwise the handling of the USB-packets gets complicated.
    I don't even mind if I have to add one of those tiny gate packages to perform the inversion. The bit stuffing could be predone in software, particularly if we had a 32 bit sender. We could preset 32 bits and let it run while we prepared the next 32 bits.
    For input, as long as we could read the register while the input was being assembled, we could remove the timing constraints of the code.
    With 160 MHz this should be not a problem, but FullSpeed with 60MHz is a challenge. I think with the FPGA we are limited to LowSpeed.

    Serial output with the Video hardware is possible, it just needs to go thru the DACs.

    Andy
    It's still possible we can shift out in 2 clocks by using one of the pin configurations to invert. However, that does not relieve us of the problem that there is a need to also be doing hub ops. Whenever this occurs, the data sync gets lost.

    I would have thought we can still use the VGA like we did on the P1, even tho' there have been some changes to the video.

    Of course, I am going to try this with a single cog (I have a DE0). So I won't be doing anything complex with the data, just proving I can read and reply to packets. I was sort of hoping someone may have found a trick/way to use the extra hardware in the P2.
  • jmgjmg Posts: 15,140
    edited 2013-05-18 19:44
    USB needs to be duplex, so probably makes sense to keep in SW for both directions.
    The LOW speed option, means code debug could be done first at that speed.

    Ideally, you want a Differential RX, and some ESD, and looking at TI I see :

    TUSB1106P 55c/1ku Advanced Universal Serial Bus Transcievers ±15-kV Human-Body Model

    they also have
    TUSB1210 80c/1k USB 2.0 ULPI Transceiver (ESD is only 2kV)
    This also claims
    - Complete HS-USB Physical Front-End: Supports High Speed (480 Mbit/s), Full Speed (12 Mbit/s) and Low Speed (1.5 Mbit/s)
    Bit-Stuffing Insertion During Transmit and Removal During Receive
    - but it is not clear how the ULPI interface scales with USB speed.
  • pedwardpedward Posts: 1,642
    edited 2013-05-18 23:57
    How can USB be anything other than simplex? It's 1 pair of wires to TX and RX.
  • Heater.Heater. Posts: 21,230
    edited 2013-05-19 01:19
    Cluso,
    I don't even mind if I have to add one of those tiny gate packages to perform the inversion
    As far as I understand you cannot drive USB like that as sometimes both lines are required to be in the same state.
    There is an explanation of all the USB line states here: http://www.usbmadesimple.co.uk/ums_3.htm
  • Cluso99Cluso99 Posts: 18,066
    edited 2013-05-19 02:48
    Heater. wrote: »
    Cluso,

    As far as I understand you cannot drive USB like that as sometimes both lines are required to be in the same state.
    There is an explanation of all the USB line states here: http://www.usbmadesimple.co.uk/ums_3.htm
    Yes, I am fully aware of this. And it needs to be tristate-able too. Neither of these are a problem with the correct use of pins. I don't mind a 20c 6-8pin gate but not interested in anything more, plus the 3+ resistors. If you want to LS & FS then an extra pin and an extra 1K5, 2x15K pulldowns +pins for host.
  • jmgjmg Posts: 15,140
    edited 2013-05-19 03:26
    pedward wrote: »
    How can USB be anything other than simplex? It's 1 pair of wires to TX and RX.

    Yes, I used too few words : USB sends/receives in both directions, (strictly called half-duplex), so any coms design has to be able to do both.
    That means there is little merit in having hardware assist for one direction only.
  • jmgjmg Posts: 15,140
    edited 2013-05-19 03:36
    Cluso99 wrote: »
    . I don't mind a 20c 6-8pin gate but not interested in anything more, plus the 3+ resistors.

    So you have no plans to worry about ESD handing, or differential Rx ?
  • pedwardpedward Posts: 1,642
    edited 2013-05-19 13:49
    The Prop2 has pin modes to do differential output and input, and lest you forget, it has ESD protected inputs.
  • jmgjmg Posts: 15,140
    edited 2013-05-19 14:07
    pedward wrote: »
    .. it has ESD protected inputs.

    ... any real numbers for the ESD rating of P2 pins yet ?
  • pedwardpedward Posts: 1,642
    edited 2013-05-19 17:24
    Enough to make your nose hairs tickle?
Sign In or Register to comment.