next topic »

[on:]

Just wondering why ARM development boards generally run 100Mhz or less when the CPU in phone and table devices are now running up to 1.5Ghz.  Any idea?  I know they are not system-on-a-chip designs like the two development boards I mentioned in the title, but I am not sure that would account for such a huge speed discrepancy.  Why can these designs be made to run so fast and what does a 1.5Ghz ARM chip cost in quantity as used in a phone or tablet device?  I know the SOC used in the Teensy 3.0 is a MK20DX128 which is about $2.50 in quantity.  The Due uses a SAM3X8E which seems to be about $7 in quantity.  Is it just that they are too expensive or is it that there is no SOCs that run this fast yet?  Thanks!

[Reply #1 on:]

what does a 1.5Ghz ARM chip cost in quantity as used in a phone or tablet device?

The ARM chip in the Pi costs $2.x/each.

[Reply #2 on:]

I suspect people who build embedded boards are more concerned about the power envelope and how long it will run on batteries than they are about the pure speed.  While in the phone arena it seems people have gotten used to only having 1-2 days before they need to recharge the batteries in order to get the most sizzle (particularly video).

[Reply #3 on:]

1-2 days? My droid 3 barely makes it thru a 8 hout workday without dieing lol, and I don't want videos, just everything else normal people do on computers
btw doesn't this belong in bar sport?

[Reply #4 on:]

btw doesn't this belong in bar sport?

I don't think so, it's a pretty straight-up electronics question.  I am still not convinced.  I would think there is a huge hobbiest market for a fast-as-possible ARM on a development board or breakout board.  I want to see it.

[Reply #5 on:]

btw doesn't this belong in bar sport?

I don't think so...

I do.  Guess who wins the tie. 

[Reply #6 on:]

I would think there is a huge hobbiest market for a fast-as-possible ARM on a development board or breakout board.

Two possibilities:

1) all the developers are stupid: if there is indeed a huge market for such a beast and those people are forgoing their chance to be the next richest person, ...
2) the market isn't huge: the developers see it as not worthy of their time / efforts / investment.

[Reply #7 on:]

I would think there is a huge hobbiest market for a fast-as-possible ARM on a development board or breakout board.

Two possibilities:

1) all the developers are stupid: if there is indeed a huge market for such a beast and those people are forgoing their chance to be the next richest person, ...
2) the market isn't huge: the developers see it as not worthy of their time / efforts / investment.

Well, I can think of a couple more:  1.  True system on a chips at these frequences are not available so you would be making a real system which adds complexity and cost and 2.  These frequencies are more likely to create RF interference than the current ones.  I cannot say, I don't know about this so I asked.

[Reply #8 on:]

BeagleBoard.  beagleBone.  raspberry pi.  chumby.
http://elinux.org/Products

Next question?

[Reply #9 on:]

I don't think so, it's a pretty straight-up electronics question.  I am still not convinced.  I would think there is a huge hobbiest market for a fast-as-possible ARM on a development board or breakout board.  I want to see it.

Compared to the general market for embedded processors (which is where the general ARM/AVR chips are designed for), the hobbyist market is very tiny.

[Reply #10 on:]

I can think of a couple more...

I would think it isn't fair to compare those ARM chips to SoCs out there.

I would venture to predict that the hobbyist markets for those ARM chips are tiny vs. the industrial applications of such chips. The learning curve for those chips are beyond what most hobbyists can overcome.

Well, we have a few test cases to see how wrong that prediction is.

[Reply #11 on:]

BeagleBoard.  beagleBone.  raspberry pi.  chumby.
http://elinux.org/Products

Next question?

Raspberry Pi is a very interesting product, but with 8 GPIOs I didn't even consider it and, reconsidering, I still don't consider it a development board. 

The Beagle Bone, OTOH, looks very interesting.  Too bad it is a bit on the expensive side, but it has nice IO built in: 2 I2C, 5 UART, SPI, CAN, 66 GPIO, 8 PWM, 8 ADC.   Thanks for bringing that to my attention.  I saw it before and never really considered it enough to read the specs carefully which was totally my error.

[Reply #12 on:]

They are for different market: the Pi is an embedded computer and the Beagle is an embedded controller.

Try to get the datasheet for the arm chip in the Pi and you will know.

[Reply #13 on:]

Raspberry Pi is a very interesting product, but with 8 GPIOs I didn't even consider it

Are you not counting the serial, i2c, and spi pins?  Nor the SD card, external memory interface (with 256KB memory attached), (HD) video, sound, ethernet, or USB?  That's 8 GPIOs plus four "buses" capable of speaking to multiple peripherals, plus lots of "other stuff", which is pretty much more than the usual arduino...

reconsidering, I still don't consider it a development board. 

It's much more a "software development" board than a bit-twiddling development board.

This is what happens with faster CPUs.  Physics gets in the way, and you don't get to twiddle GPIO pins at the system clock rate any more.  Actually talking to peripherals becomes "expensive" compared to the memory/CPU pipeline.  Talking to things that are "off chip" becomes very expensive.  Instruction timing becomes non-deterministic because of pipelines, caches, and variability in memory timing.  The usual technique for doing IO to to put the data in a block of memory, point some smart controller at it, and say "go."

What is it you think you would DO with a 1GHz CPU and a bunch of general purpose IOs?  At some point, the "problem" becomes defining your actual requirements, rather than just saying you want it all.  You can see this in the numerous discussions about 8 vs 32 processors, or (less often) discussions about using board-level "modules" in a product rather than a design based on chips.

There have been a couple of attempts at implementing fast but simple cpu chips, and letting the programmer do all the fancy IO.  They have ... fallen by the wayside, done in by the enormous speedups that you get by doing more work within the chip.

[Reply #14 on:]

I guess I am a bit twiddler at heart.  But that all makes sense and I will be keeping it in mind.  Good point about non-deterministic machine code.  I know this to be the case on high-end microprocessors, of course, with their huge pipelines and cache memory and I was happy to see it was NOT the case when I started working with the ATMega architecture.  I see now when you get to the higher speeds you are back in that world again.