drvh, drvl - what do they do?
msrobots
Posts: 3,709
in Propeller 2
It seems to me that I have some misunderstanding here.
I was thinking that they are there to put pullups/pulldowns on a pin declared as input, but it seems that this is wrong.
I also seem to struggle with the documentation as of why wrpin ##$1_0000, tx_out set the pin to registered mode, it does work but where is that written in the documents.
What I need is to have inputs with a pull down attached so they do not float and toggle when nothing is connected or started yet.
Mike
I was thinking that they are there to put pullups/pulldowns on a pin declared as input, but it seems that this is wrong.
I also seem to struggle with the documentation as of why wrpin ##$1_0000, tx_out set the pin to registered mode, it does work but where is that written in the documents.
What I need is to have inputs with a pull down attached so they do not float and toggle when nothing is connected or started yet.
Mike
Comments
To get resistive pull-down, set the low-side drive to, say, 15k and do a DRVL. The pin will read whatever its level is.
WRPIN ##%000_010_00_00000_0,#16
DRVL #16
But if DRVL sets the pin to output does it not conflict with the pin it is connected to?
I want to read another connected device sending as output. The P2 needs to be input. But with some pull down.
Wait, slowly I get you. As usual you are some steps ahead of me.
So I define the smart pins LOW state as 15k, drive the pin as OUTPUT low and read the pin as input. And for the other connected device this appears as a pulled down connection it can send too?
and why does wrpin ##$1_0000, tx_out regiters the pin, I mean where do I find that in your docs to look at?
I have a unbelievable amount of fun with the P2, thank you for doing this, it's alive now and just wonderful.
Mike
Look at the smart pin section in the Google doc. There is an image that has a purple blue background that shows all the drive modes of the smart pin.
The ring net driver is somehow working right now, I am using drvl without setting the smart pin to 15k and will change that.
Right now I do all my experiences with the P2 eval just by 'redirecting/double using' pins, I am to afraid to damage it until there are more available.
But I would like to run this over, say a servo cable and really connect different pins to see what difference this makes on usable sys clock dividers of the streamer over wires.
But I am good at making stupid wiring mistakes (damn those Silk screen labels are small), and - well - need more P2's.
Enjoy!
Mike
I will post a black and white version in the next few days. Sorry about that.
Chip has directed you to that pin mode config page for showing you all the available custom hardware options that's in each and every physical pin in the pad ring all the way around the very edge of the physical die. Pin mode config'ing is done with the WRPIN instruction.
WRPIN does two distinct jobs of configuring the smartpin mode and also configuring the pin mode. Smartpin config is only the bottom 6 bits, the %MMMMM_0 bits. The remaining 26 config bits are all pin mode config bits. Which is why WRPIN ##$1_0000, #5 enables Pin5's clocked I/O (registered I/O).
PS: The smartpin circuitry is not with the physical I/O. Smartpins are part of the synthesised core logic that was automatically laid by On Semi tools. Each one is a mini processor in its own right. They are likely near the centre of the die to keep the large number of associated databuses short. This creates long single bit paths out to the individual physical pins. Those paths had to exist anyway for IN/OUT and DIR, amongst others.
Right. It's actually WRPIN D[20:8], though, that are the low-level pin configuration bits. Bits above 20 and below 8 are all core-logic smart pin configuration bits.
WRPIN ##%100_000_010_00_00000_0,#16
DRVL #16
would be a registered pin usable as input and pulled down to by 15k to prevent spurious inputs if nothing connected, right?
Mike
Right. And you could set both high- and low-drive fields to %010, so that it drives 15k for both high and low output. Then, an external system could overpower that to make the pin read high or low.
I have been suffering from almost the same problem here (poor eyesight), so I can understand your difficulties...
Hope it helps
Henrique
Ouch! - Forum software is refusing to let me attach it to that post, either as a .png image or a zipped version of it.
ok, will do, because that is what I need.
This might be interesting. I have to think about it.
the P2 is just cool.
Mike
Let me know if I've used a term that isn't clear to understand.
Oops, yes. Just out of bed. The As, Bs and Fs are another group again. I've found the %TT bits are tricky to categorise.
##%100_010_010_00_00000_0 did not work, because I just have one P2. And no wires, one COG reads the same pin another COG uses to send. So i can not change HHHLLL, since both COGS use the same smart pin.
That is just a restriction of my development environment, when using different pins/P2s I may be able to activate this.
Next step is to simulate a 3 P2 net work with up to 16 data lines, that will use 0-47. Then I will go back to less data lines (<16) and, test a pin to pin connection over servo wires with some resistor in between.
Then ##%100_010_010_00_00000_0 should work for the receiver without affecting the smart pin of the sender.
If I start with 1-bit transfer I just can kill two pins, I am sadly good at that.
Mike
https://yanomani.weebly.com/uploads/1/0/5/7/105790329/background-images/194052254.png
Hope it can help
Enjoy!
Mike
Pin config is not smartpin config.
yeah, but in my simulated 'more then one P2' environment, I am cheating and use the same smart pins from different COGs. Thus it interferes.
Mike
My own eyes do also feel more confortable to read it this way...
Time to have some more pills, now a Vitamin A suplement. Ouch!
Mike
************************************************************************ Outline of where WRPIN config bits go (for digital modes at least) ************************************************************************ All cogs share the one per pin mode config register. WRPIN {#}D,{#}S D/# = %AAAA_BBBB_FFF_PPPPPPPPPPPPP_TT_MMMMM_0 Other ---------------------------------------- RND | v [============] [=============] [ (M == 0) ] [ ]<---------[---o----o---]<------- DIR [=============] DIR [ Logic Output] [ ] [ Pin Output ]<----------[ Config ] [ (M == 0) ] [========] [ Config ] OUT [ (%TT) ]<---------[---o----o---]<------- OUT [ ]<--------------[ (%P...P) ]<--+-------[ ] [ ] [Physical] [ ] | [=============] [ ] [ Even ] [=============] | [ Even # ] [ Pin ] ^ | [ Smartpin ] [ ]------ | | -1 -2 -3 [ Config ] [========] | | | | | | [ (%MMMMM_0) ] | | | v v v [ ] | | | [=============] A [ ] | PinB [=============] ------>[ Logic Input ]--------->[---o----o---]--------> IN ---------->[ Pin Input ] [ Config ] B [ (M == 0) ] | | PinA [ Config ]---------->[ (%A_B_F) ]--------->[ ] | +------->[ (%P...P) ] [=============] [ ] | | [ ] ^ ^ ^ [============] | | [=============] | | | | | +1 +2 +3 | | | | | | |\ | +------------------| |O------------------ Other | | |/ | | | v [============] | | [=============] [ (M == 0) ] | | [ ]<---------[---o----o---]<------- DIR | | [=============] DIR [ Logic Output] [ ] | | [ Pin Output ]<----------[ Config ] [ (M == 0) ] [========] | | [ Config ] OUT [ (%TT) ]<---------[---o----o---]<------- OUT [ ]<--------------[ (%P...P) ]<--+-------[ ] [ ] [Physical] | | [ ] | [=============] [ ] [ Odd ] | | [=============] | [ Odd # ] [ Pin ] | | ^ | [ Smartpin ] [ ]---+ | | | -1 -2 -3 [ Config ] [========] | | | | | | | [ (%MMMMM_0) ] | | | | v v v [ ] | | | | [=============] A [ ] | | PinB [=============] ------>[ Logic Input ]--------->[---o----o---]--------> IN | ------->[ Pin Input ] [ Config ] B [ (M == 0) ] | PinA [ Config ]---------->[ (%A_B_F) ]--------->[ ] ---------->[ (%P...P) ] [=============] [ ] [ ] ^ ^ ^ [============] [=============] | | | +1 +2 +3EDIT: Added inverter to odd "Other".
EDIT2: Added link to updates.
My basic idea is that I could use the absence of a high as indicator that the ring is broken.
I am also thinking about using a interrupt instead of waitse1 leaving a - constantly interrupted - COG to run some diagnostic or even user code on the pretty much empty COG while running the ring net driver.
Mike
EDIT: Ah, I should point out that there is only one mode config register per pin. If two cogs both do a WRPIN, then the first cog's WRPIN is overwritten by the second. If they coincide on the exact same sysclock cycle then the pin/smartpin config will be corrupted with unknown outcome.
This is different to OUT and DIR, where each cog has its own special register for each.
You know that means the tx task will be the one to wait for the go signal. It requires extra negotiation step because the rx task is no longer waiting for the exactly timed go signal.
In that ASCII diagram above, I've got the "Other" signal feeding into the %TT block, which is synthesised logic in my head, where it gets selected into the output path appropriately. Then goes back to the custom ring where it can perform many duties.
My question is: Does the PinB "Other" actually come out of the custom ring? Or is there only control lines and RND "Other" going into the custom ring with all the relevant muxes in there?
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.
Thanks
Martin
WXPIN is for writing smartpin X parameter.
WYPIN is for writing smartpin Y parameter.
RDPIN is for reading smartpin Z value.
When a smartpin is selected (%MMMMM != 0):
DIR no longer enables pin logic output drive but becomes smartpin enable instead.
IN no longer shows pin input logic level but becomes smartpin status instead.
OUT continues to function as logic level output although there is exceptions for certain smartpin modes.
Note: Be aware that WRPIN can do more than just select a smartpin mode. For example, there is also a logic input selector that can be used for plain IN reading.