I've been thinking what hardware we might want to hook up and test. I think I2S should be relatively straightforward using the same strategy Chip just outlined.
There's uSD cards, obviously
This Linear tech ADC series might test things a bit as serial clock pushes up towards 90 MHz. Could be good for digitizing greyscale video http://www.linear.com/product/LTC2315-12
The TSL3301 line scan array too, though its much slower.
A good test framework for Capture, is a Reciprocal Frequency Counter.
This has 2 x 32 bit counters, that capture on the same edge.
One counter is Time (SysCLK/N clocked), and the other is Cycles (Fin clocked)
The Arm-capture is done at a relatively slow rate, 10ms to 1000ms, and when Armed, the next Fin edge triggers both Time & Cycles captures, once. (ie Capture is always whole cycles, rounds up in time to the next Fin edge)
This trigger element can be as simple as a D-FF with CLK and RS signals, or anything that HW triggers and SW clears.
I'm not sure is this will need 2 Pin cells, or 3, with the 3rd one providing D-FF emulation ? (hopefully 2)
This will give 0.5Hz to 40MHz type dynamic range, with no range-select needed & many of these can manage from one COG.
Where less dynamic range is tolerable, designs can capture Time after /M Fin Cycles, and /M is chosen to give a useful period read rate. eg 1MHz in may capture every 4096 edges, for a 4.096ms update rate.
At 80MHz this update is ~3ppm LSB
A variant of this captures Fin Cycles count, after a fixed time, but this has low precision at low frequencies, tho it does give Hz rather than Period result.
Timer Interval A-B :
Capture side is simple - Chosen Pin edge loads time.
This does need to be Arm-capture as a pair, so you know you have a single-span time from A to B & it should work down to very narrow 1 SysCLK wide pulses.
Some systems give the option to Clear-On-capture, others capture without clear, and the user subtracts previous value.
Okay. I just reread this. I think I get it.
We are measuring both the period and the number of periods over an interval. The first gives us low-frequency accuracy and the second gives us high-frequency accuracy.
This can certainly be done with two smart pins looking at the same physical pin. Or, it can be done by one smart pin which first takes one type of reading and then the other.
Yes. This is done also on PLC's counter cards. It is called "frequency measurement" (where a number of periods, of the input signal, are counted in a given time window) and "period measurement" (where a number of periods, of an internal reference frequency, are counted in a given window determined by the input signal period.
Yes, frequency measurement gives better accuracy over high frequencies while period measurement gives better accuracy on low frequencies.
But it will be nice if 3 smart pins can source from the same (couple of) pin(s) so that you can have the incremental counter(1) value from quadrature (incremental) encoder and its frequency(2)/period(3) measurements. 1 gives position while 2 and 3 gives speed.
I hope that the quadrature mode can count for both cases:
1) A=pulse B=direction (standard counting)
2) by evaluating A and B rising and falling edges (4 times increased resolution)
I've been thinking what hardware we might want to hook up and test. I think I2S should be relatively straightforward using the same strategy Chip just outlined.
Yes, I think I2S should be able to use Smart Pin's ability to 'link-nearby', and generate a CLK/16/24/32 as needed, for the LRCLOCK
(uses opposite edge to the data sample edge)
The streamer should provide the data.
Yes. This is done also on PLC's counter cards. It is called "frequency measurement" (where a number of periods, of the input signal, are counted in a given time window) and "period measurement" (where a number of periods, of an internal reference frequency, are counted in a given window determined by the input signal period.
Yes, frequency measurement gives better accuracy over high frequencies while period measurement gives better accuracy on low frequencies.
Reciprocal Counting measures (Whole Cycles > Gate Time)/(Time for those Cycles), and does the calculation. This means it has (essentially) the same precision no matter where in the range it is.
A common spec is so many Digits per Second (of nominal gate time), set by SysCLK.
The required Division (and SysCLK multiply) is why it is called Reciprocal Counting.
But it will be nice if 3 smart pins can source from the same (couple of) pin(s) so that you can have the incremental counter(1) value from quadrature (incremental) encoder and its frequency(2)/period(3) measurements. 1 gives position while 2 and 3 gives speed.
Good point, there is a near-adjacent mapping Chip has mentioned, but the Pin cells may set the upper total limit here.
Just 2 pins are needed per Quad, and one Cell can do Quad_Ctr, but Period and Cycles need a Pin Cell each, and maybe one more for the capture control.
Hopefully, it can be done in 3 Pin Cells, not 4, as that avoids consuming pins.
I'm not sure if a Side-linked Pin Cell means that Pin's IO is mapped to the Pin Cell not the pin, but I think so.
ie I think the IN and OUT are used by the Pin Cell as flag/control, so are Pin Cell or pin, not both, which means a side linked Pin Cells, consumes that Pin ? (not avail as IO at that time ?)
I hope that the quadrature mode can count for both cases:
1) A=pulse B=direction (standard counting)
2) by evaluating A and B rising and falling edges (4 times increased resolution)
2) has certainly been mentioned, 1) seems an easy subset ?
The quadrature mode can keep a running count, or report periodically over any 16-bit number of clocks, giving delta (speed), without losing any counts.
I got the final Prop123_A9 compile done for the current Prop2 with smart pins. Next, I need to do the DE2-115 and the two DE0-Nano versions. I still need to make some smart pin example programs for the .zip file and I want to come up with some better names for the smart pin instruction mnemonics. I hope to get this done tonight, before I go to bed.
.. and I want to come up with some better names for the smart pin instruction mnemonics.
It could be nice to have all pin-operating mnemonics using a common root.
The PIN you have now, seems to have good clarity ?
PIN support on P2 is rather different from Generic ARM parts, so being able to show-case all the pin-opcodes makes that difference easier for new users to follow.
Maybe. Smartpin commands are a specific mode of pin operation. When one is ignoring them, the existing mnemonics are reasonable. Differentiating that isn't a bad thing.
The quadrature mode can keep a running count, or report periodically over any 16-bit number of clocks, giving delta (speed), without losing any counts.
So if you wanted both Position control, and Speed, you could cross-configure two pin cells, both as Quadrature ? (uses 2 pins and 2 pin cells)
One CTR is set to update on-demand, and the other updates on-timebase, where some 16 bit timescale is chosen to give Delta(speed).
Read the first one for accurate Position, and the second one for Speed indication.
The quadrature mode can keep a running count, or report periodically over any 16-bit number of clocks, giving delta (speed), without losing any counts.
So if you wanted both Position control, and Speed, you could cross-configure two pin cells, both as Quadrature ? (uses 2 pins and 2 pin cells)
One CTR is set to update on-demand, and the other updates on-timebase, where some 16 bit timescale is chosen to give Delta(speed).
Read the first one for accurate Position, and the second one for Speed indication.
Or, have one short-period quadrature mode cause interrupts that grab the delta and add it into an accumulator. Then you get both speed and position.
I got the final Prop123_A9 compile done for the current Prop2 with smart pins. Next, I need to do the DE2-115 and the two DE0-Nano versions. I still need to make some smart pin example programs for the .zip file and I want to come up with some better names for the smart pin instruction mnemonics. I hope to get this done tonight, before I go to bed.
Exciting times ahead! Refresh....refresh....refresh...
Or, have one short-period quadrature mode cause interrupts that grab the delta and add it into an accumulator. Then you get both speed and position.
Yes, but that's a more Classic-MCU approach, and I was wanting to check what the Pins themselves are capable of, leaving interrupts for something else.
(or allowing 3,4,5 AXIS control in one COG )
Is it possible to 'cross-configure' two pin cells, both as Quadrature ? (uses 2 pins and 2 pin cells, one fast update, one slower delta)
Or, have one short-period quadrature mode cause interrupts that grab the delta and add it into an accumulator. Then you get both speed and position.
Yes, but that's a more Classic-MCU approach, and I was wanting to check what the Pins themselves are capable of, leaving interrupts for something else.
(or allowing 3,4,5 AXIS control in one COG )
Is it possible to 'cross-configure' two pin cells, both as Quadrature ? (uses 2 pins and 2 pin cells, one fast update, one slower delta)
Yes, you can do that.
Think of this, though: If you set up three encoders and six triangle PWMs, all with the same period, and start them on the same clock, you can use any one of them to trigger a single interrupt in which all three encoders can be read for speed and accumulated for position, and all six PWMs can be updated with next samples. Actually, it would be better to compute the PID loops and just wait for any of those pins' IN to go high, and then read and update everything. All with one cog in a simple loop.
It's getting late and I only have the Prop123-A9 board compiled, so far. I had some "combination loops" in the pin mux's and I had to make some changes and recompile. I also had to update the assembler and spin files. I still need to do the DE2-115 and the two DE0-Nano's. Also, I need to make some example programs, yet, for the smart pins.
At this point, it will be Monday when I get these files out. Sorry for all these delays, but I think you will find it worthwhile.
If software is part of the servo loop then the "classic" approach is all that's useful, although, in the case of the Prop, it probably wouldn't use interrupts per se. The only time anything more is useful is if the Prop hardware is expected to handle the servo function itself - which would be going overboard IMHO.
I wonder if 64 smart pins are going to make 16 cogs look like total overkill.
Yeah, I've been wondering that myself as a cog is meant to be the smarts itself and we just needed some extra pin functionality. As I have mentioned before I don't think of these as smart pins at all, I think of them as peripherals, one for each pin!
I wonder if 64 smart pins are going to make 16 cogs look like total overkill.
I like the idea that the P2 is now completely open to parallel processing... with plenty of room(cogs).
On the other hand, if you can improve throughput by cutting out 8 cogs... then that would trump parallelism in my mind. Adding another fifo sure seems desireable:)
It was looking like the available opcode space was getting down to nil. There are lots of general opcodes that could be added... and possibly some specialized ones:)
8 cores is so last decade. Even a Raspberry Pi has 4 now a days.
I want to be able to, for example, parallelize a big FFT over 8 COGS using OpenMP or whatever and still have 8 COGS left for other stuff and still have those high IQ pins.
What we need is the chip. Before I shuffle of this mortal coil.
I think what you meant to say is that reducing the cog count and adding another FIFO is a perfect FPGA exercise...and a good place to start the P3 design.
Comments
Great!! I'm looking forward to trying it out.
re:smart pin documentation
We will certainly appreciate that.
Will smartpins help SDRAM?
All assuming this round of smart pin functionality gets us to a good place.
Yes, the ROM needs completion.
Smart pins will be useful for generating the SDRAM clock, while the streamer will move the data, as the cog writes the address and control signals.
There's uSD cards, obviously
This Linear tech ADC series might test things a bit as serial clock pushes up towards 90 MHz. Could be good for digitizing greyscale video
http://www.linear.com/product/LTC2315-12
The TSL3301 line scan array too, though its much slower.
Yes. This is done also on PLC's counter cards. It is called "frequency measurement" (where a number of periods, of the input signal, are counted in a given time window) and "period measurement" (where a number of periods, of an internal reference frequency, are counted in a given window determined by the input signal period.
Yes, frequency measurement gives better accuracy over high frequencies while period measurement gives better accuracy on low frequencies.
But it will be nice if 3 smart pins can source from the same (couple of) pin(s) so that you can have the incremental counter(1) value from quadrature (incremental) encoder and its frequency(2)/period(3) measurements. 1 gives position while 2 and 3 gives speed.
I hope that the quadrature mode can count for both cases:
1) A=pulse B=direction (standard counting)
2) by evaluating A and B rising and falling edges (4 times increased resolution)
(uses opposite edge to the data sample edge)
The streamer should provide the data.
This means it has (essentially) the same precision no matter where in the range it is.
A common spec is so many Digits per Second (of nominal gate time), set by SysCLK.
The required Division (and SysCLK multiply) is why it is called Reciprocal Counting.
Good point, there is a near-adjacent mapping Chip has mentioned, but the Pin cells may set the upper total limit here.
Just 2 pins are needed per Quad, and one Cell can do Quad_Ctr, but Period and Cycles need a Pin Cell each, and maybe one more for the capture control.
Hopefully, it can be done in 3 Pin Cells, not 4, as that avoids consuming pins.
I'm not sure if a Side-linked Pin Cell means that Pin's IO is mapped to the Pin Cell not the pin, but I think so.
ie I think the IN and OUT are used by the Pin Cell as flag/control, so are Pin Cell or pin, not both, which means a side linked Pin Cells, consumes that Pin ? (not avail as IO at that time ?)
2) has certainly been mentioned, 1) seems an easy subset ?
It could be nice to have all pin-operating mnemonics using a common root.
The PIN you have now, seems to have good clarity ?
PIN support on P2 is rather different from Generic ARM parts, so being able to show-case all the pin-opcodes makes that difference easier for new users to follow.
So if you wanted both Position control, and Speed, you could cross-configure two pin cells, both as Quadrature ? (uses 2 pins and 2 pin cells)
One CTR is set to update on-demand, and the other updates on-timebase, where some 16 bit timescale is chosen to give Delta(speed).
Read the first one for accurate Position, and the second one for Speed indication.
Or, have one short-period quadrature mode cause interrupts that grab the delta and add it into an accumulator. Then you get both speed and position.
Yes, but that's a more Classic-MCU approach, and I was wanting to check what the Pins themselves are capable of, leaving interrupts for something else.
(or allowing 3,4,5 AXIS control in one COG )
Is it possible to 'cross-configure' two pin cells, both as Quadrature ? (uses 2 pins and 2 pin cells, one fast update, one slower delta)
Yes, you can do that.
Think of this, though: If you set up three encoders and six triangle PWMs, all with the same period, and start them on the same clock, you can use any one of them to trigger a single interrupt in which all three encoders can be read for speed and accumulated for position, and all six PWMs can be updated with next samples. Actually, it would be better to compute the PID loops and just wait for any of those pins' IN to go high, and then read and update everything. All with one cog in a simple loop.
At this point, it will be Monday when I get these files out. Sorry for all these delays, but I think you will find it worthwhile.
Yeah, I've been wondering that myself as a cog is meant to be the smarts itself and we just needed some extra pin functionality. As I have mentioned before I don't think of these as smart pins at all, I think of them as peripherals, one for each pin!
I like the idea that the P2 is now completely open to parallel processing... with plenty of room(cogs).
On the other hand, if you can improve throughput by cutting out 8 cogs... then that would trump parallelism in my mind. Adding another fifo sure seems desireable:)
It was looking like the available opcode space was getting down to nil. There are lots of general opcodes that could be added... and possibly some specialized ones:)
Of course I could be completely wrong... this is how I understand it today:)
8 cores is so last decade. Even a Raspberry Pi has 4 now a days.
I want to be able to, for example, parallelize a big FFT over 8 COGS using OpenMP or whatever and still have 8 COGS left for other stuff and still have those high IQ pins.
I want all my cakes and eat them
I think what you meant to say is that reducing the cog count and adding another FIFO is a perfect FPGA exercise...and a good place to start the P3 design.
I couldn't agree more:)