Also I just have no idea when the P2 will be available! If I knew for sure it would be available by the end of the year I might even refactor my application to use the P2 and my own application would be so much better off for it.
P2 will not be in volume production in 2017, so you will need to work with what you can get...
As it stands the P2 is a maybe for next generation version but by then the code-base will have grown and I will be forced to maintain 2 product lines and 2 code-bases ( P1 & P2 ) with 2 documentation and feature lineups etc and so on..
Yup. That's pretty much commercial norms, anytime you have volume products and multiple generations of design.
In the end it may prove better to roll my own P1V+ ASIC to get the performance I need while keeping my P1 code-base and single product line. ( I think it's a big mistake to not be backward compatible with the P1 ) .
Very few advances are 100% backward compatible, a smarter question is how can designs be ported ?
What areas is P1 running out of steam ?
Another option is to augment P1 with a FPGA, either with a P1V COG, or just use the FPGA to add HW capability.
If you keep one eye on P2 when you design the FPGA, you can make porting to P2 easier.
My HoloShield application involves being about to put any peripheral on any pin to emulate any ( or as many as possible ) hardware device configurations
A primary goal is to enable my users to interface with my emulated versions of hardware without requiring code changes to their application code.
For example a SPI peripheral I can run with 2 cogs at 4Mhz right now. This is quite useful since the default rate for the Arduino is 4Mhz. However, some popular applications - like LCD's (eg Arduboy) run at 8Mhz SPI and right now I have to tell them to modify their application code to use 4Mhz. That is not my design goal but for now it's good enough.
So I really would like to at least double the clock speed to get more soft peripheral coverage
> a smarter question is how can designs be ported ?
I am part of the way to this with a customised compiler but the P1 can ONLY JUST handle SPI at 4Mhz which is the bare minimum performance I need so only hand crafted PASM can get me there. With more speed I could be more portable and I have a nice compiled java solution for this.
>Another option is to augment P1 with a FPGA, either with a P1V COG, or just use the FPGA to add HW capability
Yes, this is what I am looking into but up goes the complexity and associated cost. The main win for me is the elegant soft-peripheral solution where I can upload new peripherals compiled from my virtual breadboard design configurations effortlessly. VBB configuration => Peripheral Layout => CodeGen => OpenSpin => Bootloader ==> Upload in less than 5 seconds. The reason it's so good for this application is I can just keep adding soft peripherals as future applications demand them.
>either with a P1V COG,
I have explored this idea and it's the most likely next step (unless parallax iterate a P1 at double the clock speed). You (jmg) have identified some newer low cost devices in previous threads ( ICE40 ) and my plan is to prove the product and then do a RISC version of the P1V throwing away everything I don't need ( video etc ) to get the throughput I need but keep my code base.
>If you keep one eye on P2 when you design the FPGA, you can make porting to P2 easier.
The P2 might use the soft-java compiled peripheral code version and this would be a nice portable solution. I am also looking at the new PIC32MZ family which now have remappable pins which is a new feature.
And this is the bottom problem isn't it -- there are so many ways to solve the problem but each has cost profile in engineering resources etc which if you are giant company might not be the issue but as small company it's the only issue.
>If you keep one eye on P2 when you design the FPGA, you can make porting to P2 easier.
The P2 might use the soft-java compiled peripheral code version and this would be a nice portable solution. I am also looking at the new PIC32MZ family which now have remappable pins which is a new feature.
Certainly P2 would manage this very easily. At highest performance levels, there may be some pin constraints, but far less than other micros.
I think the new PIC32 is still only partial remapping, so comes up well short of P1/P2 ?
My HoloShield application involves being about to put any peripheral on any pin to emulate any ( or as many as possible ) hardware device configurations
A primary goal is to enable my users to interface with my emulated versions of hardware without requiring code changes to their application code.
For example a SPI peripheral I can run with 2 cogs at 4Mhz right now. This is quite useful since the default rate for the Arduino is 4Mhz. However, some popular applications - like LCD's (eg Arduboy) run at 8Mhz SPI and right now I have to tell them to modify their application code to use 4Mhz. That is not my design goal but for now it's good enough.
So I really would like to at least double the clock speed to get more soft peripheral coverage
This is probably best in a separate thread - how many IO does your HoloShield need ? (I guess 5V tolerance is not important ?)
Just like to say a small high-five for Chip. - Now that I've got access to the Prop2, I'm liking both HubExec and ##immediate. The two work so well together I'm starting to wonder if I'll bother with C even. On the Prop2, PASM be the bomb, as they say. Cheers Chip.
Here's a couple of examples of clean and easy:
mov parm, ##message
call #puts
call #putnl
message byte "test string for printing from hubram",0
CON
tpin = 0 ' pin # to test
MMMMM = %10001 ' "Time A-input High States" %AAAA_BBBB_FFF_PPPPPPPPPPPPP_TT_MMMMM_0
TT = %00 ' disable direct out to pin, only the Smartpin sees the OUTxx
PPPPPPPPPPPPP = 0 ' default
FFF = %000 ' no filtering
BBBB = %0100 ' set B-input to cog OUTxx of this pin
AAAA = %0100 ' set A-input to cog OUTxx of this pin
DAT
...
wrpin ##((AAAA<<28)|(BBBB<<24)|(FFF<<21)|(PPPPPPPPPPPPP<<8)|(TT<<6)|(MMMMM<<1)), #tpin
dirh #tpin 'enable Smartpin
...
Just like to say a small high-five for Chip. - Now that I've got access to the Prop2, I'm liking both HubExec and ##immediate. The two work so well together I'm starting to wonder if I'll bother with C even. On the Prop2, PASM be the bomb, as they say. Cheers Chip.
Here's a couple of examples of clean and easy:
mov parm, ##message
call #puts
call #putnl
message byte "test string for printing from hubram",0
CON
tpin = 0 ' pin # to test
MMMMM = %10001 ' "Time A-input High States" %AAAA_BBBB_FFF_PPPPPPPPPPPPP_TT_MMMMM_0
TT = %00 ' disable direct out to pin, only the Smartpin sees the OUTxx
PPPPPPPPPPPPP = 0 ' default
FFF = %000 ' no filtering
BBBB = %0100 ' set B-input to cog OUTxx of this pin
AAAA = %0100 ' set A-input to cog OUTxx of this pin
DAT
...
wrpin ##((AAAA<<28)|(BBBB<<24)|(FFF<<21)|(PPPPPPPPPPPPP<<8)|(TT<<6)|(MMMMM<<1)), #tpin
dirh #tpin 'enable Smartpin
...
I hadn't really thought of hub exec in this way before but I guess one of the main reasons on P1 to move from PASM to Spin or C was to write programs bigger than will fit in COG RAM. Since that is no longer an issue, those who prefer to use assembler don't even need to consider any high-level language.
Recently I gave a complete "newbie" a crash course (10 mins) in microcontrollers and assembly language.
I showed the newb some PIC,AVR and P2 PASM.
Surprise surprise , the newb gravitated towards P2 PASM because it was easier to understand.
In viewing the above responses as to “who do you think will buy the Prop2”, there were wonderful discussions and speculations of where the new hardware will thrive.
I’m not a nuts & bolts hardware guy; I’ve created software solutions for over 4 decades before getting involved with robotics. I started with the Javelin Stamp because of its virtual Peripherals and was quickly drawn to the P1 for my Drones because the multi-cog architecture that allows software design not to be bogged-down by the design constraints/conflicts between “Concurrency” vs “Parallelism”. (There is a wonderful description contained within the marketing hype in the video found at: http://forums.parallax.com/discussion/166588/concurrency-is-not-parallelism)
My belief is that the biggest market for the Prop2 does not exist yet, but will make an appearance in the next few years. Time has shown us that Theoretical principals make their way into new products via a two-step process. The first step often happens within academia’s post-graduate programs. The Thesis written and the development of Proof-of-Concept projects (let’s keep our focus to computer sciences and electrical engineering disciplines for now), become building blocks for the future. By citing and using previous post-graduate efforts, new post-grads & their advisors keep advancing the field.
In the second step, innovators re-task the core concepts of the original research and develop new prototypes for products, and a number become successful products.
As an example: one of the last entries in “Erco’s Figure 8 Challenge”, is the “Three-wheel Mar Rover Robot Built in UNNC”, I believe is an example of such post-graduate work. see youtube.com/watch?v=YAeaS1WhAgU
Again look at some of the comments following the “Three-wheel Mar Rover”. I see product innovation in those comments.
Now image if post-graduates had ready access to the Prop2s with its incredible set of hardware features and its ability to handle “Concurrency” vs “Parallelism”? I personally can’t wait to see what comes from Academia over the next few years and how the research will be used by others.
As innovators, we need the Prop2 as soon as possible.
I was lying down in lush green pastures slowly chewing the cud when a storm came up and suddenly were struck by lightning. Then I had a vision ... somewhat related to this brainstorming thread.
This thread started questioning the viability of P2 when every new modern $8 MCU is made in a two-digits nm process and has plenty of peripherals inside.
So here it goes ... the P2 development board should have also a cheap and high-performance ARM MCU too.
Ken and Chip might think that the best companion MCU to P2 is a P1. But this will be a big error.
Something like the NUC505DL13Y (with 2MB flash, SD Host, USB 2.0 HS, RTC ...) can complement P2 with a lot of useful peripherals for demostration purposes.
There are several benefits:
- It can have a dual educative purpose (ARM + P2).
- The P2+ARM will not be overlooked anymore.
- The ARM will complement P2 with hard peripherals (RTC, SD Host, USB 2.0 HS) and nonvolatile memory (2MB Flash)
- Those new instructors that are forced/suggested (by department guidelines/rules) to use a modern ARM MCU can use also the P2 board.
...
My usage case for the P2 hard real time I/O for instrumentation, control, and robotics.
Superglue if you will for high speed I/O without going FPGA.
I think this needs an inexpensive module with all the required voltage regulation (say from 5V), a QSPI flash and a PropPlug connector or on-board USB programming capability. Perhaps 64 pin DIP or DIMM module format.
With the assorted cheap SBC's I think generating video (except possibly driving LCD's and perhaps VGA) is no longer relevant.
The ability to generate/process high speed signals is.
(sorry I did not see this thread earlier - I've been busy in Pi land)
Before we spend a lot of money to push Prop2 to completion, could you please help us identify likely markets for it and explain your rationale? Just a few sentences, or even one, would be appreciated.
This matter came up at a Parallax board-of-directors meeting and I offered to poll the Prop2 forum about it, as I don't want the other board members to be in the position of having my suppositions, only, to consider. For better or for worse, we want to know what you think.
As you know, this project has taken eleven years and the world has changed a lot over time. Every new $8 microcontroller is built in a small process and boasts lots of everything. Can the Prop2 provide some unique and valuable capabilities amid all this?
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 think this needs an inexpensive module with all the required voltage regulation (say from 5V), a QSPI flash and a PropPlug connector or on-board USB programming capability. Perhaps 64 pin DIP or DIMM module format.
(sorry I did not see this thread earlier - I've been busy in Pi land)
You did not mention Pi-Zero format for the module ? Wouldn't an existing form factor make more sense than DIP64 ?
With the assorted cheap SBC's I think generating video (except possibly driving LCD's and perhaps VGA) is no longer relevant.
I'd say HDMI Video is outside the P2 target market, but LCD displays with P2 + HyperRAM is looking quite practical.
I see FTDI have a significant business selling a larger module, that is [Touch LCD+Backplane PCB + Plastic Bezel] with mounting for their EVE parts.
Parallax should consider that as well.
I haven't posted in a long, long while, but I always come wandering back here to see what's going on.
The world, for better or worse, has seen a lot of SBC's like RPis and Beaglebones and whatever. There's million's of them out there, and every single user out there has there own opinion on which is better.
If I was Parallax, I would bow to reality, and go with the Killer App approach. Leverage the RPi 3 (it's the most widely supported base unit - yes xxxx is better - don't care), and build a hat board (or base motherboard!), around a P2, and build a smash up good IDE in the Pi3 - designed around the strengths of the P2. Get your software - INCLUDED with the Pi.org standard image (raspbian, pixel, whatever). Design a nice high speed interface into the board. Make it work with any language in the Pi (C, Python, Ruby, Node RED, Sonic Pi, Mathematica). Get a nice series of articles written up in Mag Pi, Servo, Circuit Cellar, etc.
Throw in the ubiquitous Parallax breadboard and some cool sensors if you want...
Level 1 - 10 million plus schoolkids around the world get instant exposure to Parallax and P2 via the Pi.
Level 2 - Mass exodus of Arduino / Pi makers stuck with I2C and SPI, and serial.
Level 3 - Incorporate the P2 into an industrial soft PLC package like Codesys. Industrial users with this option buy hundreds of units per customer. Its EASY. even I was able to modify Adafruit's I2C driver and interface it to the Prop and Teensy...
Case in point: I'm testing for quite a few applications using Pi3, Codesys, and Teensy MCU's for packaging applications. Looking at a couple hundred units a year for various components, and I would love to be able to use a P2 versus a Teensy. I use the Codesys softPLC as a gateway to Rockwell Compact and Contrologix PLCs (Ethernet IP to Modbus TCP). As a side note, I would have been perfectly happy with Props - BUT - Spin was too slow, Didn't care to use Assembly, and the C compiler path was always too much setup involved.
For my applications, I don't care about video, since the Pi has these - and my HMI interface is over the Codesys Web server anyway. It's pretty hard to beat a Pi with the Pi camera option IMO.
Just think about this. A P2 on a Pi3. You've connected over your wireless to the Pi using VNC. Your editing using the way cool INCLUDED design environment that Parallax has gotten into a Pi image (that you can maintain BTW), downloaded from Parallax. No cables. No software to install. No wires to wire up. No Pi Linux OS tweaking, Nothing. How cool would that be?
Better to go with the stock Raspbian OS. Just provide the tools needed to develop for the P2 all packaged up nicely on the Pi. And I nice selection of demos and documentation.
As noted above, having things "just work" on the P2 HAT with a Python interface for the Raspi side code might be a good start.
Ah, typo. I was thinking P2 HAT for the R-Pi, running the R-Pi version of the Micromite BASIC. Not that I see me doing it because I don't want to wait for any OS to boot but I can imagine the possibilities.
I know what you mean. On the other hand most of the uses I put machines like Pi to rarely get powered down or rebooted. If that happens I consider it a failure. Generally I run them without any X Windows so reboot times are not such a drag when developing things.
Aside: My last serious Pi project stopped after a year when it's SD card started smoking?
If you want to run apps on the bare metal Rpi and get better I/O performance use Ultibo. it's a Freepascal cross compiler that generates code for the Rpi. Don't need a OS with it.
Probably won't help P1 or P2 sales though.
I just wonder how much interest there is in the Rpi user community for real world stuff. I know there are P1 and PIC32 boards and wonder how well they are selling. The Pi Hat is being discontinued, that's not a good sign.
That is going to make Parallax rather gun shy.
Though not a Rpi user. I can see a lot real world possibilities for Rpi coupled with a good front end, like P2. It would make a dirt cheap data acquisition unit if you put in a telemetry front end run by a P2 with the ARM doing the data crunch and display.
It would also make a all around real world I/O for a variety of experiments and data logging at dirt cheap prices.
I just wonder how much interest there is in the Rpi user community for real world stuff. I know there are P1 and PIC32 boards and wonder how well they are selling. The Pi Hat is being discontinued, that's not a good sign.
I should clarify. It looks like Parallax is no longer going to be selling the Pi Hat. However, since they don't make it, that doesn't necessarily mean it is being discontinued. It may continue to be available elsewhere. Also, Bill Henning has a similar but far more capable board called the RoboPi. Maybe he'll tell us how well that is selling. Are you still around, Bill?
Though not a Rpi user. I can see a lot real world possibilities for Rpi coupled with a good front end, like P2. It would make a dirt cheap data acquisition unit if you put in a telemetry front end run by a P2 with the ARM doing the data crunch and display.
It would also make a all around real world I/O for a variety of experiments and data logging at dirt cheap prices.
Only a small percentage of Pi users need such a front end, but even that is still a large enough user base.
Parallax also need to think about what users will do, when P2 alone is not enough.
A P2 modue in Pi-Zero form factor can be used either as a Hat, or stand alone. (and it needs to be designed so it can operate stand alone)
For me, the Prop2 is interesting as a flexible low-to-medium-speed serial bus bitbanger, for niche or uncommon buses where there is no pre-available MAC chip or MCU peripheral.
One project of mine involves two separate low-speed differential serial buses. I designed a transceiver front-end for the bus, and the back-end "MAC" runs on an ARM micro. However, since there are two buses involved, I need two micros to do the job. A single, single-core microcontroller won't cut it, since we have to capture all transactions on all buses, and can't afford to "ignore" one while servicing the other.
I considered using an FPGA, but it turns out to be less cost-effective than the solution with two micros. FPGAs are much more costly to implement in a design than even two microcontrollers, and the FPGA may have needed external RAM to buffer the messages.
I have investigated some dual-core microcontrollers, but they are relatively uncommon, offer more performance and memory than I really need (so more expensive), and usually there is some architectural ugliness about the approach. One chip comes to mind which combines a Cortex-M0+ and a Cortex-M4 together. I could, in theory, use that chip to accomplish the goal, but it would be odd to have one bus serviced by a much faster processor than the other.
Strangely, I considered using the dual-core Espressif ESP32 chip for the MAC (yes, the one with the WiFi/BT transciever, just not using that part), and it seemed like it was a win. Dual cores so I can service both buses at once, very cheap, plenty of performance and capacity, and the two cores can share memory, rather than passing messages over a UART, as in my implementation with the ARM micros. However, I just wasn't familiar with its Xtensa processor core and so I decided against it. Most users use the EPS32 chip for IoT stuff, not bit-banging buses, so I didn't think I'd get much help if I ran into trouble.
Two ARM micros isn't so bad, and would likely be cheaper than the Prop2, but imagine if I had 4 or 8 buses to service. Now all of a sudden, the Prop2 looks like a great solution. Easier to implement than an FPGA, plenty of memory to buffer the bus transactions, and full programmability, unlike an off-the-shelf MAC chip or MCU peripheral.
I considered the Prop1 for the task, but it didn't quite have enough memory to buffer the messages, and the implementation cost would have been higher than the ARM micros anyway.
So I see the Prop2 as useful for these odd I/O tasks. Just my two cents.
That's really interesting, Zane. I have to agree with the hidden FPGA costs, and have always regarded the P1 is solving the kind of issues you'd normally turn to an FPGA for, but with just the right things locked down (for speedy development).
Recently I've been noticing several gadgets that really need "the propeller treatment". One is my 2011 car radio which struggles to do any two things too closely, eg changing radio station and then volume, because its busy animating the display in between. So keypresses are 'lost'
The other one in past couple of weeks is the thermal camera scene. Keep finding artificial limits such as not being able to record movies longer than 5 minutes unless you have a PC connected, and the Flir I bought has an MSX feature which overlays visual edges with the lower res thermal image. There's an offset between the two sensors which the software should be able to shift/compensate for, but it just doesn't.
These things and more would be trivial for P2 to sort out.
Comments
Yup. That's pretty much commercial norms, anytime you have volume products and multiple generations of design.
Very few advances are 100% backward compatible, a smarter question is how can designs be ported ?
What areas is P1 running out of steam ?
Another option is to augment P1 with a FPGA, either with a P1V COG, or just use the FPGA to add HW capability.
If you keep one eye on P2 when you design the FPGA, you can make porting to P2 easier.
My HoloShield application involves being about to put any peripheral on any pin to emulate any ( or as many as possible ) hardware device configurations
A primary goal is to enable my users to interface with my emulated versions of hardware without requiring code changes to their application code.
For example a SPI peripheral I can run with 2 cogs at 4Mhz right now. This is quite useful since the default rate for the Arduino is 4Mhz. However, some popular applications - like LCD's (eg Arduboy) run at 8Mhz SPI and right now I have to tell them to modify their application code to use 4Mhz. That is not my design goal but for now it's good enough.
So I really would like to at least double the clock speed to get more soft peripheral coverage
> a smarter question is how can designs be ported ?
I am part of the way to this with a customised compiler but the P1 can ONLY JUST handle SPI at 4Mhz which is the bare minimum performance I need so only hand crafted PASM can get me there. With more speed I could be more portable and I have a nice compiled java solution for this.
>Another option is to augment P1 with a FPGA, either with a P1V COG, or just use the FPGA to add HW capability
Yes, this is what I am looking into but up goes the complexity and associated cost. The main win for me is the elegant soft-peripheral solution where I can upload new peripherals compiled from my virtual breadboard design configurations effortlessly. VBB configuration => Peripheral Layout => CodeGen => OpenSpin => Bootloader ==> Upload in less than 5 seconds. The reason it's so good for this application is I can just keep adding soft peripherals as future applications demand them.
>either with a P1V COG,
I have explored this idea and it's the most likely next step (unless parallax iterate a P1 at double the clock speed). You (jmg) have identified some newer low cost devices in previous threads ( ICE40 ) and my plan is to prove the product and then do a RISC version of the P1V throwing away everything I don't need ( video etc ) to get the throughput I need but keep my code base.
>If you keep one eye on P2 when you design the FPGA, you can make porting to P2 easier.
The P2 might use the soft-java compiled peripheral code version and this would be a nice portable solution. I am also looking at the new PIC32MZ family which now have remappable pins which is a new feature.
And this is the bottom problem isn't it -- there are so many ways to solve the problem but each has cost profile in engineering resources etc which if you are giant company might not be the issue but as small company it's the only issue.
Modedit:YouTube link
I think the new PIC32 is still only partial remapping, so comes up well short of P1/P2 ?
This is probably best in a separate thread - how many IO does your HoloShield need ? (I guess 5V tolerance is not important ?)
I have moved this to a new thread
http://forums.parallax.com/discussion/166803/holoshield-a-soft-peripheral-application-case-study
Here's a couple of examples of clean and easy:
I showed the newb some PIC,AVR and P2 PASM.
Surprise surprise , the newb gravitated towards P2 PASM because it was easier to understand.
I’m not a nuts & bolts hardware guy; I’ve created software solutions for over 4 decades before getting involved with robotics. I started with the Javelin Stamp because of its virtual Peripherals and was quickly drawn to the P1 for my Drones because the multi-cog architecture that allows software design not to be bogged-down by the design constraints/conflicts between “Concurrency” vs “Parallelism”. (There is a wonderful description contained within the marketing hype in the video found at: http://forums.parallax.com/discussion/166588/concurrency-is-not-parallelism)
My belief is that the biggest market for the Prop2 does not exist yet, but will make an appearance in the next few years. Time has shown us that Theoretical principals make their way into new products via a two-step process. The first step often happens within academia’s post-graduate programs. The Thesis written and the development of Proof-of-Concept projects (let’s keep our focus to computer sciences and electrical engineering disciplines for now), become building blocks for the future. By citing and using previous post-graduate efforts, new post-grads & their advisors keep advancing the field.
In the second step, innovators re-task the core concepts of the original research and develop new prototypes for products, and a number become successful products.
As an example: one of the last entries in “Erco’s Figure 8 Challenge”, is the “Three-wheel Mar Rover Robot Built in UNNC”, I believe is an example of such post-graduate work. see youtube.com/watch?v=YAeaS1WhAgU
Again look at some of the comments following the “Three-wheel Mar Rover”. I see product innovation in those comments.
Now image if post-graduates had ready access to the Prop2s with its incredible set of hardware features and its ability to handle “Concurrency” vs “Parallelism”? I personally can’t wait to see what comes from Academia over the next few years and how the research will be used by others.
As innovators, we need the Prop2 as soon as possible.
Malcolm
This thread started questioning the viability of P2 when every new modern $8 MCU is made in a two-digits nm process and has plenty of peripherals inside.
So here it goes ... the P2 development board should have also a cheap and high-performance ARM MCU too.
Ken and Chip might think that the best companion MCU to P2 is a P1. But this will be a big error.
Something like the NUC505DL13Y (with 2MB flash, SD Host, USB 2.0 HS, RTC ...) can complement P2 with a lot of useful peripherals for demostration purposes.
There are several benefits:
- It can have a dual educative purpose (ARM + P2).
- The P2+ARM will not be overlooked anymore.
- The ARM will complement P2 with hard peripherals (RTC, SD Host, USB 2.0 HS) and nonvolatile memory (2MB Flash)
- Those new instructors that are forced/suggested (by department guidelines/rules) to use a modern ARM MCU can use also the P2 board.
...
My usage case for the P2 hard real time I/O for instrumentation, control, and robotics.
Superglue if you will for high speed I/O without going FPGA.
I think this needs an inexpensive module with all the required voltage regulation (say from 5V), a QSPI flash and a PropPlug connector or on-board USB programming capability. Perhaps 64 pin DIP or DIMM module format.
With the assorted cheap SBC's I think generating video (except possibly driving LCD's and perhaps VGA) is no longer relevant.
The ability to generate/process high speed signals is.
(sorry I did not see this thread earlier - I've been busy in Pi land)
I'd say HDMI Video is outside the P2 target market, but LCD displays with P2 + HyperRAM is looking quite practical.
I see FTDI have a significant business selling a larger module, that is [Touch LCD+Backplane PCB + Plastic Bezel] with mounting for their EVE parts.
Parallax should consider that as well.
I haven't posted in a long, long while, but I always come wandering back here to see what's going on.
The world, for better or worse, has seen a lot of SBC's like RPis and Beaglebones and whatever. There's million's of them out there, and every single user out there has there own opinion on which is better.
If I was Parallax, I would bow to reality, and go with the Killer App approach. Leverage the RPi 3 (it's the most widely supported base unit - yes xxxx is better - don't care), and build a hat board (or base motherboard!), around a P2, and build a smash up good IDE in the Pi3 - designed around the strengths of the P2. Get your software - INCLUDED with the Pi.org standard image (raspbian, pixel, whatever). Design a nice high speed interface into the board. Make it work with any language in the Pi (C, Python, Ruby, Node RED, Sonic Pi, Mathematica). Get a nice series of articles written up in Mag Pi, Servo, Circuit Cellar, etc.
Throw in the ubiquitous Parallax breadboard and some cool sensors if you want...
Level 1 - 10 million plus schoolkids around the world get instant exposure to Parallax and P2 via the Pi.
Level 2 - Mass exodus of Arduino / Pi makers stuck with I2C and SPI, and serial.
Level 3 - Incorporate the P2 into an industrial soft PLC package like Codesys. Industrial users with this option buy hundreds of units per customer. Its EASY. even I was able to modify Adafruit's I2C driver and interface it to the Prop and Teensy...
Case in point: I'm testing for quite a few applications using Pi3, Codesys, and Teensy MCU's for packaging applications. Looking at a couple hundred units a year for various components, and I would love to be able to use a P2 versus a Teensy. I use the Codesys softPLC as a gateway to Rockwell Compact and Contrologix PLCs (Ethernet IP to Modbus TCP). As a side note, I would have been perfectly happy with Props - BUT - Spin was too slow, Didn't care to use Assembly, and the C compiler path was always too much setup involved.
For my applications, I don't care about video, since the Pi has these - and my HMI interface is over the Codesys Web server anyway. It's pretty hard to beat a Pi with the Pi camera option IMO.
Just think about this. A P2 on a Pi3. You've connected over your wireless to the Pi using VNC. Your editing using the way cool INCLUDED design environment that Parallax has gotten into a Pi image (that you can maintain BTW), downloaded from Parallax. No cables. No software to install. No wires to wire up. No Pi Linux OS tweaking, Nothing. How cool would that be?
As far as I know, I have one of most everything Parallax has made or makes since I started my electronics/robotic's hobby!
The one exception is to this is all the Ardui** related products!
I second the P2 on Raspberry Pi HAT idea.
Of course, it's one I have been suggesting for a long time
Better to go with the stock Raspbian OS. Just provide the tools needed to develop for the P2 all packaged up nicely on the Pi. And I nice selection of demos and documentation.
As noted above, having things "just work" on the P2 HAT with a Python interface for the Raspi side code might be a good start.
http://www.thebackshed.com/forum/forum_posts.asp?TID=9487&PN=2
Pi Hat?
Aside: My last serious Pi project stopped after a year when it's SD card started smoking?
Probably won't help P1 or P2 sales though.
I just wonder how much interest there is in the Rpi user community for real world stuff. I know there are P1 and PIC32 boards and wonder how well they are selling. The Pi Hat is being discontinued, that's not a good sign.
That is going to make Parallax rather gun shy.
Though not a Rpi user. I can see a lot real world possibilities for Rpi coupled with a good front end, like P2. It would make a dirt cheap data acquisition unit if you put in a telemetry front end run by a P2 with the ARM doing the data crunch and display.
It would also make a all around real world I/O for a variety of experiments and data logging at dirt cheap prices.
Maybe only discontinued from Parallax,. as it seems still in stock here at original supplier
Only a small percentage of Pi users need such a front end, but even that is still a large enough user base.
Parallax also need to think about what users will do, when P2 alone is not enough.
A P2 modue in Pi-Zero form factor can be used either as a Hat, or stand alone. (and it needs to be designed so it can operate stand alone)
One project of mine involves two separate low-speed differential serial buses. I designed a transceiver front-end for the bus, and the back-end "MAC" runs on an ARM micro. However, since there are two buses involved, I need two micros to do the job. A single, single-core microcontroller won't cut it, since we have to capture all transactions on all buses, and can't afford to "ignore" one while servicing the other.
I considered using an FPGA, but it turns out to be less cost-effective than the solution with two micros. FPGAs are much more costly to implement in a design than even two microcontrollers, and the FPGA may have needed external RAM to buffer the messages.
I have investigated some dual-core microcontrollers, but they are relatively uncommon, offer more performance and memory than I really need (so more expensive), and usually there is some architectural ugliness about the approach. One chip comes to mind which combines a Cortex-M0+ and a Cortex-M4 together. I could, in theory, use that chip to accomplish the goal, but it would be odd to have one bus serviced by a much faster processor than the other.
Strangely, I considered using the dual-core Espressif ESP32 chip for the MAC (yes, the one with the WiFi/BT transciever, just not using that part), and it seemed like it was a win. Dual cores so I can service both buses at once, very cheap, plenty of performance and capacity, and the two cores can share memory, rather than passing messages over a UART, as in my implementation with the ARM micros. However, I just wasn't familiar with its Xtensa processor core and so I decided against it. Most users use the EPS32 chip for IoT stuff, not bit-banging buses, so I didn't think I'd get much help if I ran into trouble.
Two ARM micros isn't so bad, and would likely be cheaper than the Prop2, but imagine if I had 4 or 8 buses to service. Now all of a sudden, the Prop2 looks like a great solution. Easier to implement than an FPGA, plenty of memory to buffer the bus transactions, and full programmability, unlike an off-the-shelf MAC chip or MCU peripheral.
I considered the Prop1 for the task, but it didn't quite have enough memory to buffer the messages, and the implementation cost would have been higher than the ARM micros anyway.
So I see the Prop2 as useful for these odd I/O tasks. Just my two cents.
Recently I've been noticing several gadgets that really need "the propeller treatment". One is my 2011 car radio which struggles to do any two things too closely, eg changing radio station and then volume, because its busy animating the display in between. So keypresses are 'lost'
The other one in past couple of weeks is the thermal camera scene. Keep finding artificial limits such as not being able to record movies longer than 5 minutes unless you have a PC connected, and the Flir I bought has an MSX feature which overlays visual edges with the lower res thermal image. There's an offset between the two sensors which the software should be able to shift/compensate for, but it just doesn't.
These things and more would be trivial for P2 to sort out.