I... it handles both synchronous (SPI/I2C, MSB first) and asynchronous (baud rate, LSB first).
Can the user specify MSB/LSB ? - SPI often gives that choice.
What Baud rate control is there ?
What Bit-length range is supported ?
Is Dual/Quad SPI supported ?
By integrating what were four separate blocks (async tx, async rx, sync tx, sync rx) into one,
So this needs config twice of 2 Pin-Cells for a two way link ?
It seems to allow different Tx and Rx baud rates ? (Some MCUs offer that, but I've never really used it... )
I have done designs with skewed Rx/Tx counts, in extreme cases those used PLDs - this sounds like you could have one Rx and 63 Tx (or 63 Rx, 1 Tx) ? Wow.
SPI usually rotates one shift register, with a common clock, but I guess if a separate Rx 'clips onto' the Tx clock, that would work the same way ?
I'm getting a little closer to having the smart pins done. For that last several days, getting the serial transceiver worked out has been very challenging, as it's all wrapped up in one tight ball to save logic, and it handles both synchronous (SPI/I2C, MSB first) and asynchronous (baud rate, LSB first). By integrating what were four separate blocks (async tx, async rx, sync tx, sync rx) into one, the logic shrank by 20%, which is significant, since this could be replicated 64 times. I'll see what other functions could be melded soon. Anyway, still moving forward.
I... it handles both synchronous (SPI/I2C, MSB first) and asynchronous (baud rate, LSB first).
Can the user specify MSB/LSB ? - SPI often gives that choice.
What Baud rate control is there ?
What Bit-length range is supported ?
Is Dual/Quad SPI supported ?
By integrating what were four separate blocks (async tx, async rx, sync tx, sync rx) into one,
So this needs config twice of 2 Pin-Cells for a two way link ?
It seems to allow different Tx and Rx baud rates ? (Some MCUs offer that, but I've never really used it... )
I have done designs with skewed Rx/Tx counts, in extreme cases those used PLDs - this sounds like you could have one Rx and 63 Tx (or 63 Rx, 1 Tx) ? Wow.
SPI usually rotates one shift register, with a common clock, but I guess if a separate Rx 'clips onto' the Tx clock, that would work the same way ?
Right now, asynchronous serial is fixed to LSB-first and synchronous serial (SPI/I2C) is fixed to MSB-first. From everything I've seen, all SPI and I2C use MSB-first shifting. I'd like to keep it simple, if it's reasonable to do so.
For asynchronous serial, the baud rate is set by a 16-bit word, where $0001 = every clock, $0002 = every 2nd clock, $0003 = every third clock, etc.
Just 8 and 32 bits are supported for all modes.
Neither dual nor quad SPI is supported. At this time, two pins are the maximum with which activity can be coordinated.
For synchronous serial, the adjacent pin supplies the clock input. There is a transition mode that outputs N transitions at X clocks per. You'd set up the adjacent pin to output the clock using this mode.
Chip,
For synchronous, can the clock be input in the adjacent pin as an alternative?
Are we able to read the input shift register at any time? What I am thinking is where you might want to use sync or async and want to read a variable number of bits and start this in software and delay a specific time and then read what has been accumulated.
Right now, asynchronous serial is fixed to LSB-first and synchronous serial (SPI/I2C) is fixed to MSB-first. From everything I've seen, all SPI and I2C use MSB-first shifting. I'd like to keep it simple, if it's reasonable to do so.
It's quite a widespread problem, mainly on SPI -That's why many MCUs allow users to define this.
For asynchronous serial, the baud rate is set by a 16-bit word, where $0001 = every clock, $0002 = every 2nd clock, $0003 = every third clock, etc.
The Sync SPI clock control is the same ?
Being able to Tx right up to SysCLK/1 is generally useful, but for Async RX and SPI slave, there usually is some additional lower limit given by sampling.
AsYnc RX to Clk/4, Clk/6 are common practical max, and SPI Slave f Clk/4 is common, tho some impost Clk/10, which is more of a pain.
16b granularity is good, but does push up the lower baud limit, ie 160MHz does not quite hit 2400bd - are there any other prescalers ?
There must be a bit-counter and shifter for 32b, so making that count user-definable adds nothing to the main data flow paths (but it does add just 4 more config bits)
There are 16b SPI parts, and also 24b SPI for i2s, plus PC UARTS can support 5,6,7,8 bits with Parity and variable Stop. 9 bit UART is common is small MCU.
User define of Serial Length, gives a simple way to cover all of that - if someone needs 8b + Parity + 2 stop, they select 10b Length, and the existing 1 Start and 1 Stop augment with Parity and 10th bit set high for extra stop.
This also allows simple any-choice of Stop bits, for system that need hard timing.
Are we able to read the input shift register at any time? What I am thinking is where you might want to use sync or async and want to read a variable number of bits and start this in software and delay a specific time and then read what has been accumulated.
If you are doing that, you probably want to also read a Bit-Counter.
I've seen MCUs expose the live Bit-Count to users, which covers your use case, and also is useful in SLAVE SPI, where the lack of framing in SPI is a real noise risk.
A readable BIT COUNT, means you can check for <> MOD 8 Rx bits, which signals a likely clock glitch and bad data.
That detail may be a little beyond smart pins, but a single flag that confirms RxBits = Set value might be doable ?
jmg,
I am quite happy to time these bits and/or multiple bits in software.
IMHO, All that we really need is a serialiser/deserialiser that just accumulates the bits into a 32 bit shift register that can either be started either by
(1) a low edge (because we can invert the input pin to get high going)
(2) by software
Then we need to be able to read the shift register
(1) without altering the shift register contents
(2) with clearing the shift register
(3) option to stop the reading
For clocking this shift register, we need to select the clock from
(1) an external pin (adjacent pin pair is fine)
(2) internally generated by the counters
We need to be able to tell the input shifting to start on
(1) external clock: next and subsequent low going edge (can be inverted at the pin)
(2) internal clock: software control -
(2a) next 1/2 clock and then each full clock (useful for software starting and shifting in on centre of bit time)
(2b) next clock and each following clock
(2c) next 1 1/2 clock and then each full clock (doesn't shift in the start bit)
(3) internal clock: hardware control -
(3a) start clock on next input going low, sample on next 1/2 clock and then each full clock
(3b) start clock on next input going low, and sample on next and each full clock
(3c) start clock on next input going low, and begin sampling in 1 1/2 clocks time, then each clock (this doesn't shift in the start bit)
(4) software clock (ie no clock): sample next bit now (software is performing clock using the hardware to shift the data into the register)
We can AND the number of required bits by software and/or test the stop bit in software.
This handles receiving I think.
The internal clock for baud generation needs to be better than divide by powers of 2. This was the old problem of requiring baud to be a sub multiple of the xtal. We need a competitor to reset the counter when a value is reached IMHO.
If an interrupt can be generated at 8 (may need to include start and stop bits?) and 32 bits that might also be useful, else perhaps a waitsmartpins instruction ???
Transmitting would be similar but in reverse. We could add start and stop bits by software, or the smart pins could be told to add them.
BTW at one stage we were thinking of adding CRC to the mix too.
The internal clock for baud generation needs to be better than divide by powers of 2. This was the old problem of requiring baud to be a sub multiple of the xtal.
?
Yes, I think Chip was already talking about a 16b value, not just 2^N, so you do get full granularity now.
ie Any value under 1.6MBd will have under 1% granularity, from SysCLK of 160MHz.
Then we need to be able to read the shift register
(1) without altering the shift register contents
(2) with clearing the shift register
(3) option to stop the reading
That may be possible, it depends on how chip has the interface mapped, but I think the access to Smart Pin cells is not parallel high speed real time, but serial.
That means single-cycle granularity peek on snooping, is not really looking practical.
Things are really coming together on getting the smart pins compacted. I found a lot of commonality between what were four separate blocks and they are melding into one very nicely.
Things are really coming together on getting the smart pins compacted. I found a lot of commonality between what were four separate blocks and they are melding into one very nicely.
Things are really coming together on getting the smart pins compacted. I found a lot of commonality between what were four separate blocks and they are melding into one very nicely.
Great. Did you manage to fit
User config of MSB/LSB order
User config of 1 thru 32 bits shifted
.. and ideally....
True Frequency Counter support ?
Could use 2 adjacent pin-cells.
Things are really coming together on getting the smart pins compacted. I found a lot of commonality between what were four separate blocks and they are melding into one very nicely.
Great. Did you manage to fit
User config of MSB/LSB order
User config of 1 thru 32 bits shifted
.. and ideally....
True Frequency Counter support ?
Could use 2 adjacent pin-cells.
None of that, yet. Once we get an initial release out, we'll spice it up.
There are a total of four disparate blocks which mux to three 32-bit registers and one 8-bit register:
1) signal timer
2) clock/NCO/PWM/DAC
3) periodic/continuous measurement
4) sync/async serial
... does the following:
- clock output with 16-bit prescaler and 32-bit transition count
- 32-bit NCO/duty with 16-bit prescaler
- 16-bit sawtooth/triangle PWM with 16-bit prescaler
- DAC dither/pwm/cog/noise output with ADC tracking, 16-bit period
Choice of NCO and Jitter-free is good.
Do you have formula/granularity on those ?
ie is the 16b prescaler /(1..65536) or /2^N,
I presume the 32b transition count is a 32b reload value ?
The PWM period is user-controlled, (1..65536) not fixed to 16b ?
Do the PWM Period & Setpoints update @ Ctr=0 ?
Still testing the smartpins. Everything looks good. They are like magic! Combined with the analog features of the full-custom pin circuit, they will be rather unique, I think.
I need to come up with some assembly mnemonics that really pop, so the pin commands won't get lost in the source code. I mean, they configure and deal with whole subsystems, so they should stand out a little.
I went to the USPTO, for fun, to check trademarks and some company in Finland called BIONX has the single active 'smartpin' trademark, among many dead ones. This got me thinking about other names, not that a trademark is desired or remotely necessary.
We have a 'propeller' chip that uses a propeller beanie cap for its logo, so why not keep it fun, instead of some nouveau-Italian-sounding name, like everyone seems to want? How about calling smart pins 'pinheads'? I thought about 'pinbrain', but that maybe promises too much. 'Pinhead' is a little comical and sets up realistic expectations, I think. "Only the Parallax Propeller has Pinheads." Anybody could remember that name, but nobody would want to copy it. Alas, nobody may notice!
There are a total of four disparate blocks which mux to three 32-bit registers and one 8-bit register:
1) signal timer
2) clock/NCO/PWM/DAC
3) periodic/continuous measurement
4) sync/async serial
... does the following:
- clock output with 16-bit prescaler and 32-bit transition count
- 32-bit NCO/duty with 16-bit prescaler
- 16-bit sawtooth/triangle PWM with 16-bit prescaler
- DAC dither/pwm/cog/noise output with ADC tracking, 16-bit period
Choice of NCO and Jitter-free is good.
Do you have formula/granularity on those ?
ie is the 16b prescaler /(1..65536) or /2^N,
I presume the 32b transition count is a 32b reload value ?
The PWM period is user-controlled, (1..65536) not fixed to 16b ?
Do the PWM Period & Setpoints update @ Ctr=0 ?
What capture capabilities are in there ?
The 16-bit prescaler is 1..65535 clocks, with 0 being 65536. So, it's linear, not 2^n, or something.
Yes, the transition count is a reload value. You give it a value, it does it, then signals it's done via the IN bit, so the interrupt system can trap the event.
The PWM uses the 16-bit prescaler, and then has a same-resolution scheme for setting up the PWM frame size. The PWM cycles from frame size down to 1, and then from 1 back up to frame size in the case of triangle mode. The output is high when the sample value is >= frame position. This way, 0 always outputs a low and frame size always outputs a high. Output samples are double-buffered and loaded at the start of each new frame.
Capturing is for states and rise-to-rise, as well as pin <> adjacent pin. For states and pin mismatch capturing, the MSB of the 32-bit return value holds the state or mismatch, while the 31 LSBs hold the count. It can capture 1-clock events, but in such cases, the prior measurement will be quickly lost, and you'll only get the more recent one. You'd better have a low duty cycle for 1-clock event capturing. Hmmm... is there any value in simply capturing a time stamp on an edge? We've got a single 32-bit return value to work with.
In measuring modes, a measurement can be taken for some fixed number of clocks, or allowed to accumulate from smart pin reset (DIR=0), which would be good for the rotary encoder mode. Data returning from the smart pins are correlated to the system counter (CT), so that on every %...000 to %...111 CT sequence, a framed long is sent at four bits per clock. This makes sure you don't get part of an old reading and part of a new one. Of course, the cog has to wait for the start nibble, which could be 7 clocks away, initially.
We have a 'propeller' chip that uses a propeller beanie cap for its logo, so why not keep it fun, instead of some nouveau-Italian-sounding name, like everyone seems to want? How about calling smart pins 'pinheads'? I thought about 'pinbrain', but that maybe promises too much. 'Pinhead' is a little comical and sets up realistic expectations, I think. "Only the Parallax Propeller has Pinheads." Anybody could remember that name, but nobody would want to copy it. Alas, nobody may notice!
Seems a bit playground bullyish a name does Pinhead. Maybe that's just a British perspective.
You did make me think though.... you have the Propeller Multi-Core, so why not a Multi-Pin. The trademark for MultiPin has been long abandoned.
There's probably lots of combinations involving Pin, Gate and Smart, etc.. SmartGate perhaps. Having pin in the name seems simpler though - self descriptive.
Hmmm... is there any value in simply capturing a time stamp on an edge? We've got a single 32-bit return value to work with.
Most certainly YES. Say you want to build a high resolution logic probe.
Or with an edge time stamp, you could conceivably manipulate a timer to give a deterministic response without losing processing cycles to the wait instructions.
Or this problem I'm sorting out on P1 right now. I want to synchronize with some unknown rate asynchronous serial bit pattern without losing any data, I will record the times in a circular buffer and sort the speed and data out when enough samples have been collected. With the time stamp capture ability this could apply to a very high speed burst of data as well as easier to implement.
Comments
Can the user specify MSB/LSB ? - SPI often gives that choice.
What Baud rate control is there ?
What Bit-length range is supported ?
Is Dual/Quad SPI supported ?
So this needs config twice of 2 Pin-Cells for a two way link ?
It seems to allow different Tx and Rx baud rates ? (Some MCUs offer that, but I've never really used it... )
I have done designs with skewed Rx/Tx counts, in extreme cases those used PLDs - this sounds like you could have one Rx and 63 Tx (or 63 Rx, 1 Tx) ? Wow.
SPI usually rotates one shift register, with a common clock, but I guess if a separate Rx 'clips onto' the Tx clock, that would work the same way ?
That's a significant saving!
I keep thinking about a new game show... "Are You Smarter than a Pin?"
My only prayer is that you post a simple I2C example... with emphasis on "simple."
Right now, asynchronous serial is fixed to LSB-first and synchronous serial (SPI/I2C) is fixed to MSB-first. From everything I've seen, all SPI and I2C use MSB-first shifting. I'd like to keep it simple, if it's reasonable to do so.
For asynchronous serial, the baud rate is set by a 16-bit word, where $0001 = every clock, $0002 = every 2nd clock, $0003 = every third clock, etc.
Just 8 and 32 bits are supported for all modes.
Neither dual nor quad SPI is supported. At this time, two pins are the maximum with which activity can be coordinated.
For synchronous serial, the adjacent pin supplies the clock input. There is a transition mode that outputs N transitions at X clocks per. You'd set up the adjacent pin to output the clock using this mode.
For synchronous, can the clock be input in the adjacent pin as an alternative?
Are we able to read the input shift register at any time? What I am thinking is where you might want to use sync or async and want to read a variable number of bits and start this in software and delay a specific time and then read what has been accumulated.
Google of SPI code reverse bits gives 570,000 hits, and this discussion shows common issues :
https://developer.mbed.org/forum/mbed/topic/2170/
Since the MSB/LSB control flag has to be there now, fixing this just exposes it to the user to change ?
The Sync SPI clock control is the same ?
Being able to Tx right up to SysCLK/1 is generally useful, but for Async RX and SPI slave, there usually is some additional lower limit given by sampling.
AsYnc RX to Clk/4, Clk/6 are common practical max, and SPI Slave f Clk/4 is common, tho some impost Clk/10, which is more of a pain.
16b granularity is good, but does push up the lower baud limit, ie 160MHz does not quite hit 2400bd - are there any other prescalers ?
Hmm...That's the most serious limitation there.
There must be a bit-counter and shifter for 32b, so making that count user-definable adds nothing to the main data flow paths (but it does add just 4 more config bits)
There are 16b SPI parts, and also 24b SPI for i2s, plus PC UARTS can support 5,6,7,8 bits with Parity and variable Stop. 9 bit UART is common is small MCU.
User define of Serial Length, gives a simple way to cover all of that - if someone needs 8b + Parity + 2 stop, they select 10b Length, and the existing 1 Start and 1 Stop augment with Parity and 10th bit set high for extra stop.
This also allows simple any-choice of Stop bits, for system that need hard timing.
All this is x32 or x64. Best to put the hardware assist where it does real good, IMHO.
I've seen MCUs expose the live Bit-Count to users, which covers your use case, and also is useful in SLAVE SPI, where the lack of framing in SPI is a real noise risk.
A readable BIT COUNT, means you can check for <> MOD 8 Rx bits, which signals a likely clock glitch and bad data.
That detail may be a little beyond smart pins, but a single flag that confirms RxBits = Set value might be doable ?
I am quite happy to time these bits and/or multiple bits in software.
IMHO, All that we really need is a serialiser/deserialiser that just accumulates the bits into a 32 bit shift register that can either be started either by
(1) a low edge (because we can invert the input pin to get high going)
(2) by software
Then we need to be able to read the shift register
(1) without altering the shift register contents
(2) with clearing the shift register
(3) option to stop the reading
For clocking this shift register, we need to select the clock from
(1) an external pin (adjacent pin pair is fine)
(2) internally generated by the counters
We need to be able to tell the input shifting to start on
(1) external clock: next and subsequent low going edge (can be inverted at the pin)
(2) internal clock: software control -
(2a) next 1/2 clock and then each full clock (useful for software starting and shifting in on centre of bit time)
(2b) next clock and each following clock
(2c) next 1 1/2 clock and then each full clock (doesn't shift in the start bit)
(3) internal clock: hardware control -
(3a) start clock on next input going low, sample on next 1/2 clock and then each full clock
(3b) start clock on next input going low, and sample on next and each full clock
(3c) start clock on next input going low, and begin sampling in 1 1/2 clocks time, then each clock (this doesn't shift in the start bit)
(4) software clock (ie no clock): sample next bit now (software is performing clock using the hardware to shift the data into the register)
We can AND the number of required bits by software and/or test the stop bit in software.
This handles receiving I think.
The internal clock for baud generation needs to be better than divide by powers of 2. This was the old problem of requiring baud to be a sub multiple of the xtal. We need a competitor to reset the counter when a value is reached IMHO.
If an interrupt can be generated at 8 (may need to include start and stop bits?) and 32 bits that might also be useful, else perhaps a waitsmartpins instruction ???
Transmitting would be similar but in reverse. We could add start and stop bits by software, or the smart pins could be told to add them.
BTW at one stage we were thinking of adding CRC to the mix too.
PS sorry, typed on my iPhone.
Yes, I think Chip was already talking about a 16b value, not just 2^N, so you do get full granularity now.
ie Any value under 1.6MBd will have under 1% granularity, from SysCLK of 160MHz.
That may be possible, it depends on how chip has the interface mapped, but I think the access to Smart Pin cells is not parallel high speed real time, but serial.
That means single-cycle granularity peek on snooping, is not really looking practical.
Great. Did you manage to fit
User config of MSB/LSB order
User config of 1 thru 32 bits shifted
.. and ideally....
True Frequency Counter support ?
Could use 2 adjacent pin-cells.
None of that, yet. Once we get an initial release out, we'll spice it up.
http://forums.parallax.com/discussion/comment/1361262/#Comment_1361262
Tonight I tested and finished a complex block which does the following:
- clock output with 16-bit prescaler and 32-bit transition count
- 32-bit NCO/duty with 16-bit prescaler
- 16-bit sawtooth/triangle PWM with 16-bit prescaler
- DAC dither/pwm/cog/noise output with ADC tracking, 16-bit period
It turned out that all those functions had a lot of similarities, so they all went into one block.
There are a total of four disparate blocks which mux to three 32-bit registers and one 8-bit register:
1) signal timer
2) clock/NCO/PWM/DAC
3) periodic/continuous measurement
4) sync/async serial
It's down from 500 ALM's to 400 now, per pin. I don't think there's anything to squeeze, anymore, but I'll try.
Tomorrow I'm going to test the measurement and timer blocks and make sure everything is tidy.
In a few more days, I'll have an FPGA update.
Choice of NCO and Jitter-free is good.
Do you have formula/granularity on those ?
ie is the 16b prescaler /(1..65536) or /2^N,
I presume the 32b transition count is a 32b reload value ?
The PWM period is user-controlled, (1..65536) not fixed to 16b ?
Do the PWM Period & Setpoints update @ Ctr=0 ?
What capture capabilities are in there ?
I take it ADC is part of "continuous/periodic measurement"?
I need to come up with some assembly mnemonics that really pop, so the pin commands won't get lost in the source code. I mean, they configure and deal with whole subsystems, so they should stand out a little.
I went to the USPTO, for fun, to check trademarks and some company in Finland called BIONX has the single active 'smartpin' trademark, among many dead ones. This got me thinking about other names, not that a trademark is desired or remotely necessary.
We have a 'propeller' chip that uses a propeller beanie cap for its logo, so why not keep it fun, instead of some nouveau-Italian-sounding name, like everyone seems to want? How about calling smart pins 'pinheads'? I thought about 'pinbrain', but that maybe promises too much. 'Pinhead' is a little comical and sets up realistic expectations, I think. "Only the Parallax Propeller has Pinheads." Anybody could remember that name, but nobody would want to copy it. Alas, nobody may notice!
The 16-bit prescaler is 1..65535 clocks, with 0 being 65536. So, it's linear, not 2^n, or something.
Yes, the transition count is a reload value. You give it a value, it does it, then signals it's done via the IN bit, so the interrupt system can trap the event.
The PWM uses the 16-bit prescaler, and then has a same-resolution scheme for setting up the PWM frame size. The PWM cycles from frame size down to 1, and then from 1 back up to frame size in the case of triangle mode. The output is high when the sample value is >= frame position. This way, 0 always outputs a low and frame size always outputs a high. Output samples are double-buffered and loaded at the start of each new frame.
Capturing is for states and rise-to-rise, as well as pin <> adjacent pin. For states and pin mismatch capturing, the MSB of the 32-bit return value holds the state or mismatch, while the 31 LSBs hold the count. It can capture 1-clock events, but in such cases, the prior measurement will be quickly lost, and you'll only get the more recent one. You'd better have a low duty cycle for 1-clock event capturing. Hmmm... is there any value in simply capturing a time stamp on an edge? We've got a single 32-bit return value to work with.
In measuring modes, a measurement can be taken for some fixed number of clocks, or allowed to accumulate from smart pin reset (DIR=0), which would be good for the rotary encoder mode. Data returning from the smart pins are correlated to the system counter (CT), so that on every %...000 to %...111 CT sequence, a framed long is sent at four bits per clock. This makes sure you don't get part of an old reading and part of a new one. Of course, the cog has to wait for the start nibble, which could be 7 clocks away, initially.
Seems a bit playground bullyish a name does Pinhead. Maybe that's just a British perspective.
You did make me think though.... you have the Propeller Multi-Core, so why not a Multi-Pin. The trademark for MultiPin has been long abandoned.
There's probably lots of combinations involving Pin, Gate and Smart, etc.. SmartGate perhaps. Having pin in the name seems simpler though - self descriptive.
ProPort
SmartPort
MultiPort
ProPin (geddit? Prop-in!)
Mary Proppins!
or
Merry Prop-pins
Pinhead does have a slight schoolyard bully tone, but these pins don't quite have brains.
PBrain.
Most certainly YES. Say you want to build a high resolution logic probe.
Or with an edge time stamp, you could conceivably manipulate a timer to give a deterministic response without losing processing cycles to the wait instructions.
Or this problem I'm sorting out on P1 right now. I want to synchronize with some unknown rate asynchronous serial bit pattern without losing any data, I will record the times in a circular buffer and sort the speed and data out when enough samples have been collected. With the time stamp capture ability this could apply to a very high speed burst of data as well as easier to implement.
Goes well with cog, supports the cog, drives pins.
Sort of a play on minion, the cogs have minions that drive pins, so they are pinions.
Regardless of the name these are shaping up very nicely.
C.W.