Yeah but I don't think its niche will change as much. It fell slightly short in terms of processing power at not so many things. Obviously the faster the better though.
Actually one of the biggest failings of the original Pi was that you couldn't do timing-sensitive I/O operations on the GPIO pins reliably. If you can dedicate one of the 4 cores for GPIO processing (we're not talking a lot of data throughput here), that problem goes away. My biggest beef with the Arduino platform is that the CPU/RAM is just too small to really do much with other than act as a pure sensor<->serial bridge -- and functional GPIO means the new Pi is essentially a half-price replacement for an Arduino Yun.
You'd probably need to write the code in C/C++ (rather than Python or some other interpreted language) to get deterministic execution, but that's an acceptable limitation in my mind.
Is there an implementation of RTLinux on ARM? If so, is it (mostly) compatible with the RPi2?
I doubt that you could easily dedicate one core for RT GPIO while running regular Linux on the rest. That would require quite significant engineering both from the kernel and HW. Probably a better architecture would be something like the PRUs in OMAP SoCs used in BBB, i.e. semi-independent RT co-processors.
Besides there is lots of devices in the market positioned between Arduino and RPi. STM32 F4 Discovery board is a good example; an order of magnitude more processing power than an Arduino Uno but still a MCU designed for bare-metal (real-time) operation.
Some timing sensitive operations like PWM are possible on the old Pi by making the DMA controller directly transfer data from hardware PWM to GPIO without using any CPU cycles.
Frameworks like pigpio and servoblaster use that trick, but the standard gpio python module which doesn't use DMA has more mindshare, probably due to its simplicity.
There is an implementation of RTlinux for the RPi from the Navio guys [1], but I'm not sure if it's compatible with RPi2.
It's why I'm using Beaglebone Black for a project involving many RGB LEDs that have a timing-sensitive protocol - it has two "programmable realtime units" on-die with the CPU. It's a pair of separate cores (200mhz, IIRC) that can handle in hardware the kind of software bit-banging that needs to be done on RPi, and it shares some memory with the CPU. It's able to process or raise interrupts, too. It can handle ADC, PWM, and probably a few other TLAs that I'm missing.
Black Swift [1] guys are telling us: [2] "Want realtime I/O? Add yourself an ATtiny MCU [3] for under $1."
Black Swift is a newer, tinier single-board computer - for 'a bit more embedded' computing than the Raspberry Pi. No audio/video, but a built-in Wi-Fi. Actually, its central SoC in itself is a recent Atheros Wi-Fi chip that happens to have a 400 MHz MIPS 24k CPU embedded. Here's where Black Swift founders see themselves in comparison to the competition: http://www.black-swift.com/images/wiki/BlackSwift-competitio...
Math, lots and lots of math. The new chip has an actual floating point unit instead of it being emulated, support for the NEON SIMD extensions, both of which will definitely help in speed in dealing with any amount of number crunching. It's also got virtualization extensions, so you should be able to run Xen on it and do some level of OS development if you wanna get one for that. Really, it boils down to a lot of little differences that will line up together to make a lot of tasks on the Pi a lot easier to handle.
The previous RPi did actually have hardware FP, see http://raspberrypi.stackexchange.com/questions/545/does-the-.... I think the arch support is probably the big issue - any standard Linux distro with an armhf port will work on the new RPi. Probably gets you access to a lot more interesting Debian packages than you did with Raspbian.
Thanks for the correction. I recalled the original release of debian for the Pi didn't have floating point support, but did not recall that that was because Debian was building towards the least common denominator. I don't think you'd get that many more interesting packages with the new arch, but you probably will get a lot more usability out of the packages
