Streamer and Smartpin questions

ManAtWork

Sorry for asking things again that have probably discussed before... But I have problems understanding the docs and before I try out something that can't work I'll better ask in advance.

The streamer could be used to output a bit pattern directly to a pin, for example to make a SPI like interface with one smartpin in transition mode to output the clock and the MOSI data pin fed by the streamer. The flash ROM bootloader uses something like this so I'm pretty sure it works.

However, as I read the docs the streamer can't be used to feed a smartpin function like a WYPIN to asynchronous serial transmit mode. If I want to make a UART interface with streamer I guess I have to pre-process the data to include the start/stop bits before sending them, correct?

Additionally, the streamer is always NCO-driven with a constant data rate. It can't be used like a DMA channel known from other processors that can be triggered by events like receive-buffer-full or something. No problem, I could use interrupts or polling. I just don't want to make it more complicated if there was an easier way.

evanh

ManAtWork wrote: »

... The streamer could be used to output a bit pattern directly to a pin, for example to make a SPI like interface with one smartpin in transition mode to output the clock and the MOSI data pin fed by the streamer. The flash ROM bootloader uses something like this so I'm pretty sure it works.

Yep.

However, as I read the docs the streamer can't be used to feed a smartpin function like a WYPIN to asynchronous serial transmit mode. If I want to make a UART interface with streamer I guess I have to pre-process the data to include the start/stop bits before sending them, correct?

Correct. Remember, if it was an available capability then it'd still only be simplex or maybe half-duplex with overheads at best.

Additionally, the streamer is always NCO-driven with a constant data rate. It can't be used like a DMA channel known from other processors that can be triggered by events like receive-buffer-full or something. No problem, I could use interrupts or polling. I just don't want to make it more complicated if there was an easier way.

When dealing with hubRAM the streamer grabs data from the FIFO (Setup with a RDFAST), or places the data in the FIFO (Setup with a WRFAST). Together they form a simple DMA engine per cog.

There is a completion event, XFI, and a ready event, XMT. Chip uses WAITXFI in his flash_loader.spin2 code. These events can also be used for an interrupt or polled. Interestingly, I've not seen anyone use XMT, nor does it get described in the docs. Chip has stated that there is a single level command buffer but I've not thought to determine exactly how that interacts with software.

evanh

All the video drivers use XCONT and XZERO instructions to seamlessly adjoin disparate parts of the data stream, which stalls cog execution as needed. Presumably XCONT and XZERO wait on the XMT state.

cgracey

XMT means transmitter empty.

Under that condition, you can feed a new streamer command without having to wait. You would use the XMT event to trigger interrupts to keep the streamer fed, without ever having to stall on an XZERO or XCONT instruction.

evanh

Hmm, rethinking that, I'm a little wrong with the main purpose of XCONT and XZERO. They're really for precise timing of next lot of data. Adding pre-calculated timing gaps.

evanh

Testing the command buffer finds expected behaviour of holding an extra buffered command on top of the active command.

		setxfrq	##$1000_0000
		getct	misc1		'measure
		xinit	dm, #$a5
		xcont	dm, #$ac
		getct	misc2		'measure
		xcont	dm, #$ac
		getct	pa		'measure
		...
		...

dm		long	DM_1bIMMle | DM_DIGI_IO | 8

Measured execution: misc2 - misc1 = 6 sysclocks. PA - misc1 = 69 sysclocks

evanh

Notably, only XCONT and XZERO generates XMT events. XINIT does not.