Shop OBEX P1 Docs P2 Docs Learn Events
drvh, drvl - what do they do? - Page 2 — Parallax Forums

drvh, drvl - what do they do?

2»

Comments

  • evanhevanh Posts: 15,091
    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?
  • cgraceycgracey Posts: 14,131
    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.
  • evanhevanh Posts: 15,091
    edited 2019-07-07 17:48
    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. :D
  • @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

  • evanhevanh Posts: 15,091
    edited 2019-07-08 13:03
    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.
  • evanhevanh Posts: 15,091
    edited 2019-07-09 15:17
    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?

  • cgraceycgracey Posts: 14,131
    edited 2019-07-09 22:21
    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.
  • evanhevanh Posts: 15,091
    edited 2019-07-10 04:26
    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.

Sign In or Register to comment.