Slave Output Pin using counters?

Tubular

I have an application where i'd like to parallel multiple output pins in hardware, if possible.

I was wondering whether there is a way to do this using the counters, but the nearest I can come up with would be a POS or NEG mode with feedback, where the B pin output would be inverted (!A, delayed 1 clock). I could then pass that inverted output through a second counter to achieve my goal, it would just use 2 counters instead of one.

I'm not using the counters for anything else this time. I don't mind the one or two clock delay. It might even be useful.

Anyone know of a way to achieve this using just a single counter?

Tracy Allen

Not without the double inversion. To have multiple outputs, multiple cogs would have to be running to enlist their counters, so why not just start a cog with a pasm loop to map the i/o any way you want, a bit more delay.

Phil Pilgrim (PhiPi)

What Tracy said:

:loop   test    inp_mask,inp_mask wc
        muxc    outa,out_mask
        jmp     #:loop

One dedicated cog; 8 to 12 clock delay.

-Phil

Tubular

Yes that would work, however the counters seem to recover from low voltage excursions somewhat automatically so I'm keen to pursue the hardware approach for at least a little longer and see where it goes. And the hardware counter approach should be faster at 1 or 2 clock delay.

It just occurred to me perhaps it makes sense just to invert the software controlled "master" pin, in code, but not connect that to anything. Just have multiple slave hardware counter pins feeding off that one inverted master, inverting their outputs back to positive logic. That would allow up to 16 hardware slaves (spare counters permitting) at the expense on 1 wasted pin, an "overall win"

Thanks for the input

Phil Pilgrim (PhiPi)

Tubular,

What's your overall objective here? Give us the big picture. And I'm not sure what you mean by "... the counters seem to recover from low voltage excursions somewhat automatically ..."

-Phil

Phil Pilgrim (PhiPi)

'Just happened to think, this may be faster than my example code above:

:loop   waitpeq inp_mask,inp_mask
        or      outa,out_mask
        waitpne inp_mask,inp_mask
        andn    outa,out_mask
        jmp     #:loop

-Phil

Tubular

I was afraid someone would ask for the big picture. Its a jigsaw, with a few pieces missing, and some most likely from another jigsaw

There are three applications that I've mucked around with in the past, and am now revisiting:-
1) Decreasing the drive resistance at low operating voltages (below 1.5 volts). The P and N fet resistances increase up above 100 ohms, and they are no longer symmetric.
2) Increasing the drive current at nominal 3v3, to drive very small motors (ie the Prop's pins are ganged 6 or 8 way to create a dual H-bridge).
3) Decreasing the drive resistance at higher voltages (3v6, perhaps nudging 4v). I've been experimenting with combining power and high speed data onto 2 wires - data/power and gnd, and rectifying to recover power at the other end. That's working nicely but the clear limit is the P fet resistance.

I'll get back to this thread later and drop in links to other posts scattered across the forums. I'll try your loop code, thanks for that.

Phil Pilgrim (PhiPi)

Given your objectives, why do you have to mirror a single pin? Why not just drive all the pins that you want to parallel in code?

-Phil

Tubular

Yes its usually an option, as is adding external fet(s). I did that for the h-bridge motor test

One advantage is using obex objects as-is, just using any spare cog counters to reinforce the output. Some might feel safer with a hardware approach to mirrored pins. Apart from that it's just interesting to see how much can be done inside the chip, especially anything taking advantage of counters.

I need to revisit some experiments at very low voltage (Lawson's thread). My memory is that the counters keep toggling, even after the software driven outputs have given up. Whether that difference just applies to NCO mode, or POS/NEG mode with feedback, would be good to know.