Chip
I'm experiencing a random issue with the smartpin quadrature encoder mode.
~1 in 10 program loads from Pnut (F11) result in erratic encoder values directly after program load.
No amount of movement fixes the problem but another program load does.
Encoders seem to be stable after a good program load/reset.
I have two encoders connected and the issue appears in one or the other and sometimes both.
I even replaced both encoders just to be sure it wasn't something with them (could still be!).
Perhaps it's related to the "reset" problem you mentioned in an earlier post.
Okay. I think I see why. You have an -A9 board, right?
I need to update the Z register during reset, at least. There may be some other issue, but I will test after a recompile. Then, I will post a file that should fix the problem.
Okay. I think I see why. You have an -A9 board, right?
I need to update the Z register during reset, at least. There may be some other issue, but I will test after a recompile. Then, I will post a file that should fix the problem.
Yes I have a P123-A9 board.
Looking forward to testing the latest V8 image.
@cgracey, can you elaborate which of the PINSETM fields still apply to the smart cell behavior for "normal" (%00000) mode? For instance, could you still specify an A and B input and set the %FFF field to %011 (xor) such that the cell's IN bit reflects A xor B?
That's correct.
A single PINSETM with %AAAA,%BBBB and %FFF fields reflects on the INx bit.
I just used this "snoop mode" with the streamer and it works great!
Since the smart cell has control/relations with adjacent pins +/-3, perhaps a hardware handshake for serial receive and transmission (rts,cts) would be useful. Even if this is made on fixed pins (not user selectable)
I agree, with the Pin Cells light on buffering, to keep the logic down, it is not clear if SW handshake alone is enough to keep up with highest data rates.
Most of the high-end UARTs have handshake included -many do the full old Modem sets, but it is probably enough to do a single Wire in each direction in HW, and slower status signaling can be done in SW.
Each smart pin read inputs from relative pins -3..+3, but can only output on its own pin. So, to support hardware handshaking, it would require two pins for the transmit case. This may be a little much, at the moment. For what it's worth, though, could you please post a link to a document that explains how simple one-wire-each-direction handshaking is used by some modern IC?
@cgracey,
I understand the +/-3 detail as real pin inputs to each smart cell. That means 7 inputs if you count 0 as its own pin. All real pin states. Right?
I also understand that each smart cell have only one output, its own pin because of missing paths/routes to adjacent pins, but I seem to remember a discussion of daisy chaining smart cells by selecting adjacent cell output as input for current cell.
Is this done through the +/-3 real pin state, so forcing the adjacent cell to output to real world (and potentially wasting a pin) or there is an internal path to the adjacent cell internal output, the one that is eventually routed to external pin?
I explain better.
If smart pin 1 is set as input and can't output on pin2 could pin2's smart cell take internal output of smart cell 1 and output it on its own pin (2).
If not there is a (application) reason why you have chosen 7 inputs (+3..0..-3) span for each cell? Perhaps +2..0..-2 so 5 can be enough and the 2 free channels can be wired to -1 and +1 smart cell internal output regardless if it is routed to external pin or not. I think it takes the same logic as the number of paths are the same, only the source changes for two routes.
In this way smart cells can be daisy chained internally (without the need to output to real world) and more complex functions blocks can be obtained. Also for the future, the ones that can't be foreseen today.
Perhaps in this way the async serial receivers/transmitters can route hw handshake to adjacent pins?
I hope that my english is clear enough, i didn't meant to bother with long writing.
@cgracey, can you elaborate which of the PINSETM fields still apply to the smart cell behavior for "normal" (%00000) mode? For instance, could you still specify an A and B input and set the %FFF field to %011 (xor) such that the cell's IN bit reflects A xor B?
That's correct.
A single PINSETM with %AAAA,%BBBB and %FFF fields reflects on the INx bit.
I just used this "snoop mode" with the streamer and it works great!
Thanks for confirming that! I'm out of town without my 1-2-3 board (what was I thinking???), so can't test any of this out myself.
... having a smart cell mode that simply reported when A or B changes. Here's the thought:
* When you set DIR to 1, initial %AB is shifted into Z.
* Each time A or B changes, the current %AB is shifted into Z and IN is set.
@cgracey, could this be easily added? As I mention elsewhere, this would provide the basis for driving a state machine. Instead of the way the old modes worked, this version simply delegates all the work to software. It's not as fast as the old modes, but it's completely generic.
... having a smart cell mode that simply reported when A or B changes. Here's the thought:
* When you set DIR to 1, initial %AB is shifted into Z.
* Each time A or B changes, the current %AB is shifted into Z and IN is set.
@cgracey, could this be easily added? As I mention elsewhere, this would provide the basis for driving a state machine. Instead of the way the old modes worked, this version simply delegates all the work to software. It's not as fast as the old modes, but it's completely generic.
Good idea. I'm still working on implementing the last changes for digital DACs, but I'll see what we can do about this. It would kind of need an event counter, in case you missed a few changes. You could always use the PIN-pattern detector for this in the cog, too.
... having a smart cell mode that simply reported when A or B changes. Here's the thought:
* When you set DIR to 1, initial %AB is shifted into Z.
* Each time A or B changes, the current %AB is shifted into Z and IN is set.
@cgracey, could this be easily added? As I mention elsewhere, this would provide the basis for driving a state machine. Instead of the way the old modes worked, this version simply delegates all the work to software. It's not as fast as the old modes, but it's completely generic.
Good idea. I'm still working on implementing the last changes for digital DACs, but I'll see what we can do about this. It would kind of need an event counter, in case you missed a few changes. You could always use the PIN-pattern detector for this in the cog, too.
While a counter would be nice, I wouldn't bother to start with. It will limit the safe state change rate, but it will keep the implementation simple.
The problem with using the PIN-pattern detector for a state machine is that you have to know which pattern your are expecting next. That greatly limits how complex the state machine can be.
Though... I suppose you could check for "not the current input states", but you can't atomically get what the new state is at the same time.
... having a smart cell mode that simply reported when A or B changes. Here's the thought:
* When you set DIR to 1, initial %AB is shifted into Z.
* Each time A or B changes, the current %AB is shifted into Z and IN is set.
@cgracey, could this be easily added? As I mention elsewhere, this would provide the basis for driving a state machine. Instead of the way the old modes worked, this version simply delegates all the work to software. It's not as fast as the old modes, but it's completely generic.
Good idea. I'm still working on implementing the last changes for digital DACs, but I'll see what we can do about this. It would kind of need an event counter, in case you missed a few changes. You could always use the PIN-pattern detector for this in the cog, too.
While a counter would be nice, I wouldn't bother to start with. It will limit the safe state change rate, but it will keep the implementation simple.
The problem with using the PIN-pattern detector for a state machine is that you have to know which pattern your are expecting next. That greatly limits how complex the state machine can be.
Though... I suppose you could check for "not the current input states", but you can't atomically get what the new state is at the same time.
Yes, you would just detect a change and then grab the new state, making it the new comparison target.
By counter, I meant a 3 or 4-bit event counter that would help you make sense of multiple states that streamed in faster than you could have read them. It would let you grab the new states and properly shift them to get the one that you need to look at first.
By counter, I meant a 3 or 4-bit event counter that would help you make sense of multiple states that streamed in faster than you could have read them. It would let you grab the new states and properly shift them to get the one that you need to look at first.
I got what you were saying. I just don't think you need it. If you can't handle the events as they come in, how are you going to handle them when there's a backlog?
By counter, I meant a 3 or 4-bit event counter that would help you make sense of multiple states that streamed in faster than you could have read them. It would let you grab the new states and properly shift them to get the one that you need to look at first.
I got what you were saying. I just don't think you need it. If you can't handle the events as they come in, how are you going to handle them when there's a backlog?
I agree. Nothing like getting behind! Wouldn't just trapping changes using the cog be as efficient, considering that it takes 9..16 clocks for a PINGETZ? You could have the pin-pattern sensor generate an interrupt.
I agree. Nothing like getting behind! Wouldn't just trapping changes using the cog be as efficient, considering that it takes 9..16 clocks for a PINGETZ? You could have the pin-pattern sensor generate an interrupt.
That's ok, only up to a modest time window, but it may be tolerable.
For time windows less than the pin-interact times, you may be able to use capture, but that comes back to the request for Same-Clock ARM of multi channel capture, in order to get the Atomic action Searth seeks.
By counter, I meant a 3 or 4-bit event counter that would help you make sense of multiple states that streamed in faster than you could have read them. It would let you grab the new states and properly shift them to get the one that you need to look at first.
I got what you were saying. I just don't think you need it. If you can't handle the events as they come in, how are you going to handle them when there's a backlog?
I agree. Nothing like getting behind! Wouldn't just trapping changes using the cog be as efficient, considering that it takes 9..16 clocks for a PINGETZ? You could have the pin-pattern sensor generate an interrupt.
With SETPAN, the pin pattern that triggered the interrupt may have changed by the time you actually read INx. With SETPAE, you have to know in advance which pattern will occur next.
I agree that using the smart cell would be slower, but I don't see another way to capture both the event and the pin state at the same time.
But maybe you're right. Maybe the pin-pattern approach is still good enough for now....
By counter, I meant a 3 or 4-bit event counter that would help you make sense of multiple states that streamed in faster than you could have read them. It would let you grab the new states and properly shift them to get the one that you need to look at first.
I got what you were saying. I just don't think you need it. If you can't handle the events as they come in, how are you going to handle them when there's a backlog?
I agree. Nothing like getting behind! Wouldn't just trapping changes using the cog be as efficient, considering that it takes 9..16 clocks for a PINGETZ? You could have the pin-pattern sensor generate an interrupt.
With SETPAN, the pin pattern that triggered the interrupt may have changed by the time you actually read INx. With SETPAE, you have to know in advance which pattern will occur next.
I agree that using the smart cell would be slower, but I don't see another way to capture both the event and the pin state at the same time.
But maybe you're right. Maybe the pin-pattern approach is still good enough for now....
What do you mean by capturing both the event and pin state at the same time? Are they not the same?
I agree that using the smart cell would be slower, but I don't see another way to capture both the event and the pin state at the same time.
But maybe you're right. Maybe the pin-pattern approach is still good enough for now....
What do you mean by capturing both the event and pin state at the same time? Are they not the same?
For a single pin, yes, they are the same.
Where it gets complicated is when two pins (or more) trigger a condition.
The PIN POLL then reads some time later, but you cannot be sure what you see, is exactly what caused the capture.
One way to capture both the event, and pin state, is to dedicate a capture channel to each pin. This does not by itself capture a pattern, but I think the pattern can run in parallel ? - and the edge time stamp that is one read time back, is the triggering pin.
Other time stamps may be present, (capture flag set?) if other pins triggered since the first one, and before they are read,
Chip
According to the docs the PINACK instruction takes 2 clocks.
In NCO frequency mode for example if I do a PINACK I then have to wait ~8 clocks before the INx state reflects the PINACK instruction.
Is this the expected scenario for all PINACK's?
If so maybe an additional note in the docs might be needed.
What do you mean by capturing both the event and pin state at the same time? Are they not the same?
For a single pin, yes, they are the same.
Where it gets complicated is when two pins (or more) trigger a condition.
The PIN POLL then reads some time later, but you cannot be sure what you see, is exactly what caused the capture.
Exactly. Even if you have
WAITPAT
MOV t0, INA
the value of the pins can change between the point that WAITPAT resumes and MOV captures INA. For i2c, this should not be an issue, since the signalling is relatively slow (i.e. the signal should not be changing quickly enough to lose state changes between the WAITPAT and MOV).
In reality, there is a practical upper limit to signal capturing. Even if there were a shadow register that automatically captured the state of INx, the value in the shadow register could be overwritten by subsequent events before you read the first value into a cog register. While the smart cell mode would mitigate this a bit by holding the past 16 events (but for 2 pins instead of 32), you still have to find a way to extract those events and do something with them in a reasonable amount of time. In this case, the smart cell mode could theoretically handle short bursts of fast events, followed by long idle periods. But I don't know how common that sort of signalling is.
So... what this probably really comes down to is a matter of resource usage. When you are trying to capture the state of two pins, does it make more sense to use a smart cell or a pattern event? Both free up the cog to do other things (or efficiently wait). The smart cell requires more clock cycles to read, but it can also efficiently capture multiple event.
I don't know what the right answer is. My thought is still along the lines of adding the smart cell mode (if it can be done cheaply), as it adds overall versatility.
Chip
According to the docs the PINACK instruction takes 2 clocks.
In NCO frequency mode for example if I do a PINACK I then have to wait ~8 clocks before the INx state reflects the PINACK instruction.
Is this the expected scenario for all PINACK's?
If so maybe an additional note in the docs might be needed.
Thanks for realizing this. It hadn't occurred to me that there might be such a significant delay for PINACK response. There are clock cycle delays, but I'm surprised the number is so high. I'll investigate this when I get back into the shop.
the value of the pins can change between the point that WAITPAT resumes and MOV captures INA. For i2c, this should not be an issue, since the signalling is relatively slow (i.e. the signal should not be changing quickly enough to lose state changes between the WAITPAT and MOV).
In reality, there is a practical upper limit to signal capturing. Even if there were a shadow register that automatically captured the state of INx, the value in the shadow register could be overwritten by subsequent events before you read the first value into a cog register. While the smart cell mode would mitigate this a bit by holding the past 16 events (but for 2 pins instead of 32), you still have to find a way to extract those events and do something with them in a reasonable amount of time.
The next question is what information is stored in those 16 past events ?
If you store only pin-state, you have lost timing info, so that rather limits use.
If you store pin-state and timing, that would be great, but sounds like a resource hog to me ?
Other MCUs do have FIFOs on their capture pathways, and that allows very short Pulse-Width timings, down to 1 sysclk.
Some also have simple capture prescalers, that can /1 /2 /4 etc, that let designers choose how many cycles between capture, which is a nice way to improve resolution on high frequency signals.
FIFOs are a good idea, on any peripheral, but they do use resource.
This resource trade-off, is one reason I favour using co-operative capture, where multiple pin cells can be tasked in groups.
The adjacent MUX feature means the HW can map many Pin-cells onto one pin, or pair of pins, the missing piece from what I understand as the design is now, is you can only control reset-release on all those cells, in a atomic/same SysCLK manner.
That's very close, but that needs expanding to include things like capture-arm, across multiple cells.
If you wanted to capture many pins edges to a common master time, I think you can now map pairs of pins ie two capture channels per pin), leaving every 2nd pin as 'other use. (there is a pulse width mode, but that is not master time stamped)
A ripple-capture system may be possible using the Time-Interval A-B that Chip has mentioned, again using multiple pin cells, but operation of that needs the common enable/arm control.
Given the smart pin hardware, a single COG should be able to operate multiple frequency counters, or transit timers, etc (8,16,up to 32? or more ?) .
It is the housekeeping details of that multiple channel design that needs attention.
@jmg, that sounds so much more complicated than what I had in mind. If a new capture mode cannot be added quickly and easily, then leave it out. What you describe sounds neither quick nor easy to add.
Thanks for realizing this. It hadn't occurred to me that there might be such a significant delay for PINACK response. There are clock cycle delays, but I'm surprised the number is so high. I'll investigate this when I get back into the shop.
Chip
Here's an example of the delay needed to get the updated PINACK state.
@jmg, that sounds so much more complicated than what I had in mind. If a new capture mode cannot be added quickly and easily, then leave it out. What you describe sounds neither quick nor easy to add.
I see the opposite.
A 16 stage buffer on every pin, is going to add significant logic, not to mention is a new feature, but one that comes up short on information captured.
(unless you propose to add time too, but that is even more logic..)
It seems more aligned to the KISS focus of Smart Pins, to be able to use more than one, on the more complex tasks, rather than add more buffers to every pin.
Chip has already said reset release is possible now across many pins, so the core mechanism is already here, all it needs is to be able to reach more than just reset, and to me, that detail of atomic multiple pin reach reach, is a simple config option.
Let's take a simple example of multi-channel Simple Frequency counter :
Each pin is set as External edge count, and then at some exact time base (COG determined) , every count value is SW captured, on the same SysCLK, and read later.
Any pin-path Delays in the SW capture request are always the same, so the Time Delta is correct. Multiple captures can be averaged, for higher precision.
Just a little more complex, is Reciprocal Counting, or Multi-cycle DutyCycle measure.
Those need pairs of capture values, with the slight difference the capture is armed-one-shot, and happens on the next Signal Edge, once armed.
Reading is the same.
With the fixed/improved control paths, a single COG can manage a lot of measurement channels, with no precision loss.
Alternatively, can anyone give a config setup where the existing pin cell can do the above 3 types of common Any-Channel measurements ?
@jmg, that sounds so much more complicated than what I had in mind. If a new capture mode cannot be added quickly and easily, then leave it out. What you describe sounds neither quick nor easy to add.
I see the opposite.
A 16 stage buffer on every pin, is going to add significant logic, not to mention is a new feature, but one that comes up short on information captured.
(unless you propose to add time too, but that is even more logic..)
I was under the impression that there was already a shift register per cell, as the serial modes would require one. All you are doing is shifting in A and B pin states into that register. If this would require separate additional registers, just don't implement the feature.
I was under the impression that there was already a shift register per cell, as the serial modes would require one. All you are doing is shifting in A and B pin states into that register. If this would require separate additional registers, just don't implement the feature.
There is shifter support( but is there a 2 bit shifter ?) , but that has no age-information.
If you only want to cover 2 bits (which seems quite limiting) you could do a 2 bit special case, of a 2-bit shifter, where the shifter clock was derived from Change-of-state on the 2 pins, instead of normal CLK.
I'm not sure how this shifter queue would then interact with interrupts ?
With Quad Counting already covered, and this prone to fill-up on any bounce, & no age-info, I'm not sure of the use cases ?
If there is a 2 bit shifter, you could clock that normally, and get age-info and filter with SW.
I have used Pin-Change interrupts in other MCUs and there, I just live with the upper speed limit, and it samples the Pin when it can, and compares. If they are ==, it assumes an impulse (pin restored before capture) and can ignore that, and other outcomes are managed, with the caveat it assumes the trigger-event matches the later capture.
Above that speed, you can use streamer, or normally clocked shifters, but those still need finite SW time to process.
I could see a useful streamer mode, where it captured Pin-pattern and Time, on masked-change.
Because it stores two values per sample, it is half the max speed of simply clocked streaming, but it has very wide dynamic range, and needs no clock-scale adjustment.
Some logic analyzers do this, and it gives high precision over a very wide data rate.
Speaking of shifters, I'm still not clear on the current Streamer/shifter bit widths, Chip I think mentioned QuadSPI support, and maybe Dual SPI ?, but I don't know if that has made the FPGA yet.
Test examples I've seen have all been single-bit SPI.
I'm talking about a slightly different angle, of working with any-number-of-pin-cells under tight/atomic single COG control.
Thanks for realizing this. It hadn't occurred to me that there might be such a significant delay for PINACK response. There are clock cycle delays, but I'm surprised the number is so high. I'll investigate this when I get back into the shop.
Chip
Here's an example of the delay needed to get the updated PINACK state.
pinack #pin
waitx #3
testb ina,#pin wc
I looked into this and there are 6 flops in series that make this process happen:
1) flop in hub that aggregates pin messages from cogs to each pin
2) flop in smart pin that receives message from hub
3) flop in smart pin that shifts in message
4) flop in smart pin that cancels IN high, based on empty PINACK message
5) flop in hub that forwards IN signals to cogs
6) flop in cog that gets IN into S/D
That 'WAITX #3' takes 2+3 clocks. To get rid of those 5 clocks, so that we could poll IN right away, we'd need to eliminate 5 series flops. The only way that can happen is to make an alternate conduit for the PINACK purpose, circumventing the messaging system. And only 1 flop is allowed. This probably cannot be achieved without resorting to lots of parallel flops and logic, maybe in each cog.
I see two simple solutions:
1) Document current behavior and live with it - don't poll IN until 5 clocks after PINACK.
2) Have PINACK send out all eight nibbles, not just an empty message.
In case (2) The smart pin would sense the PINACK and act as it does now, but the cog would waste 8 more clocks sending out %0000 nibbles, getting past the 'danger' zone, so that the next instruction would see a cleared IN.
2) Have PINACK send out all eight nibbles, not just an empty message.
In case (2) The smart pin would sense the PINACK and act as it does now, but the cog would waste 8 more clocks sending out %0000 nibbles, getting past the 'danger' zone, so that the next instruction would see a cleared IN.
What do you think?
That is quite a lot of extra clocks.
Can it not send just enough to meet timing ?
Or, can opcodes that readback, self-time in order to meet timing ?
The benefit of the last approach, is you can do something useful in the required dead time.
2) Have PINACK send out all eight nibbles, not just an empty message.
In case (2) The smart pin would sense the PINACK and act as it does now, but the cog would waste 8 more clocks sending out %0000 nibbles, getting past the 'danger' zone, so that the next instruction would see a cleared IN.
What do you think?
That is quite a lot of extra clocks.
Can it not send just enough to meet timing ?
Or, can opcodes that readback, self-time in order to meet timing ?
The benefit of the last approach, is you can do something useful in the required dead time.
Two of those six flops may be able to be eliminated in the ASIC, but the FPGA needs them to make interconnect timing.
Good idea about making PINACK take just enough time, instead of three extra clocks. That would be very easy to do. I don't know why that didn't occur to me. Like you said, though, five clocks can be used for something useful, like three 2-clock instrucions. It's just a bug-a-boo to remember you need to elapse the time before polling again.
Like you said, though, five clocks can be used for something useful, like three 2-clock instrucions. It's just a bug-a-boo to remember you need to elapse the time before polling again.
The assembler & tools could issue a warning, as I think this is a quite easy to check situation ?
Assemblers could even have an optional auto-pack mode, where they add delays, if enough are not found, or ( if that spooks the horses too much) the user can conditionally code for this if the delay per 32b fetch is known (which I think is always 2 sysclks in P2 ?)
I've used both approaches in Assembler coding for other MCUs :
Checks with warnings, and address checks that conditionally add or change packing if violations are looming.
Like you said, though, five clocks can be used for something useful, like three 2-clock instrucions. It's just a bug-a-boo to remember you need to elapse the time before polling again.
The assembler & tools could issue a warning, as I think this is a quite easy to check situation ?
Assemblers could even have an optional auto-pack mode, where they add delays, if enough are not found, or ( if that spooks the horses too much) the user can conditionally code for this if the delay per 32b fetch is known (which I think is always 2 sysclks in P2 ?)
I've used both approaches in Assembler coding for other MCUs :
Checks with warnings, and address checks that conditionally add or change packing if violations are looming.
We could issue warnings. It would be good if there were some other way around this, though.
I just updated the smart pin documentation for the coming release and I noted that it takes 5 clocks after PINACK before IN can be polled again. I guess it's not so bad. Better than being made to wait.
1) Document current behavior and live with it - don't poll IN until 5 clocks after PINACK.
What do you think?
Thinking about it further the most common combination of instructions is likely to be a PINACK followed by a PINSETY.
As PINSETY takes 10 clocks that more than covers the 5 clock delay of PINACK.
Just document the delay and we all should "smartpin" happily ever after.
Comments
Okay. I think I see why. You have an -A9 board, right?
I need to update the Z register during reset, at least. There may be some other issue, but I will test after a recompile. Then, I will post a file that should fix the problem.
Looking forward to testing the latest V8 image.
A single PINSETM with %AAAA,%BBBB and %FFF fields reflects on the INx bit.
I just used this "snoop mode" with the streamer and it works great!
I understand the +/-3 detail as real pin inputs to each smart cell. That means 7 inputs if you count 0 as its own pin. All real pin states. Right?
I also understand that each smart cell have only one output, its own pin because of missing paths/routes to adjacent pins, but I seem to remember a discussion of daisy chaining smart cells by selecting adjacent cell output as input for current cell.
Is this done through the +/-3 real pin state, so forcing the adjacent cell to output to real world (and potentially wasting a pin) or there is an internal path to the adjacent cell internal output, the one that is eventually routed to external pin?
I explain better.
If smart pin 1 is set as input and can't output on pin2 could pin2's smart cell take internal output of smart cell 1 and output it on its own pin (2).
If not there is a (application) reason why you have chosen 7 inputs (+3..0..-3) span for each cell? Perhaps +2..0..-2 so 5 can be enough and the 2 free channels can be wired to -1 and +1 smart cell internal output regardless if it is routed to external pin or not. I think it takes the same logic as the number of paths are the same, only the source changes for two routes.
In this way smart cells can be daisy chained internally (without the need to output to real world) and more complex functions blocks can be obtained. Also for the future, the ones that can't be foreseen today.
Perhaps in this way the async serial receivers/transmitters can route hw handshake to adjacent pins?
I hope that my english is clear enough, i didn't meant to bother with long writing.
Thanks for confirming that! I'm out of town without my 1-2-3 board (what was I thinking???), so can't test any of this out myself.
@cgracey, could this be easily added? As I mention elsewhere, this would provide the basis for driving a state machine. Instead of the way the old modes worked, this version simply delegates all the work to software. It's not as fast as the old modes, but it's completely generic.
Good idea. I'm still working on implementing the last changes for digital DACs, but I'll see what we can do about this. It would kind of need an event counter, in case you missed a few changes. You could always use the PIN-pattern detector for this in the cog, too.
While a counter would be nice, I wouldn't bother to start with. It will limit the safe state change rate, but it will keep the implementation simple.
The problem with using the PIN-pattern detector for a state machine is that you have to know which pattern your are expecting next. That greatly limits how complex the state machine can be.
Though... I suppose you could check for "not the current input states", but you can't atomically get what the new state is at the same time.
Yes, you would just detect a change and then grab the new state, making it the new comparison target.
By counter, I meant a 3 or 4-bit event counter that would help you make sense of multiple states that streamed in faster than you could have read them. It would let you grab the new states and properly shift them to get the one that you need to look at first.
Except you can't do this atomically. In other words, you can't guarantee that you can capture the pin state that triggered the event.
I got what you were saying. I just don't think you need it. If you can't handle the events as they come in, how are you going to handle them when there's a backlog?
I agree. Nothing like getting behind! Wouldn't just trapping changes using the cog be as efficient, considering that it takes 9..16 clocks for a PINGETZ? You could have the pin-pattern sensor generate an interrupt.
For time windows less than the pin-interact times, you may be able to use capture, but that comes back to the request for Same-Clock ARM of multi channel capture, in order to get the Atomic action Searth seeks.
With SETPAN, the pin pattern that triggered the interrupt may have changed by the time you actually read INx. With SETPAE, you have to know in advance which pattern will occur next.
I agree that using the smart cell would be slower, but I don't see another way to capture both the event and the pin state at the same time.
But maybe you're right. Maybe the pin-pattern approach is still good enough for now....
What do you mean by capturing both the event and pin state at the same time? Are they not the same?
Where it gets complicated is when two pins (or more) trigger a condition.
The PIN POLL then reads some time later, but you cannot be sure what you see, is exactly what caused the capture.
One way to capture both the event, and pin state, is to dedicate a capture channel to each pin. This does not by itself capture a pattern, but I think the pattern can run in parallel ? - and the edge time stamp that is one read time back, is the triggering pin.
Other time stamps may be present, (capture flag set?) if other pins triggered since the first one, and before they are read,
According to the docs the PINACK instruction takes 2 clocks.
In NCO frequency mode for example if I do a PINACK I then have to wait ~8 clocks before the INx state reflects the PINACK instruction.
Is this the expected scenario for all PINACK's?
If so maybe an additional note in the docs might be needed.
Exactly. Even if you have
the value of the pins can change between the point that WAITPAT resumes and MOV captures INA. For i2c, this should not be an issue, since the signalling is relatively slow (i.e. the signal should not be changing quickly enough to lose state changes between the WAITPAT and MOV).
In reality, there is a practical upper limit to signal capturing. Even if there were a shadow register that automatically captured the state of INx, the value in the shadow register could be overwritten by subsequent events before you read the first value into a cog register. While the smart cell mode would mitigate this a bit by holding the past 16 events (but for 2 pins instead of 32), you still have to find a way to extract those events and do something with them in a reasonable amount of time. In this case, the smart cell mode could theoretically handle short bursts of fast events, followed by long idle periods. But I don't know how common that sort of signalling is.
So... what this probably really comes down to is a matter of resource usage. When you are trying to capture the state of two pins, does it make more sense to use a smart cell or a pattern event? Both free up the cog to do other things (or efficiently wait). The smart cell requires more clock cycles to read, but it can also efficiently capture multiple event.
I don't know what the right answer is. My thought is still along the lines of adding the smart cell mode (if it can be done cheaply), as it adds overall versatility.
Thanks for realizing this. It hadn't occurred to me that there might be such a significant delay for PINACK response. There are clock cycle delays, but I'm surprised the number is so high. I'll investigate this when I get back into the shop.
The next question is what information is stored in those 16 past events ?
If you store only pin-state, you have lost timing info, so that rather limits use.
If you store pin-state and timing, that would be great, but sounds like a resource hog to me ?
Other MCUs do have FIFOs on their capture pathways, and that allows very short Pulse-Width timings, down to 1 sysclk.
Some also have simple capture prescalers, that can /1 /2 /4 etc, that let designers choose how many cycles between capture, which is a nice way to improve resolution on high frequency signals.
FIFOs are a good idea, on any peripheral, but they do use resource.
This resource trade-off, is one reason I favour using co-operative capture, where multiple pin cells can be tasked in groups.
The adjacent MUX feature means the HW can map many Pin-cells onto one pin, or pair of pins, the missing piece from what I understand as the design is now, is you can only control reset-release on all those cells, in a atomic/same SysCLK manner.
That's very close, but that needs expanding to include things like capture-arm, across multiple cells.
If you wanted to capture many pins edges to a common master time, I think you can now map pairs of pins ie two capture channels per pin), leaving every 2nd pin as 'other use. (there is a pulse width mode, but that is not master time stamped)
A ripple-capture system may be possible using the Time-Interval A-B that Chip has mentioned, again using multiple pin cells, but operation of that needs the common enable/arm control.
Given the smart pin hardware, a single COG should be able to operate multiple frequency counters, or transit timers, etc (8,16,up to 32? or more ?) .
It is the housekeeping details of that multiple channel design that needs attention.
Here's an example of the delay needed to get the updated PINACK state.
A 16 stage buffer on every pin, is going to add significant logic, not to mention is a new feature, but one that comes up short on information captured.
(unless you propose to add time too, but that is even more logic..)
It seems more aligned to the KISS focus of Smart Pins, to be able to use more than one, on the more complex tasks, rather than add more buffers to every pin.
Chip has already said reset release is possible now across many pins, so the core mechanism is already here, all it needs is to be able to reach more than just reset, and to me, that detail of atomic multiple pin reach reach, is a simple config option.
Let's take a simple example of multi-channel Simple Frequency counter :
Each pin is set as External edge count, and then at some exact time base (COG determined) , every count value is SW captured, on the same SysCLK, and read later.
Any pin-path Delays in the SW capture request are always the same, so the Time Delta is correct. Multiple captures can be averaged, for higher precision.
Just a little more complex, is Reciprocal Counting, or Multi-cycle DutyCycle measure.
Those need pairs of capture values, with the slight difference the capture is armed-one-shot, and happens on the next Signal Edge, once armed.
Reading is the same.
With the fixed/improved control paths, a single COG can manage a lot of measurement channels, with no precision loss.
Alternatively, can anyone give a config setup where the existing pin cell can do the above 3 types of common Any-Channel measurements ?
I was under the impression that there was already a shift register per cell, as the serial modes would require one. All you are doing is shifting in A and B pin states into that register. If this would require separate additional registers, just don't implement the feature.
If you only want to cover 2 bits (which seems quite limiting) you could do a 2 bit special case, of a 2-bit shifter, where the shifter clock was derived from Change-of-state on the 2 pins, instead of normal CLK.
I'm not sure how this shifter queue would then interact with interrupts ?
With Quad Counting already covered, and this prone to fill-up on any bounce, & no age-info, I'm not sure of the use cases ?
If there is a 2 bit shifter, you could clock that normally, and get age-info and filter with SW.
I have used Pin-Change interrupts in other MCUs and there, I just live with the upper speed limit, and it samples the Pin when it can, and compares. If they are ==, it assumes an impulse (pin restored before capture) and can ignore that, and other outcomes are managed, with the caveat it assumes the trigger-event matches the later capture.
Above that speed, you can use streamer, or normally clocked shifters, but those still need finite SW time to process.
I could see a useful streamer mode, where it captured Pin-pattern and Time, on masked-change.
Because it stores two values per sample, it is half the max speed of simply clocked streaming, but it has very wide dynamic range, and needs no clock-scale adjustment.
Some logic analyzers do this, and it gives high precision over a very wide data rate.
Speaking of shifters, I'm still not clear on the current Streamer/shifter bit widths, Chip I think mentioned QuadSPI support, and maybe Dual SPI ?, but I don't know if that has made the FPGA yet.
Test examples I've seen have all been single-bit SPI.
I'm talking about a slightly different angle, of working with any-number-of-pin-cells under tight/atomic single COG control.
I looked into this and there are 6 flops in series that make this process happen:
1) flop in hub that aggregates pin messages from cogs to each pin
2) flop in smart pin that receives message from hub
3) flop in smart pin that shifts in message
4) flop in smart pin that cancels IN high, based on empty PINACK message
5) flop in hub that forwards IN signals to cogs
6) flop in cog that gets IN into S/D
That 'WAITX #3' takes 2+3 clocks. To get rid of those 5 clocks, so that we could poll IN right away, we'd need to eliminate 5 series flops. The only way that can happen is to make an alternate conduit for the PINACK purpose, circumventing the messaging system. And only 1 flop is allowed. This probably cannot be achieved without resorting to lots of parallel flops and logic, maybe in each cog.
I see two simple solutions:
1) Document current behavior and live with it - don't poll IN until 5 clocks after PINACK.
2) Have PINACK send out all eight nibbles, not just an empty message.
In case (2) The smart pin would sense the PINACK and act as it does now, but the cog would waste 8 more clocks sending out %0000 nibbles, getting past the 'danger' zone, so that the next instruction would see a cleared IN.
What do you think?
Other MCUs have this issue, tho not quite as large as 5 Clocks.
That is quite a lot of extra clocks.
Can it not send just enough to meet timing ?
Or, can opcodes that readback, self-time in order to meet timing ?
The benefit of the last approach, is you can do something useful in the required dead time.
Two of those six flops may be able to be eliminated in the ASIC, but the FPGA needs them to make interconnect timing.
Good idea about making PINACK take just enough time, instead of three extra clocks. That would be very easy to do. I don't know why that didn't occur to me. Like you said, though, five clocks can be used for something useful, like three 2-clock instrucions. It's just a bug-a-boo to remember you need to elapse the time before polling again.
The assembler & tools could issue a warning, as I think this is a quite easy to check situation ?
Assemblers could even have an optional auto-pack mode, where they add delays, if enough are not found, or ( if that spooks the horses too much) the user can conditionally code for this if the delay per 32b fetch is known (which I think is always 2 sysclks in P2 ?)
I've used both approaches in Assembler coding for other MCUs :
Checks with warnings, and address checks that conditionally add or change packing if violations are looming.
We could issue warnings. It would be good if there were some other way around this, though.
I just updated the smart pin documentation for the coming release and I noted that it takes 5 clocks after PINACK before IN can be polled again. I guess it's not so bad. Better than being made to wait.
As PINSETY takes 10 clocks that more than covers the 5 clock delay of PINACK.
Just document the delay and we all should "smartpin" happily ever after.