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
We need to keep things really straightforward, without any embellishment. We don't want any terms that over-promise.
There is a trap in trying to piggyback on simple terms which hold too much connotation, where a short description would do a lot more justice.
... It seemed to me, though, that there was no better way to do it. I know it doesn't look good.
Okay. It's not a biggie I guess. It only creates one extra instruction in my code above. And Cluso's method doesn't need anything extra outside of the init code. I suppose Cluso's method is perfectly okay on the whole.
So that would be:
' 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
wypin #0, #tx_pin 'write null character to Y buffer to trigger first "buffer-empty"
...
' Now transmit a byte
putch
testp #tx_pin wz 'buffer free? (IN state shows Y buffer empty status)
if_nz jmp #putch 'wait while Smartpin buffer is still full (nz)
_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)
I propose not to focus to much on naming. If a name is familiar, the object named is put in a box and now you have to argue, why the object is outstanding. If the name is unfamiliar, there is no box to put it and you have to compare to the content of the box that seems to match the unknown best. However you see it: something new is first to be analyzed and next to be placed in an environment.
We should defocus on possible applications that allow to make use of the outstanding features of P2. Just one hint: acoustic camera. Others are cnc controllers which have a huge market in 3d-printers.
8 Processor Cores (32-bit)
4 kB local RAM in each Core
64 I/O Smart Pin Controllers
1 Pipelined CORDIC Math Unit
512 kB Shared RAM
Single step debugging
... while I've avoided "smartpin" as it's gimmicky and reads like a trademark.
I saw that as a good thing. Giving the module type a specific name helps clarity I feel. Like naming cordic, hub, cog, lut, fifo, streamer, the list goes on ...
Note, a smartpin is not actually an I/O pin module. There is config bits for how each smartpin functionally inserts itself between the cogs and the pins.
And, as I discovered, the smartpins are also not geo-located anywhere near their respective pin number. I'm guessing the auto-placement favours making the mux'd buses as short as possible so makes the I/O lines long instead.
PS: I'll stop capitalising the names. I wasn't very consistently applying it anyway.
...
When it comes to describing this chip for the likes of Mouser and Digikey we have a problem. It doesn't have any UARTS, yet it has 32 of them. It doesn't have any A/D, yet it has 64 channels, but when we say channels, we mean fully independent and simultaneous conversions. P2 doesn't have any PWMs, yet it has 64 of them etc etc. I know with FPGAs we can say "logic elements" etc and so we know that they can be turned into whatever we need, within reason. But the Smartpin is a bit like an FPGA per pin, it is so so configurable, and we have 64 of them so we could almost say "Realtime programmable I/O Array"
...
I speak for 80(3/5)(1/2) and PICs which I know directly. These MCUs have many hw peripherals (PWM, U(S)ART, TMR, ...) but many times if you use one you can't use another because they share some common resources (eg. timers). So even if their datasheet states " x PWM, y UART, z TMR(8-16bit), n SPI m I2C, ... you can't use them all together at the maximum indicated numbers.
So for the same reason I will not see anything wrong if in digikey/mouser compare/selection tables for P2 I read 32 UART, 64 PWM, 64 ADC, 32 DAC, .... it doesn't matter if they come from SmartPins and/or they are sw peripherals because these figures are all real even if you can't use them all at the same time .... like it happens with other's brand MCU.
I speak for 80(3/5)(1/2) and PICs which I know directly. These MCUs have many hw peripherals (PWM, U(S)ART, TMR, ...) but many times if you use one you can't use another because they share some common resources (eg. timers). So even if their datasheet states " x PWM, y UART, z TMR(8-16bit), n SPI m I2C, ... you can't use them all together at the maximum indicated numbers.
So for the same reason I will not see anything wrong if in digikey/mouser compare/selection tables for P2 I read 32 UART, 64 PWM, 64 ADC, 32 DAC, .... it doesn't matter if they come from SmartPins and/or they are sw peripherals because these figures are all real even if you can't use them all at the same time .... like it happens with other's brand MCU.
Yes, there is a general consensus the numbers mean 'up to', and if the part has 64 IO, it is also clear you cannot have all peripherals at once.
The pick-any-mix feature of P2 is quite compelling, and the ability to do adjacent-pin mapping when you need more than one Pin->SmartPin Cell
A quick check finds 8 Channel UARTS are the Max Digikey list, and they start $11.54/3k, and go up quickly, to $20~$30
Single channel SPI-UARTS are $1.22/3k, so 8 is $9.76 and already more PCB space.
Be interesting to see how a P2 can manage a QuadSPI <-> OctalUART bridge - to what baud rates ?
I speak for 80(3/5)(1/2) and PICs which I know directly. These MCUs have many hw peripherals (PWM, U(S)ART, TMR, ...) but many times if you use one you can't use another because they share some common resources (eg. timers). So even if their datasheet states " x PWM, y UART, z TMR(8-16bit), n SPI m I2C, ... you can't use them all together at the maximum indicated numbers.
So for the same reason I will not see anything wrong if in digikey/mouser compare/selection tables for P2 I read 32 UART, 64 PWM, 64 ADC, 32 DAC, .... it doesn't matter if they come from SmartPins and/or they are sw peripherals because these figures are all real even if you can't use them all at the same time .... like it happens with other's brand MCU.
Yes, there is a general consensus the numbers mean 'up to', and if the part has 64 IO, it is also clear you cannot have all peripherals at once.
The pick-any-mix feature of P2 is quite compelling, and the ability to do adjacent-pin mapping when you need more than one Pin->SmartPin Cell
A quick check finds 8 Channel UARTS are the Max Digikey list, and they start $11.54/3k, and go up quickly, to $20~$30
Single channel SPI-UARTS are $1.22/3k, so 8 is $9.76 and already more PCB space.
Be interesting to see how a P2 can manage a QuadSPI <-> OctalUART bridge - to what baud rates ?
Be more interesting to see if anyone uses QuadSPI or OctalSPI in any P2 design. I know it won't be you
Sorry if this question has been asked a thousand times before (I did not read the entire thread), but does this mean that there won't be a DIL version of the Propeller 2? Or is it planned for a later date?
Sorry if this question has been asked a thousand times before (I did not read the entire thread), but does this mean that there won't be a DIL version of the Propeller 2? Or is it planned for a later date?
If you mean some DIP40 package, no, that will never appear.
However, there is a Breakout PCB, with 0,1" pitch headers here in P2D2 thread
Sorry if this question has been asked a thousand times before (I did not read the entire thread), but does this mean that there won't be a DIL version of the Propeller 2? Or is it planned for a later date?
The P2 package is too big to fit in the width of a standard 0.6" 40 pin DIP but the P2D2 module can plug into matrix board with a QIL pinout. I know that this does not permit plug-in breadboard use though due to the dual row of pins on either side but a slightly wider 40-pin DIP module could be made with perhaps the same pinout otherwise as the P1. That is, only 32 I/O + Power + reset etc. This is something I might even do in a similar way to the P2D2, maybe calling it the P2D1
(actually, it is possible to plug this module into another adapter pcb that can plug into a plug-in breadboard.)
Have a look at my prototype, still awaiting a P2 of course!
(these use low profile sockets on the module so that low profile pin headers can be used on the matrix board or pcb)
..... a slightly wider 40-pin DIP module could be made with perhaps the same pinout otherwise as the P1. That is, only 32 I/O + Power + reset etc. This is something I might even do in a similar way to the P2D2, maybe calling it the P2D1
A 'P2-FLiP' may be better target ? ie clone the existing FLiP module pinout, which is almost the same as P1 (no Xtal pins, DC in) - FLiP has one spare pin.
..... a slightly wider 40-pin DIP module could be made with perhaps the same pinout otherwise as the P1. That is, only 32 I/O + Power + reset etc. This is something I might even do in a similar way to the P2D2, maybe calling it the P2D1
A 'P2-FLiP' may be better target ? ie clone the existing FLiP module pinout, which is almost the same as P1 (no Xtal pins, DC in) - FLiP has one spare pin.
I thought I had stepped onto Parallax's toes before but it was not so and they were happy for me to sell serial LCDs through the forum even though they sell serial LCDs. However a P2 Flip module should really be Parallax's but if they don't do one, I will, at least for myself
(I would always put a microSD socket onboard though)
Also, can OnSemi provide a recommended stencil layout?
See the drawing above - I think that has enough info for a stencil ?
- except maybe for the % coverage of the inner pad, but that could be extracted from other packages.
QFNs above 64 pins are prone to manufacturing challenges, especially where center pad connectivity is a major concern. With the current design of the P2 QFP, the center pad is the only ground connection so minimal voiding will be a major requirement on PCBAs. I have mentioned somewhere else that a BGA (144 ball, 12x12mm package, 0.8mm pitch) would be a more ideal package for the P2. A 5x5 or 6x6 ball pattern in the center can be used for thermal dissipation/grounding and still leave 19 or 8 balls for additional grounding. Using a 0.8mm package would ease manufacturing concerns as well.
As far as a DIL/DIP format option, it would not take much to create a P2 in a FLiP compatible package even as the QFP package. The PCB would obviously be wider then the outline desired, but there are several ways to accomplish this. The easiest is to use SMT Machine Headers on the bottom side spaced accordingly and let the PCB "overhang". I did this format with my Propeller BSC module as seen on this thread. Works great for sockets on a larger board as seen in the picture on that thread of the Prop-BSC sitting in a Basic Stamp BOE.
Obviously, if being used on a breadboard, this creates accessibility issues, but there are easy ways to resolve that as well. Most common is buying the segmented style breadboards and just separate them under the module so the module consumes the minimal amount of breadboard space.
However, if a BGA144 is used for the P2, then a module with dimensions similar to my Prop-BSC could be made. The challenge is all of the support components that are needed for the P2.
I asked about the other packages because I had the idea that there would be other flavors of the P2, with less pins and IOs. I was asking this because I'm planning to build a library containing all the parts. The QFP package is fine for me.
As for the coverage on the internal pad, I usually use 60% and a 4x4 or 9x9 "graticule". I'm yet to decide on that.
Comments
We need to keep things really straightforward, without any embellishment. We don't want any terms that over-promise.
There is a trap in trying to piggyback on simple terms which hold too much connotation, where a short description would do a lot more justice.
Okay. It's not a biggie I guess. It only creates one extra instruction in my code above. And Cluso's method doesn't need anything extra outside of the init code. I suppose Cluso's method is perfectly okay on the whole.
So that would be:
We should defocus on possible applications that allow to make use of the outstanding features of P2. Just one hint: acoustic camera. Others are cnc controllers which have a huge market in 3d-printers.
4 kB local RAM in each Core
64 I/O Smart Pin Controllers
1 Pipelined CORDIC Math Unit
512 kB Shared RAM
Single step debugging
I saw that as a good thing. Giving the module type a specific name helps clarity I feel. Like naming cordic, hub, cog, lut, fifo, streamer, the list goes on ...
Note, a smartpin is not actually an I/O pin module. There is config bits for how each smartpin functionally inserts itself between the cogs and the pins.
And, as I discovered, the smartpins are also not geo-located anywhere near their respective pin number. I'm guessing the auto-placement favours making the mux'd buses as short as possible so makes the I/O lines long instead.
PS: I'll stop capitalising the names. I wasn't very consistently applying it anyway.
So for the same reason I will not see anything wrong if in digikey/mouser compare/selection tables for P2 I read 32 UART, 64 PWM, 64 ADC, 32 DAC, .... it doesn't matter if they come from SmartPins and/or they are sw peripherals because these figures are all real even if you can't use them all at the same time .... like it happens with other's brand MCU.
The pick-any-mix feature of P2 is quite compelling, and the ability to do adjacent-pin mapping when you need more than one Pin->SmartPin Cell
A quick check finds 8 Channel UARTS are the Max Digikey list, and they start $11.54/3k, and go up quickly, to $20~$30
Single channel SPI-UARTS are $1.22/3k, so 8 is $9.76 and already more PCB space.
Be interesting to see how a P2 can manage a QuadSPI <-> OctalUART bridge - to what baud rates ?
Here is a package description from the ON document for our chip:
I don't know what "tape out release" means, but it sounds like good news!
Never mind, found it on wikepedia https://en.wikipedia.org/wiki/Tape-out
If you mean some DIP40 package, no, that will never appear.
However, there is a Breakout PCB, with 0,1" pitch headers here in P2D2 thread
Best case on that is a small module type product people could breadboard with.
That is my current understanding. If, somehow, I have it wrong, others will chime in soon enough.
The P2 package is too big to fit in the width of a standard 0.6" 40 pin DIP but the P2D2 module can plug into matrix board with a QIL pinout. I know that this does not permit plug-in breadboard use though due to the dual row of pins on either side but a slightly wider 40-pin DIP module could be made with perhaps the same pinout otherwise as the P1. That is, only 32 I/O + Power + reset etc. This is something I might even do in a similar way to the P2D2, maybe calling it the P2D1
(actually, it is possible to plug this module into another adapter pcb that can plug into a plug-in breadboard.)
Have a look at my prototype, still awaiting a P2 of course!
(these use low profile sockets on the module so that low profile pin headers can be used on the matrix board or pcb)
A 'P2-FLiP' may be better target ? ie clone the existing FLiP module pinout, which is almost the same as P1 (no Xtal pins, DC in) - FLiP has one spare pin.
I thought I had stepped onto Parallax's toes before but it was not so and they were happy for me to sell serial LCDs through the forum even though they sell serial LCDs. However a P2 Flip module should really be Parallax's but if they don't do one, I will, at least for myself
(I would always put a microSD socket onboard though)
Will there be any other packages/footprints? Also, can OnSemi provide a recommended stencil layout?
Kind regards, Samuel Lourenço
The P2 die is very large, so that limits anything smaller.
Candidates that might be possible are BGA and QFN. The only QFN parts google could find, are too small to fit the die.
See the drawing above - I think that has enough info for a stencil ?
- except maybe for the % coverage of the inner pad, but that could be extracted from other packages.
As far as a DIL/DIP format option, it would not take much to create a P2 in a FLiP compatible package even as the QFP package. The PCB would obviously be wider then the outline desired, but there are several ways to accomplish this. The easiest is to use SMT Machine Headers on the bottom side spaced accordingly and let the PCB "overhang". I did this format with my Propeller BSC module as seen on this thread. Works great for sockets on a larger board as seen in the picture on that thread of the Prop-BSC sitting in a Basic Stamp BOE.
Obviously, if being used on a breadboard, this creates accessibility issues, but there are easy ways to resolve that as well. Most common is buying the segmented style breadboards and just separate them under the module so the module consumes the minimal amount of breadboard space.
However, if a BGA144 is used for the P2, then a module with dimensions similar to my Prop-BSC could be made. The challenge is all of the support components that are needed for the P2.
I asked about the other packages because I had the idea that there would be other flavors of the P2, with less pins and IOs. I was asking this because I'm planning to build a library containing all the parts. The QFP package is fine for me.
As for the coverage on the internal pad, I usually use 60% and a 4x4 or 9x9 "graticule". I'm yet to decide on that.
Kind regards, Samuel Lourenço
Links in Peter's first post in thread.
J