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?
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.
@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.
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.
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?
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.
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.
Comments
No. It's directly between pads in these cases. No core logic is involved.
EDIT: Not that I've verified this assertion.
@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
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.
This is my well worn comport transmit routine: 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:
And you could conserve the Z flag:
Whoops! Never mind. I didn't remember that you were restoring C and Z on the RET.
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.