Who Will be Prop2's Biggest Competition?
tryit
Posts: 72
in Propeller 2
Who will be Prop2's biggest competition? Arduino Due? Adafruit Feather? Teensy3.6? TinyCircuits?
Comments
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.
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.
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.
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.
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.
https://developer.microsoft.com/en-us/windows/iot/getstarted
There are also on board Camera connections as well as the multiple USB Ports and Ethernet port.
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.
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.
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.
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.
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.
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.
http://processors.wiki.ti.com/index.php/PRU-ICSS
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.
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.
I don't understand what you mean by What are these 30 longs?
Normal processors don't have 512 registers.
Normal processors don't execute code from their registers.
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!
-Phil
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