The 555 timer chip was introduced in 1971. A very simple little chip. But very flexible. It's simple arrangement of analogue comparator, flip-flop etc could be configured for all kinds of different uses. Even today, in the face of thousands of other "smarter" chips including micro-controllers and such, the humble 555 sells by the billion.
I sometimes wonder how it would be if the 555 did not come out in 1971 but was instead launched in recent years. Would all the kids of today look at it and sneer, laughing at how crude it is compared to a AVR Tiny whatever? Not understanding what can be done with it. Resulting in no 555 sales.
All of which makes me sometimes wonder if the P1 is like that 555 that was introduced into the wrong era? It's not a high speed compute engine, it's not a SoC loaded with hardware peripherals, it is a very simple and flexible device that the kids don't know what to do with.
The 555 timer chip was introduced in 1971. A very simple little chip. But very flexible. It's simple arrangement of analogue comparator, flip-flop etc could be configured for all kinds of different uses. Even today, in the face of thousands of other "smarter" chips including micro-controllers and such, the humble 555 sells by the billion.
I sometimes wonder how it would be if the 555 did not come out in 1971 but was instead launched in recent years. Would all the kids of today look at it and sneer, laughing at how crude it is compared to a AVR Tiny whatever? Not understanding what can be done with it. Resulting in no 555 sales.
All of which makes me sometimes wonder if the P1 is like that 555 that was introduced into the wrong era? It's not a high speed compute engine, it's not a SoC loaded with hardware peripherals, it is a very simple and flexible device that the kids don't know what to do with.
Better than hippies... the women they married. QVC at Christmas, with Courtney and a few hundred robots. Mix in your favorite
engineer with a "hack your house" segment. Finish up with Ken flying his favorite Quad, and Chip for the supernerds at home.
What a nice day that would be:)
Better than hippies... the women they married. QVC at Christmas, with Courtney and a few hundred robots. Mix in your favorite
engineer with a "hack your house" segment. Finish up with Ken flying his favorite Quad, and Chip for the supernerds at home.
What a nice day that would be:)
When Prop2 is done, we'll have a get together. I imagine it will be kind of like this:
Personally, I like the idea of bit banging every protocol. It feels like I have a lot more control of every little thing happening all the time. Hardware com ports feel like sitting in the back seat of a taxi- sure I'll get to my destination, but how do I know the driver knows the best way to get there?
It's good to have the option to bit-bang what you want.
In Windows programming, I found that nothing beyond a button and a scrollbar was trustworthy. I built every other control myself. That was for the SX-Key software, which was an assembler, programmer, and in-circuit debugger.
For these smart pins, only the most fundamental functions are being implemented - things that have been and will be useful, indefinitely.
I love the bit-banging ability of the P1. We can still do that in the P2.
But a little bit of basic assistance will go a long way to assist with faster protocols.
It was a shame that the P1 couldn't use the video to shift in also. Ain't hindsight wonderful!
These are the things that make the prop so exciting - you can make these things happen and see the results. Plus, you only have to have one chip, not a hundreds of different chips in case you want a special configuration of peripherals. You can make the peripherals smarter than a hardware block, and you are not having to intertwine it between other code and interrupts.
The P2 is much faster, and twice the cogs, and more hub ram, so there should be some really smart things we will do with it.
However, we still have a lot more things that we can do with the P1
Hardware com ports feel like sitting in the back seat of a taxi- sure I'll get to my destination, but how do I know the driver knows the best way to get there?
You prefer a pedal car to a Porche ?
Hardware will always get there (much) faster, which is the point you missed.
The project I'm working on right now requires that I send bits onto an i2c bus with one pin and read ack bits on another. There's no way around it, the hardware design dictates that it's the only option. With the Prop, that means a few minutes of changing masks and such. With a hardware i2c port I'd be screwed.
The project I'm working on right now requires that I send bits onto an i2c bus with one pin and read ack bits on another. There's no way around it, the hardware design dictates that it's the only option. With the Prop, that means a few minutes of changing masks and such. With a hardware i2c port I'd be screwed.
Sure, that's a special use case, different from what you mentioned earlier. (even done similar myself)
No one is even suggesting i2c is hardware only.
The only suggestion is option support in HW to sense Start and STOP (1 FlipFlop+GATE).
ACK would usually be in SW, tho if Chip allows 9 bit lengths, ACK send could easily be optionally tacked onto a byte send for some data, if the user wanted.
We still have the full software control over all pins. And the P2 should run 2x clock and instructions are now 2 instead of 4 (another 2x), and we have 2x cog ram and hub access can be much faster with blocks or hubexec.
Two clock instructions??? At 200MHz that'd be 10ns per instruction. Mind blowing, Chip. Also, @Tubular I looked at his documentation for P2 and noticed the section on the debugging registers. Do you think this means when P2 comes out there will be a big update to the Propeller Tool allowing step by step debugging with an onscreen memory map?
I always thought that it was going to be one clock/instruction. Guess I'm out of date.
Some of the old preliminary spec sheets are still quoting the old Prop2-Hot specs. Back then there was half as many Cogs (Eight) and half as much HubRAM (256MB) fitting in the same die dimensions. Each Cog was substantially bigger. This increased size had the effect of people wanting to treat all eight Cogs like general processor cores that run application code and DSP like functions, anything less wasn't using the hulking cores effectively ... which led to demands for hardware peripherals to do the low level work.
Works for me. Still a total of 1600MIPS. That spec has me salivating. So Chip once threw out that Spin2 was going to be 40 X the speed of Spin1 (IIRC). This means that it's now 20 X, right?
If the P2 runs at 200MHz the instruction rate will be 5 times that of the P1. Code that runs within a cog and does not do hub accesses should run 5 times faster. For code that does random hub accesses this will be reduced somewhat since the hub access window on P1 is every 4 instructions, and on P2 it is every 8 instructions. So code that randomly accesses hub RAM will run between 2.5 and 5 times faster than the P1.
The P2 does have twice as many cogs, so the aggregate increase in speed is 10 times the P1. However, there are very few applications that fully utilize all of the cogs. Most applications use the extra cogs for peripheral drivers.
The Spin interpreter is a program that runs from cog memory. This should get a 5x increase in speed on the P2, but the speed improvement will be degraded a bit since the Spin VM accessed hub RAM at least twice for every bytecode it processes. Let's say the speed increase is 4x. P2 allows execution from the LUT RAM, so this will allow unrolling the Spin interpreter a bit, which will speed it up. I would guess this unrolling will yield about a 50% improvement in speed. My guess is that we'll see about a 6x improvement in the speed of the Spin interpreter.
Spin code can be converted to C++ using spin2cpp. This will run at least 10 times faster than interpreted Spin. Comparing interpreted Spin on the P1 to compiled Spin on the P2 could achieve a 40x increase.
I just got an email from Sparkfun about a new board they are selling with an Atmel ARM ATSAMD21G18 on it. One of the paragraphs describing the chip says:
One of the most unique features of the SAMD21 is SERCOM – a set of six configurable serial interfaces that can be turned into either a UART, I2C master, I2C slave, SPI master, or SPI slave. Each SERCOM provides for a lot of flexibility: the ports can be multiplexed, giving you a choice of which task each pin is assigned.
I suppose this is something like the P2's smart pins although it sounds like these pins can only do serial.
Sort of. Looks to me like they are taking standard blocks and adding a little pin flexibility.
The programmer is still going to see registers, and a dedicated block, with the addition of pin indirection. That's nice.
Smart Pins are different in that there is some capability out on the pins, and the comms are serial messages to and from COGS. The overall logic cost may be higher, due to cloning the smart pin logic x number of times. (32? or 64? --seems like 32) And the logic is being designed as an assist to software more than a dedicated type of interface.
The smart pin idea, coupled with the COG idea means a broad application space for programmers. One can focus a lot of COGS and Smart Pins on, say one high complexity task, or a few of those. Or, spread it all out to address a large number of simpler tasks, or do a few tasks at the same time really well, etc... Software will determine this, and programmers can mix 'n match, optionally creating their own "dedicated modules" which will be a combination of software that uses the hardware assists available to package up a task, or bit of functionality for reuse later on. Or, to make it parallel, by simply calling it, or including it (depending on how it's written and what it does) multiple times.
The ports are just ports, so they really improve on how that chip can do concurrent serial type comms and the flexibility on pin assignment are improved.
So, on that chip, there may be "wasted" ports, depending on how many concurrent serial comms type tasks are needed for an application.
On the P2, there may be "wasted" COGS and or Smart Pin logic blocks, depending on the need for more general concurrency in the application.
I know the term "cog" is near & dear to the parallax people. However I was hoping I'd see the moniker "parallel processor" in there too. As a new customer, "parallel processor" has a stronger draw than "cog". I think this feature is a great distinguishing discriminator compared to Arduino, R-Pi, etc.
Seems the ADC resolution is 12 bits. Wasn't the plan originally for 13 bits?
Lots of good information can be found in the forum, but unfortunately it's buried. A recommendation... a half-page summary of high level specs should be posted in an easy to find place, like below. Doesn't hurt to start promoting.
Seems the ADC resolution is 12 bits. Wasn't the plan originally for 13 bits?
Even 12b is not confirmed, so do not take too much notice of 'plans'.
Final ADC performance will not be defined until real parts are operating, but in SDM you can collect as many bits as you care to.
Of course, the noise floor is what really matters in ADC, not some bit-count.
Lots of good information can be found in the forum, but unfortunately it's buried. A recommendation... a half-page summary of high level specs should be posted in an easy to find place, like below. Doesn't hurt to start promoting.
I think Chip is still shooting for 64.
I've suggested 32 paired cells, but if Chip can pack in 64, (without lowering CODE) that allows 1 Rx and 63 Tx for example, which is certainly attention getting !
63 Frequency Counting or capture channels would also be attention getting.
If that does not fit, 1 Rx & 31 Tx is still impressive.
One question is how many customers do they gain, with any boost from 31 to 63 ?
I am looking forward to using the P2 for parallel processing. But if you were to call a cog... a parallel processor, you would be directing attention to a feature of the cogs that until now has been almost completely unused. Not completely... just nearly completely.
Up til the P2, most of the interesting applications used cogs in concurrency not in parallel... so it would be most accurate to call them concurrent processors... cops.
I always thought that it was going to be one clock/instruction. Guess I'm out of date.
one clock/instruction is more a Marketing number, than an Engineering number.
Once you have a PLL, the Pin MHz is << Core MHz, so a designer is free to tune the speeds.
Many of the '1 Cycle' RISC MCUs, are now constrained by that decision, as the core limits the system performance.
To fix that, they add PLLs and run the peripherals at a higher speed than the core.
I would rather have 160MHz timers/counters/timing and a 80 MIP CPU, than a 1 Clock design where everything was 80MHz.
Comments
I sometimes wonder how it would be if the 555 did not come out in 1971 but was instead launched in recent years. Would all the kids of today look at it and sneer, laughing at how crude it is compared to a AVR Tiny whatever? Not understanding what can be done with it. Resulting in no 555 sales.
All of which makes me sometimes wonder if the P1 is like that 555 that was introduced into the wrong era? It's not a high speed compute engine, it's not a SoC loaded with hardware peripherals, it is a very simple and flexible device that the kids don't know what to do with.
Forget kids. We need hippies.
Yep, there is a real shortage of hippies in the world today. They don't make new ones and the old ones are almost extinct.
Hope my little sideways look at the Propeller situation did not come over as negative. It was certainly not meant to be.
I've always agreed with everything you've ever said, Heater. Our lot in life is to suffer such awareness.
engineer with a "hack your house" segment. Finish up with Ken flying his favorite Quad, and Chip for the supernerds at home.
What a nice day that would be:)
When Prop2 is done, we'll have a get together. I imagine it will be kind of like this:
But a little bit of basic assistance will go a long way to assist with faster protocols.
It was a shame that the P1 couldn't use the video to shift in also. Ain't hindsight wonderful!
These are the things that make the prop so exciting - you can make these things happen and see the results. Plus, you only have to have one chip, not a hundreds of different chips in case you want a special configuration of peripherals. You can make the peripherals smarter than a hardware block, and you are not having to intertwine it between other code and interrupts.
The P2 is much faster, and twice the cogs, and more hub ram, so there should be some really smart things we will do with it.
However, we still have a lot more things that we can do with the P1
A can I quote you on that next time the forum moderators are having a nag at me?
Interesting about the controls. Every so often, I run across a program or other where that was done. Often the flow is different, but cohesive.
The project I'm working on right now requires that I send bits onto an i2c bus with one pin and read ack bits on another. There's no way around it, the hardware design dictates that it's the only option. With the Prop, that means a few minutes of changing masks and such. With a hardware i2c port I'd be screwed.
No one is even suggesting i2c is hardware only.
The only suggestion is option support in HW to sense Start and STOP (1 FlipFlop+GATE).
ACK would usually be in SW, tho if Chip allows 9 bit lengths, ACK send could easily be optionally tacked onto a byte send for some data, if the user wanted.
SmartPins is icing on the cake.
Yeah, I just spent 5 years sitting out the P1...only just seen the light..D'OH!
Can you provide a snapshot of the current specs? This is what I know now:
forums.parallax.com/discussion/163134/propeller-2-specs/p1
If you have a specific question, many of the forum members can answer with reasonable expectations.
see Chip's recent document in very top post of the FPGA files!!! thread
http://forums.parallax.com/discussion/162298/prop2-fpga-files
Some of the old preliminary spec sheets are still quoting the old Prop2-Hot specs. Back then there was half as many Cogs (Eight) and half as much HubRAM (256MB) fitting in the same die dimensions. Each Cog was substantially bigger. This increased size had the effect of people wanting to treat all eight Cogs like general processor cores that run application code and DSP like functions, anything less wasn't using the hulking cores effectively ... which led to demands for hardware peripherals to do the low level work.
The P2 does have twice as many cogs, so the aggregate increase in speed is 10 times the P1. However, there are very few applications that fully utilize all of the cogs. Most applications use the extra cogs for peripheral drivers.
The Spin interpreter is a program that runs from cog memory. This should get a 5x increase in speed on the P2, but the speed improvement will be degraded a bit since the Spin VM accessed hub RAM at least twice for every bytecode it processes. Let's say the speed increase is 4x. P2 allows execution from the LUT RAM, so this will allow unrolling the Spin interpreter a bit, which will speed it up. I would guess this unrolling will yield about a 50% improvement in speed. My guess is that we'll see about a 6x improvement in the speed of the Spin interpreter.
Spin code can be converted to C++ using spin2cpp. This will run at least 10 times faster than interpreted Spin. Comparing interpreted Spin on the P1 to compiled Spin on the P2 could achieve a 40x increase.
The programmer is still going to see registers, and a dedicated block, with the addition of pin indirection. That's nice.
Smart Pins are different in that there is some capability out on the pins, and the comms are serial messages to and from COGS. The overall logic cost may be higher, due to cloning the smart pin logic x number of times. (32? or 64? --seems like 32) And the logic is being designed as an assist to software more than a dedicated type of interface.
The smart pin idea, coupled with the COG idea means a broad application space for programmers. One can focus a lot of COGS and Smart Pins on, say one high complexity task, or a few of those. Or, spread it all out to address a large number of simpler tasks, or do a few tasks at the same time really well, etc... Software will determine this, and programmers can mix 'n match, optionally creating their own "dedicated modules" which will be a combination of software that uses the hardware assists available to package up a task, or bit of functionality for reuse later on. Or, to make it parallel, by simply calling it, or including it (depending on how it's written and what it does) multiple times.
The ports are just ports, so they really improve on how that chip can do concurrent serial type comms and the flexibility on pin assignment are improved.
So, on that chip, there may be "wasted" ports, depending on how many concurrent serial comms type tasks are needed for an application.
On the P2, there may be "wasted" COGS and or Smart Pin logic blocks, depending on the need for more general concurrency in the application.
Found it. Thank you very much.
https://docs.google.com/document/d/10qQn_-B7avY2ce0N1MDDdzOF1lACPNWUJkjHFyzITiY/edit?pref=2&pli=1
I know the term "cog" is near & dear to the parallax people. However I was hoping I'd see the moniker "parallel processor" in there too. As a new customer, "parallel processor" has a stronger draw than "cog". I think this feature is a great distinguishing discriminator compared to Arduino, R-Pi, etc.
Seems the ADC resolution is 12 bits. Wasn't the plan originally for 13 bits?
Lots of good information can be found in the forum, but unfortunately it's buried. A recommendation... a half-page summary of high level specs should be posted in an easy to find place, like below. Doesn't hurt to start promoting.
https://www.parallax.com/microcontrollers/propeller
Final ADC performance will not be defined until real parts are operating, but in SDM you can collect as many bits as you care to.
Of course, the noise floor is what really matters in ADC, not some bit-count.
Of course, but the Specs are not final yet.
I think Chip is still shooting for 64.
I've suggested 32 paired cells, but if Chip can pack in 64, (without lowering CODE) that allows 1 Rx and 63 Tx for example, which is certainly attention getting !
63 Frequency Counting or capture channels would also be attention getting.
If that does not fit, 1 Rx & 31 Tx is still impressive.
One question is how many customers do they gain, with any boost from 31 to 63 ?
1/2 tongue in cheek...
I am looking forward to using the P2 for parallel processing. But if you were to call a cog... a parallel processor, you would be directing attention to a feature of the cogs that until now has been almost completely unused. Not completely... just nearly completely.
Up til the P2, most of the interesting applications used cogs in concurrency not in parallel... so it would be most accurate to call them concurrent processors... cops.
But that would confuse the social media.
one clock/instruction is more a Marketing number, than an Engineering number.
Once you have a PLL, the Pin MHz is << Core MHz, so a designer is free to tune the speeds.
Many of the '1 Cycle' RISC MCUs, are now constrained by that decision, as the core limits the system performance.
To fix that, they add PLLs and run the peripherals at a higher speed than the core.
I would rather have 160MHz timers/counters/timing and a 80 MIP CPU, than a 1 Clock design where everything was 80MHz.