Shop Learn
Smartpin Sync. transmit byte/long issue — Parallax Forums

Smartpin Sync. transmit byte/long issue

ozpropdevozpropdev Posts: 2,745
edited 2016-03-06 07:14 in Propeller 2
Hi Chip
I'm experiencing an issue with the sync transmit byte mode in the smartpins.
When I start a transmission and send 8 clocks the first bit shifted out is bit 6 not bit 7.
The eighth clock shifts out bit 7.
Here's a slow motion test program for the P123-A9 to show the output.
'sync serial tx byte test

con
	sys_clk = 80_000_000
	data_out = 32
	clk = data_out + 1
	done_led = 40

dat		orgh
		org

main		setb	dirb,#done_led
		loc	adra,#@clkgen		'clock generator
		coginit	#16,adra
		pinsetm	.mode,#data_out		'sync tx byte mode
		pinsetx	#0,#data_out
		setb	dirb,#data_out

.again		waitx	##sys_clk * 3
		clrb	outb,#done_led
		pinsety	#$82,#data_out		'send byte
.busy		testb	inb,#data_out wc	'wait for smartpin
	if_nc	jmp	#.busy
		setb	outb,#done_led		'done
		pinack	#data_out
		jmp	#.again

.mode		long	%1_11_11000_0001_0100_00_0_0000000000000

'=========================================================================
		orgh	$400
		cog

clkgen		setb	dirb,#clk
.again		waitx	##sys_clk * 10
		rep	@.loop,#16		'8 clocks @ 0.5Hz
		notb	outb,#clk
		waitx	##sys_clk 
.loop
		jmp	#.again

Am I missing something in the configuration?

«1

Comments

  • ozpropdevozpropdev Posts: 2,745
    edited 2016-03-06 07:13
    The same issue also appears in the long mode.
    First bit shifted out is bit 30 not 31 and last bit shifted out is bit 31.
    Also noticed that the first pass after a power up transmits 0's not the pattern required.
  • cgraceycgracey Posts: 13,373
    Looks like there's a bug.

    I'll get this fixed in the next release. I'm glad you noticed this!
  • cgraceycgracey Posts: 13,373
    I just realized something.

    By design, the first bit (MSB), is output BEFORE a clock edge occurs. Isn't that how it should be?

    I think you are seeing the data wrap around.

    Could you check this? There may be some other issue, but I think this is what you are seeing.
  • cgracey wrote: »
    By design, the first bit (MSB), is output BEFORE a clock edge occurs. Isn't that how it should be?

    That depends.

    For I2C, the data output changes while the clock is low. In this case, the first bit is set before the clock edge occurs.

    For SPI, it can be either way. If the sync serial is fixed as you describe above, then the P2 can only support Mode 1 and 3. Further, if subsequent bits are only output on the falling clock edge, then it only supports Mode 0. Some SPI devices support only a subset of modes, so there is a possibility for a mismatch.
  • cgraceycgracey Posts: 13,373
    Seairth wrote: »
    cgracey wrote: »
    By design, the first bit (MSB), is output BEFORE a clock edge occurs. Isn't that how it should be?

    That depends.

    For I2C, the data output changes while the clock is low. In this case, the first bit is set before the clock edge occurs.

    For SPI, it can be either way. If the sync serial is fixed as you describe above, then the P2 can only support Mode 1 and 3. Further, if subsequent bits are only output on the falling clock edge, then it only supports Mode 0. Some SPI devices support only a subset of modes, so there is a possibility for a mismatch.

    It updates on positive clock edges, but you can easily flip the incoming 'B' input to get negative edge.

    Couldn't you just give it one clock pulse before doing the PINSETY if you wanted post-clock updating?
  • jmgjmg Posts: 14,592
    cgracey wrote: »
    I just realized something.

    By design, the first bit (MSB), is output BEFORE a clock edge occurs. Isn't that how it should be?
    Yes, data is usually placed on the edge that is not the active edge , but config selects which clk edge that is.
    SPI systems usually config POL & PHA & some allow MSB.

    (If you design synch using only _/= FF that limits spi to sysclk/2, the common limit)

    For i2c you ideally want some delay between data change and clk changes, and I've seen some designs implement a 4 phase scheme (like a quad ctrl) for that. Clk is then sysclk/4 in this mode.
  • RaymanRayman Posts: 11,813
    Can we manually set the initial clock Hi/lo condition and then just have the smartpin toggle the state (instead of going to a particular state)?
  • cgraceycgracey Posts: 13,373
    Rayman wrote: »
    Can we manually set the initial clock Hi/lo condition and then just have the smartpin toggle the state (instead of going to a particular state)?

    It outputs "0", initially, but you can change that to high by setting the "O" output-invert bit in the low-level pin setup when you do the PINSETM.

    The transition output mode toggles the output, regardless of current state.
  • jmgjmg Posts: 14,592
    cgracey wrote: »
    It outputs "0", initially, but you can change that to high by setting the "O" output-invert bit in the low-level pin setup when you do the PINSETM.
    That covers the usual SPI CPOL option, but how do you cover the SPI.CPHA phase equivalent ?
    (same as a phase shift in the SPI Data out )

  • cgraceycgracey Posts: 13,373
    jmg wrote: »
    cgracey wrote: »
    It outputs "0", initially, but you can change that to high by setting the "O" output-invert bit in the low-level pin setup when you do the PINSETM.
    That covers the usual SPI CPOL option, but how do you cover the SPI.CPHA phase equivalent ?
    (same as a phase shift in the SPI Data out )

    Generate one clock pulse before doing the PINSETY to set the output data?
  • jmgjmg Posts: 14,592
    cgracey wrote: »
    jmg wrote: »
    cgracey wrote: »
    It outputs "0", initially, but you can change that to high by setting the "O" output-invert bit in the low-level pin setup when you do the PINSETM.
    That covers the usual SPI CPOL option, but how do you cover the SPI.CPHA phase equivalent ?
    (same as a phase shift in the SPI Data out )

    Generate one clock pulse before doing the PINSETY to set the output data?
    Not sure that would work in continual transmission cases ?
    In SPI CPOL simply flips the clock, but CPHA changes which edge (leading/trailing) updates and samples data.
    When you look at SPI specs, the nett result is a half-clock-period shift in data placement.

  • cgraceycgracey Posts: 13,373
    edited 2016-03-08 00:59
    I'm struggling to get the NCO added to the asynchronous serial. It's wound up tightly with the synchronous mode and it's not simple.

    How important is NCO baud for asynchronous serial?

    It seems to me that baud rates above 1MHz are usually 1/2/4/8MHz. USB is 12MHz, but that's a different animal. Can someone please give an example of why we'd need NCO baud rates for async, if we'll be able to hit the common low-Mhz bauds?


    EDIT: I think I just figured out what I needed to do to implement it.
  • I think if we have low bit number (2 bit? 4bit?) options with the NCO controlled streamer, that would help
  • cgraceycgracey Posts: 13,373
    Tubular wrote: »
    I think if we have low bit number (2 bit? 4bit?) options with the NCO controlled streamer, that would help

    I'll get those in there. That will take maybe an hour, or two.
  • jmgjmg Posts: 14,592
    edited 2016-03-08 01:21
    cgracey wrote: »
    I'm struggling to get the NCO added to the asynchronous serial. It's wound up tightly with the synchronous mode and it's not simple.

    I would have thought a shared common baud system was simpler ?
    There are also what I would call Clocked Async modes, where the Data pin has the usual Start and Stop async framing, but is delivered with a companion CLK.

    The FT232H series use this, in their fast Serial mode.
    In this case, you want a sort of hybrid, with a Clock generated by P2, of fixed phase relative to any transmission, and any Rx is sampled using that clock, but with Async rules for Start/Stop bits.
    ( but because the CLK is provided there is no need for re-sync on start-bit )

    With a CLK, you can go above the SysCLK/3 limit, and FTxxH parts can go to 50MHz
    so that gives a practical, existing device target.

    cgracey wrote: »
    How important is NCO baud for asynchronous serial?

    It seems to me that baud rates above 1MHz are usually 1/2/4/8MHz. USB is 12MHz, but that's a different animal. Can someone please give an example of why we'd need NCO baud rates for async, if we'll be able to hit the common low-MHz bauds?

    It's not drop-dead critical, as systems out there now work without fractional Baud.

    The issue is fractional Baud is expanding, and the P2 has already constrained PLL control, and the Single SysCLK VCO will have values imposed on it, by others parts of the system.

    NCO (fractional baud) allows those designs with 'imposed value' clocks to support higher value baud rates.

    Raspberry PI, for example, has a UART starting point of 15.625 MBaud
    (Pi3 I think can now do 25Mbd). Register names suggest that has fractional choices, but I've not see OS or library examples that actually use that.
    Pi3 also seems to have swapped UARTS to give the 'better' one to Bluetooth, and that likely has caveats.

    The default USB-UART Baud formula is 12MHz/N or 24MHz/N, with some newer parts allowing fractional baud.
    That means 12/8/6/4.8/4/3.428/3... etc are the new 'standard baud rates'

    To me that 25MBd (and faster SPI) values of Pi3, are low hanging fruit that Prop2 can use, to give a compelling support card offering.
  • jmgjmg Posts: 14,592
    cgracey wrote: »
    EDIT: I think I just figured out what I needed to do to implement it.

    Great :)
    This NCO resyncs for Rx on Start bit, right ?
  • jmgjmg Posts: 14,592
    cgracey wrote: »
    Tubular wrote: »
    I think if we have low bit number (2 bit? 4bit?) options with the NCO controlled streamer, that would help

    I'll get those in there. That will take maybe an hour, or two.
    Cool.
    The 4 bit mode will be very widely used, with QuadSPI, but needs to be nimble.
    ie it will be changing direction often, and some QuadSPI parts need one-bit preambles of up to 32 clocks to set mode+addr, before Quad kicks in.
    Most of the faster/smarter ones power up in 1 bit, and then can sticky-lock to Quad.
    A good library (and compact boot loader) would likely do a reset to one bit then apply quad, to be sure where it was.
    That means change from 4b <-> 1b streaming, needs to be easy.

    2 bit mode I see as useful for JTAG, which raises the detail of what bit-order should apply ? Are there other common 2 bit standards out there ?

  • cgraceycgracey Posts: 13,373
    jmg wrote: »
    cgracey wrote: »
    EDIT: I think I just figured out what I needed to do to implement it.

    Great :)
    This NCO resyncs for Rx on Start bit, right ?

    Yes, of course.

    Thanks for all your examples, jmg.
  • I've noticed that a PINSETY command in sync. tx byte mode has no effect on the bit counter.
    If I send say 11 clocks instead of 8 all subsequent tx'd data will be shifted by 3 bits.

    On initialization of he smartpin if I issue 7 dummy clocks it "aligns" the bit counter and all subsequent transmissions are correctly aligned.

    I've got a Interactive Logic Analyzer program for the P123-A9 that captures all my tests.
    I'll post it tomorrow with some notes on sing it. Its been useful for learning smartpin operation.


  • cgraceycgracey Posts: 13,373
    ozpropdev wrote: »
    I've noticed that a PINSETY command in sync. tx byte mode has no effect on the bit counter.
    If I send say 11 clocks instead of 8 all subsequent tx'd data will be shifted by 3 bits.

    On initialization of he smartpin if I issue 7 dummy clocks it "aligns" the bit counter and all subsequent transmissions are correctly aligned.

    I've got a Interactive Logic Analyzer program for the P123-A9 that captures all my tests.
    I'll post it tomorrow with some notes on sing it. Its been useful for learning smartpin operation.


    I'm redoing that circuit now, so I'll give it a thorough testing this time.
  • Here's the code I used to visualize the smartpin outputs on a P123-A9 board.
    it's a basic ;pgic analyzer that captures and displays pin activity on a VGA monitor.

    In the included test code I have set up 2 smartpins.
    The first as a sync byte transmitter and the second as a trasition output.
    The idea was to supply the clock from the second smartpin.

    As there is no internal feedback of the smartpin outputs I have linked them to two other pins in standard Io mode.
    This was necessary for the streamer to capture them.
    Pin 20 (data_pin) output is linked to pin 22 (data_fb)
    Pin 21 (clk_pin) is linked to pin 23 (clk_fb)
    Pin 18 is used to mark the execution of the PINSETY instruction used to set the tx byte.

    The four buttons on the P123-A9 board are used to control the tests.
    The labels at the bottom of the LA screen show their functions.

    In the code there is a section labelled "fix" which if removed or changed to differnt values (multiples of 2) shows the alignment issue mentioned earlier in this thread.

    This code is very much a work in progress and I plan to add more features along the way.
  • That's pretty neat and very useful

    I note when repeating the send time timing of clk, data, done all shift slightly (but in a quantized way) relative to pinsety. Is it triggering off pinsety?

    One very minor thing - the third button is also labelled INC, same as the second button, though its function clearly decrements
  • Thanks Tubular for picking up on that.
    I corrected that and a few typos.
    The shift you are seeing I believe is linked to the PINSETY that start the transition output.
    Maybe it's a smartpin comm slot thing?
    Cheers
    Brian
  • Thats what I thought too, initially, but try scaling pinsetx to #10, it's exactly the safe effect but more compressed in time

    The other weird thing - there are 5 possible 'slots' on quantized offsets (not 8 or 16 or other power of 2. The order they appear in is different each time the P2 is loaded (doesn't follow the same sequence after fresh F11 loads)
  • I found that 7,15,23 and 31 dummy pulses align things Ok.
    Other values seem to ignore PINSETY on every second pass.
  • Update: Version 3 - fixed plotting bug and added screen capture stuff.
    1024 x 768 - 65K
  • cgraceycgracey Posts: 13,373
    ozpropdev wrote: »
    Update: Version 3 - fixed plotting bug and added screen capture stuff.

    That's pretty neat!
  • cgraceycgracey Posts: 13,373
    edited 2016-03-09 23:09
    I think I've got the new serial mode finished for the smart pins.

    It supports 15-bit N-clock and NCO baud rates in async modes and its word length is settable from 1..32 bits.

    The async modes work up to clock/2, though it's certainly at the edge. Clock/3 should be quite safe, though.

    I'm confirming that the sync modes are okay now. You can select sample positions of 1 or 2 clocks before the clock edge.
  • jmgjmg Posts: 14,592
    cgracey wrote: »
    I think I've got the new serial mode finished for the smart pins.

    It supports 15-bit N-clock and NCO baud rates in async modes and its word length is settable from 1..32 bits.

    The async modes work up to clock/2, though it's certainly at the edge. Clock/3 should be quite safe, though.

    I'm confirming that the sync modes are okay now. You can select sample positions of 1 or 2 clocks before the clock edge.

    Wow, Great, sounding very flexible now :)

    Async to /2 would realistically only be used in RX with a companion CLK, such as in the FTDI Fast Serial mode, but it is important to be able to operate to that.

    I presume you can start/stop a CLK pin, and Serial RX in known phase ?


    Tx to /2 might be used for asymmetric clocked designs - because P2 can support pretty much any baud, remote slave P2's could run at lower power Clock speeds, to a higher speed clocked HUB.
    I guess Tx to /1 could even be useful in that case ?


    Have you looked at the sustained speeds issues in the 8-25-50MBd regions ?
    Ozpropdev's tests suggested 3 stop bits added, at 8MBd
  • cgracey wrote: »
    I think I've got the new serial mode finished for the smart pins.

    It supports 15-bit N-clock and NCO baud rates in async modes and its word length is settable from 1..32 bits.

    The async modes work up to clock/2, though it's certainly at the edge. Clock/3 should be quite safe, though.

    I'm confirming that the sync modes are okay now. You can select sample positions of 1 or 2 clocks before the clock edge.

    That's exciting stuff! Dare I ask how soon you'll have an updated image available?
Sign In or Register to comment.