Jump to content
Sign in to follow this  
JonnyBoats

Raspberry PI Zero for $5

Recommended Posts

Further cements a trend many of us probably saw coming a while back...

 

MCUs are eventually going the way-side, replaced by super-cheap Linux-running MPU platforms.  Except for really esoteric niche products that require ultra-low-power et al, but really at some point the cost of system integration will start to balance things around as it may emerge that it's cheaper to just find a way to provide your Linux ARM board with the power it needs vs. locking yourself into a ULP paradigm.

 

Samsung's ARTIK series is another step in that direction, soon to be available for public ordering, but even then from what I've read - the ARTIK 1, which houses a MIPS MPU/MCU hybrid, is meant to cost around $10, while their ARTIK 5 and ARTIK 10 offerings are probably comparable to similar-spec products at prices seen a year or 2 back (e.g. $50-ish for the ARTIK 5, which is comparable to an RPi 2 in spec, and $100+ for ARTIK 10 which includes the SoC used in the Samsung Galaxy S4).  RPi Zero just smashed the bar too low for a lot of players I bet.

Share this post


Link to post
Share on other sites

MCUs are eventually going the way-side, replaced by super-cheap Linux-running MPU platforms.  Except for really esoteric niche products that require ultra-low-power et al, but really at some point the cost of system integration will start to balance things around as it may emerge that it's cheaper to just find a way to provide your Linux ARM board with the power it needs vs. locking yourself into a ULP paradigm.

 

Interesting analysis. Until now, Linux is a real challenge for me on MPU platforms. I find MCU development much easier.

 

For MPU platforms, the killing application will be a nicely packaged IDE with full documentation to make developing really easy. Because MPU packs more power, part of it can be waisted on high-level programming. I haven't found this tool yet...

Share this post


Link to post
Share on other sites

Interesting analysis. Until now, Linux is a real challenge for me on MPU platforms. I find MCU development much easier.

 

For MPU platforms, the killing application will be a nicely packaged IDE with full documentation to make developing really easy. Because MPU packs more power, part of it can be waisted on high-level programming. I haven't found this tool yet...

I hear ya on the IDE et al - I think it's all very much in its infancy, but many folks comfortable with command line environments or use Linux professionally already have options that suit them- however projects such as Cloud9 on BeagleBone help and unlike some MCU platforms that are quite proprietary in toolchain or at least somewhat beholden to their silicon makers for toolchain support, MPU OS platforms offer a true open source ecosystem where better options can emerge.

 

Also, Linux isn't the only player. Microsoft's stepping into the ring with Windows 10. They tend to have well designed GUI development environments.

Share this post


Link to post
Share on other sites

Further cements a trend many of us probably saw coming a while back...

 

MCUs are eventually going the way-side, replaced by super-cheap Linux-running MPU platforms.  Except for really esoteric niche products that require ultra-low-power et al, but really at some point the cost of system integration will start to balance things around as it may emerge that it's cheaper to just find a way to provide your Linux ARM board with the power it needs vs. locking yourself into a ULP paradigm.

 

I do not really agree. The reason is pretty simple - Determinism.  Depending of course. but Linux really can not offer much in the way of reliable determinism. Even with RT-PREEMPT enabled in the kernel. With that said, Linux is probably deterministic *enough* for many situations.

 

So in short, even a "lowly" MCU such as an MSP430<whichever> can perform a specific task, or a small amount of specific tasks faster, and more deterministic than any application processor( running Linux ) could ever hope to.

 

It'd be pretty scary if someone out there, be it broadcom, TI, or whoever introduced a board at this price-point though with an on die IPU, or two . . . essentially offering the best of both worlds.

 

EDIT:

 

In addition: I've read some talk about comparing say the A8 Sitara processor core on the beaglebone's against the on die PRU, which operates at a fraction of the main core frequency. Depending on what one needs to do, the PRU can actually be faster. Despite the main cores large base speed advantage. Of course, this is on the context of bare metal( no OS ). As I recall though, this is due to the Application processors( A8) instruction pipeline depth. Where the PRU has none.

Share this post


Link to post
Share on other sites

In addition: I've read some talk about comparing say the A8 Sitara processor core on the beaglebone's against the on die PRU, which operates at a fraction of the main core frequency. 

 

The Intel Edison suffers from a similar problem.

 

The MCU is slow (tick time = 10 ms) and seems to go through the MPU to address ports.

Share this post


Link to post
Share on other sites

I do not really agree. The reason is pretty simple - Determinism.  Depending of course. but Linux really can not offer much in the way of reliable determinism. Even with RT-PREEMPT enabled in the kernel. With that said, Linux is probably deterministic *enough* for many situations.

 

So in short, even a "lowly" MCU such as an MSP430<whichever> can perform a specific task, or a small amount of specific tasks faster, and more deterministic than any application processor( running Linux ) could ever hope to.

 

It'd be pretty scary if someone out there, be it broadcom, TI, or whoever introduced a board at this price-point though with an on die IPU, or two . . . essentially offering the best of both worlds.

 

EDIT:

 

In addition: I've read some talk about comparing say the A8 Sitara processor core on the beaglebone's against the on die PRU, which operates at a fraction of the main core frequency. Depending on what one needs to do, the PRU can actually be faster. Despite the main cores large base speed advantage. Of course, this is on the context of bare metal( no OS ). As I recall though, this is due to the Application processors( A8) instruction pipeline depth. Where the PRU has none.

Well you are definitely right about the determinism et al - and my own tests with libsoc and an SPI library has demonstrated for me how dog-slow Linux can be driving protocols from userspace... So the real winner is a marriage of the two, MPU with MCU.  PRU is a bit of a shame to me because it's so esoteric and proprietary ... if only it were an ARM Cortex-M4 or something.

 

Still, I seem to recall someone made an RPi extension that included an AVR ATmega328P or similar.  That's the idea.  Put a cheap MCU onboard to handle the bullshit while the MPU rocks it ... I'll say though, I feel the cheap-MPU really kills options like the TI CC3200, TM4C1294, ESP8266 et al.  Leave the heavy communications to a "real" processor.  Then the MCU can be super cheap and small, think G2553 or G2955 or FR2033 or similar (in TI MSP430 land).  Rather than trying to go nuts with ever-higher-end (and more expensive) ARM Cortex-M options or MIPS MCUs just so it's powerful enough to handle TCP/IP when it has no business even attempting it...

Share this post


Link to post
Share on other sites

The Intel Edison suffers from a similar problem.

 

The MCU is slow (tick time = 10 ms) and seems to go through the MPU to address ports.

This is not a problem for the AM335x processors. It's a feature. most instructions executed on the PRU execute in 5ns. Those that do not, use the L4 interconnect fabric( accessing most pins, or DDR memory, etc ).  But the PRU with a few select pins. Can actually toggle GPIO at 200Mhz, which could yield a 100Mhz square wave I guess . . .which would not be very useful.

 

10ms for an MCU is simply unacceptable.

Share this post


Link to post
Share on other sites

Well you are definitely right about the determinism et al - and my own tests with libsoc and an SPI library has demonstrated for me how dog-slow Linux can be driving protocols from userspace... So the real winner is a marriage of the two, MPU with MCU.

Yeah, a problem with a lot of these libraries, is that many of these "developers" do not understand what introducing system calls, or interrupts does to software in Linux. Others, probably do not care.

 

 

PRU is a bit of a shame to me because it's so esoteric and proprietary ... if only it were an ARM Cortex-M4 or something.

 

From what I've read it has many of the same instructions that an M3 has, or can have. But yeah, I think what you're getting at is having the ability to use something like arm-eabi-none port of gcc, or something for the PRU's. Which is a shame that you can't.

 

Anyway . . .rPI for 5 bux, has me at least interested. I'm curious what all could be done with this board. Looks like 40 GPIO, and then 1x hdmi out, and 2x micro USB. They make no mention which GPU IP the processor uses . . . I'd think the same as the B/B+ but who knows ? heh

Share this post


Link to post
Share on other sites

Yeah, a problem with a lot of these libraries, is that many of these "developers" do not understand what introducing system calls, or interrupts does to software in Linux. Others, probably do not care.

 

 

From what I've read it has many of the same instructions that an M3 has, or can have. But yeah, I think what you're getting at is having the ability to use something like arm-eabi-none port of gcc, or something for the PRU's. Which is a shame that you can't.

 

Anyway . . .rPI for 5 bux, has me at least interested. I'm curious what all could be done with this board. Looks like 40 GPIO, and then 1x hdmi out, and 2x micro USB. They make no mention which GPU IP the processor uses . . . I'd think the same as the B/B+ but who knows ? heh

Yeah, C and C++ compiler plus peripheral driver library is really what I want ... heck maybe the PRU has that nowadays, what have you found?  I am pretty sure TI's C compiler for the PRU is fairly limited right?

Share this post


Link to post
Share on other sites

For those who do not know about MagPI, here is the PDF print for MagPI #40 that has 35 pages of information on the pi Zero( or so they say ). But for instance, only one of those mini USB ports is availible for external peripherals. the other is an Android like power port . . . according to MagPI.

 

https://www.raspberrypi.org/magpi-issues/MagPi40.pdf

 

BTW, for those who live in the UK, can pick up the magazine in print, and each Magazine has a free rPI zero attached to the front of it . . .

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×