OLinuXino, a serious Rasberry Pi competitor?

[Jasen Betts]

On 11/03/2012 05:13, Mark Borgerson wrote:

Not delivering - well that is easy.
Keeping momentum and recovering from it could be challenging.

I'm just not so sure why so many people appear to want them to fail.

Look at the price,

it's competing with thinks like Olimexino Arm7 (vs Arm11) , 128K ram
(vz 512) . no netowork (vs onboard 10/100 (over usb)), no video.

It's even challenging beaglebone, 2/3 of the features at 1/3 the price.

there's even 8-bit boards out there with higher prices.

 

[Mark Borgerson]

The toolchain were not on the RPi. It was just the target. Just the same
your point has been made, those toolchains take gigs.

?-)

So to do any programming of the RPi, you still need a PC with Linux
either native or in a virtual machine. Of course the same is true of
any other low-cost system.

It does seem disingenuous to promote the idea that you could do
significant hardware and C software development with the RPi and just
a keyboard, monitor and mouse. You really need a PC and a second
keyboard, monitor and mouse unless you plan to switch a lot of cables
when you want to test your software.


Mark Borgerson

 

[[email protected]]

So to do any programming of the RPi, you still need a PC with Linux
either native or in a virtual machine. Of course the same is true of
any other low-cost system.

Compiling KDE is a pretty extreme example. I find it rather disingenuous to
dismiss the device as unfit for any purpose just because it isn't everything
for everyone, especially when the complaints are about things that weren't
design goals in the first place.

-a

 

[Nico Coesel]

So to do any programming of the RPi, you still need a PC with Linux
either native or in a virtual machine. Of course the same is true of
any other low-cost system.

It does seem disingenuous to promote the idea that you could do
significant hardware and C software development with the RPi and just
a keyboard, monitor and mouse. You really need a PC and a second
keyboard, monitor and mouse unless you plan to switch a lot of cables
when you want to test your software.

That would be faster but you don't need an extra keyboard and monitor.
You can work remote from a Linux system. Mount the filesystem of the
RP using fuse and have the RP use the Linux system as X server for
output.

 

[hamilton]

Compiling KDE is a pretty extreme example. I find it rather disingenuous to
dismiss the device as unfit for any purpose just because it isn't everything
for everyone, especially when the complaints are about things that weren't
design goals in the first place.

-a

Very good point!!

By the way, who did set the design goals in the first place ?

Was anyone here on the committee to set the design specs ??


Anyone ??????

 

[[email protected]]

On 9/03/2012 8:54 AM, Paul wrote:


Cell phone chargers do not put out 3000 mA. They typically put out
0.5 to 0.7 mA... at least the ones I use do. I guess the "smart"
phones that run down a 1500 mAHr battery in a day might charge at a
higher rate.

Mine will charge in an hour. One of my chargers has two outputs and will
handle two phones concurrently.

I think 100 mA is a bit light though.

*WAY* too light.

 

[josephkk]

None of that is by any means trivial.

You need to put significant effort into getting that information out to
the right people, convincing the sales channel that this is the right
thing to push as well as the media.

Then get 10000 people to commit to buying before delivery

Anyone who can do that needs to put in a lot of effort.

Not delivering - well that is easy.
Keeping momentum and recovering from it could be challenging.

I'm just not so sure why so many people appear to want them to fail.

And that shirt still hasn't been ironed. No product, no win; good product
(even subsidized by Broadcom, funny situation - did they order too many
millions/) possible big win. Result not known yet.

?-)

 

[josephkk]

Look at the price,

it's competing with thinks like Olimexino Arm7 (vs Arm11) , 128K ram
(vz 512) . no netowork (vs onboard 10/100 (over usb)), no video.

It's even challenging beaglebone, 2/3 of the features at 1/3 the price.

there's even 8-bit boards out there with higher prices.

And that is supposed to mean something? It is a sloppy engineer that
cannot beat off such sloppy bean counters questions, and has a sloppy
manager for letting the bean counter get to him/her with sloppy questions.

?-)

 

[Jasen Betts]

So to do any programming of the RPi, you still need a PC with Linux
either native or in a virtual machine. Of course the same is true of
any other low-cost system.

It does seem disingenuous to promote the idea that you could do
significant hardware and C software development with the RPi and just
a keyboard, monitor and mouse. You really need a PC and a second
keyboard, monitor and mouse unless you plan to switch a lot of cables
when you want to test your software.

nah, if the PC is linux just run an X server (if this term is
unfamiliar, look it up, it's probably not what you think) on
the RPI and leave everything plugged into it.

or get a KVM switch. or just do non-graphical apps....

If it's windows (I know of people who run GCC on windows) you could
perhaps use rdesktop or VNC instead.

 

[Chris Baird]

You are complaining about high memory requirements when compiling

KDE4? Have you any concept about how big KDE4 is? KDE4 is a
marvellous desktop environment, if you like that sort of thing - but
it is huge. It is too big to run on such devices, never mind compile.

The RSS stats I posted where from compiling one C++ file. It should've
been the point that compiling a C++ program can need a significant
amount of real RAM-- far more than the 64MB in the ChokoPi that
Dontronics proposes selling.

False. Both models of the RPi will have 256MB, which is more than enough
to do self-hosting software builds (for everything but large C++
projects, and Java environments..)

 

[Chris Baird]

I mean, there were C (not C++) compilers back in the days of 8-bit

PCs with 64kB of memory, and while, yeah, they weren't as fancy as
the ones we have today, they did work and produced reasonably-sized
executables that ran a lot faster than BASIC.

BDC C, Mix-C (that I actually have the disks for within an arm's reach..)

I've got to believe that a decent C compiler that requires no more
1MB while compiling reasonably-sized programs would be entirely
viable.

A 'decent C compiler' would need to do ANSI C at the minimum--
structures, floating point, actual optimization, and really in this day
and age, have the feature-sets that everyone needs... and you end up
with another GCC (as the likes of LLVM, pcc, tcc, discovered.)
And it would need ARM platform support...

Also, don't forget the RPi has significant video capabilities as well,
in line with its "21st Century Home Microcomputer" charter. (What made
the Apple][, CBM64, and Spectrums popular..?) Headless embedded boards
like the Choko/OLinuXino and BeagleBone are forgetting that when they
push themselves as an RPi 'alternative'.

 

[josephkk]

I mean, there were C (not C++) compilers back in the days of 8-bit
PCs with 64kB of memory, and while, yeah, they weren't as fancy as
the ones we have today, they did work and produced reasonably-sized
executables that ran a lot faster than BASIC.

BDC C, Mix-C (that I actually have the disks for within an arm's reach..)

I've got to believe that a decent C compiler that requires no more
1MB while compiling reasonably-sized programs would be entirely
viable.

A 'decent C compiler' would need to do ANSI C at the minimum--
structures, floating point, actual optimization, and really in this day
and age, have the feature-sets that everyone needs... and you end up
with another GCC (as the likes of LLVM, pcc, tcc, discovered.)
And it would need ARM platform support...

Also, don't forget the RPi has significant video capabilities as well,
in line with its "21st Century Home Microcomputer" charter. (What made
the Apple][, CBM64, and Spectrums popular..?) Headless embedded boards
like the Choko/OLinuXino and BeagleBone are forgetting that when they
push themselves as an RPi 'alternative'.

Well, it seems you have finally come to your point. On the other hand the
RPi folks are targeting a bit different market segment than the others.
Maybe comparison in not appropriate, and may never be. Then again the
others are shipping, so far the RPi is still promises and samples.

?-)

 

[Nico Coesel]

nah, if the PC is linux just run an X server (if this term is
unfamiliar, look it up, it's probably not what you think) on
the RPI and leave everything plugged into it.

or get a KVM switch. or just do non-graphical apps....

If it's windows (I know of people who run GCC on windows) you could
perhaps use rdesktop or VNC instead.

Better use Xming if you want to use X 'remotely'. Works like a charm
and its pretty cheap.

 

[josephkk]

It can be fixed, I gave the link some time ago,
http://linuxtv.org/pipermail/vdr/2008-July/017347.html

Better would be to let the chip handle it,
There are so many frame rates and formats these days,
having solutions and modelines for the X server for each one
would be problematic,
Running mplayer or xine in X and having it doing resizing deinterlacing
perhaps and aspect correction just to name a few things, but then playing
50 Hz movies on a 60 Hz system does NOT make a real media player.

I am not quite sure what you are going on about here. Handbrake (thanks
to underlying tools) can convert between the two. With enough processor
power it can do it at real time and faster rates. It hurts S/N a bit, but
where were you in the meantime?

 

[Chris Baird]

Why is X limited to a fixed frame-rate, though?

It isn't. "Someone is Wrong on the Internet."

It seems like having an API to deal with an adjustable frame-rate
would be a pretty straightforward addition?

Most desktops today have disabled the "Ctrl-Alt-plus" binding
for changing screen mode on the fly, but you can put it back in,
and software that uses SDL often changes screen mode to what
it wants.

More than once in the same post, too..

in line with its "21st Century Home Microcomputer" charter. (What
made the Apple][, CBM64, and Spectrums popular..?)

Wrong, you should have mentioned Amiga [..]

The Amiga wasn't mentioned because it wasn't a system that your common
(teenage) self-taught programmer could get into-- it was a starter in
trend for personal computers being /too hard/ to program. It took a
significant amount of effort to get into programming the Amiga to do
anything more than the completely trivial like could be done in the
feature-bereft AmigaBASIC.. You want to plot that classic 3D 'eggcarton'
graph? Yeah, you were looking at 2000 lines of 68000 assembly, or 250
lines of C, that had to hook into the system libraries with pointers.. I
don't personally know of _one_ person who got started in programming on
the Amiga-- they all started on Micros, or TurboPascal on the PC.

Whereas the 8-bitter triumvirate I mentioned can give you neat results
from programs small enough to print on one page. Dozens of computer
magazines were published for exact that.

Apple?

The Apple][ was the first really popular machine with high-resolution
graphics, and got a lot of amateur programming action. HGR2 : HCOLOR=7 :
FOR I=0 TO 191 : HPLOT 0,I TO I,0 TO 191,191-I TO 191-I,191 : NEXT

 

[Jasen Betts]

I have often wondered why all the gcc crap gets so big.

it's big because it's got too many features.

It deon't convert C directly into machine language, but goes through
at-least 5 steps along the way, this is so that features only need to be
develped once to be available for different platforms or different
languages,

And that C80 compiler had a floating point lib too.
Mind you, integer was 16 bits...

IIRC there's a compile-time option for size of int on some platforms.
I think for AVR you can choose 8 or 16 bits. (8 is of course
non-standard)

I leaned to write code in a minimal C set, since those
days my programs are very portable...
And it has in line asm too....

Much of the extension to the C language is perhaps to cater for those who
cannot program or have amnesia, or even worse altzheimer,

you say that like you think C is for people who cant't handle assembler

the ISO C features don't cost you anything in the size of the output if you
don't use them, they only cost in compiler bloat.

 

[Jasen Betts]

It did although I believe it was stuck at a ~15.75kHz line rate. I.e.,
the locking was meant to support the small variations in line rate that
you'd get coming out of video recorders or cheap cameras, but it didn't
support markedly different frame rates.

Why is X limited to a fixed frame-rate, though? It seems like having an
API to deal with an adjustable frame-rate would be a pretty
straightforward addition?

I think it does xrandr changes the display geometry, and xvidtune does
(or did) the same sort of thing at a lower level tweaking the CRTC
counter limits and pixel clock

 

[Nico Coesel]

You not even understand the problem.
I have one system here with more modelines then you have ever seen
in XF86Config, and yes you can change between them with ctrl alt +/-
That is not the point, and not even that not every monitor will like that,
The point is locking the frame rate of the X server to the video played.
I gave a good link that explains it, try reading it,
The other point is that people happily play 50 Hz video on a 60 Hz
display these days, and then dare call that configuration a 'media player'.
lack of real knowledge about video.

If you have a TFT screen then the controller inside the TFT screen
will convert the incoming frame rate to the frame rate native to the
TFT panel. You are jumping through hoops for nothing.

 

[Boo]

HGR2 : HCOLOR=7 :

FOR I=0 TO 191 : HPLOT 0,I TO I,0 TO 191,191-I TO 191-I,191 : NEXT

Thank **** those days are over.

Boo

 

[Andrew Smallshaw]

So then there are the guys running a 60 Hz display, probably
most of the peesees, and feeding that with HDMI into the latest LCD TV,
and then play a 50 Hz movie on it.
I have tried all that to see what happens, and it is shit.

....and even if you DO match the frame rates you are still watching
a film originally shot at 24 Hz. Do you ever notice how films on
TV are "really shit"? No: that shows how silly the argument is.
There's sufficient latency in the eye's response that at these
kinds of frame rates a slightly inconsistent frame rate is a complete
non-issue. You can always imagine problems if you want, but the
average user doesn't care because it isn't a problem that exists
in any real-world sense.