I guess for a delay generator, you'd want to set a say 16-bit value to some # of clocks
so that when A went high, b would go high that many clocks later...
If there was a C, maybe you'd want the option that C=A or B or C= A and B, etc.
Maybe that's already there, I don't know...
Anyone second this automatic delay function? I never thought about something like this.
This is sort of what we do when bit-banging I2C and SPI.
On Rayman's question. My "guess" is that many cameras' output could be directly displayed if the clock differences became a parameter.
If this is true, then I think that might be a good argument. The problem I have is that with all of the other untapped capabilities of the P2, this might already be possible in other ways.
All combinations of A rise/fall, B hi/lo and B rise/fall, A hi/lo * would be helpful, just like a "stateful" scope trigger. This would accommodate quadrature decoding (which I know is already covered elsewhere), as well as Start/Stop detection for I2C.
* or, equivalently, all combinations of A, A(prev), B, and B(prev) , with an additional command long telling what to do (increment, decrement, nothing, error) for each.
Will the smart pin max pulse count rate be limited to ~(sysclk/2) like the P1?
On P1 we can generate a nice range of frequencies at a pin but with a 80MHz clock we can
only measure frequencies up to ~37MHz before we hit the wall.
It would be nice if P2 could internally measure/verify frequencies it has generated.
There is always a SysCLK sampling limit, but some MCUs have local prescalers before the SysCLK limit.
These can be small - I've tested the CLU logic blocks in a EFM8 device up to 200MHz, and they also have a ExtPin/8, that can clock above SysCLK (because the sampled final f is ExtPin/8)
- A small Async (preSync?) prescaler could cost 3 FF per in-cell, plus some MUX/select logic.
It might be useful to also have the ability to detect rising/falling edge cases between A and previous A (like XOR but also the current state gets used too). I am wondering if that could possibly be handy for (differential) Manchester and or Biphase Mark Inversion type line decoding schemes, and/or doing clock recovery perhaps.
Manchester encoding is used for 10Base-T Ethernet, and BMI for S/PDIF digital audio, though maybe the bitrates there are low enough to do things in software.
Anyone second this automatic delay function? I never thought about something like this.
I noticed in your earlier description of the current 'triangle wave' pwm that you didn't specifically mention deadtime. Perhaps this could be a cheap way to implement deadtime for driving an I or H bridge.
Little things like this, if they don't overcomplicate things, can be big BOM savers later on.
It might be useful to also have the ability to detect rising/falling edge cases between A and previous A (like XOR but also the current state gets used too). I am wondering if that could possibly be handy for (differential) Manchester and or Biphase Mark Inversion type line decoding schemes, and/or doing clock recovery perhaps.
Manchester encoding is used for 10Base-T Ethernet, and BMI for S/PDIF digital audio, though maybe the bitrates there are low enough to do things in software.
Bi-Phase (leading edge coded) can be decoded with an any-edge Monostable and a D-FF.
Manchester (mid edge coded) needs two Monostables (one is a hold-off) and a D-FF.
(this is not PLL based decode, just edge triggered)
All combinations of A rise/fall, B hi/lo and B rise/fall, A hi/lo * would be helpful, just like a "stateful" scope trigger. This would accommodate quadrature decoding (which I know is already covered elsewhere), as well as Start/Stop detection for I2C.
* or, equivalently, all combinations of A, A(prev), B, and B(prev) , with an additional command long telling what to do (increment, decrement, nothing, error) for each.
-Phil
I have something like that now, where for each counter mode, there's a fixed pattern of 16 two-bit values which are used as +0/+1/-1. There are sixteen to accommodate all cases of A, A(prev), B, B (prev). The %10 case is unused, but could be an event trigger.
I've thought about making this 16x2-bit pattern user-settable, but it would require another 32 bits of flops (out of a current ~200) per smart pin. My thinking has been to keep such details away from the user, so he's not burdened with thinking about these patterns. It seems easier to just have modes for A-B encoders, counters, frequency measuring, etc. Otherwise, they'd have to load some cryptic long into the smart pin to get it to do something. I'm not against that, personally, but I don't want to overburden people with details. We could have labels for these values (ie 'pin_encoder' = %00_01_11_00__11_00_00_01__01_00_00_11__00_11_01_00).
Anyone second this automatic delay function? I never thought about something like this.
I noticed in your earlier description of the current 'triangle wave' pwm that you didn't specifically mention deadtime. Perhaps this could be a cheap way to implement deadtime for driving an I or H bridge.
Little things like this, if they don't overcomplicate things, can be big BOM savers later on.
Ha! I think the one-shot with an inverted output would do the same thing. So, it's already there.
Great!
By running two pins as triangle PWMs with the same prescaler and framesize, and started on the same clock, you'd get deadtime when neither pin was "high". There are polarity matters in something like this, which are selectable.
The thing I worry about with SMPS modes is that timing will be controlled by an external crystal in almost all applications. If that crystal stops, even temporarily, there's a chance that a pin driving a FET gate will stall, causing too much current to flow. This could be catastrophic. When you buy a dedicated SMPS chip, this is not a possibility, since its timing control is internal. I think the remedy for this problem is to couple the microcontroller pin to the FET gate through a capacitor with a resistor to bleed it towards the 'off' voltage. A low-drop, fast diode could be used to clamp the gate side of the capacitor to the 'off' rail, so that the pin is able to drive a good 'on' voltage, just not forever. That would add a resistor, cap, and diode to the bill of materials, but would make things safe.
The thing I worry about with SMPS modes is that timing will be controlled by an external crystal in almost all applications. If that crystal stops, even temporarily, there's a chance that a pin driving a FET gate will stall, causing too much current to flow. This could be catastrophic.
Yep. That is the moment you find out what "real-time programming" means.
The %10 case is unused, but could be an event trigger.
That's kinda what I had in mind. That way things like illegal quadrature transitions could be caught.
We could have labels for these values (ie 'pin_encoder' = %00_01_11_00__11_00_00_01__01_00_00_11__00_11_01_00).
Absolutely, yes. Keep the flexibility in the hardware, and hide any resulting complexity from novice users by giving them predefined constants. That way, advanced users can still define weird counting modes as their needs dictate. I think the lesson from the P1 is that the counters were used in unanticipated ways. I'm sure the same will be true of the P2 -- only more so.
The %10 case is unused, but could be an event trigger.
That's kinda what I had in mind. That way things like illegal quadrature transitions could be caught.
We could have labels for these values (ie 'pin_encoder' = %00_01_11_00__11_00_00_01__01_00_00_11__00_11_01_00).
Absolutely, yes. Keep the flexibility in the hardware, and hide any resulting complexity from novice users by giving them predefined constants. That way, advanced users can still define weird counting modes as their needs dictate. I think the lesson from the P1 is that the counters were used in unanticipated ways. I'm sure the same will be true of the P2 -- only more so.
-Phil
I've been looking into this. I'm trying to get my head around what kinds of actions need to result from 16 possible states, and if there maybe needs to be more than one pattern.
It seems that any limited, flexible solution is only good for a few very narrow cases. To make a smart pin that does lots of different things, you need specific logic for each function. This is going to need a lot more thinking. For now, I will finish what I've been working on and get an update out.
xtal failure sounds like a remote possibility to me.
Maybe with the removable xtals or bad routing it can happen, but I think it would be extremely rare event with a soldered xtal.
xtal failure sounds like a remote possibility to me.
Maybe with the removable xtals or bad routing it can happen, but I think it would be extremely rare event with a soldered xtal.
Handling live boards with your fingers can cause trouble if you happen to contact a crystal node on the PCB and bridge it to something else. I've noticed this a few times.
I have seen that too with board where the xtal traces have vias.
What I do now is keep all xtal traces on the top layer with no vias.
Also, keep xtal close to uC chip.
Then, you really have to work to make it go haywire.
Still, it is possible.
Also, I happen to know that running your finger under the P123 board SMPS can make it go haywire too.
So maybe, in general, running your fingers over SMPS components is a bad idea...
I have seen that too with board where the xtal traces have vias.
What I do now is keep all xtal traces on the top layer with no vias.
Also, keep xtal close to uC chip.
Then, you really have to work to make it go haywire.
Still, it is possible.
Also, I happen to know that running your finger under the P123 board SMPS can make it go haywire too.
So maybe, in general, running your fingers over SMPS components is a bad idea...
Good idea about no vias and short wires.
These SMPS circuits make me kind of nervous. Our original SX-Key (for the SX chips) had a direct-drive switcher for generating the programming voltage. A few of those things smoked. Inserting a series cap and resistor between the I/O pin and the base solved the problem.
Using a current-limited supply when developing a switcher circuit is great, and then make sure the transistor can't get left 'on' in the final circuit via some DC isolation. Then, things are pretty safe. There's the other possibility, though, of the voltage feedback being interfered with, causing over-voltage.
All combinations of A rise/fall, B hi/lo and B rise/fall, A hi/lo * would be helpful, just like a "stateful" scope trigger. This would accommodate quadrature decoding (which I know is already covered elsewhere), as well as Start/Stop detection for I2C.
* or, equivalently, all combinations of A, A(prev), B, and B(prev) , with an additional command long telling what to do (increment, decrement, nothing, error) for each.
-Phil
I have something like that now, where for each counter mode, there's a fixed pattern of 16 two-bit values which are used as +0/+1/-1. There are sixteen to accommodate all cases of A, A(prev), B, B (prev). The %10 case is unused, but could be an event trigger.
I've thought about making this 16x2-bit pattern user-settable, but it would require another 32 bits of flops (out of a current ~200) per smart pin. My thinking has been to keep such details away from the user, so he's not burdened with thinking about these patterns. It seems easier to just have modes for A-B encoders, counters, frequency measuring, etc. Otherwise, they'd have to load some cryptic long into the smart pin to get it to do something. I'm not against that, personally, but I don't want to overburden people with details. We could have labels for these values (ie 'pin_encoder' = %00_01_11_00__11_00_00_01__01_00_00_11__00_11_01_00).
What do you guys think?
This comes down to coverage.
Do you have a table of the modes supported by your current code ?
- ie what is missing, from the simpler choices ?
FlipFlops are not of as high as cost in ASIC, as they are in FPGAs, and they replace mini-roms.
Having pre-defines as words for modes, is not hard to document, so users rarely need to know the 10101's
All combinations of A rise/fall, B hi/lo and B rise/fall, A hi/lo * would be helpful, just like a "stateful" scope trigger. This would accommodate quadrature decoding (which I know is already covered elsewhere), as well as Start/Stop detection for I2C.
* or, equivalently, all combinations of A, A(prev), B, and B(prev) , with an additional command long telling what to do (increment, decrement, nothing, error) for each.
-Phil
I have something like that now, where for each counter mode, there's a fixed pattern of 16 two-bit values which are used as +0/+1/-1. There are sixteen to accommodate all cases of A, A(prev), B, B (prev). The %10 case is unused, but could be an event trigger.
I've thought about making this 16x2-bit pattern user-settable, but it would require another 32 bits of flops (out of a current ~200) per smart pin. My thinking has been to keep such details away from the user, so he's not burdened with thinking about these patterns. It seems easier to just have modes for A-B encoders, counters, frequency measuring, etc. Otherwise, they'd have to load some cryptic long into the smart pin to get it to do something. I'm not against that, personally, but I don't want to overburden people with details. We could have labels for these values (ie 'pin_encoder' = %00_01_11_00__11_00_00_01__01_00_00_11__00_11_01_00).
What do you guys think?
This comes down to coverage.
Do you have a table of the modes supported by your current code ?
- ie what is missing, from the simpler choices ?
FlipFlops are not of as high as cost in ASIC, as they are in FPGAs, and they replace mini-roms.
Having pre-defines as words for modes, is not hard to document, so users rarely need to know the 10101's
I got the smart pin pretty much done, but I've decided to combine the measurement and timer logic blocks. I am adding some modes where you can inc/dec/clear on any combination of A, A(prev), B, B(prev) and selectively report results back or just alert via the IN bit.
The A and B inputs to smart pins can now be the local pin, any of three pins above or below, or the OUT signal to either the local or adjacent pin. This will allow a smart pin to use another smart pin's output as one of its inputs, or allow you to control it via the OUT bit. Just working out the details now.
All combinations of A rise/fall, B hi/lo and B rise/fall, A hi/lo * would be helpful, just like a "stateful" scope trigger. This would accommodate quadrature decoding (which I know is already covered elsewhere), as well as Start/Stop detection for I2C.
* or, equivalently, all combinations of A, A(prev), B, and B(prev) , with an additional command long telling what to do (increment, decrement, nothing, error) for each.
-Phil
I have something like that now, where for each counter mode, there's a fixed pattern of 16 two-bit values which are used as +0/+1/-1. There are sixteen to accommodate all cases of A, A(prev), B, B (prev). The %10 case is unused, but could be an event trigger.
I've thought about making this 16x2-bit pattern user-settable, but it would require another 32 bits of flops (out of a current ~200) per smart pin. My thinking has been to keep such details away from the user, so he's not burdened with thinking about these patterns. It seems easier to just have modes for A-B encoders, counters, frequency measuring, etc. Otherwise, they'd have to load some cryptic long into the smart pin to get it to do something. I'm not against that, personally, but I don't want to overburden people with details. We could have labels for these values (ie 'pin_encoder' = %00_01_11_00__11_00_00_01__01_00_00_11__00_11_01_00).
What do you guys think?
This comes down to coverage.
Do you have a table of the modes supported by your current code ?
- ie what is missing, from the simpler choices ?
FlipFlops are not of as high as cost in ASIC, as they are in FPGAs, and they replace mini-roms.
Having pre-defines as words for modes, is not hard to document, so users rarely need to know the 10101's
I got the smart pin pretty much done, but I've decided to combine the measurement and timer logic blocks. I am adding some modes where you can inc/dec/clear on any combination of A, A(prev), B, B(prev) and selectively report results back or just alert via the IN bit.
The A and B inputs to smart pins can now be the local pin, any of three pins above or below, or the OUT signal to either the local or adjacent pin. This will allow a smart pin to use another smart pin's output as one of its inputs, or allow you to control it via the OUT bit. Just working out the details now.
These things are just getting smarter and smarter! I'm afraid that they're getting too smart for me to understand!
All combinations of A rise/fall, B hi/lo and B rise/fall, A hi/lo * would be helpful, just like a "stateful" scope trigger. This would accommodate quadrature decoding (which I know is already covered elsewhere), as well as Start/Stop detection for I2C.
* or, equivalently, all combinations of A, A(prev), B, and B(prev) , with an additional command long telling what to do (increment, decrement, nothing, error) for each.
-Phil
I have something like that now, where for each counter mode, there's a fixed pattern of 16 two-bit values which are used as +0/+1/-1. There are sixteen to accommodate all cases of A, A(prev), B, B (prev). The %10 case is unused, but could be an event trigger.
I've thought about making this 16x2-bit pattern user-settable, but it would require another 32 bits of flops (out of a current ~200) per smart pin. My thinking has been to keep such details away from the user, so he's not burdened with thinking about these patterns. It seems easier to just have modes for A-B encoders, counters, frequency measuring, etc. Otherwise, they'd have to load some cryptic long into the smart pin to get it to do something. I'm not against that, personally, but I don't want to overburden people with details. We could have labels for these values (ie 'pin_encoder' = %00_01_11_00__11_00_00_01__01_00_00_11__00_11_01_00).
What do you guys think?
This comes down to coverage.
Do you have a table of the modes supported by your current code ?
- ie what is missing, from the simpler choices ?
FlipFlops are not of as high as cost in ASIC, as they are in FPGAs, and they replace mini-roms.
Having pre-defines as words for modes, is not hard to document, so users rarely need to know the 10101's
I got the smart pin pretty much done, but I've decided to combine the measurement and timer logic blocks. I am adding some modes where you can inc/dec/clear on any combination of A, A(prev), B, B(prev) and selectively report results back or just alert via the IN bit.
The A and B inputs to smart pins can now be the local pin, any of three pins above or below, or the OUT signal to either the local or adjacent pin. This will allow a smart pin to use another smart pin's output as one of its inputs, or allow you to control it via the OUT bit. Just working out the details now.
These things are just getting smarter and smarter! I'm afraid that they're getting too smart for me to understand!
It's nothing that a little diagram won't clear up.
I was thinking, after I worked all night, that inspiration is akin to a true random number generator, where you must wait for some phenomenon to generate the number. You can't just get it on demand. Most of the night, I just kind of sat there waiting for things to congeal in my head, not knowing when, or if, it would come. Finally, almost on its own, the mental picture emerged and it was quite clear. I had been trying to think about this for a week, to no avail.
We"ve got a framework now that can do all kinds of measurements, including things like A-B encoding. I had thsee measurements working, already, but not as a general case where the user could set up any configuration. This is going to be very simple to code, but these darn ideas are hard to get.
It's nothing that a little diagram won't clear up.
Despite my trepidation, I am really looking forward to playing with the smart pins. A diagram (and then some, I think) will be critical to understanding these little beasties!
Chip,
Do I understand this correctly?
You can program the smart pins to process a pair of almost adjacent pins and have the output result optionally placed on that pins input to the cogs (instead of the actual pins input) so that a cog could do further processing without talking further with the smart pins???
If so, that is absolutely amazing!!!
Also I understand that the smart pins can use the output pin(s) from the cogs or an adjacent smart pins output???
Oh God! Chip, you are sometimes hilarious. That is so nice, and humble. Here you are telling us that "those ideas" are hard, when the truth is, that you get them at all is such a gift!
Good times right now, that's all I can say. Happy to be here, a part of it, learning lots of fun stuff!
Comments
Could have other uses too.
Will it take much silicon?
If this is true, then I think that might be a good argument. The problem I have is that with all of the other untapped capabilities of the P2, this might already be possible in other ways.
* or, equivalently, all combinations of A, A(prev), B, and B(prev) , with an additional command long telling what to do (increment, decrement, nothing, error) for each.
-Phil
These can be small - I've tested the CLU logic blocks in a EFM8 device up to 200MHz, and they also have a ExtPin/8, that can clock above SysCLK (because the sampled final f is ExtPin/8)
- A small Async (preSync?) prescaler could cost 3 FF per in-cell, plus some MUX/select logic.
Manchester encoding is used for 10Base-T Ethernet, and BMI for S/PDIF digital audio, though maybe the bitrates there are low enough to do things in software.
https://en.wikipedia.org/wiki/Manchester_code
https://en.wikipedia.org/wiki/Differential_Manchester_encoding
http://ip.cadence.com/ipportfolio/verification-ip/simulation-vip/mipi/mipi-i3c-simulation-vip
Then again it may be so "closed" we never have to worry about it
I noticed in your earlier description of the current 'triangle wave' pwm that you didn't specifically mention deadtime. Perhaps this could be a cheap way to implement deadtime for driving an I or H bridge.
Little things like this, if they don't overcomplicate things, can be big BOM savers later on.
Great!
Bi-Phase (leading edge coded) can be decoded with an any-edge Monostable and a D-FF.
Manchester (mid edge coded) needs two Monostables (one is a hold-off) and a D-FF.
(this is not PLL based decode, just edge triggered)
I have something like that now, where for each counter mode, there's a fixed pattern of 16 two-bit values which are used as +0/+1/-1. There are sixteen to accommodate all cases of A, A(prev), B, B (prev). The %10 case is unused, but could be an event trigger.
I've thought about making this 16x2-bit pattern user-settable, but it would require another 32 bits of flops (out of a current ~200) per smart pin. My thinking has been to keep such details away from the user, so he's not burdened with thinking about these patterns. It seems easier to just have modes for A-B encoders, counters, frequency measuring, etc. Otherwise, they'd have to load some cryptic long into the smart pin to get it to do something. I'm not against that, personally, but I don't want to overburden people with details. We could have labels for these values (ie 'pin_encoder' = %00_01_11_00__11_00_00_01__01_00_00_11__00_11_01_00).
What do you guys think?
By running two pins as triangle PWMs with the same prescaler and framesize, and started on the same clock, you'd get deadtime when neither pin was "high". There are polarity matters in something like this, which are selectable.
Absolutely, yes. Keep the flexibility in the hardware, and hide any resulting complexity from novice users by giving them predefined constants. That way, advanced users can still define weird counting modes as their needs dictate. I think the lesson from the P1 is that the counters were used in unanticipated ways. I'm sure the same will be true of the P2 -- only more so.
-Phil
I've been looking into this. I'm trying to get my head around what kinds of actions need to result from 16 possible states, and if there maybe needs to be more than one pattern.
Maybe with the removable xtals or bad routing it can happen, but I think it would be extremely rare event with a soldered xtal.
Handling live boards with your fingers can cause trouble if you happen to contact a crystal node on the PCB and bridge it to something else. I've noticed this a few times.
What I do now is keep all xtal traces on the top layer with no vias.
Also, keep xtal close to uC chip.
Then, you really have to work to make it go haywire.
Still, it is possible.
Also, I happen to know that running your finger under the P123 board SMPS can make it go haywire too.
So maybe, in general, running your fingers over SMPS components is a bad idea...
Good idea about no vias and short wires.
These SMPS circuits make me kind of nervous. Our original SX-Key (for the SX chips) had a direct-drive switcher for generating the programming voltage. A few of those things smoked. Inserting a series cap and resistor between the I/O pin and the base solved the problem.
Using a current-limited supply when developing a switcher circuit is great, and then make sure the transistor can't get left 'on' in the final circuit via some DC isolation. Then, things are pretty safe. There's the other possibility, though, of the voltage feedback being interfered with, causing over-voltage.
Well, this page shows using varistors instead of zener diodes:
http://www.mouser.com/epcos-smps/
This comes down to coverage.
Do you have a table of the modes supported by your current code ?
- ie what is missing, from the simpler choices ?
FlipFlops are not of as high as cost in ASIC, as they are in FPGAs, and they replace mini-roms.
Having pre-defines as words for modes, is not hard to document, so users rarely need to know the 10101's
I got the smart pin pretty much done, but I've decided to combine the measurement and timer logic blocks. I am adding some modes where you can inc/dec/clear on any combination of A, A(prev), B, B(prev) and selectively report results back or just alert via the IN bit.
The A and B inputs to smart pins can now be the local pin, any of three pins above or below, or the OUT signal to either the local or adjacent pin. This will allow a smart pin to use another smart pin's output as one of its inputs, or allow you to control it via the OUT bit. Just working out the details now.
These things are just getting smarter and smarter! I'm afraid that they're getting too smart for me to understand!
I've been watching, and hoping/expecting this would happen. VERY cool..
It's nothing that a little diagram won't clear up.
I was thinking, after I worked all night, that inspiration is akin to a true random number generator, where you must wait for some phenomenon to generate the number. You can't just get it on demand. Most of the night, I just kind of sat there waiting for things to congeal in my head, not knowing when, or if, it would come. Finally, almost on its own, the mental picture emerged and it was quite clear. I had been trying to think about this for a week, to no avail.
We"ve got a framework now that can do all kinds of measurements, including things like A-B encoding. I had thsee measurements working, already, but not as a general case where the user could set up any configuration. This is going to be very simple to code, but these darn ideas are hard to get.
Despite my trepidation, I am really looking forward to playing with the smart pins. A diagram (and then some, I think) will be critical to understanding these little beasties!
Do I understand this correctly?
You can program the smart pins to process a pair of almost adjacent pins and have the output result optionally placed on that pins input to the cogs (instead of the actual pins input) so that a cog could do further processing without talking further with the smart pins???
If so, that is absolutely amazing!!!
Also I understand that the smart pins can use the output pin(s) from the cogs or an adjacent smart pins output???
Looking forward to seeing a diagram
Good times right now, that's all I can say. Happy to be here, a part of it, learning lots of fun stuff!