Can TI compete with Raspberry Pi?

Hi,

is a beagle device comparable to the rasp pi at a similar price point possible?

I really think the raspberry pi is crossing an important price boundary as it is now in the range of
ordinary microcontroller dev boards and is a direct competition to all those AVR and PIC based
boards. And this may imho really make the difference.

Any plans to be as competitive with a TI based unit? There's imho a huge market for "Linux based
microcontroller replacements" where the key factors are price and power consumption as these
are usually the main reasons to not choose a linux board. Additionally Linux adds the
wlan/ethernet/ip connectivity all current µC based boards lack. This is really is something many
people are waiting for (yes, i know uIP and LwIP, but these are pretty limited).

Regards,
   Till

ARM11 is not compatible with float operations. So here BB beats it.

Hi,

is a beagle device comparable to the rasp pi at a similar price point possible?

Under a similar business model, I’d certainly expect it to be. The primary SoC cost for an AM3352 in 100k unit quantities with standard lead times is $5. Supplying the voltage rails can be done rather affordably. The memory and connector costs for a similar board would of course be rather similar and the AM335x devices are optimized for an affordable PCB layout and assembly.

I really think the raspberry pi is crossing an important price boundary as it is now in the range of
ordinary microcontroller dev boards and is a direct competition to all those AVR and PIC based
boards. And this may imho really make the difference.

I agree. I believe the BeagleBone is extremely affordable today and there is a bit of you-get-what-you-pay-for. The CPU performance and interconnectivity of the BeagleBone is clearly in another class. Further, CircuitCo has been very kind with handling RMA issues, we have some great value-added distributors and it is quite reasonable for other companies to build hardware for similar or lower price points. We’ve tried to stay true to the Open Hardware movement. It is clear, however, that simply reaching a price point does something to energize people around the platform and I personally feel motivated to try to energize all parties involved to see a roadmap to price cuts as costs are able to be removed from the system. Profit from the board sales isn’t a high priority, but to remove it entirely would, in my view, remove some valuable players in the ecosystem and risk the longevity of the project.

Any plans to be as competitive with a TI based unit?

I personally think it would be great if RPi were to consider using a well-documented and broadly available TI based unit over their current choice. And if someone wanted to start-up a similar project with a TI processor, I’d be in support of that too. However, I think we all benefit from RPi advancing the state of access to ARM systems and educating people to program on ARM, so it isn’t in my motivation to try to push TI to supply something that would fragment/confuse the market and reduce the overall success of such initiatives. While I think it could be sufficient benefit enough to simply move from an armv6 architecture to an armv7 one with better documentation and broader availability, I would want such a project to be compelling enough not to simply confuse potential buyers, but something clearly better.

There’s imho a huge market for “Linux based
microcontroller replacements” where the key factors are price and power consumption as these
are usually the main reasons to not choose a linux board. Additionally Linux adds the
wlan/ethernet/ip connectivity all current µC based boards lack. This is really is something many
people are waiting for (yes, i know uIP and LwIP, but these are pretty limited).

I agree and I believe the AM335x line is uniquely qualified to satisfy that demand. What can I say but I think RPi chose the wrong processor? We live and BeagleBoard.org clearly offers compelling products that satisfy most of the demands of people looking for affordable, low-power, quick-to-expand Linux (and other high-level operating system) solutions with a great community of developers who don’t feel trapped in what they can do with their designs.

This is not a goal or a vision of any plans moving forward, but in my experience it is common to see new products launch and products that occupy the same space either offer new SKUs or in some other way seek to compete—and I guess that might be largely what is motivating your e-mail—that you’ve seen similar patterns. With the timing of things, however, I suspect that you’d likely see a new product launch and examine how it does in the market before existing vendors would lock themselves into a singular response to the rumors.

Anton Komarov <akomarov@nvisiongroup.ru> writes:

ARM11 is not compatible with float operations. So here BB beats it.

That is not true. Most ARM11 implementations have a VFP floating point
unit.

I almost forgot…

You can get Beagle stickers as well:
https://www.adafruit.com/products/674

(I couldn’t resist making at least one snarky comment about that being all that is available for purchase on their website.)

My hope is that RasPi will actually help BeagleBoard and BeagleBone.
Assuming the Chinese-made RasPi boards work reliably, RasPi has the
potential to introduce many enthusiastic people to tiny, low-power
computers running GNU/Linux. Many of them will hit the memory and I/O
limitations of RasPi, and the jump to a BeagleBoard/Bone is much
shorter and cheaper since they'll already have all the needed
peripherals and GNU/Linux knowledge. Weaning people away from closed
systems and from consumption devices helps everyone.

The performance of an ARM11 processor, or rather the standard specs of RPi is probably “good enough” for “lot of” potential applications which till date were possible only on BBone/BB/BBx. This is simply so because of the SBC price (less than half of the bone), good-enough / just-enough documentation and community activity. Of course, RPi has created tremendous amount of anticipation, and so far apart from stickers, labels, QR codes, posters etc., only some lucky very few have even held the thing in their hands, let alone program it or hack it. I certainly hope that it lives up to the expectations.

That said, I think I completely agree with John’s comment, that by-and-large RPi would help the ARM open SBC ecosystem.

Not sure it rather could process mp3 encoding with even 8000 Hz. On
BBxM it takes 5 percent of CPU on 800 MHz.
If we would talk about 44100 Hz encoding it will eat 40% CPU on
1000MHz. What will happen with Rasp in that case? I am pretty sure you
can guess. Rasp could be effectively used in non-multimedia tasks as
BBxM could be effectivly used in both cases. I wonder when TI will
make audio encoding with DSP?

I think RPI should to improve a lot to compete with BB:
- RPI should be abaliable. It isn't and maybe it will engross its
delaying history.
- It is not as well documented as BB, and probably it won't ever. At
this point RPI's documentation is a joke.

Its worth noting that the rpi price point is reached with integrated gfx and hdmi output. So it’s able to target a broader beginner market, than the Beagle can at the moment. The cost of adding gfx and audio output significantly adds to the complexity and price for people new to these platforms.

At the moment I see BB and rpi aiming at overlapping but slightly different audiences. If you want more GPIO etc then BB wins hands down.

I see the BB as a logical step up for rpi users if they want to expand into a more hardcore SBC environment.

So the two should complement each other well.

Just my 2c worth :wink:

T

Anton Komarov <anton.komarov@gmail.com> writes:

I am talking about lame. Right now i am writing scripts to turn BBxm
into digital recorder for Uniden radio scanner and get enough
experience with lame and can estimate overall BBxm performance.

The R.Pi GPU is capable of 24 GFLOPS of general-purpose compute, but for licensing reasons only h.264 and MPEG4 (plus some license-free) codecs will be exposed at launch time as I understand it. It will be interesting to see if and how Broadcom exposes more of that general-purpose GPU grunt in the coming months and years.

Either way, with 1080p30 h.264, Open GL ES 2.0, Open VG, EGL and OpenMAX support from launch, it should offer some very impressive bang for buck in a number of (arguably somewhat specific or focussed) media use cases.

http://www.raspberrypi.org/archives/592
http://www.youtube.com/watch?v=4NR57ELY28s&feature=player_embedded

What I fear will happen is people wanting to run a 'desktop' on that 1080p screen. The original beagleboard (720MHz cortex A8) needed a lot of tweaking for that to become "usable" and people were disappointed with that. On the Pi you'll have to explain that decoding 1080p h264 works fine, but minesweeper is glacially slow...
But yeah, XBMC will do nicely on the Pi.

regards,

Koen

The Pi has a Broadcom BCM2835 Soc containing a 700 MHz ARM11 ARM1176JZF-S core.
According to the tech manual [1] this core has a VFP unit.

[1] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0301h/Cegdejjh.html

Frans

PS: I hope the Pi is a little bit less picky wrt SDHC than the BB

Frans Meulenbroeks <fransmeulenbroeks@gmail.com> writes:

Anton Komarov <akomarov@nvisiongroup.ru> writes:

ARM11 is not compatible with float operations. So here BB beats it.

That is not true. Most ARM11 implementations have a VFP floating point
unit.

The Pi has a Broadcom BCM2835 Soc containing a 700 MHz ARM11 ARM1176JZF-S core.
According to the tech manual [1] this core has a VFP unit.

It does indeed, as indicated by the F in the core designation.

[1] Documentation – Arm Developer

Frans

PS: I hope the Pi is a little bit less picky wrt SDHC than the BB

BB picky? I had not noticed.

Frans Meulenbroeks <fransmeulenbroeks@gmail.com> writes:

[...]

PS: I hope the Pi is a little bit less picky wrt SDHC than the BB

BB picky? I had not noticed.

I have a number of cards that work fine in an SD reader but give
occasional transfer errors -110 on beagle. Iirc they worked also fine
in my camera.

see eg my post at
http://groups.google.com/group/beagleboard/browse_thread/thread/60d79985a34047f5)?pli=1

I tried one of those cards with ubuntu on beagle bone a while back and
bumped into the same issue. Didn't dive further in it.

Frans

I think the SD Card issue is a fundamental problem for the embedded
Linux industry as a whole. These HC speed ratings etc. are basically
for cameras ... not the way we are using them (filesystems etc.). So
the HC speed rating is basically meaningless. If you google this
subject you'll find out lots of good info about various vendors and
which ones work well for filesystems etc. I doubt that the problem is
unique to BeagleBoard or PI, I think it is a function of how the cards
are used with Linux in general but I could be wrong.

There are people out there testing cards and posting their real
performance data in r/w operations on various Linux filesystems.
Hopefully the manufactures will get wind of this and clean their act
up and come up with a rating scheme that reflects reality.

Regards,

Brian

For me 'errors -110' were only on latest 2.6.32 kernel from Angstrom
recipe. They were not occasional, they were constant. So the problem
lays somewhere in a piece of code not silicon.

There was a patch a while ago on this mailing list which came from
inside TI and incremented a delay counter (by 2 from memory but I
may be wrong). There was a question as to whether this fix could
go into the mainstream and I suppose it may never have. Maybe
someone needs to push it.

David