Smartpin Sync. transmit byte/long issue
ozpropdev
Posts: 2,792
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.
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 #.againAm I missing something in the configuration?
Comments
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.
I'll get this fixed in the next release. I'm glad you noticed this!
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.
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?
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.
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.
(same as a phase shift in the SPI Data out )
Generate one clock pulse before doing the PINSETY to set the output data?
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.
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'll get those in there. That will take maybe an hour, or two.
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.
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.
Great
This NCO resyncs for Rx on Start bit, right ?
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 ?
Yes, of course.
Thanks for all your examples, jmg.
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.
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.
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
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
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)
Other values seem to ignore PINSETY on every second pass.
That's pretty neat!
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
That's exciting stuff! Dare I ask how soon you'll have an updated image available?