SmartPin Synchronous Serial Transmit

2»

Comments

  • Solved it I think. You've got a startup out of sync problem with the data word length against the 8 clock pulses. It never recovers. This might be something to be wary of at the start of any packet, ie: make sure clock and data are in sync.

    Add a DIRL #clkout at the top of the program, before the WRPIN. May as well do the #txout too.
    We have the vastness of the internet and yet billions of people decided to spend most of their time within a horribly designed, fake-news emporium of a website that sucks every possible piece of personal information out of you so it can sell it to others. And they see nothing wrong with that.
  • Without the DIRL, what can happen is the DIR can already be high and the moment WRPIN sets the mode it acts. Which for transition mode may start streaming clocks so that the moment the sync.serial is enable/set will be shifting without you having told it to.
    We have the vastness of the internet and yet billions of people decided to spend most of their time within a horribly designed, fake-news emporium of a website that sucks every possible piece of personal information out of you so it can sell it to others. And they see nothing wrong with that.
  • Thank you evanh! I will give this a try this evening. I agree, it seems to be some sort of race condition.

    I thought I was going crazy for a moment!
    Terry's Workbench

    Feel the need for speed between your PC's com port and Prop?
    Try the FTDI 245 and the FullDuplexParallel Object.
    Check out my spin driver for the Parallax "96 x 64 Color OLED Display Module" Product ID: 28087
    22FPS video from the P2 on the Parallax "96 x 64 Color OLED Display Module" https://www.youtube.com/watch?v=ja84rf38QHM
  • jmgjmg Posts: 14,140
    evanh wrote: »
    Solved it I think. You've got a startup out of sync problem with the data word length against the 8 clock pulses. It never recovers. This might be something to be wary of at the start of any packet, ie: make sure clock and data are in sync.
    To handle this, I thought Smart Pins has some ability to prepare (arm) a number of pins, and then start ?
    Even without that, the code seems to always have Tx Shifter load, right before Tx Clock load, so shouldn't that always have a fixed and small 2 Sysclk offset ?

    Or, do you mean the startup/configure sequence should always configure CLK first, so the pin is in a stable state, before it preps the TX connected to that clock pin ?
    The above code does not do that, and in a part that floats pins during reset and until users define them, there is no assumed starting pin state.
  • jmg wrote: »
    Or, do you mean the startup/configure sequence should always configure CLK first, so the pin is in a stable state, before it preps the TX connected to that clock pin ?
    The above code does not do that, and in a part that floats pins during reset and until users define them, there is no assumed starting pin state.
    I think he'll be happy when he tries this out tonight! Moving the CLK config before Tx, worked in PNut as well as with fastspin/loadp2...
    dirl    #clkout
        wrpin   trans,#clkout
        wxpin   ##$1000,#clkout     'set base period
        dirh    #clkout
    
        dirl    #txout
        wrpin   sync_tx,#txout      'sync tx
        wxpin   #%1_00111,#txout    'stop/start mode
        dirh    #txout          'enable smartpin
    
    serTest.png

    dgately
    1079 x 684 - 631K
    Livermore, CA (50 miles SE of San Francisco)
  • ???
    The code works Ok in Pnut and spin2gui here on my P2-ES without any changes.
    Melbourne, Australia
  • evanh wrote: »
    Without the DIRL, what can happen is the DIR can already be high and the moment WRPIN sets the mode it acts. Which for transition mode may start streaming clocks so that the moment the sync.serial is enable/set will be shifting without you having told it to.
    On reset the P2 sets all DIR bits low anyway.

    This still doesn't explain why it works for Terry in Pnut (most of the time?) but never from spin2gui.

    The code runs fine here from both pnut and spin2gui.
    I even tried loading from Python P2 loader as well and it worksfine too.
    Melbourne, Australia
  • dgately wrote: »
    Moving the CLK config before Tx, worked in PNut as well as with fastspin/loadp2...

    Huh, you're right. I'd done that too and forgotten about it.
    We have the vastness of the internet and yet billions of people decided to spend most of their time within a horribly designed, fake-news emporium of a website that sucks every possible piece of personal information out of you so it can sell it to others. And they see nothing wrong with that.
  • evanh wrote: »
    dgately wrote: »
    Moving the CLK config before Tx, worked in PNut as well as with fastspin/loadp2...

    Huh, you're right. I'd done that too and forgotten about it.
    Chainging the config order makes no difference here,it still works.
    Same scope images either way.
    Melbourne, Australia
  • evanhevanh Posts: 8,372
    edited 2019-02-18 - 01:04:45
    I'm guessing it depends on prior X and Y. Maybe they can be indeterminate if not set. And Y isn't being set until after the first second.
    PS: I've been testing FPGA with v33j.
    We have the vastness of the internet and yet billions of people decided to spend most of their time within a horribly designed, fake-news emporium of a website that sucks every possible piece of personal information out of you so it can sell it to others. And they see nothing wrong with that.
  • jmgjmg Posts: 14,140
    ozpropdev wrote: »
    On reset the P2 sets all DIR bits low anyway.
    Yes, but that just floats the pins.
    Ideally, you want the Sync CLK pin firmly defined before you enable any connected-shifter, otherwise you have a lottery of a possible first edge on init.


  • And from the docs:
    During reset (DIR=0), IN is low, the output is low, and Y is set to zero.

    My take from that is, if DIR is high then, any pre-existing Y value is a case for automatic transitions on mode config. And they don't stop until Y counts to zero.

    We have the vastness of the internet and yet billions of people decided to spend most of their time within a horribly designed, fake-news emporium of a website that sucks every possible piece of personal information out of you so it can sell it to others. And they see nothing wrong with that.
  • evanhevanh Posts: 8,372
    edited 2019-02-18 - 01:34:04
    Actually, dgately may have identified the most important part - placing the DIRH #txout at the end of the init code.

    EDIT: Like JMG says, clkout needs to be well defined before txout is engaged.
    We have the vastness of the internet and yet billions of people decided to spend most of their time within a horribly designed, fake-news emporium of a website that sucks every possible piece of personal information out of you so it can sell it to others. And they see nothing wrong with that.
  • evanh wrote: »
    Actually, dgately may have identified the most important part - placing the DIRH #txout at the end of the init code.
    Actually, that part of the code was as ke4pjw had written it... I just added the dirl instructions and moved the clk config portion above the txout config portion. So, that's all from JMG's suggestion.
    Livermore, CA (50 miles SE of San Francisco)
  • It would seem that my P2-ES board has lower noise than Terry's board.
    As has been pointed out the clock config should be done before tx config.
    This doesn't seem to matter on my board as I've mentioned above.
    To replicate the $1c error I did the following in between tx and clock config.
       drvh  #clkout
      fltl #clkout
    
    A single clock throws the sync transmitter out of order.
    Scope images now show $1c instead of $C1 as Terry observed.

    So Clock before Tx config and your good to go. :cool:
    Melbourne, Australia
  • Yep, a bit of both. In my case every DIR was indeed high before init. I had a devil of a time getting anything sensible for a while.
    We have the vastness of the internet and yet billions of people decided to spend most of their time within a horribly designed, fake-news emporium of a website that sucks every possible piece of personal information out of you so it can sell it to others. And they see nothing wrong with that.
  • Glorious! Thank you guys *SO* much! Works perfect with pnut, spin2gui, and boot from SD.

    Someone may want to add this to the tricks and traps thread.

    Again, thank you!
    con
    	clkout = 9
    	txout = 8
    
    dat	org
    
    
    	dirl    #clkout
    	wrpin	trans,#clkout
    	wxpin	##$1000,#clkout		'set base period
    	dirh	#clkout
    
    	dirl    #txout
    	wrpin	sync_tx,#txout		'sync tx
    	wxpin	#%1_00111,#txout	'stop/start mode
    	dirh	#txout			'enable smartpin
    
    	SHL data,#32-8  ' Set MSB First
    	REV data	' Set MSB First
    
    
    loop	waitx	##20_000_000
    	wypin	data,#txout		'data
    	wypin	#16,#clkout		'start clock, tx data
    
    busy	testp	#clkout wc
    	if_nc	jmp	#busy
    	rdpin	pa,#clkout
    	wypin	#0,#txout
    
    	jmp	#loop
    
    sync_tx	long	%1001 << 24 | %1_11100_0  'b pin = current pin+1 and inverted
    trans	long	%1_00101_0
    data	long	$C1
    
    
    Terry's Workbench

    Feel the need for speed between your PC's com port and Prop?
    Try the FTDI 245 and the FullDuplexParallel Object.
    Check out my spin driver for the Parallax "96 x 64 Color OLED Display Module" Product ID: 28087
    22FPS video from the P2 on the Parallax "96 x 64 Color OLED Display Module" https://www.youtube.com/watch?v=ja84rf38QHM
  • ke4pjw wrote: »
    ...Someone may want to add this to the tricks and traps thread...

    Just do it, It is just a normal thread...

    Cool that you nailed it down.

    Enjoy!

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
Sign In or Register to comment.