It seems like calling the pins cores is a bad idea. While they are configurable they aren't really programmable are they?
Good point. SiLabs and Microchip are adding what they call 'Configurable Logic Units', which can do simple 3-wire logic plus an optional FlipFlop.
P2 could use that existing terminology, and expand the Smart Pin as being 'a Configurable Pin Unit with 32b Counter/Timer/Shifting capability at the pin'
Each smart pin has three 32-bit registers: X, Y, and Z (result). There is also a single flag bit result which can be written to C. That gives some indication of the smart pins' complexity.
Each smart pin has three 32-bit registers: X, Y, and Z (result). There is also a single flag bit result which can be written to C. That gives some indication of the smart pins' complexity.
Cool! Let's see if Peter can write a Forth interpreter to run in a smart pin!
Each smart pin has three 32-bit registers: X, Y, and Z (result). There is also a single flag bit result which can be written to C. That gives some indication of the smart pins' complexity.
Those are the 'visible' registers. There are also Shifters/Counters 'hidden' behind those too I think ?
One of the best ways to document peripherals I've seen, is by equations.
Yes, this is coming back to where Peter asked how to make the Prop2 fit into search criteria of the component suppliers. The Prop1 can do much but only as soft peripherals. This means it is not listed in the searches.
Each smart pin has three 32-bit registers: X, Y, and Z (result). There is also a single flag bit result which can be written to C..
No idea what that means. I’d rather see
Each smart pin has built in standalone functions:
PWM
Counters
Quadrature encoder
Etc
There are really three places where you place data sheet expansions
The first, is in the Features overview, where a single line is common , such as
Features:
64 x Smart Pins : Configurable Pin Units with 32b Counter/Timer/Shifting capability at the pin
Then in the Smart Pin section you can say more
64 x Smart Pins : Configurable Pin Units with 32b Counter/Timer/Shifting capability at the pin
Each smart pin unit can be configured for one of built in standalone functions, and attach to one of 4? nearby pins :
1..32b PWM
32b Counters/Timers
32b Quadrature encoder
1..32b Shifter, UART and SPI
32b Timing capture. Pulse Width, Period, ..?
Two Pin units can combine for high precision/dynamic range Reciprocal Frequency Counting
...
and then the register/ user interface section can have the register details Smart Pin Configurable Pin Unit Software interface:
Each smart pin has three 32-bit registers: X, Y, and Z (result). There is also a single flag bit result which can be written to C..
and here small, working code snippets will be clearest.
What's the purpose of the X, Y and Z registers? Are they independent of the PWM, Counters/Timers and other peripherals, or are they used to implement those features?
What's the purpose of the X, Y and Z registers? Are they independent of the PWM, Counters/Timers and other peripherals, or are they used to implement those features?
They are the data passing registers of each Smartpin for operation and access. There's also the unlabelled mode register, so four registers in each Smartpin.
X and Y, both write only, are the dynamically adjustable parameters. Z, read only, is usually an accumulator of sorts and forms a result when read.
The way smart pins work is by mux'ing the selected logic to the three 32-bit registers and pin signals. There is also a 16-bit set of registers that is involved in this.
Here's an example of transmitting UART data. I hope the comments help out with the curly details.
' Setup a pin to be used as a UART transmitter.
' Only has to be done once per power up if not being repurposed later on.
' %01 is to enable driving of the physical pin.
' %11110 configures the Smartpin to asynchronous transmit mode.
dirl #tx_pin 'force Z to zero. Smartpins don't really stop operating
wrpin #%01_11110_0, #tx_pin 'set to async tx mode
wxpin asynpar, #tx_pin 'set X with baudrate and framing config
dirh #tx_pin 'release Z from zero
...
' Now transmit a byte (code is from used debug routines)
putch
rqpin temp1, #tx_pin wc 'transmiting? (read Z to see if actively shifting out)
testp #tx_pin wz 'buffer free? (IN state shows Y buffer full status)
if_nz_and_c jmp #putch 'wait while Smartpin is both full (nz) and transmitting (c)
_ret_ wypin char, #tx_pin 'write new byte to Y buffer
asynpar long (clock_freq * 8 / (baud_rate / 8) * 1024) | 7 '8N1 framing, (* 1024 is to left shift the baudrate by 10 bits so both the baud and framing bits sit in the same word)
OK, so the X, Y and Z registers are used to control the various configurable features of the smart pins. I don't understand why they need to be highlighted as features of the P2. They're just configuration and I/O registers. They are no different than the registers you would see in a USART chip, ADC/DAC or a DMA. The beauty of the smart pins is that all these features are combined into a dedicated chunk of logic for each pin.
Chip,
I can't quite remember the detail but there is a reason why I had to also check transmitting status in the putch routine rather than just buffer status. It's a first use problem where initial Smartpin config leaves the buffer-full flag set to wrong state.
I noted Cluso's solution was to always to send a null character out at init time.
It was something I didn't get my head around until quite late due to happily using bit-bashing for debug code. At the time I did solve it I thought the Prop2 was set in stone. I'd forgotten about this niggle when you actually were finalising it.
OK, so the X, Y and Z registers are used to control the various configurable features of the smart pins. I don't understand why they need to be highlighted as features of the P2. They're just configuration and I/O registers. They are no different than the registers you would see in a USART chip, ADC/DAC or a DMA. The beauty of the smart pins is that all these features are combined into a dedicated chunk of logic for each pin.
Correct. Not a detail for datasheets nor brochures.
OK, so the X, Y and Z registers are used to control the various configurable features of the smart pins. I don't understand why they need to be highlighted as features of the P2. They're just configuration and I/O registers. They are no different than the registers you would see in a USART chip, ADC/DAC or a DMA. The beauty of the smart pins is that all these features are combined into a dedicated chunk of logic for each pin.
There are special instructions for manipulating these smartpin registers directly as they are not memory mapped like other kinds of registers. So the smartpins are not just lumped onto the P2 CPU, they are part of it. If I try to even just configure a peripheral in an ARM, it is a whole block of code to address the I/O base and load and store the configurations in all the different peripheral registers. That is, after I've spent a day reading the 16 pages just on that tiny part of the peripheral. P2 smartpins are tightly integrated with the P2 architecture, they are not a bolt-on cell that's mapped into it afterwards.
What I'd like to get across also is the fact that each one of these peripherals is not only independent and self-contained, but they are all equally accessible by any core, and that any pin can be assigned any of these functions independently without affecting any other pin. This is unheard of in the microcontroller world where a pin can have this or that peripheral signal but then this other pin must be this or that, and now you have lost this and that function, and so that's it.
The P2 and it's tightly integrated smartpins are like 64 independent configurable peripherals. I like to refer to the P2 smartpins as dedicated configurable peripheral per pin I/O but you have to be careful saying that to people, it could blow their minds.
Actually, my original comment was based on misreading jmg's post. I thought he was highlighting the X, Y and Z registers under the list of features. After re-reading his comment I see that he was stating the opposite, and the description of the X, Y and Z registers should be put in an area of the spec that provides the details of operation.
What I'd like to get across also is the fact that each one of these peripherals is not only independent and self-contained, but they are all equally accessible by any core, and that any pin can be assigned any of these functions independently without affecting any other pin. This is unheard of in the microcontroller world where a pin can have this or that peripheral signal but then this other pin must be this or that, and now you have lost this and that function, and so that's it.
The P2 and it's tightly integrated smartpins are like 64 independent configurable peripherals. I like to refer to the P2 smartpins as dedicated configurable peripheral per pin I/O but you have to be careful saying that to people, it could blow their minds.
...and this is EXACTLY why I suggest referring to them as CORES.
The word CORES will grab peoples attention.
8 Microprocessor CORES with 64 Smart Pin CORES
(or Peripheral CORES, or whatever...)
People NEED to have their minds blown a bit to entice them to investigate the P2. The description is accurate and people will see that (unlike many other marketing campaigns). There are no false alarms here.
CPLB - Configurable Peripheral Logic Block - it sounds enough like CPLD that people think of configurable logic but with the emphasis on Peripheral. But while it may be a "block" it really is dedicated to a single pin so CPLP doesn't roll off the tongue as well but CPLB port/pin may? If the description of a smartpin could be encapsulated into an easy to remember and apt acronym, it would make it a lot easier to get the idea across.
@thej - cores almost always evokes the thought of CPU cores, so it probably isn't a good idea to use this term.
...
It's a first use problem where initial Smartpin config leaves the buffer-full flag set to wrong state.
I noted Cluso's solution was to always to send a null character out at init time.
Chip,
This needs to be noted for fix if any hardware revisions happen.
I could have changed this a month ago, as I did look into it. It seemed to me, though, that there was no better way to do it. I know it doesn't look good.
Comments
64 "Peripheral Cores"
Jason
It will also draw attention when people read; "8 Processor Cores and 64 Peripheral Cores".
I think this really does tell the story of what the P2 is in one sentence and draws them in to find out what the "Peripheral Cores" can do.
Jason
Good point. SiLabs and Microchip are adding what they call 'Configurable Logic Units', which can do simple 3-wire logic plus an optional FlipFlop.
P2 could use that existing terminology, and expand the Smart Pin as being 'a Configurable Pin Unit with 32b Counter/Timer/Shifting capability at the pin'
Those are the 'visible' registers. There are also Shifters/Counters 'hidden' behind those too I think ?
One of the best ways to document peripherals I've seen, is by equations.
If nothing else, it creates intrigue to investigate further.
No idea what that means. I’d rather see
Each smart pin has built in standalone functions:
PWM
Counters
Quadrature encoder
Etc
Yes, this is coming back to where Peter asked how to make the Prop2 fit into search criteria of the component suppliers. The Prop1 can do much but only as soft peripherals. This means it is not listed in the searches.
There are really three places where you place data sheet expansions
The first, is in the Features overview, where a single line is common , such as
Features:
64 x Smart Pins : Configurable Pin Units with 32b Counter/Timer/Shifting capability at the pin
Then in the Smart Pin section you can say more
64 x Smart Pins : Configurable Pin Units with 32b Counter/Timer/Shifting capability at the pin
Each smart pin unit can be configured for one of built in standalone functions, and attach to one of 4? nearby pins :
1..32b PWM
32b Counters/Timers
32b Quadrature encoder
1..32b Shifter, UART and SPI
32b Timing capture. Pulse Width, Period, ..?
Two Pin units can combine for high precision/dynamic range Reciprocal Frequency Counting
...
and then the register/ user interface section can have the register details
Smart Pin Configurable Pin Unit Software interface:
Each smart pin has three 32-bit registers: X, Y, and Z (result). There is also a single flag bit result which can be written to C..
and here small, working code snippets will be clearest.
They are the data passing registers of each Smartpin for operation and access. There's also the unlabelled mode register, so four registers in each Smartpin.
X and Y, both write only, are the dynamically adjustable parameters. Z, read only, is usually an accumulator of sorts and forms a result when read.
EDIT: Had left out the "putch" label.
I can't quite remember the detail but there is a reason why I had to also check transmitting status in the putch routine rather than just buffer status. It's a first use problem where initial Smartpin config leaves the buffer-full flag set to wrong state.
I noted Cluso's solution was to always to send a null character out at init time.
It was something I didn't get my head around until quite late due to happily using bit-bashing for debug code. At the time I did solve it I thought the Prop2 was set in stone. I'd forgotten about this niggle when you actually were finalising it.
Correct. Not a detail for datasheets nor brochures.
There are special instructions for manipulating these smartpin registers directly as they are not memory mapped like other kinds of registers. So the smartpins are not just lumped onto the P2 CPU, they are part of it. If I try to even just configure a peripheral in an ARM, it is a whole block of code to address the I/O base and load and store the configurations in all the different peripheral registers. That is, after I've spent a day reading the 16 pages just on that tiny part of the peripheral. P2 smartpins are tightly integrated with the P2 architecture, they are not a bolt-on cell that's mapped into it afterwards.
What I'd like to get across also is the fact that each one of these peripherals is not only independent and self-contained, but they are all equally accessible by any core, and that any pin can be assigned any of these functions independently without affecting any other pin. This is unheard of in the microcontroller world where a pin can have this or that peripheral signal but then this other pin must be this or that, and now you have lost this and that function, and so that's it.
The P2 and it's tightly integrated smartpins are like 64 independent configurable peripherals. I like to refer to the P2 smartpins as dedicated configurable peripheral per pin I/O but you have to be careful saying that to people, it could blow their minds.
...and this is EXACTLY why I suggest referring to them as CORES.
The word CORES will grab peoples attention.
8 Microprocessor CORES with 64 Smart Pin CORES
(or Peripheral CORES, or whatever...)
People NEED to have their minds blown a bit to entice them to investigate the P2. The description is accurate and people will see that (unlike many other marketing campaigns). There are no false alarms here.
Jason
@thej - cores almost always evokes the thought of CPU cores, so it probably isn't a good idea to use this term.
Chip,
This needs to be noted for fix if any hardware revisions happen.
I could have changed this a month ago, as I did look into it. It seemed to me, though, that there was no better way to do it. I know it doesn't look good.