Re: Looking for Microcontroller Recommendations

On a sunny day (Fri, 15 Jan 2010 03:35:11 -0800) it happened John Larkin wrote in :

>>The future seems to be the ARM architecture. >>> >>>John >> >>I bought a book on ARM in the eighties? I was also the future then ;-) >>But somehow x86 grabbed it. > >x86 has - for now - won on the desktop, but there are around 100 >embedded uPs for every PC, and the embedded chips aren't x86. Some >netbooks are ARM+Linux, and that may be an increasing trend. > >There's no justification for putting a hundred dollars (or more) worth >of power-hogging x86 CPU into a web browser or a cell phone. Some of >the low-end ARM chips cost well under a dollar now, and there is some >awesome stuff for $5 or so. > >I'm sorta hoping that Intel will be the next DEC, except that I miss >DEC. > >John

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, Let's look at an old one here: # cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 3 model name : AMD Duron(tm) processor stepping : 1 cpu MHz : 959.526 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow bogomips : 1920.77 clflush size : 32

So, mmx, 3dnow, give the x86 an incredible speed advantage over ARM, as ARM will have to to a zillion asm instructions for every high level x86 instruction. It is possible (I did not keep up after that book in the eighties) that ARM also added some special multimedia capabilities, but then again there is the overhead of re-encoding. So I do not expect ARM to make big inroads into personal computing and especially multimedia soon. Why do you think Apple left their old architecture for ix86? Multimedia likely!

Then there is that power issue you mention, sure, but my last encounter with an ARM was on the SkyStar1 PCI satellite receiver card, and that was a power hog so bad it needed an extra fan, and I finally was glad to get rid of it, and replace it by a new card that uses the PC's processor only.... I am not sure if it was the ARM that got so hot or the TI 7010 chip in retrospect, but for me it associated ARM with power hog. I know about the latest netbooks with ARM appearing on the various exhibitions, but why bother? As I wrote in an other post, for embedded, you can use PIC, and then the next step up is a small motherboard (and they come very small these days) with a x86, maybe Intel Atom or something along that line, AMD second source almost. readily available, all software almost or completely for free, portability, asm or C, or even your Power Basic. Unless your PowerBasic is written in C without inline asm, will it appear on ARM? Well maybe it already does, seems a lot of extra work for no gain. What is a Watt? That is even if it saves a Watt or 2, what is the total power consumption of the thing you are making? If you are controlling a 700 kV HV cross ocean DC line with 10GW power? I write that because I just did read the 700kV line here has been operational for some time, and I did not know about it! And now they are planning more all over Europe to make it possible to distribute wind power and maybe solar power so there is always some power, and always there is some wind somewhere.... but no sun at night, solar eclipses... mm let's have nuclear power please. Drifting of topic, what was the topic? :-)

Reply to
Jan Panteltje
Loading thread data ...

long list... drivers.

probably know

Nope. Those drivers are already included in every major OS for ARM. See below.

will have to to a zillion asm instructions

also added some special multimedia

especially multimedia soon.

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.

You really should catch up with ARM. There is a lot of exciting stuff going on. From the ultra low power small '16 bit' LPC1100 series by NXP to the Cortex A8/A9 stuff from TI, Freescale and Samsung.

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

On a sunny day (Fri, 15 Jan 2010 21:14:55 GMT) it happened snipped-for-privacy@puntnl.niks (Nico Coesel) wrote in :

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? Everything needs to be recompiled, and all codecs have to be re-written. For ***what*** gain? ARM is not _really_ using that less power. I would never buy one, too much incompatibility. And vendors of such high speed media applications really are not longing to write yet an other driver or codec in asm either. Not even for Linux, and most certainly not for just a few ARM based notebooks. And MS windows would likely not run on it either, unless they wrote in 7 in C.... All it's applications are closed source binaries, so forget that market!

Well, a simple x86 motherboard will do for now, if it has a par port, then you can even test 2x40 character LCDs with it :-)

Right I just ripped the pins of a W3100A, I know I should not have tried to bend those back and get some solder wick, but alas, I was out of solder wick sooo. hehe

Reply to
Jan Panteltje

controller with the CPU,

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.

Nope. That work is already done. You should get your facts right before commenting. I'm using Linux almost daily a non x86 embedded platform so I do have some real experience in that field.

A x86 platform is still very inefficient. We looked into the Intel Atom and a Cortex A8 devices for a new embedded platform. The Atom just isn't suitable for real low power and small size due to the chipset. Also the price versus performance isn't that good compared to Cortex. Together with the commonly found hardware openGL and hardware video codecs (not included in the Atom!) a Cortex device has some serious muscle.

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

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.

Very few Linux applications use assembler. A handful of libraries use assembler where available, invariably with a C fallback. Even the kernel is only around 3.5% assembler.

Reply to
Nobody

On a sunny day (Fri, 15 Jan 2010 23:56:57 GMT) it happened snipped-for-privacy@puntnl.niks (Nico Coesel) wrote in :

controller with the CPU,

binaries run?

I have Linux on a Broadcom MIPS, cross compiled from the PC. It will *not* run LTSPice in Wine see? And you have to re-compile *every* application.

So do I, but this was about netbooks, not about some system you have the sources for. Let's face it ARM sucks :-) ix86 is soooooooooooooooo much better :-)

I am sure there is some nice for an ARM here or there, 'embedded' takes a whole different meaning these days. If it needs a user interface why not buy an netbook and simply stick your I/O extension in a USB port. That gives you WiFi, Ethernet, serial via adaptor, display, keyboard, of the shelf, in 10 minutes to speed to a PC shop. then you only need to design the USB I/O box. This is what I do, and so much less worry.

X86 not efficient? You must be joking, the new netbooks run 8 hours on a battery charge.

Na x86 is the future, it has proven itself, after all we all want to run LTSpice on the Linux cellphone in Wine. hehe

You should have use a x86!

Reply to
Jan Panteltje

On a sunny day (Sat, 16 Jan 2010 08:56:49 +0000) it happened Nobody wrote in :

'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.

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 %.

Reply to
Jan Panteltje

controller with the CPU,

binaries run?

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

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@nctdevpuntnl (punt=.)
--------------------------------------------------------------
Reply to
Nico Coesel

On a sunny day (Sat, 16 Jan 2010 15:53:57 GMT) it happened snipped-for-privacy@puntnl.niks (Nico Coesel) wrote in :

Well, there are no better Spice then LTSpice

You are WRONG. Executable code that runs on a x86 will NOT run on a MIPS. That is a very silly mistake you make here, I hope you do not design embedded. I actually modified the Broadcom system so it HAS an external storage, It runs a backup webserver.

formatting link
Connect to it here: http://81.207.135.196:82/index1.html Even that needed cross compiling.

What do you think 'install a Linux distro' means anyways? What code do you think the installer uses? Where does it get the MIPS version of gcc? Linux distros only install binaries, and the source is available optional. If you want to run on an other platform then X86 then you need to compile *all* sources for that.

Man, such ignorance!

Nothing to do with it.

Reply to
Jan Panteltje

Except for the crappy user interface.

You are even more silly to suspect that I propose to run x86 code on a MIPS platform. I'd install the MIPS version ofcourse! Or the ARM version.

The code that is used on your platform.

sources for that.

No! You are so terribly wrong here! Look at this page:

formatting link

Scroll down on this page and you'll see you can choose a Linux installer for 11 different platforms. Each installer will put Debian Linux on your system (if you choose the right platform for your system).

Several years ago I had an SGI Indy (MIPS based). Debian worked fine out of the box.

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

On a sunny day (Sat, 16 Jan 2010 19:20:06 GMT) it happened snipped-for-privacy@puntnl.niks (Nico Coesel) wrote in :

I have no problems with that user interface. Have experienced much worse ones :-) I consider it excellent.

See my previous comments, the parts that need speed, likely will be compiled from C, not using the much better inline asm, so the performance will suck, not only because it is now an ARM without multimedia instructions, but also because it now runs in some compiled inefficient stuff the C complier came up with. Try ffmpeg for example, the basis of mplayer and much of the stuff I do. You need a 4 or 10 x faster processor without that asm stuff, if it runs at all. The ARM netbooks on the exhibitions recently crashed a lot. Nowhere near ready for prime time. And why bother when Atom is better?

*all* sources for that.

OK, so they pre-compiled for a lot of processors. That still does not solve the native driver problems. It is *still* binaries, recompiled.

I got the sources from the Linksys site, including the cross compiler, and compile everything on the PC. The target has only 4GB FLASH, so not really space for gcc. I can just re-flash it,. I can flash it via JTAG too. As lot is highly specific related to the hardware I do not think Debian would have a chance running. For a start there is just enough space to run a busybox. However it shows a very interesting aspect of embedded design, this example: You can get a nice Ethernet module for 26 Euro;

formatting link
Seems cool, no? But if you are smarter you get this for 55 Euro:
formatting link
Now you have a RJ45 connection, software, can connect to any PC, WiFi on top, runs Linux, has hidden serial port (that I use), that can be run with my e2s software, so serial to ethernet,... can be extended with an SDcard as I did, DC adaptor, many more advantages, antennas, comes in a nice housing. So if I was to design in that ethernet module I would need ++++Euro other stuff.... So, embedded that way becomes more looking for boxes that can be used in a smart way. If you hang my I/O PIC from it it has all of the sudden:

8 analog input channels with 10 bit resolution. 2 digital input channels. 5 digital output channels. 1 PWM output channel (0 to 100).
formatting link

Why bother with yet an other ARM board running yet an other processor hug? I/O pic also runs from a netbook with USB to RS232 adaptor. And now you can develop on the PC, even faster without cross compiling if it is a x86 netbook. ARM is DOA.

Reply to
Jan Panteltje

from C,

because

More unfounded comments without doing proper research first. Seems libavcodec (one of the cores of ffmpeg) has assembly routines for several non x86 platforms including ARM:

formatting link

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

On a sunny day (Sat, 16 Jan 2010 21:40:02 GMT) it happened snipped-for-privacy@puntnl.niks (Nico Coesel) wrote in :

from C,

because

all.

So how fast does it run on ARM (with that asm , I just looked at it), compared to a modern Atom with integrated GPU? Any benchmarks? It looks a bit primitive to me, but then again the register shuffle you have to get used to :-)

Probably unstable too. And it cannot even run LTSPice in wine, or any other of the many apps I have in wine. It cannot run MS windows 7, and neither any of its zillions of applications. No advantage, even sucks more power then a modern Atom. DOA.

Reply to
Jan Panteltje

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.