Shared smartpins - Pro's and Con's?

ozpropdev

While playing with the smartpins I realized that it's possible for multiple cogs to fight over the same smartpin.
In this example I have setup a smart pin as an async transmitter and use the same pin from 4 cogs.
The resultant output is "ABCDABCDABCD...".
While I see this sharing could be useful in some modes (measurement) it may cause havoc in others.
Do the smartpins require a "locked to owner cog" control?
Or is this just a simple case of a WARNING in the docs?

'Shared smartpin example - 4 cogs using 1 serial transmitter

	baudrate = 115_200
	tx_pin = 62

dat	org

		pinsetm	a_serial8,#tx_pin	'setup smartpin
		pinsetx	bitclkz,#tx_pin		'set baudrate
		setb	dirb,#tx_pin		'enable smartpin

		loc	adra,#mycode
		setq	##20_000_000		'start delay (1/4 sec)
		coginit	#1,adra			'launch cog

		setq	##40_000_000		'start delay (1/2 sec)
		coginit	#2,adra			'launch cog

		setq	##60_000_000		'start delay (3/4 sec)
		coginit	#3,adra			'launch cog

.loop		waitx	##80_000_000		'wait 1 sec
		pinsety	#"A",#tx_pin		'send "A" character
		jmp	#.loop

bitclkz		long	80_000_000 / baudrate
a_serial8	long	%1_00_11100_0000_0000_00_0_0000000000000

'======================================================================
		orgh	$400
		org

mycode		waitx	ptra		'get start delay in ptra
		cogid	adra
		add	adra,#"A"	'generate test chracter
.loop		waitx	##80_000_000	'wait 1 sec
		pinsety	adra,#tx_pin	'send character
		jmp	#.loop

Electrodude

At least something sensible happens. I would have thought that doing that would seriously confuse the smartpins, since I was under the impression that the lines to each smartpins were each OR'd together from each cog.

What if you add random waitcnts in your loop? Does it still do the same thing? Or does it get misconfigured or confused or locked up or something else bad?

jmg

ozpropdev wrote: »

Do the smartpins require a "locked to owner cog" control?

Good question.
Depends on what you want to protect against ?

Present Prop has 'free for all' on Pins, so an errant COG can crash any pin it likes.
Certainly, there could be merit in a safer mode, where outside code cannot take down a system, but that level of sophistication may be too much for P2 ?

I think that means you also lock items like PLL, and any other global-access critical control registers.

ozpropdev

Electrodude wrote: »

What if you add random waitcnts in your loop? Does it still do the same thing? Or does it get misconfigured or confused or locked up or something else bad?

It seems to be a case of first in first served.
No lockup or invalid characters but as expected random output. (BCDBCDBACDBCDBCDBDCBDC)
I assume some chracaters were lost along the way.

A note in the doc's is propbaly all that is needed in the end.

cgracey

ozpropdev wrote: »

...A note in the doc's is propbaly all that is needed in the end.

Yes, I need to outline limitations.

All cogs can simultaneously do PINGETZ on the same pin, but PINSETx/PINACK to the same pin cannot be from multiple cogs at once.

jmg

cgracey wrote: »

ozpropdev wrote: »

...A note in the doc's is propbaly all that is needed in the end.

Yes, I need to outline limitations.

All cogs can simultaneously do PINGETZ on the same pin, but PINSETx/PINACK to the same pin cannot be from multiple cogs at once.

'at once' sounds like it needs expanding ?
Can multiple COGS can interleave access, viz any time the channel is not busy with another COG ?

potatohead

That by definition is still one COG at a time. Should work, but needs quick test, and debug for potential overlap.

mindrobots

Any type of locking mechanism built into the chip restricts experimentation and "feature discovery" and limits forever the implementation of the impossible.

A caution in the documentation leaves the impossible as a possible achievement with the P2.

Propellerheads like to achieve the impossible!!