SOCs: Say Goodbye To C's?

Rick Lehrbaum writes: "This [LinuxDevices.com] article describes a new class of Linux-friendly system-on-chip (SOC) ICs that are taking over the 1-chip microcontroller mantle from simpler architectures like the 8051 and 68HC11. And they're going to vastly accelerate the use of embedded Linux in thousands of new designs for intelligent devices, Internet appliances, and embedded systems. Devices covered in the article include include: Intel StrongARM SA-1110, NEC VR4181, STMicro STPC, Mot MPC823e, IBM PPC 405GP, NETsilicon NET+ARM, Aplio/TRIO, Axis ETRAX, LinkUp L7205, Alchemy Au1000, and Cirrus Maverick EP9312." I'd like a walkman-size computer based on that IBM 405GP that runs on AAs for a week ... sort of neat how open source OSes can seep into things like this.

Comments

Meanwhile, back in reality...

[Silverpike]

Disclaimer: I am a design engineer on the embedded PowerPC team, interpret this accordingly.

Before I begin: don't be misled. The 68HC11 and the 405gp are two totally different ballparks. They do not compete in the same space.

faeryman sez:

I've followed the development of the for a while now, even having a few email conversations with Jonathon Thompson, Quong Ho Thoc, and Hagr Itstein (three lead developers). I told them about a few of my concerns but it looks like marketing prevailed :(
I am relatively new with the 4xx PowerPC team, but I've never heard of any of those people; I don't think they are developers (much less lead ones).

I don't see Linux being the right tool for this. I don't want to see this product fail since I know IBM is a good company. By all means everything else they made was a success, but the IBM 405GP looks like it will be a flop.
Umm, our customers sure seem to think it's the right tool. We got so much demand for Linux on 405 that we had to hire extra people to fully support Linux. As for 405gp being a flop, I don't know what planet you are on. 405 is selling so fast that it put a strain on our short term capacity. I don't consider a chip to be a 'flop' when Ericsson, Nokia, Cisco, and Alcatel use them in their products...

(1) Security - This is a big concern for me. Imagine some evil hacker getting control of this baby...now imagine if this was used in your bank or a military instituion. See the problem?
Umm, no, I don't. How exactly do you associate a SOC device with an Ethernet port automatically vulnerable to hackers? Is the 405gp somehow deficient in this regard?

While I commend the design of Open Souce, perhaps allowing the innerworkings of this to be accessable by a hacker is not good, even more so when it's an embedded system.
You are confusing connectivity with security. This article is about SOC's, and as far as their design is concerned they must be properly secured like any other computer system. Save the security tirade for a different forum.

(2) Expansion architecture - Check the specs on this thing. While a PCI slot is normally a good thing, wouldn't MCA or a propietary bus be better suited for this?
Are you f*cking kidding me? MCA? How many MCA devices can you buy? Not just cards, I means chips (which is what the vast majority of 40x's will be talking to). Almost zippo. Now how many different PCI devices do you think you can find?

Linux runs on the MCA fine, and I think it's low overhead and fault-tolerant properties are better than a run of the mill PCI slot for this. Or a new bus design could be implemented. IBM benefits with better performance, we as a comunity benefit from more GPL code being released. Sound good?
Absolutely not. The whole point of choosing PCI is because it is commodity, fast, reliable, and supported by almost every modern OS. It seems that you are desperate to reinvent the wheel here.

3) Operating system - [flamesuit] I like Linux, but I don't think Linux is the best tool for this. IBM has made the decision to go with Linux, so I'll respect that.
Like I said before, our customers want Linux. Linux is not the only OS we support. Actually you can put damn near any OS on the planet on it; IBM doesn't have support for them all however. You want a lighter weight OS than Linux? Fine, use OS/Open, which is IBM's little creation (works very well and supported too).

Scalibility and performance are key here, and QNX can deliver better than Linux.
Well, if you think so, then there's no reason you can't run it on 405gp.

Again, I don't like being negative but I don't think the IBM 405GP will do that well. I want to be proved wrong though, I want to see Linux progress and gain market share, and I want to see IBM be profitable....but Linux just ain't gonna cut it for this one my friends. Please tell me I'm wrong.
Well, since you asked so nicely... :)

Goodbye? I think not

[Matt_Bennett]

I've been building in PICs and AVR microcontrollers into a bunch of devices, and I can tell you, for sure, that they still have a long lifetime ahead of them. I've designed devices that are made in 10's quantities and in 10,000+ quantities and I have a few comments:

When you are designing with microcontrollers, you use the smallest and cheapest that will do the job. It is all about the appropriate use of technology. You don't need Linux to run your microwave oven. 99% of the microprocessors used in embedded systems don't need that much power. They aren't located in PC/104 bussed computers, they aren't in computer racks, they are in devices that are all around us, but not noticed: your microwave, your cell phone battery charger, your car alarm remote... and so on. Price is a very sensitive issue. These system-on-chip devices are very expensive- running $50+ each! If all I need is a $0.73 PIC to do the job, you're a fool (and soon to be unemployed) if you don't use the PIC (or AVR, or COP8, or whatever the latest, cheapest part is)!

The power of a real operating system is undisputed, but use it where appropriate! Rick Lehrbaum's white paper on using 75-200 MHz SOCs to replace 68HC11s and 8051s is ludicrous. If not for the simple fact that 99.9% of your clock cycles would be wasted, think about all the power (electrical) that would be wasted. Sure, Transmeta has some impressive MIPS/Watt numbers, but it doesn't scale well as you go lower. Many applications just don't need that much power. I can run a PIC off a 32 KHz crystal and only draw 50 microwatts off a power source. Not a one of the processors that Rick Lehrbaum mentions will be able to approach that low a power draw, even with a stopped clock.

Microcontrollers are going to be here a long time, just like we still use discrete transistors when we need to. Yes there are some applications that can use these systems on a chip, but for full acceptance they will have to be *cheap*, coming in at a price less than $10.00 each, and preferably less thann $5.00. It will take years for that to happen, and even then, we will still be using microcontrollers. I don't need 20 MIPS to run my microwave or my battery charger, or even my watch.

Eight Bit Devices Won't Die

[pjrc]

For the last 6 years or so, 16 bit microcontrollers have been predicted to generally replace 8 bit devices, but the trend has been very slow. The market for 4 bit chips, as I recall, as finally shrunk below 10%, but 4 bit chips are still in widespread use!

I design products with 8 bit devices, and I've used a couple larger chips here and there. There are many important features that designers need in microcontrollers:

• LOW COST !! 50 cents less times 10k units/month is a big deal. You could task an engineer for a couple man-months to rewrite code for a 50 cent lower CPU, after an initial release. Usually using an 8 bit chip instead of a 32 bit solution saves at least $10, sometimes much more.
• Low power consumption, under 4 mA is what I generally consider low power. A few years ago I designed a product that uses 9 A, 32 kHz CPU, wakes from full shutdown at 4 Hz. Try that with a linux-capable 32 bit chip! Low power also means a low cost power supply... at 1-2 mA, a resistor and zener diode can sometimes be used!
• Multiple vendors, or at least some assurance that the components will be available in the required quantities.
• Programmable program memory on-board... with in-circuit firmware download is a plus.
• Small physical size

Often times these considerations at much more important than cpu horseposer. For example, Microchip took off about 6 years ago, offering one of the most limited feature-poor instruction sets on the market, but they did all the important things very well. Their chips were cheap, low power, small size, and they offered EPROM based chips at low prices.... but the most important thing they did was they offered flexible purchasing, made possible by selling blank EPROM based devices, at a time when Motorola had inflexible purchasing requirements for masked-rom based parts.

Most projects in the embedded market just don't need a lot of CPU power. At high volumes, it's easy to pay even the most expensive engineers and programmers to re-write code to run on a cheaper chip.

I should probably disclose that I have a small website with 8051 related resources (open source), so take my words with a grain of salt, but until 32 bit microcontrollers are less expensive and use less power than their 8 bit competitors, I'd expect the bulk of the market will probably stay with the 8 bit chips.

But do we need them?

[Cerlyn]

While doing web scripts, I often find myself writing simple databases. These forms do trivial things like take a users form and add it (comma or tab seperated) to the end of a text file. While I could have used a complete SQL backend, I chose the simple append to file approach. This is because my forms were purely meant to be imported into a database on another system - there was no need for them to be entered in a manner where they would be quickly searchable locally.

So instead of connecting to an SQL server, logging in, sending the command "INSERT INTO mytable VALUES data_1, data2,..., data_n;", waiting to hear if it worked, and closing the connection, I simply appended a line to a file. When I wanted to read the file, I downloaded it, viewed it locally, and zeroed the online copy so it could be filled again. What is wrong with that?

Compare this to my work with microcontrollers. I do work on Z180's, the PIC series, Basic STAMPs, and the 68HC11's (you can get a good student deal on these from Motorola - ask them). I have done work in both C and pure assembler (or in the case of the stamp, their BASIC). Guess whose programs comes out largest? Those in C. While the assembler routine itself for the task at hand is similar, a bunch of additional preloading code added by the C compiler is added. Imagine how much bloat a crude real-time operating system (RTOS) such as Linux would add if I did not need it.

If I'm purely watching inputs and outputs, and need to scan a few interrupts, I do not see the need to have Linux in my design. Granted, I'm a huge Linux user myself, but putting a stripped-down version in a microcontroller seems to be like shoving an elephant into a tin can. Real-time OS's for microcontrollers have been around for a while; some are designed to take up less than 2 KB. Why do we need to adapt Linux to a task that has already been solved?

Glad we're finally getting rid of those...

[Imperator]

...annoying microcoulombs. If there's one metric unit I can't stand, it's the C. In fact, the prefix should be removed entirely, because you need to use the HTML character entity µ, which timothy doesn't seem to know about.