Capturing is for states and rise-to-rise, as well as pin <> adjacent pin. For states and pin mismatch capturing, the MSB of the 32-bit return value holds the state or mismatch, while the 31 LSBs hold the count. It can capture 1-clock events, but in such cases, the prior measurement will be quickly lost, and you'll only get the more recent one. You'd better have a low duty cycle for 1-clock event capturing. Hmmm... is there any value in simply capturing a time stamp on an edge? We've got a single 32-bit return value to work with.
As well as the above simple time-stamp capture, there is another 'Armed-Capture' that is very useful in Frequency Counters.
That does a one-shot, same edge, capture of two 32b values : (ie sounds like 2 Pin cells used ?)
One 32b is time, and the other 32b is Cycles (so is actually a counter that increments on the capture clock, but the capture enables on a gate-based time delay, and captures once per arm-command.
Honestly, what they will need to understand is a P2 pin, can just be a pin, or it can be more fully utilized as a peripheral. From there, it will follow that the pin itself does stuff. And of course, "what stuff exactly....?"
Which our nice datasheet to come one day soon will explain all of that.
The nice thing about it, is one can say pin, and it works in the classic sense in every context. Change that to PIP, and now it's in the specific context of the P2, and all the other verbiage can remain the same. Easy.
So back to just PIN then. Simple. Already universally accepted. And under the hood might represent the all new Programmable Intelligent Node.
Actually smartpin is kinda neat, as that also abbreviates to Spin, which obviously recognises it's own control language.
Well, I guess waiting is in order until the silicon arrives. Then we can really play the name game, based on the actually included features.
Can't wait!!
Or... Go get a $79 Terasic DE0-Nano and actually try out in a few more days.
If you want to try it ALL out (except all the analog, which needs real silicon), we have a Cyclone V -A9 board for $475 that has DACs and the capacity to emulate the whole digital design.
Smart pins can process two inputs, A and B. The smart pin can only drive its local pin, though.
I had things set up so that input A was the pin local to the smart pin circuit and B was its odd/even complement pin (A/B = 0/1, 1/0, 2/3, 3/2, etc). That was kind of constraining.
Now each smart pin is fed not just it's local and adjacent IN signals, but 8 relative pins: +3/+2/+1/0/-1/-2/-3/-4. The smart pin can select from these 8 IN's what its A and B inputs are.
This means you can gang smart pins up on one physical input pin to take multiple measurements, concurrently.
Smart pins can process two inputs, A and B. The smart pin can only drive its local pin, though.
I had things set up so that input A was the pin local to the smart pin circuit and B was its odd/even complement pin (A/B = 0/1, 1/0, 2/3, 3/2, etc). That was kind of constraining.
Now each smart pin is fed not just it's local and adjacent IN signals, but 8 relative pins: +3/+2/+1/0/-1/-2/-3/-4. The smart pin can select from these 8 IN's what its A and B inputs are.
This means you can gang smart pins up on one physical input pin to take multiple measurements, concurrently.
Cool, does this also mean that we could potentially share one common clock pin from the neighboring 8 pins between multiple I/O COGs, setting up their smart pins doing serial I/O with this common clock and essentially allow something like QSPI to be emulated or something like that to work? We would still require some interleaving of the nibble data somewhere I suppose. Maybe the streaming would have to also allow for data merging/splitting somewhere..., or another COG allocated to do this operation in software if we have some appropriate instructions to achieve that result.
Now each smart pin is fed not just it's local and adjacent IN signals, but 8 relative pins: +3/+2/+1/0/-1/-2/-3/-4. The smart pin can select from these 8 IN's what its A and B inputs are.
This means you can gang smart pins up on one physical input pin to take multiple measurements, concurrently.
Cool, does this also mean that we could potentially share one common clock pin from the neighboring 8 pins between multiple I/O COGs, ...
It does sound like that is Chip's intent.
Don't call 'em Cogs though, it's a Smartpin, or, I noticed, Pion as a name being suggested in another topic.
Ideally if one COG could control multiple Smartpins (I don't yet understand the overall topology), with something like the shared clock approach mentioned above, perhaps we may be able to interleave/split data bits in software. It would be really nice to have QSPI possible in a single COG, but if four (or maybe five with the additional interleaving) are required I guess that could suffice in some applications. For receiving data from another SPI controller (ie. behaving as a peripheral), having the possibility of a shared and asynchronous external input clock sourced from a single input pin among the nearby group would be very handy indeed for QSPI.
About time-stamping in the smart pins... I think this would be better done in the streamer, since feeding a 32-bit counter to 64 pins, with all those mux's would be power-hungry and eat a lot of silicon. I think this is better done in the cog streamer.
I'm adding two switch-mode power supply modes, one with voltage feedback and another with current and voltage feedback. Since A and B inputs no longer have to be tied to the smart pin, the smart pin can control the FET gate while using two other pins to read voltage and current feedback. There are 8-bit level comparators in each pad which can read voltages through dividers and current through low-Z shunt resistors.
Does this sound like a good recipe for a SMPS mode:
1) output high for up to X clocks, cancel early if input B current feedback resistor is above level
2) output low for Y clocks
3) wait for input A to be low, then loop
Voltage-only mode doesn't cancel early from input B, but does the whole pulse.
All input and output polarities can be reversed, by the way.
Unless the smart pins get quad SPI modes, though, you'd spend more time splitting the data in software than just bit-banging it from scratch.
Can't you just MERGEB the data together or SPLITB it apart?
Yes, but it could take up to 17 clocks to read data from each of the smart pins. Unless the read can be accomplished at once from one pin, you're better off bit-banging it
About time-stamping in the smart pins... I think this would be better done in the streamer, since feeding a 32-bit counter to 64 pins, with all those mux's would be power-hungry and eat a lot of silicon. I think this is better done in the cog streamer.
Yes, that makes good sense for Logic Analyzer modes, where you want to have the highest dynamic range.
It still should be possible to capture two 32b values, in Frequency Counter mode, and one of those is Time.
However, in this mode, the streaming rate is far lower than Logic Analayzer - sub 1ms would be considered fast.
It sounds like 2 cells can be configured to do Frequency Counter mode, but may need an Armed-trigger type sub-mode ?
The detail here is that the ARM/trigger needs to capture both values on the same edge.
(ie one shared trigger will have less aperture issues than two triggers)
Does this sound like a good recipe for a SMPS mode:
1) output high for up to X clocks, cancel early if input B current feedback resistor is above level
2) output low for Y clocks
3) wait for input A to be low, then loop
Voltage-only mode doesn't cancel early from input B, but does the whole pulse.
Sounds good. Some SMPS modulate X, and some modulate Y (and some resonant ones, both)
3) is optional I assume ?
Now each smart pin is fed not just it's local and adjacent IN signals, but 8 relative pins: +3/+2/+1/0/-1/-2/-3/-4. The smart pin can select from these 8 IN's what its A and B inputs are.
This means you can gang smart pins up on one physical input pin to take multiple measurements, concurrently.
That sounds great and very flexible, (hopefully, at not too much Logic cost?) it also means you can have one config to manage, and MUX onto multiple pins, rather than having to config many pin cells, if the system design can tolerate simple MUX operation.
This can also allow nice self test modes, where you can 'reach-across' to an output pin for example, and capture the results for confirmation and loopback type tests
This can also be very useful for Debug and initial design.
Does this sound like a good recipe for a SMPS mode:
1) output high for up to X clocks, cancel early if input B current feedback resistor is above level
2) output low for Y clocks
3) wait for input A to be low, then loop
Voltage-only mode doesn't cancel early from input B, but does the whole pulse.
Sounds good. Some SMPS modulate X, and some modulate Y (and some resonant ones, both)
3) is optional I assume ?
#3 was for voltage regulation - wait for voltage to fall below some threshold before doing another pulse.
SMPS support would help me a lot...
I've got a lot of 3.5" LCDs that need +5,-5,+15 supplies that I currently use a $4 Maxim chip for.
This sounds like it would save money and reduce my part count...
Does this sound like a good recipe for a SMPS mode:
1) output high for up to X clocks, cancel early if input B current feedback resistor is above level
2) output low for Y clocks
3) wait for input A to be low, then loop
Voltage-only mode doesn't cancel early from input B, but does the whole pulse.
Sounds good. Some SMPS modulate X, and some modulate Y (and some resonant ones, both)
3) is optional I assume ?
#3 was for voltage regulation - wait for voltage to fall below some threshold before doing another pulse.
Do you mean that is an ADC + threshold step ?
That gives hysteretic control, which is used in some simple SMPS controllers, and gives simple wide dynamic range.
A down side is always some finite ripple and some lack of 'stiffness' in the control, but for many apps those are tolerable.
SMPS support would help me a lot...
I've got a lot of 3.5" LCDs that need +5,-5,+15 supplies that I currently use a $4 Maxim chip for.
This sounds like it would save money and reduce my part count...
Cypress have made Power Supply controllers, that to me have a very high price (for what they do, relative to a similar small MCU) , but it seems someone must be paying this ?
Given one COG can manage this wholly separate from the other 15, it seems a good way to leverage down the P2 system price.
Does this sound like a good recipe for a SMPS mode:
1) output high for up to X clocks, cancel early if input B current feedback resistor is above level
2) output low for Y clocks
3) wait for input A to be low, then loop
Voltage-only mode doesn't cancel early from input B, but does the whole pulse.
Sounds good. Some SMPS modulate X, and some modulate Y (and some resonant ones, both)
3) is optional I assume ?
#3 was for voltage regulation - wait for voltage to fall below some threshold before doing another pulse.
Do you mean that is an ADC + threshold step ?
That gives hysteretic control, which is used in some simple SMPS controllers, and gives simple wide dynamic range.
A down side is always some finite ripple and some lack of 'stiffness' in the control, but for many apps those are tolerable.
Each pin has a special high-impedance DAC that only drives a comparator, with the other side connected to a pin. So, you have 8-bit threshold control.
SMPS support would help me a lot...
I've got a lot of 3.5" LCDs that need +5,-5,+15 supplies that I currently use a $4 Maxim chip for.
This sounds like it would save money and reduce my part count...
Hello Rayman, what are the power requirements? voltage precision, current?
I just added a one-shot mode, where on rising OUT (OUTA/OUTB bit), a pulse of 16-bit variable size is output. If OUT rising edges occur faster than the pulse duration, the pulse remains "high", though you can select the polarity.
Do you guys think there is any value in a mode where pseudo-random noise is output to a DAC? You could do this in software, but the update rate would be much slower, not to mention it could tie up the cog. I'm looking for a mode to cut, in order to accommodate an SMPS mode.
Do you guys think there is any value in a mode where pseudo-random noise is output to a DAC? You could do this in software, but the update rate would be much slower, not to mention it could tie up the cog. I'm looking for a mode to cut, in order to accommodate an SMPS mode.
There are 16 COGS, and you can always stream to DACS, as in Video, right ?
That means video modes can cover a lot of cases, and the ones left can use a whole COG ?
I just added a one-shot mode, where on rising OUT (OUTA/OUTB bit), a pulse of 16-bit variable size is output. If OUT rising edges occur faster than the pulse duration, the pulse remains "high", though you can select the polarity.
Is there a One-shot capture mode ? - where SW arms the capture, and that HW waits for the next external edge, to do the allocated capture ? (Basically, a D-FF, that should be able to capture adjacent Cells too )
I just added a one-shot mode, where on rising OUT (OUTA/OUTB bit), a pulse of 16-bit variable size is output. If OUT rising edges occur faster than the pulse duration, the pulse remains "high", though you can select the polarity.
Is there a One-shot capture mode ? - where SW arms the capture, and that HW waits for the next external edge, to do the allocated capture ? (Basically, a D-FF, that should be able to capture adjacent Cells too )
Yes. That exists, already. You can capture states, highs, lows, or cycles. You can also capture A-rise to B-rise.
Comments
As well as the above simple time-stamp capture, there is another 'Armed-Capture' that is very useful in Frequency Counters.
That does a one-shot, same edge, capture of two 32b values : (ie sounds like 2 Pin cells used ?)
One 32b is time, and the other 32b is Cycles (so is actually a counter that increments on the capture clock, but the capture enables on a gate-based time delay, and captures once per arm-command.
That's exactly what it is.
Tom
Honestly, what they will need to understand is a P2 pin, can just be a pin, or it can be more fully utilized as a peripheral. From there, it will follow that the pin itself does stuff. And of course, "what stuff exactly....?"
Which our nice datasheet to come one day soon will explain all of that.
The nice thing about it, is one can say pin, and it works in the classic sense in every context. Change that to PIP, and now it's in the specific context of the P2, and all the other verbiage can remain the same. Easy.
Actually smartpin is kinda neat, as that also abbreviates to Spin, which obviously recognises it's own control language.
Well, I guess waiting is in order until the silicon arrives. Then we can really play the name game, based on the actually included features.
Can't wait!!
Or... Go get a $79 Terasic DE0-Nano and actually try out in a few more days.
If you want to try it ALL out (except all the analog, which needs real silicon), we have a Cyclone V -A9 board for $475 that has DACs and the capacity to emulate the whole digital design.
I had things set up so that input A was the pin local to the smart pin circuit and B was its odd/even complement pin (A/B = 0/1, 1/0, 2/3, 3/2, etc). That was kind of constraining.
Now each smart pin is fed not just it's local and adjacent IN signals, but 8 relative pins: +3/+2/+1/0/-1/-2/-3/-4. The smart pin can select from these 8 IN's what its A and B inputs are.
This means you can gang smart pins up on one physical input pin to take multiple measurements, concurrently.
Cool, does this also mean that we could potentially share one common clock pin from the neighboring 8 pins between multiple I/O COGs, setting up their smart pins doing serial I/O with this common clock and essentially allow something like QSPI to be emulated or something like that to work? We would still require some interleaving of the nibble data somewhere I suppose. Maybe the streaming would have to also allow for data merging/splitting somewhere..., or another COG allocated to do this operation in software if we have some appropriate instructions to achieve that result.
It does sound like that is Chip's intent.
Don't call 'em Cogs though, it's a Smartpin, or, I noticed, Pion as a name being suggested in another topic.
Unless the smart pins get quad SPI modes, though, you'd spend more time splitting the data in software than just bit-banging it from scratch.
I'm adding two switch-mode power supply modes, one with voltage feedback and another with current and voltage feedback. Since A and B inputs no longer have to be tied to the smart pin, the smart pin can control the FET gate while using two other pins to read voltage and current feedback. There are 8-bit level comparators in each pad which can read voltages through dividers and current through low-Z shunt resistors.
1) output high for up to X clocks, cancel early if input B current feedback resistor is above level
2) output low for Y clocks
3) wait for input A to be low, then loop
Voltage-only mode doesn't cancel early from input B, but does the whole pulse.
All input and output polarities can be reversed, by the way.
Can't you just MERGEB the data together or SPLITB it apart?
Yes, but it could take up to 17 clocks to read data from each of the smart pins. Unless the read can be accomplished at once from one pin, you're better off bit-banging it
It still should be possible to capture two 32b values, in Frequency Counter mode, and one of those is Time.
However, in this mode, the streaming rate is far lower than Logic Analayzer - sub 1ms would be considered fast.
It sounds like 2 cells can be configured to do Frequency Counter mode, but may need an Armed-trigger type sub-mode ?
The detail here is that the ARM/trigger needs to capture both values on the same edge.
(ie one shared trigger will have less aperture issues than two triggers)
3) is optional I assume ?
That sounds great and very flexible, (hopefully, at not too much Logic cost?) it also means you can have one config to manage, and MUX onto multiple pins, rather than having to config many pin cells, if the system design can tolerate simple MUX operation.
This can also allow nice self test modes, where you can 'reach-across' to an output pin for example, and capture the results for confirmation and loopback type tests
This can also be very useful for Debug and initial design.
#3 was for voltage regulation - wait for voltage to fall below some threshold before doing another pulse.
I've got a lot of 3.5" LCDs that need +5,-5,+15 supplies that I currently use a $4 Maxim chip for.
This sounds like it would save money and reduce my part count...
That gives hysteretic control, which is used in some simple SMPS controllers, and gives simple wide dynamic range.
A down side is always some finite ripple and some lack of 'stiffness' in the control, but for many apps those are tolerable.
Given one COG can manage this wholly separate from the other 15, it seems a good way to leverage down the P2 system price.
Each pin has a special high-impedance DAC that only drives a comparator, with the other side connected to a pin. So, you have 8-bit threshold control.
Hello Rayman, what are the power requirements? voltage precision, current?
http://www.rayslogic.com/Propeller/Products/PTP/LTV350QV.pdf
SMPS functions could also be useful for creating +5 V from Lipo powered systems, I think.
Do you guys think there is any value in a mode where pseudo-random noise is output to a DAC? You could do this in software, but the update rate would be much slower, not to mention it could tie up the cog. I'm looking for a mode to cut, in order to accommodate an SMPS mode.
That means video modes can cover a lot of cases, and the ones left can use a whole COG ?
Yes. That exists, already. You can capture states, highs, lows, or cycles. You can also capture A-rise to B-rise.