Starting work on smart pins
cgracey
Posts: 14,152
I've started working on the smart pins.
The MSGOUT needed a little fixing, and it seems to be working now.
What is needed, next, is the message receiver that goes into the pin circuit.
I realized that pin message I/O could be done in the background and also be event/interrupt sources, so that you could automate smart-pin updating with interrupts, never stalling the cog.
I figure the first thing I'll make is a PWM. There are lots of simple output modes to tackle.
Later, I'll get the pin to output messages, so that we can implement ADC counters, rotary encoders, and what not.
In the next FPGA release, there will be some rudimentary smart pin circuits. Thanks to Ariba, we have some MAC-like instructions now to facilitate DSP, without needing dedicated accumulators.
The MSGOUT needed a little fixing, and it seems to be working now.
What is needed, next, is the message receiver that goes into the pin circuit.
I realized that pin message I/O could be done in the background and also be event/interrupt sources, so that you could automate smart-pin updating with interrupts, never stalling the cog.
I figure the first thing I'll make is a PWM. There are lots of simple output modes to tackle.
Later, I'll get the pin to output messages, so that we can implement ADC counters, rotary encoders, and what not.
In the next FPGA release, there will be some rudimentary smart pin circuits. Thanks to Ariba, we have some MAC-like instructions now to facilitate DSP, without needing dedicated accumulators.
Comments
I assume we can continue with minor bug fixes to the core, should they be found.
Personally, I'm pleased that the DSP level of functionality made a return. Was looking forward to learning more about that on the P2.
Agreed! It may seems like the smart pins are just one last feature to add, but I suspect it will be one of the most important capabilities of the P2! I am very much looking forward to it.
Can the PWM Clock be higher than the Core clock ?
A number of parts offer this, and this allows highest resolution PWM, with still modest power envelopes.
Then there is dual-edge (up/down counters) and deadband and trigger/reset actions.
Some parts push the PWM edge resolution beyond the clock, 1ns or 150ps but that may be outside P2 scope ?
I think it would take a PLL with multiple taps to get better than the clock.
Jmg, how do these up/down trigger things work?
Classic first generation PWM is a sawtooth counter, but that makes all trailing edges the same.
Common these days is adding modes for Up/Down counter (aka triangle counter ) that still has the Compare, but now both edges modulate, and you can define deadbands with simple differences in compare levels.
When driving high power FETS, some define the additional deadband in SW, and you can also buy MOSFET gate drivers that sense D-S voltage and delay gate hand-over to avoid crowbar conduction effects.
Trigger options are for current sense & trip use in SMPS / Motor drive, where an external signal truncates the current PWM until the next cycle.
Me too. And a lot of this will cover interesting, and new ground for me. Fun times ahead!
If you drive a FET full-bridge then this is the simplest way to get symmetrical PWM with adjustable deadtime.
It needs 2 output pins per counter, I think many of the Smartpin modes will use 2 paired pins. Encoder inputs for example (for that an up-down counter is also useful).
Andy
Easy peasy. Just run an NCO with two comparators - one for out1 and one for out2. I think the smartpin may be a two-pin affair.
For phased PWM, the disadvantage (compared to a phase register for each phase, dead band registers, and a shared duty cycle register) is that you have to compute and write the fall register for each phase for every duty cycle change (whilst taking into account the dead band for the calculation), but it's more flexible than a single duty cycle register for multiple phases.
One of the reasons I use the propeller is its PWM capability. It takes more cogs than I'd like (one per phase), but it's capable of phased PWM, dead time, and software stepping to increase the effective resolution without reducing the PWM rate, and all of these simultaneously.
16 cogs and 200 MHz goes a long way towards giving me the PWM chip of my dreams, but putting it in hardware with two compare registers per PWM pin with fault interrupts (already implemented !) would be even better.
Right time to ask about maybe including a dumb, asynchronous two pin invert? as in using 2 pins as an inverter, one input one output? This, with expected counter modes would make very high resolution inductive/capacitive/T.O.F. sensors trivial.
We've got all that in the analog pin, already. I will post a table within an hour.
Ok so I know there's analog output via those dac chips. Guess just asking about analog input possibility
PinA = this pin
PinB = neighbor pin (pin pairs are even/odd)
The "Input" column shows what is returned via INA/INB.
Mode %0000_000000000 (default) is a normal digital I/O pin.
Mode %0010_001011011 would be a dual-pin, unclocked, inverter with 100k-ohm feedback.
Mode %0100_001110110 would be a single-pin, unclocked, Schmitt-trigger relaxation oscillator with +/-10uA current feedback.
There's a 4 pin analog header on the P123-A9, just above the breadboard.
eg You can use one LSB for odd/even and another LSB for rise/fall to get to half-clock PWM granularity, (assumes 50% clock)
That's quite an overhead cost, both in SW and with two compare blocks, so this is sounding like another possible operating mode.
A common MCU timer option is a Pin-Toggle-on-Match, & what you describe could be achieved with two compare registers using that mode.
PWM designs also usually have a delayed update design, where the set-points only refresh at a PWM cycle end. This avoids missing an edge effect, where a SW change moves a set-point to the other side of the present counter value.
I think the Pin buffer on FPGAs has a small hysteresis, so you could likely do some simple threshold-based analog work, with that caveat.
Linear ramps ie RC flyback timing should mostly work, and Delta-Sigma would have to operate across that hysteresis-band, and cross talk could be significant.
I think I remember Chip's chart from P2-hot days...
I don't think Parallax wants to compete with microcontrollers dedicated to motor control and SMPS, but to make something flexible that can cover most of the bases, today and tomorrow, even if it takes somewhat more software than those other chips. Flexibility is why I suggest two (16-bit ?) compare registers per pin and common time bases.
In the end, I'll be happy with being able to duplicate P1 capabilities, with x2 speed and x2 cogs, even if I have to dedicate cogs to phases like I do now.
I would expect Parallax certainly do want to make a part that can be easily used for motor control and SMPS.
Totally agree!
The motion control market is huge and growing. I have used a couple of dedicated, $30+ motion IC's for my benchmark and have exceeded their capabilities already on the P1 using only two cogs.
With smart pins, that could be bettered with only one cog.
What about the routing overhead, and simultaneous access to Pins from COGs, as well as mapping of Pins to COGs ?
Parallel is faster, but I thought there were quite high costs to doing parallel from any of 16 COGS to any of 32-64 Pin cells ?
A time-slot mux (same as HUB) could reduce logic, but would that lose the ability of all COGS to lock onto one pin edge on the same SysCLK ?
Perhaps a mix ? - a direct connect path for low latency connected-sense, and access is time-slot parallel - that's faster in bursts than serial and could be even 8 bits DDR connected, to transfer 32b in one opcode time.
ie they would be accessible each hub slot (1:16 clocks)
Serial would be less routing, but bigger logic blobs on the pins.
I'm not sure yet. I could do a hybrid parallel/serial system, like 4-bit data paths that take 8 clocks to move a long.
I think you've misunderstood me a bit. Of course Parallax wants to make motor conteol and SMPS easy with the P2, but I don't think they want to directly support all the hardware modes that microcontrollers dedicated to motor control and SMPS support.
Instead, a very flexible counters / compare registers approach should let us support all those modes with software, like the P1 does now, but even better, without the need for each pair of pins to be babysat by a cog.
One way to do this is with two compare registers per pin and shared period counter(s), as I mentioned previously.
Another way is to have PHSx and FRQx registers for each pin. Two cogs could take care of reloading many PHSx registers at intervals (the period would have to have 16 clock granularity);. I cobbled together some PASM for this; it ends up being limited by the hub access window, with one read and two writes being necessary for the diode pin. The number of phases possible with two cogs depends on the PWM rate: 4 @ 800 kHz, 16 @ 200 kHz.
Yes, the cogs already have a nice pathway to the hub and cordic system. I suppose it would just be a 32-way link to a 32-way bus around the smart pins. A cog using the 1:16 hub could deliver/receive a 32-bit long to/from the smart pins every 16 clocks. That is 2x the clock speed !!!
Might it be possible (and worth it) to window the smart pins into a small block in the hub ram ???
Might even be possible to use the streamer/lut mechanism to stream to/from the smart pins ???