Accessory Set: Control Board
tomcrawford            
            
                Posts: 1,129            
            
            
                            
                                  in Propeller 2             
        
                    The switches do not have pulldowns:  when not pressed, the pin just sees an open circuit.  The only way I could get them to work right is:
tc
                            dir[]~~ drive the pin out[]~ low dir[]~ release waitcnt() I/O pipelining? in[] read it
tc

                            
Comments
That, said, I did see something about picking a drive current, which I guess is similar to a series resistor...
Definitely need to put this there (actually a deciphered version of this would be better, I have to relearn every time I look at this...):
EDIT: Damn smilies in code block!
So it does.
It's right there in those VVV bits ...
Hmm, I'm going to have to improve my deciphering. I've kind of given IN two separate purposes in the same lines.
The input signal path always goes from the pin into the %AAAA_BBBB_FFF selectors before reaching either the smartpins or cog's IN. So, my left-hand use of IN is too early in the signal path.
I believe the right-hand use of IN is correct. It is what the cogs see.
EDIT: No, I must be wrong. IN is consistent within that text. It isn't the cog's IN though, it's just the pin input within the custom pad ring. The purpose of having it reflect itself is to be able to do something like a sigma-delta ADC with external capacitor and still only need a single pin.
Logic buffered "OTHER" [=============] [============] -------------------------------->[ Logic Output] [ ] | -----------------[ Config ]<---------[---o----o---]<------- DIR | | [ (%TT) ] [ (M == 0) ] | v [ ] [ ] | [=============] [ ] [ ] [========] | [ Pad Output ] [ ] [ (M == 0) ] [Physical]<----------[ Config ]<------+---[ ]<---------[---o----o---]<------- OUT [ PinA ] | [ (%P...P) ] | [=============] [ ] [ ]-------- [=============] ??| [ ] [========] | | ^ | [ Smartpin ] | | | | -1 -2 -3 [ Config ] | | | | | | | [ (%MMMMM_0) ] | | | | v v v [ ] | | | | [=============] A [ ] [========] | | [=============] -->[ Logic Input ]--------->[---o----o---]--------> IN [Physical]--- -->[ Pad Input ] [ Config ] B [ (M == 0) ] [ PinB ] [ Config ]---------->[ (A_B_F) ]--------->[ ] [ ]---------->[ (%P...P) ] [=============] [ ] [========] [=============] ^ ^ ^ [============] | | | | | | +1 +2 +3EDIT: Added the ?? (OUT) input to Logic Inputs. I'm completely unsure of this source.PS: This actually worked with the FPGA. I used %CIOHHHLLL = %000111111 to set floating output drive. With both DIR and OUT high, the pin happily sank low on its own.
Express SCH is a free and reasonable schematic package.
I've started looking at LibreOffice Draw. It seems better suited. So I'm trying to expand the overall diagram at the same time. The pins are somewhat paired at the low level.
CON basepin = 32 '<32 use ina/outa, =>32 use inb/outb button = basepin+7 led = basepin+3 isbutton = %010_00_00000_0 '15k pulldown pub main asm wrpin ##isbutton,#button endasm dirb[button]~~ 'button still acts as input dirb[led]~~ repeat outb[led] := inb[button]Edit: Even SPINnier...CON basepin = 32 isbutton = %010_00_00000_0 '15k pulldown pub main | i repeat i from basepin+4 to basepin+7 asm wrpin ##isbutton,i endasm dirb[basepin..basepin+7]~~ 'buttons still act as input repeat outb[basepin..basepin+3] := inb[basepin+4..basepin+7](And what, the LED's aren't in the same order as the buttons?)edit 2: I got my control board in my charlieplexing LED matrix (attached)
But that gives at least for 2 buttons and LEDs the ability that the LED and its corresponding Button are in the reach of +-3 from each other.
Would that mean that when I set the output of the smart pin to the input of another smartpin one would not need that repeat loop above, but the LED would lit when the button is pressed, because the pins talk directly via smartpin?
curious,
Mike
I look forward to the day when Prop2 is documented as well as Prop1 (and I know that day will come).
Edit: and Thank you, @evanh
Buttons: 1 4 LEDs: 1 8 2 8 2 4Added a spin2 to echo bit pattern to the charlieplexed LED matrix in my last comment.Works as long as the Control Acc is located with 32 or greater basepin... repeat if ctrl_base < 32 v := inb[ctrl_base+4..ctrl_base+7] '<== inb? outb[ctrl_base..ctrl_base+3] := v '<== outb? else v := inb[ctrl_base+4..ctrl_base+7] outb[ctrl_base..ctrl_base+3] := v Change to: repeat if ctrl_base < 32 v := ina[ctrl_base+4..ctrl_base+7] '<== fixed :-) outa[ctrl_base..ctrl_base+3] := v '<== fixed :-) else v := inb[ctrl_base+4..ctrl_base+7] outb[ctrl_base..ctrl_base+3] := vdgately
Nah @localroger there are some typos, you use the button numbers for LEDs
best would have bee buttons and LED on odd/even pairs
Enjoy!
Mike
Express Schematic is actually quite good for block diagrams. I often use it for that purpose.
Attached are some examples
for the 'Control' P2-ES Eval accessory board, can someone explain how to read the pushbutton i/o using SPIN2?
I assume there's a way to add pull-downs to the pins somehow? (without having to use pasm)
Using PINR() yields high regardless of whether the pushbutton is activated or not, maybe either because the input floats high or is already pulled high internally?
cheers,
Edit: Updated file.