Shop OBEX P1 Docs P2 Docs Learn Events
Who Will be Prop2's Biggest Competition? — Parallax Forums

Who Will be Prop2's Biggest Competition?

Who will be Prop2's biggest competition? Arduino Due? Adafruit Feather? Teensy3.6? TinyCircuits?
«1345

Comments

  • Heater.Heater. Posts: 21,230
    From a technical perspective - none of the above.

    You are not comparinging like things.

    They are all boards/systems, the P2 is a chip.

    To make your comparison we will have to see what P2 based board/system Parallax (or someone else) comes up with.

    Personally I think one of the first P2 boards should be compatible with the Raspberry Pi HAT specification (As well as being usable on it's own). That leverages the 15 million strong Raspi user base.

    As a chip, the P2 compares with low end FPGA's. With great advantage of being a lot easier to use.

    A lot of this depends on the software libraries and tools that Parallax provides with the P2.


  • jmgjmg Posts: 15,140
    tryit wrote: »
    Who will be Prop2's biggest competition? Arduino Due? Adafruit Feather? Teensy3.6? TinyCircuits?

    Strange list, as Prop 2 is a Silicon MCU, whilst those you list are actually Assembled PCB modules, with one or more MCUs included. Rather apples and oranges ?

    There will be at least one Prop 2 module, and any P2 module will of course, have to exist in the module market place.
    In that area, higher end modules like the RaspPi etc will also be both competition, and also complementary/seed modules.
    eg making a P2 module that is Raspberry Pi Zero form factor, results in sales of TWO modules, it does not need to be either/or.

  • Nobody - P2 will blitz them all in any realtime control application - it is in a class of its own. Unlike the RPi and other "modules" that seem to need CPU "hats" just to handle stuff it can't, the P2 is an MCU with many "hats" built right into silicon.
  • Heater.Heater. Posts: 21,230
    The P2 will indeed be in a class of it's own. What with it's multiple-cores, tightly coupled I/O, deterministic timing etc. (Except for the XMOS devices)

    In that hobbyist/maker market the question is: How many people want/need/understand that capability? The XMOS has been around for years and is still unknown in this market.

    The Raspberry Pi is a whole other kettle of fish. With a very different purpose in life. It can however be a gateway for things like the P2.
  • The Raspberry Pi is a Board as well so it would not seem to be a good comparison between a MCU and a board that has a Broadcom SoC which includes a A53 1.2gig Quad Core 64 bit ARM processor as well as HDMI Graphics and can run Linux or Window 10. I'm not sure if the Pi requires any Hats to be useful; it's quite a powerful little mini computer on its own and at only $35 US.

    Are there specs for the P2? Is it that far more advanced from the P1 where it could be compared to an ARM Processor especially with what is on a Raspberry Pi? I'd like to see that.
  • Heater.Heater. Posts: 21,230
    The Raspberry Pi cannot run Windows 10. Nor any other desktop version of Windows.

    That's right the Raspi does not require any HATs as such to be useful. One can attach all kinds of sensors to it's GPIO pins, using I2C, SPI, UART, PWM or just bit banging in software.

    Speaking of which, just today I'm experimenting with bit banging data out of Raspi at a continuous 20MBytes/s. I found a sneaky way to kick the Linux kernel off of a core and get rid of all those scheduler kickups. Managed to get a real-time response guarantee down to about 10us.

    Anyway, the P2 is a big advance on the P1. However in terms of raw compute power it will still be an order of magnitude slower than a Pi.

    On the other hand, when it comes to tight real-time deadlines it will easily run rings around the Pi.




  • The biggest competitor to the P2 might be the P1. People may prefer the P1 for applications that require low power and I assume the P1 will be cheaper than the P2.
  • Heater. wrote: »
    The Raspberry Pi cannot run Windows 10. Nor any other desktop version of Windows.
    It's not the base Windows OS, but there is a Windows 10 IoT Core that can be installed and run on a Raspberry Pi:
    https://developer.microsoft.com/en-us/windows/iot/getstarted
    That's right the Raspi does not require any HATs as such to be useful. One can attach all kinds of sensors to it's GPIO pins, using I2C, SPI, UART, PWM or just bit banging in software.
    There are also on board Camera connections as well as the multiple USB Ports and Ethernet port.
    Speaking of which, just today I'm experimenting with bit banging data out of Raspi at a continuous 20MBytes/s. I found a sneaky way to kick the Linux kernel off of a core and get rid of all those scheduler kickups. Managed to get a real-time response guarantee down to about 10us.
    Yeah, pthreads are fun to play with. A couple of years back when I was working on a Linux driver, getting a thread to run on a specific NUMA node was a bit of task but was needed to stop the OS from crossing threads and Cores from the PCIe bus. You can get close to this using Python but that is a bit higher level.
    Anyway, the P2 is a big advance on the P1. However in terms of raw compute power it will still be an order of magnitude slower than a Pi.

    On the other hand, when it comes to tight real-time deadlines it will easily run rings around the Pi.

    Yeah, I look forward to seeing the P2 released and adopted in the Tech community.
    For me at least, the Propeller 1 is in a class all its own and I am sure the P2 will be as well. Having an ability to multiprocess on a Processor without using an OS or RTOS is very unique and begs to be taken advantage of. This is an area I don't see other comparable devices can touch.
    My point was that it really is not a fair comparison between the Raspberry Pi and a Propeller MCU. One big thing is that the RasPi is not Open Source Hardware. Also, the RasPi is a complete computing environment and not just a MCU. Perhaps comparing the P2 with the RasPi Broadcom BCM2837 might be a better approach, but again the Broadcom BCM2837 implementation on the RasPi is not Open Source.
  • JonM wrote: »
    My point was that it really is not a fair comparison between the Raspberry Pi and a Propeller MCU. One big thing is that the RasPi is not Open Source Hardware.
    The P2 isn't open source hardware either at least at present. There have been statements made by Parallax in the past indicating that it would be at some point though.
  • Heater.Heater. Posts: 21,230
    edited 2017-12-31 18:58
    JonM,

    That is what I said. There is no desktop Windows for the Pi. Personally I think running MS IoT core on a Pi is an abomination.

    There is no pthreads in my current Pi bit-banging experiment. I have used the Linux cgroups feature to to arrange that the kernel does not schedule any processes to run on specified cores. But I can get it to start my real-time process on such an isolated core. I use memory mapping to map the physical addresses of the ARM registers into user space so that I can access them directly without going through the kernel. This way I can toggle an IO pin at 60MHz.

    Unfortunately there are still some interrupt handlers getting run on my isolated core so my toggling has 5us pauses every millisecond or so. I have yet to figure out what is doing that or how to stop it.

    My plan was to use pthreads as well. One thread running on the dedicated "real-time" core and the other running on any other core where it can interact with network and whatever as usual. I want to have a lock free queue communicating between these two threads for maximum efficiency, and in the spirit of keeping the kernel off my rt core!

    Neither the Pi nor the P2 are open source hardware. But we have more chance of building our own P2 boards than even getting hold of a Pi SoC to build anything with.
  • TI AM437x with 4x programmable realtime units @ 200MIPS each. They're fun to program in assembly and a C compiler is available.

    The similar AM3358 used in Beaglebone products has 2 PRU cores. These are complicated chips with 4000+ page user manuals and available only in BGA form.
  • Heater. wrote: »
    JonM,

    That is what I said. There is no desktop Windows for the Pi. Personally I think running MS IoT core on a Pi is an abomination.
    Agreed.

    P2 not Open Source? That is unfortunate but understood.

    My apologies if I got the thread on the wrong path. However, as far as any direct competitors for the P2, where does Parallax see the P2 being positioned in the whole MCU world? As Heater mentioned, looking at the Raspberry Pi HAT specification might be a nice approach. But, it appears there is a ton of competition in that realm from companies such as PiFace and Pimoroni just to name 2. Heck, it looks like the Propeller HAT has faded from interest and does not seem to be selling any longer. Perhaps a multi sensor board where each sensor runs on a separate cog/core and can be interfaced via SPI or another protocol might be something to look at.
  • jmgjmg Posts: 15,140
    JonM wrote: »
    However, as far as any direct competitors for the P2, where does Parallax see the P2 being positioned in the whole MCU world?

    There are no direct competitors for P2, (that would need a P2 equivalent to be shipping now) but there are application overlaps with other solutions.

    Some of those solutions might involve using FPGAs and Verilog, or they might involve many small 8b MCUs, or some larger MPU, plus effort to shoe-horn that to 'good enough' real-time (see above).

    In all these cases, the design team could easily decide that adding, or moving to, the P2 is less effort.

    It seems the easiest sales path is to focus on the 'add a P2', and let the 'move to P2' come later, as users get a better grasp on what P2 can do.

    To me, that means making modules that match what users are used to now, it may be Ardunio form factor, or Pi Zero form factor, or Pi expansion connector or all of these.

    Perhaps smarter questions are those around what needs to be included in a P2 Module, or P2-FLiP ?

    Most serious MCU development systems these days, use a USB-Firmware MCU, that does COM port and Debug Port support for the target.
    That is so expected, Parallax pretty much need to do the same.
    A good new USB-firmware MCU candidiate is EFM8UB3 - cheaper than a FT230x, & much smarter.
  • TI AM437x with 4x programmable realtime units @ 200MIPS each. They're fun to program in assembly and a C compiler is available.

    The similar AM3358 used in Beaglebone products has 2 PRU cores. These are complicated chips with 4000+ page user manuals and available only in BGA form.
    How easy is it to program the PRUs?

  • PRU sounds so PRUdish to me. I'd like to think of the P2 begin referred to as RiPPr - for Realtime integrated Polycore Processor. Here in Oz if something is a "ripper", it is something really really good like "Crikey mate, she's a ripper!" and by crikey, I reckon P2's a ripper. The emphasis is on realtime and begin able to rip through the task or rip the task to pieces, a bit for each core :)
  • PRU sounds so PRUdish to me. I'd like to think of the P2 begin referred to as RiPPr - for Realtime integrated Polycore Processor. Here in Oz if something is a "ripper", it is something really really good like "Crikey mate, she's a ripper!" and by crikey, I reckon P2's a ripper. The emphasis is on realtime and begin able to rip through the task or rip the task to pieces, a bit for each core :)
    Not a real answer of course. Really, how does the PRU compare with a COG in terms of being able to implement deterministic logic?

  • Here is some info on TI's PRU, with both a C compiler and assembler

    http://processors.wiki.ti.com/index.php/PRU-ICSS
  • David Betz wrote: »
    Really, how does the PRU compare with a COG in terms of being able to implement deterministic logic?
    Like comparing a propeller to a jet! :-P The Propeller 2 should equalize some of the advantages, generally the ones towards the top of the list. Here's how the the AM335x PRU compares to the Propeller 1:

    PRU Advantages
    Single-cycle instructions, no pipeline, 200MHz.
    System memory writes are buffered so they only take 1 cycle. (Huge for data acquisition!)
    More RAM.
    Input shift register.
    32x32 hardware multiplier.
    Registers are accessible by long, word, byte, and bit.
    Cortex A8 or better for offloading computationally intensive tasks.
    Dedicated hardware for common protocols like SPI, I2C, CAN, ...
    3 operand instructions.

    Mostly Equivalent
    Usually 16 IO pins per core accessible by register.
    Slower access to all device pins by system bus.

    PRU Disadvantages
    Separate instruction and data memory.
    Does not support self-modifying code / LMM.
    IO direction control goes through the system bus, adds many cycles and possibly not deterministic.
    Reading memory is not single cycle.
    Fewer registers, but with 30 longs it's not a significant limitation.
    No rotate instruction, replace with 2 shifts and 1 OR.
    No reverse instruction.
    No propeller-style counters. eCAP seems a lot more complicated. Fewer counter pins.
    No PLLs.
    No video generator.
    Timing control is more complicated than WAITCNT.

    It's a bit more complicated to program PRUs than the Propeller. The worst part is making a device tree overlay to configure access to the PRU pins. Then, typically you will have a C program that launches the PRU with the desired code. Once you get the Hello World running, it gets better.

    I've used the PRU as a camera interface. It is very much capable of capturing data at a 20MHz dotclock and writing it to SDRAM. There is also a logic analyzer program that is able to sample at up to 100MHz. But, where it really shined was dealing an unintentional connector pinout change. Data bits were shuffled, horizontal sync and dotclock moved, and the vertical sync was no longer accessible. Changing the horizontal sync and dotclock pins was easy. There were enough extra cycles to unshuffle the data. Then, a little bit of creative code found the start of frame without needing the vertical sync signal. Basically, the data bits were known to be continuously zero during the vertical sync. The end result was that a new PRU program seamlessly corrected the hardware mistake.
  • Heater.Heater. Posts: 21,230
    edited 2018-01-02 05:16
    If I understand correctly the PRU's are a totally different architecture than the main CPU, which is ARM.

    That means you need a whole different compiler and tool chain to build code for PRUs. I presume there is no GCC target for the PRUs only some closed source compiler.

    Then you end up with binary blobs that need to be loaded into the PRU's like firmware to any other peripheral. Hence all that messing with the the device tree for Linux on the main CPU.

    The PRUs sound great but it is far more work than I am ever likely to want to undertake unless I really have to.


    Edit: Turns out there is a GCC target for the PRUs https://github.com/dinuxbg/gnupru although that is not in the main line GCC so who know how it will be supported in the future.
  • David Betz wrote: »
    Really, how does the PRU compare with a COG in terms of being able to implement deterministic logic?
    Like comparing a propeller to a jet! :-P The Propeller 2 should equalize some of the advantages, generally the ones towards the top of the list. Here's how the the AM335x PRU compares to the Propeller 1:

    PRU Advantages
    Single-cycle instructions, no pipeline, 200MHz.
    System memory writes are buffered so they only take 1 cycle. (Huge for data acquisition!)
    More RAM.
    Input shift register.
    32x32 hardware multiplier.
    Registers are accessible by long, word, byte, and bit.
    Cortex A8 or better for offloading computationally intensive tasks.
    Dedicated hardware for common protocols like SPI, I2C, CAN, ...
    3 operand instructions.

    Mostly Equivalent
    Usually 16 IO pins per core accessible by register.
    Slower access to all device pins by system bus.

    PRU Disadvantages
    Separate instruction and data memory.
    Does not support self-modifying code / LMM.
    IO direction control goes through the system bus, adds many cycles and possibly not deterministic.
    Reading memory is not single cycle.
    Fewer registers, but with 30 longs it's not a significant limitation.
    No rotate instruction, replace with 2 shifts and 1 OR.
    No reverse instruction.
    No propeller-style counters. eCAP seems a lot more complicated. Fewer counter pins.
    No PLLs.
    No video generator.
    Timing control is more complicated than WAITCNT.

    It's a bit more complicated to program PRUs than the Propeller. The worst part is making a device tree overlay to configure access to the PRU pins. Then, typically you will have a C program that launches the PRU with the desired code. Once you get the Hello World running, it gets better.

    I've used the PRU as a camera interface. It is very much capable of capturing data at a 20MHz dotclock and writing it to SDRAM. There is also a logic analyzer program that is able to sample at up to 100MHz. But, where it really shined was dealing an unintentional connector pinout change. Data bits were shuffled, horizontal sync and dotclock moved, and the vertical sync was no longer accessible. Changing the horizontal sync and dotclock pins was easy. There were enough extra cycles to unshuffle the data. Then, a little bit of creative code found the start of frame without needing the vertical sync signal. Basically, the data bits were known to be continuously zero during the vertical sync. The end result was that a new PRU program seamlessly corrected the hardware mistake.
    Thanks for the detailed comparison! Some might consider the lack of self-modifying code an advantage. :-)
    I don't understand what you mean by
    Fewer registers, but with 30 longs it's not a significant limitation.
    What are these 30 longs?
  • It has 30x 32-bit general purpose registers. They could be accessed as 60x 16-bit registers, or 120x 8-bit registers. But that's still less than the Propeller's 496 even allowing for some of them filled with code. There is 8kB of RAM to make up the difference.
  • Heater.Heater. Posts: 21,230
    Comparing the COG space to a "normal" processors registers is a bit odd.

    Normal processors don't have 512 registers.

    Normal processors don't execute code from their registers.

  • Also, "normal processors" doesn't have LookUp Tables where, among many other uses, code can reside and be runned, and also can be shared with another core, as a general storage area.

    Add a bit of ingenuity and synchronism, and a COG can offload the routines its own code needs to get executed. in the background, into its paired COG's LUT area, and receive results at the same area, or at the HUB, or at any single/grouped SMART pin registers.

    And the paired COG, in its turn, can be using its pair's LUT, with the same objective.

    Like a digital form of table tennis, with four players (or more) and two(or more) balls (data must "bounce" into other COG's LUT, or at the HUB, or at the SMART pins registers, to be usable), in fact, because each COG can command its interrupt structure to switch between its own self-loaded tasks execution, or the ones sent by its companion COG.

    For the ones that do feel a little weird, executing register-resident code, they could simply forward the routines they craft to the COG's LUT space, and use the registers in the sense they feel more confortable with.

    Or can free themselves, enjoying such an entire new coding style, adding external memory and the streamers to the playground, understanding how to get maximum throughput to/from the HUB and the SMART pins.

    It's each one's choice! It's freedom!

    It's beautifull! :lol:
  • David Betz wrote:
    The biggest competitor to the P2 might be the P1. People may prefer the P1 for applications that require low power and I assume the P1 will be cheaper than the P2.
    That's a fair point. In fact, given the lack of asynchronous PLL counter modes in the P2, there will still be things the P1 can do that the P2 can't.

    -Phil
  • ErNaErNa Posts: 1,738
    The question should not be, what are the competitors to the P2, but which processor could be competed in which application by the P2. While I believe, we still can not imagine what the P2 can do, so replacing other processors with a P2 must show an advantage: more simple or save firmware development, resources to implement add-ons, ... But it will be hard to replace an existing solution in terms of cost. So we just should not fear for our future, because the P comes in the right moment to balance the P and we know, that something great comes from the states to the world.
  • Agree on focusing toward new solutions, rather than specific processor comparisons.

    Self driving vehicles spring to mind. And all manner of technologies and sub-systems that could improve by being more responsive to multiple real-time inputs.

    For example, and with all his resources, I suspect Elon Musk could solve a LOT of challenges with P2 that would have otherwise been (or already are) complicated, expensive and difficult to deliver reliably and on-time.

    I like to think that P2 will enable many advances that cannot yet be comprehended. It happened to some extent with P1. I hope with P2, more young upcoming minds as-well-as established industrial engineers will take a moment to see what they can achieve the P2 way.

    Sure there will always be naysayers and engineers rooted in tradition, but NASA didn't get to the moon that way!

    Be creative and innovate I say :)
  • There’s a guy “Gnarly Grey” selling UPDuino iCE40UP5K boards for $8. Are there many Boards that pair a microcontroller with a low cost FPGA? Parallax could probably make a nice educational product in this space if they thought it was worth it.
  • Heater.Heater. Posts: 21,230
    Except, it has been noted here, by Chip himself and others, that FPGA are a direct competitor to the P2 for many applications.
  • Heater - yes that’s why I put it in this thread. But perhaps a P1 plus cheap FPGA is interesting regardless. I ordered one of those boards and it did arrive, but I didn’t try it out yet.
  • Heater.Heater. Posts: 21,230
    edited 2018-01-03 22:29
    I thought we were trying to sell the P2. A P1 board including cheap FPGA from Parallax would be sending totally the wrong message.
Sign In or Register to comment.