JMG, every time you suggest including a specify protocol it reads like you are wanting the full licensed hardware for it. I presume that's not your intent but it does come across that way.
JMG, every time you suggest including a specify protocol it reads like you are wanting the full licensed hardware for it. I presume that's not your intent but it does come across that way.
Stick to the enabling abilities please.
I'm lost here ? - i2s is a widely used serial protocol, only slightly less common than SPI or i2c in the general marketplace.
i2s is what is needed to talk to the cheap Audio Codecs.
In hardware, it is a slight variant of SPI.
I²S, also known as Inter-IC Sound, Integrated Interchip Sound, or IIS, is an electrical serial bus interface standard used for connecting digital audio devices together. It is used to communicate PCM audio data between integrated circuits in an electronic device. The I²S bus separates clock and serial data signals, resulting in a lower jitter than is typical of communications systems that recover the clock from the data stream. Despite the name, it is unrelated to the bidirectional I²C bus.
he I²S protocol outlines one specific type of PCM digital audio communication with defined parameters outlined in the Philips specification.
The bit clock pulses once for each discrete bit of data on the data lines. The bit clock frequency is the product of the sample rate, the number of bits per channel and the number of channels. So, for example, CD Audio with a sample frequency of 44.1 kHz, with 16 bits of precision and two channels (stereo) has a bit clock frequency of:
Are you seriously saying you are asking for specific/dedicated controllers? You do know you've agreed a number of times when being questioned on making things generic, right?
... The I²S bus separates clock and serial data signals, resulting in a lower jitter than is typical of communications systems that recover the clock from the data stream.
Good old Wikipedia, eh. Some people can't help themselves inserting bogus marketroid talk into the articles like that.
Are you seriously saying you are asking for specific/dedicated controllers? You do know you've agreed a number of times when being questioned on making things generic, right?
My confusion continues, what are you trying to say ? Where did I mention a specific/dedicated controller ??
i2s support is scarcely 'a specific/dedicated controller' ?
Hint: i2s is basically SPI with a frame signal of Clk/16,/24 or /32
Given it is a 3 pin interface, this should be quite doable in 3 smart pins. It just needs checking the details, to make sure nothing simple is overlooked.
I just tested the triangle PWM mode. I compiled for 16 smart pins, so that I could try a bunch at once.
.... a pin alerts you that it just grabbed the buffered sample by raising its IN signal
Nice plots, and the handshake is cool.
Is there a current trip/regulate feature (usually abort that cycle's output on Pin signal) ?
I see mention in sawtooth PWM, so guess that is also in triangle too ?
Only the SMPS sawtooth PWM modes have these 'inhibit' features. I don't see how it would work with triangle PWM, as the point is symmetry around the event point.
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.
You've brought this up several times, but I still haven't gotten into my head WHY this is important. I assume it allows accurate frequency measurements to be made in less time than 1/Hz-resolution. Is that its purpose?
I like the look of the dithered output.
Should be good for audio, right?
Maybe COG can also interpolate between values to reduce step noise...
Isn't that what the dithering is doing ?
The 8b DAC is going to set some limits on Audio Quality, as the LSBs are not going to be all the same size.
That means dithering can be good for feedback and interpolate cases, but SINAD is going to be set by the 8b DAC.
Yep. And it's hard to say how 'off' those LSB steps may be from one another. At least, by virtue of the DAC topology, it will be monotonic at 8 bits and using PWM on the LSB to get to 16 bits. Dither may not fare well past 12 effective bits, but we'll see. It seems to me that as long has you have monotonicity, though, you can have very stable closed-loop feedback systems, as up is always up and down is always down.
That is likely to need a 16 bit DAC. This new feature should perform better than 8 bits will.
8 bits is somewhat close to 50db s/n. Just blasting 16 bit samples should deliver better noise floor. I'll bet audible distortion is similar.
Can't wait to try it out!
To get a good result, you'll need to use real DACs, like on the Prop123 board. They R-2R ladders on the little add-on boards we made for the DE0-Nano and DE2-115 are not always monotonic, so they will not perform well. I, too, am interested in 'hearing' how this works.
Will the streamer be able to take advantage of the fact that smartpins can now output 16 bit dithered analog, or will they still only be able to do 8 bits?
Maybe, instead of modifying the streamer to have 16 bit modes, the smartpins could be made to get the bottom 8 bits from their B-pin, but that sounds like it would be a lot of muxes. Then, the streamer could be told to output the top 8 bits to one pin and the bottom 8 to another, using one of the modes that already exists, and then a smartpin could put two 8 bit values together.
EDIT: Or could you modify the streamer to be able to feed its output to pinsety or pinsetx?
I don't know if there's any point in having the streamer dither, since dither takes time (256 clocks for another ~8 bits of resolution) and that takes the data-delivery requirement way down, so that you could update a few smart pins on an interrupt and take advantage of their internal double buffering to get the streamer-like timing accuracy.
That is likely to need a 16 bit DAC. This new feature should perform better than 8 bits will.
The i2s DACs are quite cheap, under 50c, and they give 24b Audio.
Hopefully, the Smart Pins will eventually be able to talk i2s (mono or stereo) in 16/24/32 formats.
Yes, I just found one from Digi-Key for 45 cents at 3k units:
I looked over the data sheet, but didn't take the time to understand the serial protocol. Nothing popped out as being obvious to me. It will need some focus a little later.
My confusion continues, what are you trying to say ? Where did I mention a specific/dedicated controller ??
It's quite hard to get anything clear from you. I asked for clarification but you just when on about how useful it is with no clarification to my first question.
Hint: i2s is basically SPI with a frame signal of Clk/16,/24 or /32
The Prop2 has no SPI controller either. Like you say, it will require more than one SmartPin to achieve and still a Cog to manipulate/pipe the data and bit bash chip selects and what not.
I looked over the data sheet, but didn't take the time to understand the serial protocol. Nothing popped out as being obvious to me. It will need some focus a little later.
From a Data stream viewpoint, this may be easier via the streamer - I think that has a 1 bit mode ?
That gives more software elasticity.
In this setup, the CLK out would feed an adjacent pin cell, that has a simple preloaded /16 /24 or/32 for the framing signal.
The /N would be preset first, and the SYNC clock starts when the Data passes out the streamer, keeping the frame in phase.
I think all the HW pieces are there already for that ?
I looked over the data sheet, but didn't take the time to understand the serial protocol. Nothing popped out as being obvious to me. It will need some focus a little later.
From a Data stream viewpoint, this may be easier via the streamer - I think that has a 1 bit mode ?
That gives more software elasticity.
In this setup, the CLK out would feed an adjacent pin cell, that has a simple preloaded /16 /24 or/32 for the framing signal.
The /N would be preset first, and the SYNC clock starts when the Data passes out the streamer, keeping the frame in phase.
I think all the HW pieces are there already for that ?
I think we've got it all, so far, except for variable bit length.
You've brought this up several times, but I still haven't gotten into my head WHY this is important. I assume it allows accurate frequency measurements to be made in less time than 1/Hz-resolution. Is that its purpose?
The appeal is the wide dynamic range, which means you can create one library and use it anywhere in the spectrum, up to the limits of the silicon.
There is no need to do a ranging step.
Bean did one of these in a P1, with some caveats. (the dual capture on one edge is not quite nailed down)
You can also preload some cycles to capture over, (as in the later examples) but that requires you know the Fin, or do a calibrate/range pass first.
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.
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.
Correct. Accuracy is some number of digits per second, and independent of frequency.
This can certainly be done with two smart pins looking at the same physical pin.
Yes, provided they can see the same edge, which means a shared FF, not two FF. ( Two FF has an aperture error)
If all pins have a Clock Domain sampling FF, before they are MUX'd that may be enough - you then need a means to enable/disable Capture simultaneously on 2 pins.
Not sure how that is supported ? If Capture Enable maps to OUT, you can set two of those (in the same block) on the same clock edge.
Or, it can be done by one smart pin which first takes one type of reading and then the other.
That's a little less certain, as you need to know the same number of cycles are covered in each case,
In one pass, you get Cycles, but in the next you hope/presume the same number of Fin cycles will occur while you capture time.
I think 2 Pin cells is a Minimum, but less clear is if a 3rd pin cell needs to be used for the trigger Arm/Capt one-shot ?
Only the SMPS sawtooth PWM modes have these 'inhibit' features. I don't see how it would work with triangle PWM, as the point is symmetry around the event point.
Sometimes triangle is used to give dead-bands, and in this case usually one of the pins is inverted in a MOSFET Drive sense. (both drive MOSFETS)
As the outputs are driving MOSFET power stages, it can still make sense to have a TRIP reset on the drive, on excess current, but the polarity inversion makes the details trickier.
TRIP -> Gate Low, but that is PWM=H on one and PWM=L on the other.
Yes, provided they can see the same edge, which means a shared FF, not two FF. ( Two FF has an aperture error)
I'm pretty confident that doesn't matter. The two measurements run independently, and asynchronously to the signal, and give a separate result each. The two results are both as accurate as can be achieved respectively. One is more precise than the other depending on the pulse rate vs sample period.
Sometimes triangle is used to give dead-bands, ...
From memory, the earlier discussions for adding the triangle was primarily to bring deadbanding into the mix, ie: That is the job it does naturally. I could be wrong.
Sometimes triangle is used to give dead-bands, ...
From memory, the earlier discussions for adding the triangle was primarily to bring deadbanding into the mix, ie: That is the job it does naturally. I could be wrong.
That's my understanding, too. I think jmg was thinking about some intra-cycle abort mechanism. It seems to me that the triangle PWM, as it stands, is all we need.
I've got over half the testing done now. It's tedious. I'm going to get some sleep because I'm not being productive, anymore. Sorry this is taking so long.
Comments
On the topic of i2s, I see Analog Devices has a new A2B bus, which is a UTP 50MHz bus 10m cable lengths, designed for Power and Data(Audio) in cars
http://www.analog.com/en/products/audio-video/automotive-audio-bus/ad2410w.html#product-overview
They have transceivers for i2s to A2B, and that has to be of interest for Industrial Control too.
Another reason to ensure the Smart Pin Serial Block is i2s capable ?
Stick to the enabling abilities please.
I'm lost here ? - i2s is a widely used serial protocol, only slightly less common than SPI or i2c in the general marketplace.
i2s is what is needed to talk to the cheap Audio Codecs.
In hardware, it is a slight variant of SPI.
he I²S protocol outlines one specific type of PCM digital audio communication with defined parameters outlined in the Philips specification.
The bit clock pulses once for each discrete bit of data on the data lines. The bit clock frequency is the product of the sample rate, the number of bits per channel and the number of channels. So, for example, CD Audio with a sample frequency of 44.1 kHz, with 16 bits of precision and two channels (stereo) has a bit clock frequency of:
44.1 kHz × 16 × 2 = 1.4112 MHz
https://en.wikipedia.org/wiki/I²S
Good old Wikipedia, eh. Some people can't help themselves inserting bogus marketroid talk into the articles like that.
i2s support is scarcely 'a specific/dedicated controller' ?
You do understand what i2s involves ?
Try this :
http://www.akm.com/akm/en/file/datasheet/AK4388AET.pdf
Hint: i2s is basically SPI with a frame signal of Clk/16,/24 or /32
Given it is a 3 pin interface, this should be quite doable in 3 smart pins. It just needs checking the details, to make sure nothing simple is overlooked.
No specific/dedicated controller in sight.
Excuse me while I LMAO. Seriously.
I'm quite sure there are good reasons for it, but the return on all of that is modest at best for most use cases.
That was ten years ago, already!
I'm thankful that electrons still act in the same ways.
I love working with first principles and not being cut off from them by impenetrable black boxes.
Only the SMPS sawtooth PWM modes have these 'inhibit' features. I don't see how it would work with triangle PWM, as the point is symmetry around the event point.
Yes, the pin itself can control polarity in and out and the smart pins allow polarity flipping on the A and B inputs.
You've brought this up several times, but I still haven't gotten into my head WHY this is important. I assume it allows accurate frequency measurements to be made in less time than 1/Hz-resolution. Is that its purpose?
That's what the smart pin must do on every clock. The cog only needs to supply the goal. The smart pin will help realize it.
Yep. And it's hard to say how 'off' those LSB steps may be from one another. At least, by virtue of the DAC topology, it will be monotonic at 8 bits and using PWM on the LSB to get to 16 bits. Dither may not fare well past 12 effective bits, but we'll see. It seems to me that as long has you have monotonicity, though, you can have very stable closed-loop feedback systems, as up is always up and down is always down.
To get a good result, you'll need to use real DACs, like on the Prop123 board. They R-2R ladders on the little add-on boards we made for the DE0-Nano and DE2-115 are not always monotonic, so they will not perform well. I, too, am interested in 'hearing' how this works.
I don't know if there's any point in having the streamer dither, since dither takes time (256 clocks for another ~8 bits of resolution) and that takes the data-delivery requirement way down, so that you could update a few smart pins on an interrupt and take advantage of their internal double buffering to get the streamer-like timing accuracy.
Yes, I just found one from Digi-Key for 45 cents at 3k units:
http://www.digikey.com/product-detail/en/AK4388AET/974-1011-2-ND/2333360
I looked over the data sheet, but didn't take the time to understand the serial protocol. Nothing popped out as being obvious to me. It will need some focus a little later.
The Prop2 has no SPI controller either. Like you say, it will require more than one SmartPin to achieve and still a Cog to manipulate/pipe the data and bit bash chip selects and what not.
So, stick to the enabling abilities please.
That gives more software elasticity.
In this setup, the CLK out would feed an adjacent pin cell, that has a simple preloaded /16 /24 or/32 for the framing signal.
The /N would be preset first, and the SYNC clock starts when the Data passes out the streamer, keeping the frame in phase.
I think all the HW pieces are there already for that ?
I think we've got it all, so far, except for variable bit length.
There is no need to do a ranging step.
Bean did one of these in a P1, with some caveats. (the dual capture on one edge is not quite nailed down)
You can also preload some cycles to capture over, (as in the later examples) but that requires you know the Fin, or do a calibrate/range pass first.
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, provided they can see the same edge, which means a shared FF, not two FF. ( Two FF has an aperture error)
If all pins have a Clock Domain sampling FF, before they are MUX'd that may be enough - you then need a means to enable/disable Capture simultaneously on 2 pins.
Not sure how that is supported ? If Capture Enable maps to OUT, you can set two of those (in the same block) on the same clock edge.
That's a little less certain, as you need to know the same number of cycles are covered in each case,
In one pass, you get Cycles, but in the next you hope/presume the same number of Fin cycles will occur while you capture time.
I think 2 Pin cells is a Minimum, but less clear is if a 3rd pin cell needs to be used for the trigger Arm/Capt one-shot ?
Sometimes triangle is used to give dead-bands, and in this case usually one of the pins is inverted in a MOSFET Drive sense. (both drive MOSFETS)
As the outputs are driving MOSFET power stages, it can still make sense to have a TRIP reset on the drive, on excess current, but the polarity inversion makes the details trickier.
TRIP -> Gate Low, but that is PWM=H on one and PWM=L on the other.
I'm pretty confident that doesn't matter. The two measurements run independently, and asynchronously to the signal, and give a separate result each. The two results are both as accurate as can be achieved respectively. One is more precise than the other depending on the pulse rate vs sample period.
From memory, the earlier discussions for adding the triangle was primarily to bring deadbanding into the mix, ie: That is the job it does naturally. I could be wrong.
That's my understanding, too. I think jmg was thinking about some intra-cycle abort mechanism. It seems to me that the triangle PWM, as it stands, is all we need.