From: Jan Panteltje on
On a sunny day (Sat, 16 Jan 2010 08:56:49 +0000) it happened Nobody
<nobody(a)nowhere.com> wrote in <pan.2010.01.16.08.56.49.15000(a)nowhere.com>:

>On Fri, 15 Jan 2010 13:12:39 +0000, Jan Panteltje wrote:
>
>> I dunno, the ARM netbooks had a lot of trouble few month ago running some
>> applications (in Linux), I think some applications still use extensive asm,
>> a simple example present on all those netbooks is the mpeg2 / H264 /
>> mpeg4 ... long list... drivers. That would all have to be re-written for
>> 'RISC' architecture is asm, and as you probably know x86 has many many
>> special instructions specifically for multimedia,
>
>If you need raw processing power, the x86 is likely to win. I'd expect it
>to, given that it's one or two orders of magnitude more expensive.
>
>An ARM-based system which deals with TV-resolution (or better) video
>would typically use a dedicated decoder. I certainly wouldn't try to do
>1080p h.264 decoding with an ARM; a 3GHz P4 can barely handle it. OTOH,
>QVGA-resolution XviD (i.e. watching YouTube on a mobile phone) isn't a
>problem.
>
>For embedded applications, not only is an x86 and a software decoder
>a ridiculously expensive solution, you'd be lucky to finish a 25-minute
>episode before the battery is flat.


'embedded systems', that play full HD movies have a large screen or NEED a large screen.
That means they are big to begin with and you can then simply use a netbook or even standard mobo, or laptop.
Even my eeePC runs a 720x576 full length movie on a battery charge, when streaming it via Wifi too.
With time to spare.
If you are talking about some settop box, like the ones with ethernet in and HDMI out,
the ones that are more expensive then a netbook, and have a shitty 10 line or less character display,
I take the netbook anytime thank you.


>Very few Linux applications use assembler.

Well, you know, you can compile ffmpeg to use C only,
you what happens? It slows to snail speed, CPU usage will go up to 100 %.



> A handful of libraries use
>assembler where available, invariably with a C fallback. Even the kernel
>is only around 3.5% assembler.
From: Jan Panteltje on
On a sunny day (Sat, 16 Jan 2010 11:35:49 GMT) it happened
niks (Nico Coesel) wrote in <4b51a38c.568430625(a)news.planet.nl>:

>But be advised: as soon as you think 'I need 2 PICs for this project'
>it is time to dump the PIC and learn to use a completely different
>microcontroller. For more complicated projects using a PIC is like
>eating soup with chopsticks. PIC gets you started real fast but it
>also runs out of air real fast.

You just have no clue about how to use those PIC micros.
You keep making that stupid remark over and over again,
while it is obvious to anyone familiar with PICs that
you can use as many as you want to do as many things as you want.
Here is a nice example of a project that uses 2 PICs for a start,
http://panteltje.com/panteltje/pic/swr_pic/index.html
And guess what, both are listening on the same RS232 line,
and one does the reply work and carries the help text.



>--
>Failure impossible, failure tools...
>nico(a)nctdevpuntnl (punt=.)
>--------------------------------------------------------------

Keep dreaming.

From: Nico Coesel on
Jan Panteltje <pNaonStpealmtje(a)yahoo.com> wrote:

>On a sunny day (Fri, 15 Jan 2010 23:56:57 GMT) it happened nico(a)puntnl.niks
>(Nico Coesel) wrote in <4b50f822.524548343(a)news.planet.nl>:
>
>>Jan Panteltje <pNaonStpealmtje(a)yahoo.com> wrote:
>>
>>>On a sunny day (Fri, 15 Jan 2010 21:14:55 GMT) it happened nico(a)puntnl.niks
>>>(Nico Coesel) wrote in <4b50d744.516134265(a)news.planet.nl>:
>>>
>>>>That's where you're wrong. The ARM system-on-chips all have mpeg
>>>>accellerators. Just look closely to your CPU usage while playing an
>>>>mpeg movie. I have a pretty fast Intel based PC but it can't decode a
>>>>1080p movie. I need a video card with a mpeg accellerator to play such
>>>>movies.
>>>
>>>So, even if they do, the trend is indeed towards integrating the graphics controller with the CPU,
>>>either in the same housing or on the same silicon.
>>>The latest Intel Atoms do this, and AMD knows about it too.
>>>Why then would you release a netbook where none of the current x86 software binaries run?
>>
>>This sounds a bit strange from a Linux user. Ever installed Debian on
>>an SGI Indy? Its the same as installing it on a PC. Thats the beauty
>>of Linux. It just runs on almost anything. Netbooks included.
>
>I have Linux on a Broadcom MIPS, cross compiled from the PC.
>It will *not* run LTSPice in Wine see?

So, get another spice derivative which does compile/run on MIPS.

>And you have to re-compile *every* application.

No, you don't have to recompile every application if you have enough
storage space to install a regular Linux distro. Flash drives are very
cheap these days. If you attach a flash or hard drive to your Broadcom
system then you can install a regular Linux distro on it.

If you have no storage space, then you'll have to resort to buildroot
or OpenEmbedded. But these basically strip all the unnecessary data
away from an application (like documentation). But that is getting a
thing of the past quickly. Even the use of small C libraries like
uClibc is getting obsolete.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico(a)nctdevpuntnl (punt=.)
--------------------------------------------------------------
From: Spehro Pefhany on
On Sat, 16 Jan 2010 11:35:49 GMT, the renowned nico(a)puntnl.niks (Nico
Coesel) wrote:

>"RogerN" <regor(a)midwest.net> wrote:
>
>>Thanks for all the fantastic recommendations! It seems like for many of the
>>microcontrollers it doesn't cost much to get going at a hobby level. I
>>ordered a PIC18 something starter kit that comes with a PICkit2
>>programmer/debugger and I ordered a PICkit3 Debug Express.
>
>But be advised: as soon as you think 'I need 2 PICs for this project'
>it is time to dump the PIC and learn to use a completely different
>microcontroller. For more complicated projects using a PIC is like
>eating soup with chopsticks. PIC gets you started real fast but it
>also runs out of air real fast.

What applications have you had to implement where a 40-80 MHz 32-bit
MIPS processor with 512M of flash is so woefully inadequate?


Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff(a)interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
From: Nico Coesel on
Jan Panteltje <pNaonStpealmtje(a)yahoo.com> wrote:

>On a sunny day (Sat, 16 Jan 2010 11:35:49 GMT) it happened
>niks (Nico Coesel) wrote in <4b51a38c.568430625(a)news.planet.nl>:
>
>>But be advised: as soon as you think 'I need 2 PICs for this project'
>>it is time to dump the PIC and learn to use a completely different
>>microcontroller. For more complicated projects using a PIC is like
>>eating soup with chopsticks. PIC gets you started real fast but it
>>also runs out of air real fast.
>
>You just have no clue about how to use those PIC micros.
>You keep making that stupid remark over and over again,
>while it is obvious to anyone familiar with PICs that
>you can use as many as you want to do as many things as you want.
>Here is a nice example of a project that uses 2 PICs for a start,
> http://panteltje.com/panteltje/pic/swr_pic/index.html
>And guess what, both are listening on the same RS232 line,
>and one does the reply work and carries the help text.

So you'll have to program 2 devices, keep 2 versions of software in
sync, place 2 devices, use more boardspace and have no way to move to
a different platform without rewriting from scratch if you have to.
Sounds like an excellent product I can redesign (I actually make a lot
of money doing such projects) to cut the product cost in half using an
ARM controller.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico(a)nctdevpuntnl (punt=.)
--------------------------------------------------------------