Slashdot Mirror
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.
For my senior project, I used an HC11 to a) receive and interpret X10 home automation (extended) codes and b) act as an LCD clock. The idea was to show that you could use many of these cheap devices anywhere in your home and they could all be kept in sync.
Best of all, it worked! With less than 1024 bytes (BYTES) of memory to play with... Imagine what you could do with 16 or 32k.
I mean, using C or any other high-level language, you can barely even compile a "Hello world" inside of 1k.
uCs may not be as elegant as a SPARC, but they've got their uses. Even if it's only for hobbyists and students. You gotta start somewhere.
Also, I don't know what kind of HC11 you're programming, but last I checked, B was an 8-bit register, while X was a 16-bit index register. It's gotta be tough for Motorola's engineers to justify an instruction that only copies B to X.
Besides, you could do that with: CLRA, XGDX. It's not at all counter-intuitive.
--
First of all, I have been working on MicroMouse for the last two years, and one of the things I have been really been hunting around for is a microcontroller that has enough memory (both flash and RAM) as well as enough processing horsepower to do motor control, navigation, etc. We needed something with built-in serial interfaces, timers, interrupts, I/O ports, etc. because we wanted to make this thing as small as possible. I have looked at many different parts including PICs, the SX, various 80186 processors, the Hitachi H8 and SuperH, ARM, and many others that I'm not thinking of right now. The first thing I've learned about these devices is that the newest ones (and the ones we wanted to use) use either insanely small pin spacings (which requires a custom PCB) or they are of the BGA type (which requires a minimum 4-layer PCB with soldermask as well as special mounting equipment). We finally settled on the Hitachi H8S/2357 even though it was a 128 pin QFP with 0.5 mm pin spacing.
The things I don't like like about these newer, highly integrated processors are that they are more expensive, they tend to be a pain to mount, and chances are, you probably don't need that much processing capacity anyway. While our current versoin of the MicroMouse uses an H8 as the main processor, it also uses a couple of SXs to operate the sensor array. While these SOC's will certainly have a market, it will certainly not eliminate devices like PICs and other smaller microcontrollers from the industry.
- Not scalable Your design implies that only one person can add data at a time. Which is fine for a small operation, but if you get a few additions per second then you either corrupt your file (two write handles open) or generate errors for the others. Allowing the others to be delayed is starting to write more backend stuff.
- Not instant Using your method means that data inserted into the system won't show up in the application right away - they have to wait until you do it manually. This means either more work for you, or another weak link in the chain, such as a script run from cron.
- Not universal You can only have one application writing to the file, otherwise you need some API or have multiple copies of the code (never a good idea.) SQL is universal across languages and platforms. SQL isn't quite, but pretty close to Java's Write Once Use Anywhere.
These days, using a database from any kind of application, especially form-handling web applications, is trivial.In my opinion, not scalable is a big problem.
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...
The opinions I post here have nothing to do with my employer.
It's not about people not knowing how to program anymore. The original post is accusing the HC11 of having "crappy assembly". I'm just coming to the defense of the HC11. I'm sure there are many good programmers who have never touched assembly.
Furthermore, it's not "crappy assembly" to have a single TAB instruction instead of a flexible MOVE A B... That TAB instruction just saved me two bytes in the program over your "better" MOVE instruction. If it's really so difficult to grasp, then find a good assembler that recognizes what you want to do when it sees "MOVE A B".
You just have to do things a little differently down there... by getting dirty with the bits moving around, you can often realize huge memory and cpu savings.
--
Disclaimer: I am an IBM employee working on the PowerPC 40x cores. Adjust interpretation accordingly.
:).
spoonboy42 sez:
For battery operated devices such as handhelds and webpads however, they use considerably more power than their competition: The StrongARM, the Crusoe, and the (admitedly far less powerful) Dragonball and Coldfire. Performance-wise, the StrongARM is in about the same class as embedded PowerPC models, and the Crusoe is set to blow everyone away
Not totally true. The IBM 40x series does compete directly with ARM. Performance-wise, we do have a small edge over ARM. Power-wise, ARM has a small edge over PPC 40x. However, neither are anywhere close to realm of Crusoe in terms of power consumption.
I don't know Dragonball and Coldfire that well, but I am reasonably sure they don't compete well with ARM or PPC 40x in either power or speed.
Crusoe consumes, IIRC, in the realm of 4W avg. 40x chips consume less than 1W (including on-chip peripherals), and ARM is even less (500mW I think). So it's a big tradeoff. You pick your chips based on where you want to be in that power/speed curve.
So in short, if there's a power outlet handy, go with PowerPC, but to maximize battery life, StrongARM and Crusoe are the way to go.
That's a myth. Don't know where you got that idea, but I'm glad I could dispell it for you
The opinions I post here have nothing to do with my employer.
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.
Linux is nice and all.. but I don't really want it running my car.
The more complex an OS, the more likely bugs and security flaws will creep in (Linux hasn't shown itself to be an exception), so I'll take an OS that is proportional in size to the device it is controlling.
Strange they didn't mention ZF Linux, the company founded by PC/104 inventor David Feldman. They have had an SOC out for a while that comes with Linux installed, and they just introduced a new low-power version (586; 1/2 watt @ 133MHz).
EMJ will be their distributor.
Go check out lineo.com or something PLEASE!!.
:( This post is not informative its.. WRONG
I am a fanatic for the Open *nix Os's but trashing linux here did you no good.
Lineo is like majorly scaled back.. Did you have an inkling of what these projects were even doing before you decided to trash the security/blah blah blah of a regular Linux system? No.. you didnt read..
Motorola designed the HC11 specifically for automobile applications.
If you're sick of the assembly then get a different assembler... I seem to remember the HC16 assembly (which is much like HC11... I was writing rocket control softwarE) that I did was rather nice. Not quite as nice as PIC assembly, but...
-- Erich
Slashdot reader since 1997
Asm: it's like moving a mountain with a teaspoon. It takes a longer, but you have control over every bit of dirt.
The right tool for the job. <rolls eyes>
You use asm where you need to. Yes some people go overboard (some would consider writing a complete industrial motor starter and variable speed drive in assembly overboard but it was necessary for code space and speed reasons). Sometimes C compilers aren't available or the overhead of C is just too much.
I can't tell if that comment was supposed to be a troll or not but I've bitten. If it wasn't a troll, you need a few whacks with the clue stick.
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.
PJRC: Electronic Projects, 8051 Microcontroller Tools
I think if I could get one of these SOC's (most any of them would do) on a small board with a few ports and connectors attached for notebook type peripherals, with a few of them I'd be set for years with the embedded apps I have in mind! Don't think I'm likely to see such boards real soon in my price range however and I don't have the ability to fabricate them myself.
The StrongArm was mentioned.
This is particularly good, because many, many, applications for this chip have already been compiled for this chip by Rebel.Com for the NetWinder, including, of course, the Linux kernel.
The Netwinder is a very small and power unhungry device already, but I can imagine even smaller, more eficient devices.
Perhaps something that can run QNX? Or maybe Compaq could give more though to the ITSY?
Well, the future sure looks energy-efficient. Indeed.
Okay. I know you will very well call me a stick in the mud for this one, but I must be a bit more pessimistic than the article or the general air for the IBM 405GP is.
:(
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
While yes, I am a fan of Linux and OSS (hell, I've used been running Slackware since version 2 and my firewalls run OpenBSD), 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.
Why?
(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? 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.
Check out these sites, they explain why the needs for your desktop's security (which Linux can provide) are on the other end of the spectrum for bank/B2B/military security (which Linux cannot provide):
The CIA's spin
Military disablement
cpsr.org
(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? 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?
(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. But I must say that WindowsCE or QNX would be better. We know who WindowsCE is backed by, but I must admit Mico$oft'$ embedded OS department knows thier stuff. Look at the recent Sharp handhelds - fine work and I think the same design could be applied to the IBM 405GP. If you don't want to recognize MS products though, I can understand. QNX would be just as valid (and in some ways such as power usage and latency) even better than WindowsCE and Linux. Scalibility and performance are key here, and QNX can deliver better than Linux. [/flamesuit]
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.
,
faeryman
Ever heard of file locking?
The bulk of my career has been spent constructing realtime embedded apps, and I'd have some concerns in using Linux. Support is crucial when you're trying to determine whether a bug is yours or the OS's. I'd have a difficult time telling my customer that "we'll just post a question on Usenet if we have any problems." I've had vendors come out and spend days with me trying to isolate some weird difficulty (the best ever was when the hardware vendor had forgotten to program the MACs into their Ethernet controllers). I'd only consider using embedded Linux if there were vendors out there who will offer that degeree of support. And in that case, what does using Linux get me as opposed to, say, Wind River? The cost of the OS is generally much less important than reliability and being able to get someone on the phone right now. Perhaps others have different priorities.
I'll agree with you there to an extent. My point is that if I have some boring little website that does not get that much traffic, and the data I have is not that critical, then why do I need to set up a full-fledged database system? For your concerns with two write handles, you could use flock(), a second lockfile, or a combination of both to try and minimize that risk.
The applications I dealt with did not require any instantantaneous access to the data by anyone, so the extra step of copying a week's worth of data (mainly surveys) and importing it into a local database was acceptable to the client. They did not see the point in receiving every last response immediately; it would likely bog them down if they dealt with this data on a daily basis. So in this case, I feel justified in using a system like this; there was no SQL access set up on their systems, so I did not have to create it solely for this task. MySQL or Postgres would have been another thing for their administrators to watch which was not needed.
Linux is a huge beast. Look at it: You have support for IPv4, IPv6, IPX, parallel ports, serial ports, interprocess communication, filesystems, ethernet, etc. You can modularly add or remove these features, but only to an extent. You can run Linux on a 386, but you still need at least 8 MB of RAM to do basic functions. Many microcontrollers at most address 1 MB or 2 MB of memory! That includes your RAM, ROM, etc. Normally, not even half this address space is used. Operating systems designed from the start to fit within the limitations of a these systems (some with as little as 32 KB of RAM or below still - the 68HC11's I used only had 2 KB of EEPROM space onboard) are likely to do a better job than those that are modified and stripped down to do so.
While a high-end consumer device that needs ethernet access might be a good canidate for one of these new Linux-running chips, there will always be room for the smaller and older microcontollers and microprocessors. Remember the Z80? This microprocessor ran Timex's computers back when 16 KB would cost you US $100. It is still available today; Texas Instruments uses it in their calculators that cost about US $80 for the entire thing. Likewise, old microcontrollers are used because they are ready available in bulk -- cheap. A microcontroller for Linux may be a great idea, but likely costs a fortune.
For example, a modern Z180 (with two serial ports built in, a board with their C routines, RTOS, etc.) in quantities of 1,000+ would likely cost me US $50 -- each. That's half the cost of your modern microwave. Compare it to the lowly PIC's we use -- in the same quantities, these chips only cost about US $8 each in the one-time programmable variety. It isn't as fancy, but would be fine for controlling your average clock radio or answering machine. Which would you want in the next item you buy?
It is still available today; Texas Instruments uses it in their calculators that cost about US $80 for the entire thing.
Funny you should mention that; I'd love to replace my TI-85 with something running Linux.
Their calculators cost US $80... but they still cost $80, after being out for 8 years!!! Show me any personal computer that hasn't improved 10 fold in speed and memory or dropped 75% of it's price in the past 8 years, and I'll show you a ripoff. Yet we put up with stagnation in calculators?
A good Linux PDA should be able to (finally!) replace my calculator, and replace it with Matlab (or octave for the price-conscious, or Maple for people with more symbolic-oriented needs, etc.) to blow it away functionally.
I don't want Linux in my clock radio (although an X10 interface to control my clock from would be nice), but there are a lot of places where it would be nice to see Linux, but where it isn't there yet.
"Which means nine months from now (products take roughly the same time to gestate as human babies), the results of this frenzy of post-PC development will begin to emerge in a big way.
Obviously my problem is not that all my products are defective, they're just premature!"I'll take the red pill. No! Blue! AAAaaaahhhhhhhhh"
- Monty Python meets the Matrix
I don't believe that these chips will be replacing the HC11 just yet. There is a very important feature that none of these have that the HC11 has. They don't have on-chip memory. I realize that they HC11 only has 2K of EEPROM, well the HC811E2 that is (I think thats the correct prefix). But that 2K was enough to impliment a preemptive multitasking "kernel" and basic interpreter to control my robots. I would LOVE to see one of these chips with a couple K, maybee only 16K (about the size of most of thier L1 caches), of onboard memory. Nothing beats the simplicity and ease of use of a chip that literaly requires a couple resistors, a crystal oscillator, and power to run. Thats what will keep the HC11 going. Oh yah, that and its got programmable I/O and A/D converters on-chip too. :)
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?
We've been headed for systems on a chip for quite some time know. I remember, when working for Creative Labs, that they had a chip version of the Sound Blaster Pro waiting in the wings to be placed on a motherboard (as opposed to a card). But there was no demand for it! Looking at my IBM desktop, I'd say its no logner the case. (Sound card is integrated.)
I'd have to say though, as much as I like technology, the thought of all my appliances having a fulling running OS of some sort and hooked up to a network really really scares me.
...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.
Gates' Law: Every 18 months, the speed of software halves.
For many embedded systems, IBM PowerPC boards are great (think Tivo). They are small, cheap, they run cool, and they're still reasonably fast and powerful. For battery operated devices such as handhelds and webpads however, they use considerably more power than their competition: The StrongARM, the Crusoe, and the (admitedly far less powerful) Dragonball and Coldfire. Performance-wise, the StrongARM is in about the same class as embedded PowerPC models, and the Crusoe is set to blow everyone away.
So in short, if there's a power outlet handy, go with PowerPC, but to maximize battery life, StrongARM and Crusoe are the way to go.
Anonymous Luddite: "What do you think of the dehumanizing effects of the Internet?"
Andy Grove: "Not Much."