Here's another thought. using the LSB in PINSETM just for set/ack seems like a waste. What if you were to get rid of it and shift the mode over by one? Then, increase the mode values by one (so that "normal" is %00001, DAC noise is %00010, etc.). With this, PINACK is now really mode %00000 (which you will, of course, test). Note that PINACK and disabling smart modes (PINSETM #1) are still the same. Only the other modes (except serial modes) would would be affected, index-wise. In return, you free up one more bit for another use. Not that you necessarily need a free bit, of course. But, as with the OE bit, I'm sure you can come up with a good use for it.
Quadrature output from bottom two bits of counter. Lots more control options with NCO rate, counter count length and even possibility for phase arranging.
Err, or does NCO already use the counter?
Wouldn't bottom two bits count 0,1,2,3...
Quadrature would be 0,1,3,2... forward or 0,2,3,1... backward?
I'm certain that n-bit gray code encode and decode is just too much, but I have been surprised here before... I've lost track, maybe it's already there somewhere. Just a thought, doing it in hardware would be crazy fast.
The last thing that I'm concerned about is digital video input from digital camera modules....
It's usually an 8-bit data bus. Have to look up to see if Prop provides clock or it provides clock...
Remember that the input to an input-only function may be a neighboring pin, or even the local OUT bit. The pin tied to the smart pin input function may need to be a regular output, while its smart pin circuit does something else by reading another pin. Then, there's the matter of being able to test an input mode by manipulating it's output. So, there's occasion for an independent OE.
Quadrature output from bottom two bits of counter. Lots more control options with NCO rate, counter count length and even possibility for phase arranging.
Err, or does NCO already use the counter?
Chip has mentioned using two NCOs with a Phase-init covering most Quad generate cases ?
Not sure how much of that is in there ? I recall NCO Phase Init may not have been ?
That is not quite the same as a {Single Clock + 2 Bit State Engine with DIRN bit}, but it should cover most cases ?
Remember that the input to an input-only function may be a neighboring pin, or even the local OUT bit. The pin tied to the smart pin input function may need to be a regular output, while its smart pin circuit does something else by reading another pin. Then, there's the matter of being able to test an input mode by manipulating it's output. So, there's occasion for an independent OE.
Could you expand on what OE is actually controlling? From the above statements, it appears you are saying that
* the OE controls the pin associated with the cell, not the pin select by the A or B field?
* the a cell set to an input mode can be driven by its own OUT value, but only if OE is enabled?
Remember that the input to an input-only function may be a neighboring pin, or even the local OUT bit. The pin tied to the smart pin input function may need to be a regular output, while its smart pin circuit does something else by reading another pin. Then, there's the matter of being able to test an input mode by manipulating it's output. So, there's occasion for an independent OE.
Could you expand on what OE is actually controlling? From the above statements, it appears you are saying that
* the OE controls the pin associated with the cell, not the pin select by the A or B field?
* the a cell set to an input mode can be driven by its own OUT value, but only if OE is enabled?
There is room for four more modes, but I think I will fill them by just adding modes to the existing function blocks. Any simple suggestions? Maybe some time-this-signal-to-that-signal kind of functions? This would just entail adding a bit of steering logic to the existing measuring block, for example.
One mode that would be useful would be a diagnostic mode that selects a pin to monitor (A-pin) and sends its pin state directly to the relevant INA/INB bit.
This would allow the streamer to capture the smartpin output states.
Currently ths has to be done by hard wiring the smartpin output back to a regular IO pin.
Expanding on this mode a little further would be to include the B-pin as well and use the logic functions OR,AND,XOR output to send back to the INx bit.
One mode that would be useful would be a diagnostic mode that selects a pin to monitor (A-pin) and sends its pin state directly to the relevant INA/INB bit.
This would allow the streamer to capture the smartpin output states.
Currently ths has to be done by hard wiring the smartpin output back to a regular IO pin.
Expanding on this mode a little further would be to include the B-pin as well and use the logic functions OR,AND,XOR output to send back to the INx bit.
I think you can sniff any pin using an adjacent pin-cell and the close-by MUX feature, but of course that presumes you have a spare adjacent pin.
I think your suggestion does not consume another adjacent pin ?
If the space is otherwise spare, such direct read-back sounds like a good idea.
I've been working on smart pin reset behavior for all modes. This will eliminate glitches on normal-mode/smart-mode switchover. The USB smart pin circuit had this problem and I realized that the serial baud mode had the same potential. That's almost all fixed now, so I'll get a general update out in the next day, or two.
I believe that the smart pin is pretty much complete after this reset fix. There is room for four more modes, but I think I will fill them by just adding modes to the existing function blocks. Any simple suggestions? Maybe some time-this-signal-to-that-signal kind of functions? This would just entail adding a bit of steering logic to the existing measuring block, for example.
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)
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.
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?
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?
The FT2232H shows FSCTS signaling, for the 50MBd Fast Serial mode, and those speeds are where handshake is more likely to be required.
Ozpropdev did some test code for this mode, and managed 40MBd, but IIRC with no FSCTS polling, and using Sync mode, not async.
A more general case would need FSCTS polling, as the FT2232H has good buffers, but they are still finite.
I find this in the EFM8UB1 Data sheet, which is a sub $1 MCU with UART with HW flow control
21.3.3 Flow Control
The UART provides hardware flow control via the CTS and RTS pins. CTS and RTS may be individually enabled using the crossbar,
may be operated independently of one another, and are active only when enabled through the crossbar.
The CTS pin is an input to the device. When CTS is held high, the UART will finish any byte transfer that is currently in progress, and
then will halt before sending any more data. CTS must be returned low before data transfer will continue.
The RTS pin is an output from the device. When the receive buffer is full, RTS will toggle high. When data has been read from the
buffer and there is additional room available, RTS will be cleared low.
Notice there is no detail mention of turn-around tolerance on the RTS - for parts that do not leave extra room in the FIFO, the time between Rx -> Buffer and the Buffer 'please pause' signal needs to be actioned, can be quite short, - maybe half a bit time ?
( ie a Tx buffer is likely already filled by upstream SW, so hardware handshake is the only way to manage flow in timing like that - you want to pause the transfer from already filled buffer to shifter)
Also, has anyone written/tested a smart cell i2c driver yet?
i2c master should port almost anything from P1.
i2c slave would be more interesting, but using the new waitedge should give good code ?*
I'm not sure you can interrupt on START or STOP ?
If P2 has a CLK + Enable Counter feature on 2 pins, you could use that - set counter to -1 and wait on overflow.
Addit:* It could be a better Cell test, to try and use Length = 8 then 9 bits, and shifter HW, in both TX and RX modes, but I think that would benefit from data change mid-clk (rather than right at =\_ edge).
Here's a capture of a FT2232H transmission to PC @ 40MHz using 12 bits packet and a smartpin in sync tx mode.
Even though you can see the CTS signal I am not polling it.
Strangely my data makes it to the PC Ok. The captured image is actually the data being sent.
If I transmit packets of 11 bits the CTS signal is never seen by the P2 yet the data gets to PC Ok?
It would be nice to include the CTS in the process.
We currently poll INx for the smartpin to accept a new PINSETY command.
Maybe we could use PINACK somehow to pause/start the transmitter sending the next packet.
Here's a capture of a FT2232H transmission to PC @ 40MHz using 12 bits packet and a smartpin in sync tx mode.
Even though you can see the CTS signal I am not polling it.
If you add code to poll that, what does that do to the speed ?
Strangely my data makes it to the PC Ok. The captured image is actually the data being sent.
If I transmit packets of 11 bits the CTS signal is never seen by the P2 yet the data gets to PC Ok?
Do you mean at 11b frame lengths, the CTS never goes low, but the FT2232 otherwise transfers the data fine ?
Do you count the bytes received ? - there seems to be some preamble clocks consumed, which means an exact N*BL count would come up short ?
I still think this should work at 20 & 40MB/s also in Async Send mode, maybe Chip can comment ?
This test shows how nice it can be, to have full bit length control
Also, has anyone written/tested a smart cell i2c driver yet?
i2c master should port almost anything from P1.
i2c slave would be more interesting, but using the new waitedge should give good code ?
I'm not sure you can interrupt on START or STOP ?
If P2 has a CLK + Enable Counter feature on 2 pins, you could use that - set counter to -1 and wait on overflow.
True. Slave mode is more of what I was thinking about when I asked the question. Of course, I know this is one of those places where the bit rate is slow enough that this can all be handled in software, but it would be nice if a cog could more efficiently implement i2c by using the smart cells. I had noticed that the START and STOP states look a lot like quadrature transitions, but I didn't see a way to take advantage of that.
In the end, it might make more sense to simply set up a couple of pin edge interrupts and go with that. It wouldn't allow you to do any more than one i2c channel per cog, but at least the cog could sleep between edge events.
@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?
Thinking a little more about START/STOP conditions, I wonder if it would be worthwhile having a smart cell mode that simply reported when A or B changes. Here's the thought:
* When you set DIR to 1, %AB is shifted into Z.
* Each time A or B changes, the current %AB is shifted into Z and IN is set.
It also allows for the ability to use a single interrupt to implement an i2c slave.
You could probably also use this to help with arbitration when doing multi-master setups.
And you could implement a manual quadrature mode. It would be slower than the existing quadrature mode. But you could determine both absolute position and velocity at the same time.
...
And you could implement a manual quadrature mode. It would be slower than the existing quadrature mode. But you could determine both absolute position and velocity at the same time.
I think Chip has Quad Pos + Velocity covered already, by using 2 counters.
One is set to Quad mode, and the other ctr is set to Time-Interval. (any edge to any edge, self Zero ?)
Velocity would need a simple sanity check for edge-noise (Quad Counter ignores that, with a + then -).
It may be helpful to configure both ‘A’ and ‘B’ smart pins to quadrature mode, with one being continuous (X=0) for
absolute position tracking and the other periodic (x<>0) for velocity measurement
@jmg
I can't add polling to the my current code as I can't pause the transmitter.
Regarding the CTS signal, bit lengths from 11 to 14 bits never allow the CTS signal to go high again at 40MHz.
Bit lengths over 14 bits at 40MHz show CTS signalling as expected.
At all bit lengths (11-32) @ 40MHz, byte count and data validity are OK.
@jmg
I can't add polling to the my current code as I can't pause the transmitter.
Regarding the CTS signal, bit lengths from 11 to 14 bits never allow the CTS signal to go high again at 40MHz.
Interesting way they manage handshakes.
Shows how a real device always trumps the data sheet
Bit lengths over 14 bits at 40MHz show CTS signalling as expected.
I wonder if that changes at the 50MHz max spec ?
They seem to have quite some margin on that handshake.
It's a while since I coded for this mode in PLDs, but I recall 14 cycles, and likely that was because I used the handshake for pacing.
Sounds like anything that uses that line, will be 14 or more cycles per byte.
...
And you could implement a manual quadrature mode. It would be slower than the existing quadrature mode. But you could determine both absolute position and velocity at the same time.
I think Chip has Quad Pos + Velocity covered already, by using 2 counters.
One is set to Quad mode, and the other ctr is set to Time-Interval. (any edge to any edge, self Zero ?)
Velocity would need a simple sanity check for edge-noise (Quad Counter ignores that, with a + then -).
Don't get stuck on the quadrature bit! That was just to show the versatility of the mode. More generally, the 4 LSBs of Z could drive a 16-element lookup table. In essence, this brings back a simplified version of the state machine mode, which is ideal for something like i2c.
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.
Comments
Here's another thought. using the LSB in PINSETM just for set/ack seems like a waste. What if you were to get rid of it and shift the mode over by one? Then, increase the mode values by one (so that "normal" is %00001, DAC noise is %00010, etc.). With this, PINACK is now really mode %00000 (which you will, of course, test). Note that PINACK and disabling smart modes (PINSETM #1) are still the same. Only the other modes (except serial modes) would would be affected, index-wise. In return, you free up one more bit for another use. Not that you necessarily need a free bit, of course. But, as with the OE bit, I'm sure you can come up with a good use for it.
Quadrature would be 0,1,3,2... forward or 0,2,3,1... backward?
I'm certain that n-bit gray code encode and decode is just too much, but I have been surprised here before... I've lost track, maybe it's already there somewhere. Just a thought, doing it in hardware would be crazy fast.
It's usually an 8-bit data bus. Have to look up to see if Prop provides clock or it provides clock...
Remember that the input to an input-only function may be a neighboring pin, or even the local OUT bit. The pin tied to the smart pin input function may need to be a regular output, while its smart pin circuit does something else by reading another pin. Then, there's the matter of being able to test an input mode by manipulating it's output. So, there's occasion for an independent OE.
Not sure how much of that is in there ? I recall NCO Phase Init may not have been ?
That is not quite the same as a {Single Clock + 2 Bit State Engine with DIRN bit}, but it should cover most cases ?
Could you expand on what OE is actually controlling? From the above statements, it appears you are saying that
* the OE controls the pin associated with the cell, not the pin select by the A or B field?
* the a cell set to an input mode can be driven by its own OUT value, but only if OE is enabled?
That's right, in both cases.
This would allow the streamer to capture the smartpin output states.
Currently ths has to be done by hard wiring the smartpin output back to a regular IO pin.
Expanding on this mode a little further would be to include the B-pin as well and use the logic functions OR,AND,XOR output to send back to the INx bit.
Doh! Never mind. "Snoop" mode is already there!
I would really like to understand just how smart pins all hang together
I think you can sniff any pin using an adjacent pin-cell and the close-by MUX feature, but of course that presumes you have a spare adjacent pin.
I think your suggestion does not consume another adjacent pin ?
If the space is otherwise spare, such direct read-back sounds like a good idea.
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?
I had discovered some problems in the first release with the internal receiver clock. That's been all straightened out.
I'm getting together a general release now.
The FT2232H shows FSCTS signaling, for the 50MBd Fast Serial mode, and those speeds are where handshake is more likely to be required.
Ozpropdev did some test code for this mode, and managed 40MBd, but IIRC with no FSCTS polling, and using Sync mode, not async.
A more general case would need FSCTS polling, as the FT2232H has good buffers, but they are still finite.
I find this in the EFM8UB1 Data sheet, which is a sub $1 MCU with UART with HW flow control
21.3.3 Flow Control
The UART provides hardware flow control via the CTS and RTS pins. CTS and RTS may be individually enabled using the crossbar,
may be operated independently of one another, and are active only when enabled through the crossbar.
The CTS pin is an input to the device. When CTS is held high, the UART will finish any byte transfer that is currently in progress, and
then will halt before sending any more data. CTS must be returned low before data transfer will continue.
The RTS pin is an output from the device. When the receive buffer is full, RTS will toggle high. When data has been read from the
buffer and there is additional room available, RTS will be cleared low.
Notice there is no detail mention of turn-around tolerance on the RTS - for parts that do not leave extra room in the FIFO, the time between Rx -> Buffer and the Buffer 'please pause' signal needs to be actioned, can be quite short, - maybe half a bit time ?
( ie a Tx buffer is likely already filled by upstream SW, so hardware handshake is the only way to manage flow in timing like that - you want to pause the transfer from already filled buffer to shifter)
Wish I had time to learn USB...
i2c slave would be more interesting, but using the new waitedge should give good code ?*
I'm not sure you can interrupt on START or STOP ?
If P2 has a CLK + Enable Counter feature on 2 pins, you could use that - set counter to -1 and wait on overflow.
Addit:* It could be a better Cell test, to try and use Length = 8 then 9 bits, and shifter HW, in both TX and RX modes, but I think that would benefit from data change mid-clk (rather than right at =\_ edge).
Even though you can see the CTS signal I am not polling it.
Strangely my data makes it to the PC Ok. The captured image is actually the data being sent.
If I transmit packets of 11 bits the CTS signal is never seen by the P2 yet the data gets to PC Ok?
It would be nice to include the CTS in the process.
We currently poll INx for the smartpin to accept a new PINSETY command.
Maybe we could use PINACK somehow to pause/start the transmitter sending the next packet.
If you add code to poll that, what does that do to the speed ?
Do you mean at 11b frame lengths, the CTS never goes low, but the FT2232 otherwise transfers the data fine ?
Do you count the bytes received ? - there seems to be some preamble clocks consumed, which means an exact N*BL count would come up short ?
I still think this should work at 20 & 40MB/s also in Async Send mode, maybe Chip can comment ?
This test shows how nice it can be, to have full bit length control
True. Slave mode is more of what I was thinking about when I asked the question. Of course, I know this is one of those places where the bit rate is slow enough that this can all be handled in software, but it would be nice if a cog could more efficiently implement i2c by using the smart cells. I had noticed that the START and STOP states look a lot like quadrature transitions, but I didn't see a way to take advantage of that.
In the end, it might make more sense to simply set up a couple of pin edge interrupts and go with that. It wouldn't allow you to do any more than one i2c channel per cog, but at least the cog could sleep between edge events.
* When you set DIR to 1, %AB is shifted into Z.
* Each time A or B changes, the current %AB is shifted into Z and IN is set.
It also allows for the ability to use a single interrupt to implement an i2c slave.
You could probably also use this to help with arbitration when doing multi-master setups.
And you could implement a manual quadrature mode. It would be slower than the existing quadrature mode. But you could determine both absolute position and velocity at the same time.
One is set to Quad mode, and the other ctr is set to Time-Interval. (any edge to any edge, self Zero ?)
Velocity would need a simple sanity check for edge-noise (Quad Counter ignores that, with a + then -).
I can't add polling to the my current code as I can't pause the transmitter.
Regarding the CTS signal, bit lengths from 11 to 14 bits never allow the CTS signal to go high again at 40MHz.
Bit lengths over 14 bits at 40MHz show CTS signalling as expected.
At all bit lengths (11-32) @ 40MHz, byte count and data validity are OK.
Shows how a real device always trumps the data sheet
I wonder if that changes at the 50MHz max spec ?
They seem to have quite some margin on that handshake.
It's a while since I coded for this mode in PLDs, but I recall 14 cycles, and likely that was because I used the handshake for pacing.
Sounds like anything that uses that line, will be 14 or more cycles per byte.
Interesting, do you have a small adder, so the clock runs to the end of last data byte?
Did you try things to trigger longer handshakes. Slower PC read ?
eg maybe set to 14 or higher, and check for longer than the min-low time ?
Don't get stuck on the quadrature bit! That was just to show the versatility of the mode. More generally, the 4 LSBs of Z could drive a 16-element lookup table. In essence, this brings back a simplified version of the state machine mode, which is ideal for something like i2c.
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.