Shop OBEX P1 Docs P2 Docs Learn Events
Prop123_A9_Prop2_v7y Intermediate Release - 14 March 2016 - Faster PINSET, all shift modes LSB-first — Parallax Forums

Prop123_A9_Prop2_v7y Intermediate Release - 14 March 2016 - Faster PINSET, all shift modes LSB-first

cgraceycgracey Posts: 14,134
edited 2016-03-15 01:34 in Propeller 2
This is the 2nd intermediate release of the new serial modes in the smart pins, here is v7y for the Prop123-A9 FPGA board:

https://drive.google.com/file/d/0B9NbgkdrupkHM0wxYUlzb3dFZGs/view?usp=sharing

The Google Doc has been updated at the end to cover the new serial modes:

https://drive.google.com/open?id=10qQn_-B7avY2ce0N1MDDdzOF1lACPNWUJkjHFyzITiY

P.S. This v7y .rbf file only has four cogs, not 16. It has 64 smart pins, though.
«13

Comments

  • Thanks Chip! :)
  • cgraceycgracey Posts: 14,134
    edited 2016-03-13 02:33
    ozpropdev wrote: »
    Thanks Chip! :)

    Ah, I'm glad to see you saw this so quickly!

    I think when you read the new docs about how the serial modes work now, you'll feel more settled than before.

    I thought about how you would probably like this to work when I made the improvements.
  • cgraceycgracey Posts: 14,134
    edited 2016-03-13 02:52
    Note: To put a pin into cog DAC channel mode, you will need to do the PINSETM with this D value:

    %1010000000000_0_1_00000_1

    This will be necessary for getting video working, again.
  • jmgjmg Posts: 15,171
    cgracey wrote: »
    I think when you read the new docs about how the serial modes work now, you'll feel more settled than before.

    I thought about how you would probably like this to work when I made the improvements.

    Did you do any sustained serial transfer tests, (one way & loop-back) at the upper baud rates ?

  • cgraceycgracey Posts: 14,134
    jmg wrote: »
    cgracey wrote: »
    I think when you read the new docs about how the serial modes work now, you'll feel more settled than before.

    I thought about how you would probably like this to work when I made the improvements.

    Did you do any sustained serial transfer tests, (one way & loop-back) at the upper baud rates ?

    Yes. I believe everything works at clock/3 without a common clock signal.
  • jmgjmg Posts: 15,171
    cgracey wrote: »
    jmg wrote: »
    Did you do any sustained serial transfer tests, (one way & loop-back) at the upper baud rates ?

    Yes. I believe everything works at clock/3 without a common clock signal.

    Can that now continually Tx and/or Rx in SW bursts, with a single stop bit (stable) between bytes ?
  • cgraceycgracey Posts: 14,134
    jmg wrote: »
    cgracey wrote: »
    jmg wrote: »
    Did you do any sustained serial transfer tests, (one way & loop-back) at the upper baud rates ?

    Yes. I believe everything works at clock/3 without a common clock signal.

    Can that now continually Tx and/or Rx in SW bursts, with a single stop bit (stable) between bytes ?

    Absolutely!
  • ozpropdevozpropdev Posts: 2,792
    edited 2016-03-13 11:57
    Looks good Chip!
    NCO baud generator in async. transmitter works nice @ 12M baud on FT2232H. :)

    Edit: Sending 384k chunks @ 12M baud in 327mS using "buffer full" checks. Cool! :)
  • cgraceycgracey Posts: 14,134
    edited 2016-03-13 13:34
    ozpropdev wrote: »
    Looks good Chip!
    NCO baud generator in async. transmitter works nice @ 12M baud on FT2232H. :)

    Edit: Sending 384k chunks @ 12M baud in 327mS using "buffer full" checks. Cool! :)

    Super! Thanks for trying that out.

    Now, we've just got to get the USB done.
  • ozpropdevozpropdev Posts: 2,792
    edited 2016-03-13 13:57
    Hi Chip
    I have two smartpins set up as sync. transmitters with a common clock.
    One pin has an inverted clock input and the other normal clock input.
    This works fine as can be seen in the first image (oz1.jpg).
    If I then swap the clock inversion around, the pin with a negative relative input pin (DATA2) goes out pf sync. (oz2.jpg)
    1024 x 768 - 85K
    1024 x 768 - 85K
  • cgraceycgracey Posts: 14,134
    ozpropdev wrote: »
    Hi Chip
    I have two smartpins set up as sync. transmitters with a common clock.
    One pin has an inverted clock input and the other normal clock input.
    This works fine as can be seen in the first image (oz1.jpg).
    If I then swap the clock inversion around, the pin with a negative relative input pin (DATA2) goes out pf sync. (oz2.jpg)

    Wouldn't that be because one pin is clocking the 2nd bit out before the other is clocking the 1st bit in? Remember that the first clock on the transmitter causes the 2nd bit appear, while the last clock causes the first bit of the next word to appear.
  • jmgjmg Posts: 15,171
    ozpropdev wrote: »
    Looks good Chip!
    NCO baud generator in async. transmitter works nice @ 12M baud on FT2232H. :)

    Edit: Sending 384k chunks @ 12M baud in 327mS using "buffer full" checks. Cool! :)

    Sounds great.
    384k*10/12M = 0.32s

    It you have a frequency counter, and stream 0x55, what does that measure ?

    If you reconfigure the FT2232H to Fast Serial, it can still use VCP, and then you should be able to run 10/20/40MHz, to around these numbers ?

    384k*13/40M = 0.1248s
    or
    384k*14/40M = 0.1344s

    P2 Generates continual CLK on one pin -> FSCLK, Checks for FSCTS=1, and sends Std Async Data stable on the _/= (Data updates on =\_)

    It may be faster to config as 13-14 bits TX length (whatever the shortest time FT2232H supports), but simple 8 bit + handshake should work too.


  • Chip
    Expanding on my earlier post,

    From the P2 V7x docs:
    Words of 1 to 32 bits are shifted out on the pin, MSB first, with each new bit being output two internal clock cycles
    after registering a positive edge on the B input. For negative edge clocking, the B input may be inverted by
    setting B[3] in PINSETM’s D value

    In my configuration both smartpins are transmitting the same byte.
    The only difference between the two is is one is clocked on pos edge clock and the other is clocked on neg. edge.

    The following smartpin config produces the correct output (oz3.jpg)
    data1	long	%1001_0100_000_0000000000000_0_1_11100_1  'b_pin = +1 neg edge
    data2	long	%0101_0100_000_0000000000000_0_1_11100_1  'b_pin = -3 pos edge
    

    but simply swapping the clock polarity on both fails on neg edge clock (oz4.jpg)
    data1	long	%0001_0100_000_0000000000000_0_1_11100_1  'b_pin = +1 pos edge
    data2	long	%1101_0100_000_0000000000000_0_1_11100_1  'b_pin = -3 neg edge *** FAILS ***
    
    Hope this makes sense. :)
    Cheers
    Brian




    1024 x 768 - 76K
    1024 x 768 - 75K
  • @ozpropdev: could you provide an updated version of the demo code for the v7x variant?
  • jmgjmg Posts: 15,171
    jmg wrote: »
    ozpropdev wrote: »
    Edit: Sending 384k chunks @ 12M baud in 327mS using "buffer full" checks. Cool! :)

    Sounds great.
    384k*10/12M = 0.32s

    It you have a frequency counter, and stream 0x55, what does that measure ?

    Trying to get the Baud formula, and I think with NCO, you need to work by overflows in the 10 Bit times, which comes to
    7+7+6+7+7+6+7+7+6+7 = 67 SysCLKs

    Predicted time is
    384k*67/80M = 0.3216s

    Does a frequency counter measure 5.970149 MHz, when streaming 0x55's ?

    AutoBaud extraction can give slightly differing values, depending on what it samples.
    If it samples over 8 bit times, that gives
    8/((7+6+7+7+6+7+7+6)/80M) = 12.075472 MBd
    or if it includes Start-bit (less common, as that needs /9)
    9/((7+7+6+7+7+6+7+7+6)/80M) = 12000000

    That varies slightly from the FreqCtr value.(which times to include Start & Stop bits)


  • cgraceycgracey Posts: 14,134
    edited 2016-03-14 02:20
    ozpropdev wrote: »
    Chip
    Expanding on my earlier post,

    From the P2 V7x docs:
    Words of 1 to 32 bits are shifted out on the pin, MSB first, with each new bit being output two internal clock cycles
    after registering a positive edge on the B input. For negative edge clocking, the B input may be inverted by
    setting B[3] in PINSETM’s D value

    In my configuration both smartpins are transmitting the same byte.
    The only difference between the two is is one is clocked on pos edge clock and the other is clocked on neg. edge.

    The following smartpin config produces the correct output (oz3.jpg)
    data1	long	%1001_0100_000_0000000000000_0_1_11100_1  'b_pin = +1 neg edge
    data2	long	%0101_0100_000_0000000000000_0_1_11100_1  'b_pin = -3 pos edge
    

    but simply swapping the clock polarity on both fails on neg edge clock (oz4.jpg)
    data1	long	%0001_0100_000_0000000000000_0_1_11100_1  'b_pin = +1 pos edge
    data2	long	%1101_0100_000_0000000000000_0_1_11100_1  'b_pin = -3 neg edge *** FAILS ***
    
    Hope this makes sense. :)
    Cheers
    Brian




    It looks like the failing case is seeing some clock, since it eventually transitions. Maybe it has the wrong data? I will run your test cases in the morning.

    It looks like when the data finally transitions, it's maybe the first bit of the $C4 value. Perhaps it doesn't load the $C4 value until it exhausts an initial zero value it had, for some reason.
  • Chip
    I found the problem (me).
    It was caused by me initializing one of the sync. transmitters before initializing the clock smartpin.
    This was causing a single edge detect on the neg edge configured smartpin, thus messing up the works!
    Sorry for the false alarm. :(
    Cheers
    Brian
  • Seairth wrote: »
    @ozpropdev: could you provide an updated version of the demo code for the v7x variant?
    Here's the current version (still a work in progress)

  • cgraceycgracey Posts: 14,134
    ozpropdev wrote: »
    Chip
    I found the problem (me).
    It was caused by me initializing one of the sync. transmitters before initializing the clock smartpin.
    This was causing a single edge detect on the neg edge configured smartpin, thus messing up the works!
    Sorry for the false alarm. :(
    Cheers
    Brian

    Okay. No problem. Glad we know what the trouble was.
  • jmg wrote: »
    If you reconfigure the FT2232H to Fast Serial, it can still use VCP, and then you should be able to run 10/20/40MHz, to around these numbers ?

    384k*13/40M = 0.1248s
    or
    384k*14/40M = 0.1344s

    P2 Generates continual CLK on one pin -> FSCLK, Checks for FSCTS=1, and sends Std Async Data stable on the _/= (Data updates on =\_)

    It may be faster to config as 13-14 bits TX length (whatever the shortest time FT2232H supports), but simple 8 bit + handshake should work too.

    I setup a Ft2232H in fast serial mode and the best speed I could achieve was ~15M baud. (384k took 262mS).
    I configured a smartpin in transition mode and fed the data out using a sync. transmitter.
    The smallest transition clocks value I could use was 2 clocks. (20Mhz clock).
    One limiting factor is the instruction overhead needed to format the data before passing it to the transmitter.
    		shl	adrb,#1
    		or	adrb,##$400
    		rev	adrb
    
    
    Just this snippet adds ~30mS to the total time.
    Another limiting factor is the sync. transmitter takes 2 clocks to shift the data out after an edge which is probably why 40Mhz can't be achieved.
    I think I prefer the standard rs232 mode @ 12M over two channels. :)
  • I encountered a synchronous serial device that transmits LSB first. I know I can simply handle the flip and shift in software, but it'd be less error prone not to. Do you have plans for those unassigned smart cell modes? If not, could you use 4 of them to provide MSB/LSB selection for both sync and async serial?
  • cgraceycgracey Posts: 14,134
    Seairth wrote: »
    I encountered a synchronous serial device that transmits LSB first. I know I can simply handle the flip and shift in software, but it'd be less error prone not to. Do you have plans for those unassigned smart cell modes? If not, could you use 4 of them to provide MSB/LSB selection for both sync and async serial?

    With today's new and improved REV instruction, there is no longer any shift compensation. All 32 bits are simply reversed, end-to-end. So, just doing a REV will place the LSB into the MSB with all the bits reversed.

    It wouldn't be much to add some extra configuration bits to the serial modes, but there's always going to be some software needed to handle either shifting or reversing. If anything, I could see making everything LSB first, and letting software handle the reversal for synchronous serial. That would cut 32 mux's out of the serial mode.
  • cgraceycgracey Posts: 14,134
    edited 2016-03-14 18:42
    One thing that would make everything faster would be to increase the smart pin serial lines from 2 to 4. Then, the time needed to send a message from a cog to a smart pin would drop from 18 clocks down to 9 or 10 clocks. That would save four instructions' time.

    ADDED: And, it would be less hardware than 32 mux's times 64 pins. I think I'm going to do this. This only takes an hour, or so.
  • jmgjmg Posts: 15,171
    ozpropdev wrote: »
    I configured a smartpin in transition mode and fed the data out using a sync. transmitter.
    The smallest transition clocks value I could use was 2 clocks. (20Mhz clock).
    One limiting factor is the instruction overhead needed to format the data before passing it to the transmitter.
    		shl	adrb,#1
    		or	adrb,##$400
    		rev	adrb
    
    
    Just this snippet adds ~30mS to the total time.
    Another limiting factor is the sync. transmitter takes 2 clocks to shift the data out after an edge which is probably why 40Mhz can't be achieved.

    This should also work in ASYNC mode ? - as the Data itself is Async formatted (which your code above adds to SYNC)

    Async mode does require the step of correct edge alignment, and I'm not sure of the best way to manage that in P2.
    I think it could be done once, at config, but how does the user know they have the correct phase ?

    Can the adjacent FCLK pin 'tap-into' the TX Pin's Baud Divider, using the adjacent pin feed feature ? That would simplify setup, (just one Baud set) & ensure edge lock.

    You also say
    The smallest transition clocks value I could use was 2 clocks. (20Mhz clock).
    Another limiting factor is the sync. transmitter takes 2 clocks to shift the data out after an edge which is probably why 40Mhz can't be achieved.


    Does that mean SPI or Async cannot do SysCLK/2, only SysC:L/4 ?
    For your 20MHz speeds, working back to bits
    20M/(384k/262m) = 13.64583

    ie Sounding like a mix of 13 & 14 bit framing.

    That's actually not too bad, as the Fast Serial is longer than classic UART, I recall 13 or 14 from my tests a while ago now,

    If 40MHz was achievable, would this get to 30Mbd equiv ?
  • cgraceycgracey Posts: 14,134
    edited 2016-03-14 23:23
    I just increased the smart pin command lines from 2 to 4, dropping the PINSETM/PINSETX/PINSETY time from 18 clocks down to 10 clocks. That's time enough for four more instructions.

    I also made all shifting I/O right-shift, or LSB-first. This had a nice effect on reducing the smart pin size.

    Now, it's back to getting the USB wrapped up.
  • jmgjmg Posts: 15,171
    cgracey wrote: »
    I just increased the smart pin command lines from 2 to 4, dropping the PINSETM/PINSETX/PINSETY time from 18 clocks down to 10 clocks. That's time enough for four more instructions.

    Sounds worthwhile.
    Does that mean byte-streaming at SysCLK/2 Async can be done, with 10 spare clocks now (was just 2). ( taking std Async as 10 bit times, or 20 SysCLK at /2 )


    cgracey wrote: »
    I also made all shifting I/O right-shift, or LSB-first. This had a nice effect on reducing the smart pin size.
    Smaller is always good to see..

  • cgraceycgracey Posts: 14,134
    jmg wrote: »
    cgracey wrote: »
    I just increased the smart pin command lines from 2 to 4, dropping the PINSETM/PINSETX/PINSETY time from 18 clocks down to 10 clocks. That's time enough for four more instructions.

    Sounds worthwhile.
    Does that mean byte-streaming at SysCLK/2 Async can be done, with 10 spare clocks now (was just 2). ( taking std Async as 10 bit times, or 20 SysCLK at /2 )


    cgracey wrote: »
    I also made all shifting I/O right-shift, or LSB-first. This had a nice effect on reducing the smart pin size.
    Smaller is always good to see..

    I'm not sure, but loops will be faster now.
  • Thanks Chip

    How far away is an A9 intermediate image be with these new serial changes?
  • cgraceycgracey Posts: 14,134
    Tubular wrote: »
    Thanks Chip

    How far away is an A9 intermediate image be with these new serial changes?

    I already posted one intermediate release, but I will do another within an hour. This next one will always shift LSB-first and it's faster on the PINSETx instructions.
  • cgraceycgracey Posts: 14,134
    There's a new version at the top of this thread.

    PINSETx instructions are now 10 clocks, down from 18.

    All serial modes are LSB-first.

    Doc's have been updated to reflect changes.
Sign In or Register to comment.