#### Equip your Genius

Welcome to the Parallax Discussion Forums, sign-up to participate.

# drvh, drvl - what do they do?

2»

• Posts: 7,904
cgracey wrote: »
I'm not at my computer right now and I can't remember, but the "other" comes out of the synthesized logic, not necessarily the other pin. I believe the Google Doc covers this.
Ah, same question for P config digital pin modes. Eg: P=%0010_CIOHHHLLL ( Input = PinB logic, PinA output from Input ). In this case, is there a signal path going from PinB in the custom ring, crossing into the core, then crossing back out to PinA?
"We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
By doing that, we can more accurately measure their mass, and determine whether
scientists have systematically been underestimating how much matter they contain."
• Posts: 11,711
evanh wrote: »
cgracey wrote: »
I'm not at my computer right now and I can't remember, but the "other" comes out of the synthesized logic, not necessarily the other pin. I believe the Google Doc covers this.
Ah, same question for P config digital pin modes. Eg: P=%0010_CIOHHHLLL ( Input = PinB logic, PinA output from Input ). In this case, is there a signal path going from PinB in the custom ring, crossing into the core, then crossing back out to PinA?

No. It's directly between pads in these cases. No core logic is involved.
• Posts: 7,904
edited 2019-07-07 - 17:48:36
Cool. I note, by inverting either in or out, that differential can be achieved with that mode. "OTHER" for differential becomes redundant.

EDIT: Not that I've verified this assertion.
"We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
By doing that, we can more accurately measure their mass, and determine whether
scientists have systematically been underestimating how much matter they contain."
• Posts: 430
@evanh
@Tubular
I am attempting to replicate some p1 code ctra,ctrb, frqa,frqb.
So that's why I am looking for explanations and examples of what those pin functions do.

Thanks

“Light thinks it travels faster than anything but it is wrong. No matter how fast light travels, it finds the darkness has always got there first, and is waiting for it.”
“You only live twice:
Once when you are born
And once when you look death in the face”
• Posts: 7,904
edited 2019-07-08 - 13:03:22
Pilot,
The counters there are being used to synchronously measure singular pulse widths. In the Prop2 there is a specific smartpin mode just for doing the same: Namely M=%10001 = Time A-input high states. It has no parameters, so it's ready to go the moment the mode is selected.

You'd want to use one smartpin for X-axis and a second smartpin for Y-axis.

There is a second variant of this method that incorporates measuring the pulse period. This potentially gains improved accuracy by accounting for drift in the pulse period (sensor clock frequency) The mode to use for this method is M=%10000 = Time A-input states. This mode also has no parameters. The risk with this one is glitches in the PWM could be problematic and may need guarded against.

Another quite different way is to asynchronously accumulate the PWM as a poor man's pulse density bitstream. This inherently incorporates the pulse period as well as smoothing the response. The mode to use for this method is M=%01111 AND !Y[0] = Count A-input highs. Set both X and Y parameters to zero. This method can extract greater resolution from the signal ... but might be best left until the final Prop2 is shipping. It has new hardware to make this method easier. This method is slower response because it is also a filter.
"We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
By doing that, we can more accurately measure their mass, and determine whether
scientists have systematically been underestimating how much matter they contain."
• Posts: 7,904
edited 2019-07-09 - 15:17:22
Chip,
This is my well worn comport transmit routine:
putch
rqpin	inb, #tx_pin	wc	'transmiting? (C high == yes)  *Needed to initiate tx
testp	#tx_pin		wz	'buffer free? (IN high == yes)
if_nc_or_z	wypin	pb, #tx_pin		'write new byte to Y buffer
if_nc_or_z	ret			wcz	'restore C/Z flags of calling routine
jmp	#putch			'wait while Smartpin is both full (nz) and transmitting (c)

The first instruction I added in (The alternative is extraneous character like a null) to cleanly start the ball rolling. Otherwise it'll get stuck waiting for the buffer to go empty without ever sending the first character.

The question I have is about my use of INB special register. The RQPIN instruction returns a longword and optionally the C flag. But I only required the C flag so have just dumped the longword into the read-only INB special register on the assumption that it vanishes.

Does the data truly vanish or do instructions like that end up filling the shadow cogRAM and I'm messing up debug registers or something?

"We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
By doing that, we can more accurately measure their mass, and determine whether
scientists have systematically been underestimating how much matter they contain."
• Posts: 11,711
edited 2019-07-09 - 22:21:57
evanh wrote: »
Chip,
This is my well worn comport transmit routine:
putch
rqpin	inb, #tx_pin	wc	'transmiting? (C high == yes)  *Needed to initiate tx
testp	#tx_pin		wz	'buffer free? (IN high == yes)
if_nc_or_z	wypin	pb, #tx_pin		'write new byte to Y buffer
if_nc_or_z	ret			wcz	'restore C/Z flags of calling routine
jmp	#putch			'wait while Smartpin is both full (nz) and transmitting (c)

The first instruction I added in (The alternative is extraneous character like a null) to cleanly start the ball rolling. Otherwise it'll get stuck waiting for the buffer to go empty without ever sending the first character.

The question I have is about my use of INB special register. The RQPIN instruction returns a longword and optionally the C flag. But I only required the C flag so have just dumped the longword into the read-only INB special register on the assumption that it vanishes.

Does the data truly vanish or do instructions like that end up filling the shadow cogRAM and I'm messing up debug registers or something?

It's fine to use INB for that. INA and INB are actually used for the hidden debug vectors, but they are only writable in a special mode, so your use here is fine.

You could code your loop like this:
putch		rqpin	inb, #tx_pin	wc	'transmiting? (C high == yes)  *Needed to initiate tx
testp	#tx_pin		wz	'buffer free? (IN high == yes)
if_nz_and_c	jmp	#putch			'wait while Smartpin is both full (nz) and transmitting (c)

_ret_		wypin	pb, #tx_pin		'write new byte to Y buffer

And you could conserve the Z flag:
putch		rqpin	inb, #tx_pin	wc	'transmiting? (C high == yes)  *Needed to initiate tx
testpn	#tx_pin		andc	'buffer free? (IN high == yes)
if_c	jmp	#putch			'wait while Smartpin is both full and transmitting

_ret_	wypin	pb, #tx_pin		'write new byte to Y buffer

Whoops! Never mind. I didn't remember that you were restoring C and Z on the RET.
• Posts: 7,904
edited 2019-07-10 - 04:26:14
Excellent thanks.

Have just reused that check of tx complete in the process of building a more generalised sysclock frequency setting routine and figured I should address the possible niggle before forging ahead with using INB like that in other places.

It turns out, with all the possibilities of crystal frequencies and divider/multiplier combinations, it's not that easy to fully generalise adjusting the sysclock. I've settled on assuming the multiplier component of HUBSET having 1 MHz resolution and all other components being constants to suit.

"We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
By doing that, we can more accurately measure their mass, and determine whether
scientists have systematically been underestimating how much matter they contain."