The problem with the Teacup software is that it wasn't written in a portable manner. It has AVR-specific references scattered throughout the code. It does have a simulator mode that is portable, but I don't think the simulator mode provides the timing that is required. I think we were close to getting the Teacup software running on the Prop, but it did require significant changes. It will probably be messy to port to the P2 as well, but the interrupt capability of the P2 may make it easier.
It was never my intention to hijack this thread... My apologies Chip.
In answer to your question:
Who do you think is going to buy the Prop2 and what will they use it for, and maybe what quantities might they use it in? Do you see it filling any unique market need? Do you think any particular industry will find it valuable?
I am not as well versed in the P2 as many of the other members, but I have tried to catch some of the key aspects of the P2 as you have progressed in the development. Many years ago, I suggested that Parallax pursue the motion control industry as a key market for the P1, in hindsight, I now admit that I was wrong. The P1 had it's limitations concerning this type of application. However I now believe that the P2 is better suited for this type of application, but it lacks the code base.
If some money and effort were set aside to develop code for the motion control industry, I do believe there would be many applications for the motion control industry.
As I have said in the past, motion control is BIG business.
EDIT: And not just motion control, but machinery control, including sensors, solenoids, etc... I would love to see the P2 controlling a bunch of pneumatic and vacuum solenoids, in combination with motion control, to complete some very complex tasks in the industrial arena.
I'm not really sure what form the P2 will take, there have been so many discussed concepts that I've honestly lost track.
I can only speak for what I, myself would purchase...
1) Sick of having to boot an OS to create a more capable project. Worse still having to do a "proper shutdown" for a portable project is even worse. I've start to avoid using SBCs in my own projects because of this.
2) While I might buy a single "Activity Board" or "Experimenter's Board" -- I'd be more excited to purchase multiple inexpensive P2 chip boards which contain all the required components to make the P2 work. Something which can be easily implemented into a socket like a BASIC STAMP.
3) Once upon a time, Chip talked about an "On board programming editor" which would allow you to program and update the chip. The MICROMITE (PIC32) does this and while there are now some external programming tools, it is perfect for debugging and troubleshooting the project even when it's already built into my project.
IMHO, the idea of "Build it, and They will come" doesn't seem to work in Microcontroller business with so many choices now on the table.
Unfortunately, users like myself will not pay the bills and investment which has already been consumed by the P2 project. Parallax needs a very large manufacturer to "need" this chip for a 100 million release. Perhaps they could even team with someone like Google who is developing robotics for military and domestic purposes. Any chance that the P2 might be able to be used for self driving vehicles in some way?
And... I think the P2 would be an excellent candidate for custom real time and timing critical industrial control systems (like the motion control often mentioned).
I've actually used the P1 for several Department of Defense projects because the multi core-design and PASM allowed me to easily develop custom real time algorithms for applications where off-the-shelf components weren't available and an $8 ARM would never have a peripheral to do the stuff I needed to do.
* One project, which was a technology demonstration could possibly result in 10's of thousands of units being produced BUT... it will not use P1's if it comes into fruition because I had to pull every last bit of horse-power out of the P1 to get it to work, leaving little room for improvement so it will likely rely on an SoC for production. The P2 would totally satisfy the computational power requirement.
Currently I'm designing a custom industrial controller that will hopefully result in 1000's of units. Again, the multi-core design and assembly language programming makes the Propeller an excellent chip for the application. For this design, a production design will likely still use propeller chips because I am not pushing the chip to it's limit. A competitor for the design could have been a TI Sitara chip, but the ease of integration of the Propeller makes sense when trying to balance engineering effort vs. bells whistles &c.
My next project will involve telemetry for another industrial application (hopefully 10's of thousands of units). I'll be using the P1 for prototyping, but again will likely have to go with another solution (FPGA) for production. The P1 just can't quite cut it for production performance. BUT, if I could get a P2 it could be a whole different story.
Here's my quick rant: Get the #$&%! thing to production. Stop adding stuff to it. What made the chip useful to me was again...the multi-core design and PASM. My current and future designs would have been happy with just the faster clock, shorter pipeline and hardware math (multiplies). More cores and more pins were a great bonus. I don't need the other stuff (especially the video, I can get a $5 Pi Zero for that.)
There is one worry that I have for P2 acceptance. It seems pretty universally agreed here that C/C++ is needed for P2 to be a commercial success. However, it also seems that most of the people here prefer to use Spin/PASM for their own projects. One of the things that really made P1 stand out was forum support. If someone wanted to start a project there were always people on the forums that would help out and give advice. But if most of the forum users continue to use Spin/PASM then there won't be that great quality support for people wanting to use C/C++ on the P2 just like there wasn't on the P1. It was understandable on the P1 since Spin came far ahead of C/C++ even if you count the earlier C efforts. But I think we're all hoping that GCC will be available at launch for P2. How can we get some excitement here for programming in C/C++ so that we build up a good library of code that can be used once P2 customers start arriving. I'm afraid that won't happen if the work here is mostly focused on Spin/PASM (or Forth).
There is one worry that I have for P2 acceptance. It seems pretty universally agreed here that C/C++ is needed for P2 to be a commercial success. However, it also seems that most of the people here prefer to use Spin/PASM for their own projects. One of the things that really made P1 stand out was forum support. If someone wanted to start a project there were always people on the forums that would help out and give advice. But if most of the forum users continue to use Spin/PASM then there won't be that great quality support for people wanting to use C/C++ on the P2 just like there wasn't on the P1. It was understandable on the P1 since Spin came far ahead of C/C++ even if you count the earlier C efforts. But I think we're all hoping that GCC will be available at launch for P2. How can we get some excitement here for programming in C/C++ so that we build up a good library of code that can be used once P2 customers start arriving. I'm afraid that won't happen if the work here is mostly focused on Spin/PASM (or Forth).
I think that's a legitimate concern. Some of this may very well change simply because of the larger resources (as mentioned earlier) that will allow more standard C/C++ library usage. At the same time, the forum software really needs to do a better job of helping newcomers find the information they need. It needs to be obvious that C/C++ (or any other language that targets the P2) is discussed and supported on the forum. If a user has to ask if the language is supported before they can ask for support, then the forum has failed at Step One.
I worry that anything complex enough to really 'NEED' a P2 is possibly better done in a FPGA and anything simpler the P2 is going to be too hard to use compared to industry standard platforms and libraries.
All I really want is a faster P1 and I am confused why parallax didn't iterate the P1 'as is' onto a higher performance process as they became more cost effective over the last decade.
The P1 is excellent as a dynamically configurable soft-peripheral coprocessor but to truly be world class in this niche it could really do with at least double the current clock speed.
And welcome back, OldBitCollector. Interesting what you said about start-up and shut-down times on SBC's. That kind of thing drives me nuts, too. My cell phone can't wake up and get into camera mode fast enough to be usable in a pinch, making it somewhat useless.
Here's my quick rant: Get the #$&%! thing to production. Stop adding stuff to it. What made the chip useful to me was again...the multi-core design and PASM. My current and future designs would have been happy with just the faster clock, shorter pipeline and hardware math (multiplies). More cores and more pins were a great bonus. I don't need the other stuff (especially the video, I can get a $5 Pi Zero for that.)
.... I'd be more excited to purchase multiple inexpensive P2 chip boards which contain all the required components to make the P2 work. Something which can be easily implemented into a socket like a BASIC STAMP......
+1
The challenge is the package design of the module since you are dealing with a quantity of pins that is not necessarily easy to handle. Parallax can consider gold finger edge connector modules (like the Pi Compute Module), a castellated module with partnered TH breakout board (like bluetooth modules), or a standard QFP to TH breakout board style (like this one from Schmartboard)
-- I'd be more excited to purchase multiple inexpensive P2 chip boards which contain all the required components to make the P2 work. Something which can be easily implemented into a socket like a BASIC STAMP.
Certainly a 'most compact' breakout board has appeal.
The FLiP is 0.6" pitch, but that will not be possible on P2, as the package is larger than that.
0.9" could be possible, but still 64io pushes PCB size up.
I've seen some designs default to single row, but allow for dual-row - single row can fit into a wide DIP40/DIP48, double row needs connector-connector.
I certainly will like to play with a P2. As I am the solder sucker they talk about in another thread I am not able to build my own P2 circuit, like I was able to do with the P1.
So I think the proposed Idea of @Ken, to build a basic module to put into a circuit (or even a breadboard?) would be great for people like me.
The main thing that pulled me to the P1 (and into this fascinating forum) was the PE-Kit.
A bag of parts to handle for a beginner, a simple schematic and instant success. Mparc's Sphinx was part of it. Editor/compiler running on my own creation, ready to roll. I was back in Heaven like I was in those 8-bit days with Atari, commodore and spectrum.
A modular approach could be a quite sensitive move.
First a basic circuit with P2 and flash. Even excluding needed voltage regulators, some people need more power or less. As simple as possible so it will be easy for other people to include this in their own designs. Make that one bulletproof, so no 'glitches' like the serial problem on Quickstart-A.
This one should be as simple as possible, no funny things, no sd, no switches, even no LEDs, maybe reset button, but I am not even sure about that.
This one could be run in high production numbers and can be reasonable cheap. And Parallax (and all other people here) could provide boards to plug the standard P2-module in.
Next some power board to plug it into. Maybe different versions with different max amp supplies.
Then some Breadboard friendly board to use it. Or one with screw terminals. Here all other Guys can chime in, no need for Parallax to bother with.
Then I and others could already use it with a PPDB /other dev-boards and play with it.
But the first P2-Module should be as small and lean as possible and be able to be put into some socket. DIP is not possible I guess so maybe edge connectors and one of the sockets for them?
Being replaceable is a important aspect there. If you f...up you just need a new P2-Module not a new Activity2-Board.
Not just for the hobbyist, but also for commercial customers/support of them. Sure if you want to manufacture on your own Pick and Place you might not NEED that socket and that module, but you could use it and save some worries.
The socket also would offer a nice test point to test your boards before putting a P2-Module in.
But if you just hand solder or have not the equipment for reals mass production, you might like just to solder in a socket, not the real chip.
...
So I think the proposed Idea of @Ken, to build a basic module to put into a circuit (or even a breadboard?) would be great for people like me.
...
First a basic circuit with P2 and flash. Even excluding needed voltage regulators, some people need more power or less. As simple as possible so it will be easy for other people to include this in their own designs. Make that one bulletproof, so no 'glitches' like the serial problem on Quickstart-A.
This one should be as simple as possible, no funny things, no sd, no switches, even no LEDs, maybe reset button, but I am not even sure about that.
Close, but with a 1.8V core, this is going to need a dual regulator, but it may be that a switching regulator can be avoided, on the first module.
Dual regulators are not expensive, and 19c~36c looks possible, but Parallax may want to bump that a little to buy lower noise, Higher Io headroom, etc
LEDs are cheap, and I'd say a minimum of one, to give 'power & alive' assurance.
A trickier question is around USB, & USB connectors, but maybe that can be decided later ?
Safest and simplest, would be lowest-cost USB bridge, like CP2102N (3x3mm $1.17/1k ), as that is fast and proven on many hosts.
Cheaper still, is lowest-cost MCU with USB, like EFM8UB10F8G-C-QFN20 (65c/1k)
Tempting would be to have P2 load itself over USB, so a second USB socket could allow to test that, but I suspect that's a moving target, and you do not want to delay P2 code by USB issues in P2 core (and no easy way to update the firmware).
If Parallax is going to make a P2 board. Make one that demonstrates it's capability to show prospective customers what it can do right out of the box. Maybe a combo O'scope and Function Generator, PLC front end, maybe something in robotic or 7 axis controller, whatever. But something that makes people go wow.
It needs to stand out in a world of ARMs and PICs.
That probably means the board is going to cost around $75 or more. It's still pocket change to companies and evaluators.
If Parallax is going to make a P2 board. Make one that demonstrates it's capability to show prospective customers what it can do right out of the box. Maybe a combo O'scope and Function Generator, PLC front end, maybe something in robotic or 7 axis controller, whatever. But something that makes people go wow.
It needs to stand out in a world of ARMs and PICs.
That probably means the board is going to cost around $75 or more. It's still pocket change to companies and evaluators.
Sure offer a cheap bare bones board to hobbyists.
Most of that is software, but it may mean 2 Board designs, or one core board, and a daughter card ?
Looking at smallest possible, the P2 package bumps to above ~25mm, and needs dual-row x2 to get enough IO.
From there, it is a small step to the 65mm x 30mm of a PiZero form factor, but with 2 connectors.
Question then is, what is 2nd connector - 40pin 0.1 is vanilla-standard, but may risk wrong-way slipups ? (Must be some way to avoid that ?)
Cheapest (and still available!) edge connectors look to be PCI and 64 way would fit, needs 7.6mm penetration, but is not great overall, as most mate at 90' ...
SMD ones look to change to 52 way, still not great mechanically....
If Parallax is going to make a P2 board. Make one that demonstrates it's capability to show prospective customers what it can do right out of the box.
<snip>
Sure offer a cheap bare bones board to hobbyists.
I certainly do agree with this! It shouldn't be terribly difficult to write some code that makes the P2 (on a suitably equipped board) perform simultaneously a suite of deterministic and throughput-intensive tasks that no other uC in its price range could touch.
Then, when prospective customers realize how easy and straightforward it was to accomplish this piece of programming legerdemain (and to modify and re-purpose the code, too), it would surely get the attention of some jaded minds in the commercial and industrial sectors.
P2 (+firmware) with something like a Micromite Plus, on the front-end could out-perform the controller, cited in this article. The interpreted on-board language, I agree, is easy to use but is relatively slow and more basic than the crudest BASIC out there. They need TWO chips to handle eight axes. The significance of the P2's ability to handle so many quadrature encoders, cannot be overstated!
If there is a market as showed in the given link, then there is certainly a complementary market in robots that serve S&R and as there is beside man made desaster also the very bad, bad nature, threatening men and women so I would target application more into this direction.
I would, in a heartbeat. I adore the Propeller 1's elegance, power and remarkable feature set, while still being easy to use. On that reputation alone I'd happily get involved with Prop 2.
I often get involved with designs where high pin-count GPIO is useful and also where multiple cores is HUGELY beneficial, especially when there is no cumbersome OS getting in the way. Also, deterministic and consistent timing is assured with the Prop architecture so this makes high-speed glitch-free operations possible (and doing odd things like muxing a single input channel of RS232 to arbitrary combinations of 16 output channels is trivial on the Prop 1 even without writing much code at all). If the Prop2 does all that and more then using it is a total no-brainer.
I hope to soon become delirious with power once I get my hands on a Prop2 chip (or several).
And I've never even touched the Spin language apart from the bare minimum needed to get the cogs spun-up with some PASM code, I never really understood the point of the Spin language, it seems to go against everything the hardware stands for. But as long as PASM is available on the P2 then I'm one extremely happy camper and a guaranteed customer.
As one who has worked in the military & defense industry - the development of new systems of all types ( defensive and offensive) is ever expanding into new technology. We are not necessarily tied to any one operating system or chip set. Many designs are compromised by using too much (battery) power, or lacking in chip capabilities (thru-put) Many times we design & build stuff you could not imagine. We used to say - If you saw it on StarTrek, its already deployed. I can personally think of more than a few military systems that were / are on the back burner because the technology does not exist / or the micro-processor chip does not exist.
I am going to repeat what I said above, for the automotive industry and the medical device industry. Several ways to introduce the P2 technology into industry, is introduce it / P2 in the schools so these students will take that P2 technology into industry when they graduate. AND building on the P2 chip technology to fill the need of new devices that can use the power of the P2 features. In this instance the only way to do this is remember "technology is fleeting" What the ARM / and all the other chip sets do today will not work for tomorrow (it's old school stuff). Being quick & nimble with new micro-processor solutions is a huge plus. P2 fills the bill perfectly.
I think having ADCs und DACs on each Pin will open up a lot of applications in Home Electric and Solar/WInd.
I really would like - for example - to put some board in the breaker-box in my house, measuring Amps on every single breaker.
The same might be useful to check Battery-Banks or the output of multiple Solar-Cells. Solar tracking is also interesting.
I personally do not really see IOT and me getting friends. Not everything belongs into the net. But I do really like the OS agnostic way Ethernet is handled. If we have USB then WI-FY or Ethernet dongles are in reach, but it would be way nicer if the P2 could Bit-Bang Ethernet direct.
Someone smarter then me said here in the forum that it might be possible, I wish he is right.
I fell in love with the simplicity of P1, P2 seems already overwhelming to me, but I am just lurking, have not written any P2-Pasm yet. But the basic concepts are already nice documented and I slowly dig myself into P2-Pasm.
I still beg for being able to link Spin2, C(++) and Pasm modules together, what basically means that the Spin-Compiler should be able to produce ELF compatible files. Does not have to do always, but should have a option to allow this.
Spin and C/C++ should use the same loader. That one can then help to set a standard for multiple stage loading. Parallax does now 2-stage loading to support Wi-Fy, PropGCC used multiple stage loading for XMM support. P2 already needs some boot-flash first stage loader so lets do it right.
One thing in SPIN1/PASM1 was that reusing the HUBRAM used by the binary images loaded into the COGs at startup has no standard. Some use the space as buffer, some does not use it at all, some have their own routines to suck the binary from EEPROM or SD.
As far as I understand we can now load a cog without starting it. And then later jump into the COG to start it.
This would allow a multi-stage loader to first load needed COG-Images (even including LUT) and then the HUBRAM.
Comments
In answer to your question:
I am not as well versed in the P2 as many of the other members, but I have tried to catch some of the key aspects of the P2 as you have progressed in the development. Many years ago, I suggested that Parallax pursue the motion control industry as a key market for the P1, in hindsight, I now admit that I was wrong. The P1 had it's limitations concerning this type of application. However I now believe that the P2 is better suited for this type of application, but it lacks the code base.
If some money and effort were set aside to develop code for the motion control industry, I do believe there would be many applications for the motion control industry.
As I have said in the past, motion control is BIG business.
EDIT: And not just motion control, but machinery control, including sensors, solenoids, etc... I would love to see the P2 controlling a bunch of pneumatic and vacuum solenoids, in combination with motion control, to complete some very complex tasks in the industrial arena.
I can only speak for what I, myself would purchase...
1) Sick of having to boot an OS to create a more capable project. Worse still having to do a "proper shutdown" for a portable project is even worse. I've start to avoid using SBCs in my own projects because of this.
2) While I might buy a single "Activity Board" or "Experimenter's Board" -- I'd be more excited to purchase multiple inexpensive P2 chip boards which contain all the required components to make the P2 work. Something which can be easily implemented into a socket like a BASIC STAMP.
3) Once upon a time, Chip talked about an "On board programming editor" which would allow you to program and update the chip. The MICROMITE (PIC32) does this and while there are now some external programming tools, it is perfect for debugging and troubleshooting the project even when it's already built into my project.
IMHO, the idea of "Build it, and They will come" doesn't seem to work in Microcontroller business with so many choices now on the table.
Unfortunately, users like myself will not pay the bills and investment which has already been consumed by the P2 project. Parallax needs a very large manufacturer to "need" this chip for a 100 million release. Perhaps they could even team with someone like Google who is developing robotics for military and domestic purposes. Any chance that the P2 might be able to be used for self driving vehicles in some way?
/still lurking occasionally..
-8b
- Make it easy to integrate into a design
- Document well
And... I think the P2 would be an excellent candidate for custom real time and timing critical industrial control systems (like the motion control often mentioned).
I've actually used the P1 for several Department of Defense projects because the multi core-design and PASM allowed me to easily develop custom real time algorithms for applications where off-the-shelf components weren't available and an $8 ARM would never have a peripheral to do the stuff I needed to do.
* One project, which was a technology demonstration could possibly result in 10's of thousands of units being produced BUT... it will not use P1's if it comes into fruition because I had to pull every last bit of horse-power out of the P1 to get it to work, leaving little room for improvement so it will likely rely on an SoC for production. The P2 would totally satisfy the computational power requirement.
Currently I'm designing a custom industrial controller that will hopefully result in 1000's of units. Again, the multi-core design and assembly language programming makes the Propeller an excellent chip for the application. For this design, a production design will likely still use propeller chips because I am not pushing the chip to it's limit. A competitor for the design could have been a TI Sitara chip, but the ease of integration of the Propeller makes sense when trying to balance engineering effort vs. bells whistles &c.
My next project will involve telemetry for another industrial application (hopefully 10's of thousands of units). I'll be using the P1 for prototyping, but again will likely have to go with another solution (FPGA) for production. The P1 just can't quite cut it for production performance. BUT, if I could get a P2 it could be a whole different story.
Here's my quick rant: Get the #$&%! thing to production. Stop adding stuff to it. What made the chip useful to me was again...the multi-core design and PASM. My current and future designs would have been happy with just the faster clock, shorter pipeline and hardware math (multiplies). More cores and more pins were a great bonus. I don't need the other stuff (especially the video, I can get a $5 Pi Zero for that.)
Welcome back!
Jeff, please keep lurking. We miss you.
I think that's a legitimate concern. Some of this may very well change simply because of the larger resources (as mentioned earlier) that will allow more standard C/C++ library usage. At the same time, the forum software really needs to do a better job of helping newcomers find the information they need. It needs to be obvious that C/C++ (or any other language that targets the P2) is discussed and supported on the forum. If a user has to ask if the language is supported before they can ask for support, then the forum has failed at Step One.
All I really want is a faster P1 and I am confused why parallax didn't iterate the P1 'as is' onto a higher performance process as they became more cost effective over the last decade.
The P1 is excellent as a dynamically configurable soft-peripheral coprocessor but to truly be world class in this niche it could really do with at least double the current clock speed.
And welcome back, OldBitCollector. Interesting what you said about start-up and shut-down times on SBC's. That kind of thing drives me nuts, too. My cell phone can't wake up and get into camera mode fast enough to be usable in a pinch, making it somewhat useless.
+1
+1
The challenge is the package design of the module since you are dealing with a quantity of pins that is not necessarily easy to handle. Parallax can consider gold finger edge connector modules (like the Pi Compute Module), a castellated module with partnered TH breakout board (like bluetooth modules), or a standard QFP to TH breakout board style (like this one from Schmartboard)
ps. good to see you lurking Jeff!
Glad to you are lurking, even if only occasionally
The FLiP is 0.6" pitch, but that will not be possible on P2, as the package is larger than that.
0.9" could be possible, but still 64io pushes PCB size up.
I've seen some designs default to single row, but allow for dual-row - single row can fit into a wide DIP40/DIP48, double row needs connector-connector.
So I think the proposed Idea of @Ken, to build a basic module to put into a circuit (or even a breadboard?) would be great for people like me.
The main thing that pulled me to the P1 (and into this fascinating forum) was the PE-Kit.
A bag of parts to handle for a beginner, a simple schematic and instant success. Mparc's Sphinx was part of it. Editor/compiler running on my own creation, ready to roll. I was back in Heaven like I was in those 8-bit days with Atari, commodore and spectrum.
A modular approach could be a quite sensitive move.
First a basic circuit with P2 and flash. Even excluding needed voltage regulators, some people need more power or less. As simple as possible so it will be easy for other people to include this in their own designs. Make that one bulletproof, so no 'glitches' like the serial problem on Quickstart-A.
This one should be as simple as possible, no funny things, no sd, no switches, even no LEDs, maybe reset button, but I am not even sure about that.
This one could be run in high production numbers and can be reasonable cheap. And Parallax (and all other people here) could provide boards to plug the standard P2-module in.
Next some power board to plug it into. Maybe different versions with different max amp supplies.
Then some Breadboard friendly board to use it. Or one with screw terminals. Here all other Guys can chime in, no need for Parallax to bother with.
Then I and others could already use it with a PPDB /other dev-boards and play with it.
But the first P2-Module should be as small and lean as possible and be able to be put into some socket. DIP is not possible I guess so maybe edge connectors and one of the sockets for them?
Being replaceable is a important aspect there. If you f...up you just need a new P2-Module not a new Activity2-Board.
Not just for the hobbyist, but also for commercial customers/support of them. Sure if you want to manufacture on your own Pick and Place you might not NEED that socket and that module, but you could use it and save some worries.
The socket also would offer a nice test point to test your boards before putting a P2-Module in.
But if you just hand solder or have not the equipment for reals mass production, you might like just to solder in a socket, not the real chip.
As I said, I am a solder sucker.
Mike
Close, but with a 1.8V core, this is going to need a dual regulator, but it may be that a switching regulator can be avoided, on the first module.
Dual regulators are not expensive, and 19c~36c looks possible, but Parallax may want to bump that a little to buy lower noise, Higher Io headroom, etc
LEDs are cheap, and I'd say a minimum of one, to give 'power & alive' assurance.
A trickier question is around USB, & USB connectors, but maybe that can be decided later ?
Safest and simplest, would be lowest-cost USB bridge, like CP2102N (3x3mm $1.17/1k ), as that is fast and proven on many hosts.
Cheaper still, is lowest-cost MCU with USB, like EFM8UB10F8G-C-QFN20 (65c/1k)
Tempting would be to have P2 load itself over USB, so a second USB socket could allow to test that, but I suspect that's a moving target, and you do not want to delay P2 code by USB issues in P2 core (and no easy way to update the firmware).
It needs to stand out in a world of ARMs and PICs.
That probably means the board is going to cost around $75 or more. It's still pocket change to companies and evaluators.
Sure offer a cheap bare bones board to hobbyists.
Looking at smallest possible, the P2 package bumps to above ~25mm, and needs dual-row x2 to get enough IO.
From there, it is a small step to the 65mm x 30mm of a PiZero form factor, but with 2 connectors.
Question then is, what is 2nd connector - 40pin 0.1 is vanilla-standard, but may risk wrong-way slipups ? (Must be some way to avoid that ?)
Cheapest (and still available!) edge connectors look to be PCI and 64 way would fit, needs 7.6mm penetration, but is not great overall, as most mate at 90' ...
SMD ones look to change to 52 way, still not great mechanically....
Then, when prospective customers realize how easy and straightforward it was to accomplish this piece of programming legerdemain (and to modify and re-purpose the code, too), it would surely get the attention of some jaded minds in the commercial and industrial sectors.
P2 (+firmware) with something like a Micromite Plus, on the front-end could out-perform the controller, cited in this article. The interpreted on-board language, I agree, is easy to use but is relatively slow and more basic than the crudest BASIC out there. They need TWO chips to handle eight axes. The significance of the P2's ability to handle so many quadrature encoders, cannot be overstated!
http://www.roboticstomorrow.com/content.php?post_type=1782
I would, in a heartbeat. I adore the Propeller 1's elegance, power and remarkable feature set, while still being easy to use. On that reputation alone I'd happily get involved with Prop 2.
I often get involved with designs where high pin-count GPIO is useful and also where multiple cores is HUGELY beneficial, especially when there is no cumbersome OS getting in the way. Also, deterministic and consistent timing is assured with the Prop architecture so this makes high-speed glitch-free operations possible (and doing odd things like muxing a single input channel of RS232 to arbitrary combinations of 16 output channels is trivial on the Prop 1 even without writing much code at all). If the Prop2 does all that and more then using it is a total no-brainer.
I hope to soon become delirious with power once I get my hands on a Prop2 chip (or several).
And I've never even touched the Spin language apart from the bare minimum needed to get the cogs spun-up with some PASM code, I never really understood the point of the Spin language, it seems to go against everything the hardware stands for. But as long as PASM is available on the P2 then I'm one extremely happy camper and a guaranteed customer.
I am going to repeat what I said above, for the automotive industry and the medical device industry. Several ways to introduce the P2 technology into industry, is introduce it / P2 in the schools so these students will take that P2 technology into industry when they graduate. AND building on the P2 chip technology to fill the need of new devices that can use the power of the P2 features. In this instance the only way to do this is remember "technology is fleeting" What the ARM / and all the other chip sets do today will not work for tomorrow (it's old school stuff). Being quick & nimble with new micro-processor solutions is a huge plus. P2 fills the bill perfectly.
I really would like - for example - to put some board in the breaker-box in my house, measuring Amps on every single breaker.
The same might be useful to check Battery-Banks or the output of multiple Solar-Cells. Solar tracking is also interesting.
I personally do not really see IOT and me getting friends. Not everything belongs into the net. But I do really like the OS agnostic way Ethernet is handled. If we have USB then WI-FY or Ethernet dongles are in reach, but it would be way nicer if the P2 could Bit-Bang Ethernet direct.
Someone smarter then me said here in the forum that it might be possible, I wish he is right.
I fell in love with the simplicity of P1, P2 seems already overwhelming to me, but I am just lurking, have not written any P2-Pasm yet. But the basic concepts are already nice documented and I slowly dig myself into P2-Pasm.
I still beg for being able to link Spin2, C(++) and Pasm modules together, what basically means that the Spin-Compiler should be able to produce ELF compatible files. Does not have to do always, but should have a option to allow this.
Spin and C/C++ should use the same loader. That one can then help to set a standard for multiple stage loading. Parallax does now 2-stage loading to support Wi-Fy, PropGCC used multiple stage loading for XMM support. P2 already needs some boot-flash first stage loader so lets do it right.
One thing in SPIN1/PASM1 was that reusing the HUBRAM used by the binary images loaded into the COGs at startup has no standard. Some use the space as buffer, some does not use it at all, some have their own routines to suck the binary from EEPROM or SD.
As far as I understand we can now load a cog without starting it. And then later jump into the COG to start it.
This would allow a multi-stage loader to first load needed COG-Images (even including LUT) and then the HUBRAM.
Anyways,
Mike