SOCs: Say Goodbye To C's? 66
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.
Re:Hey! (Score:3)
For my senior project, I used an HC11 to a) receive and interpret X10 [x10.com] 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.
--
Re:This is posted, but DATA LOSS on Sourceforge.ne (Score:1)
Therefore, get over it. Files get lost. Last time I checked SourceForge was charging absolutely dick for their site and service.
This is what is wrong with M$: end users that expect the moon from people on Earth. M$ has infected the world with whimpering, paranoids like you.
Or maybe like me.
Say Goodbye To µC's? Yeah right! (Score:2)
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.
Re:But do we need them? (Score:3)
- 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.
Re:Hey! (Score:1)
Asm: it's like moving a mountain with a teaspoon. It takes a longer, but you have control over every bit of dirt.
Meanwhile, back in reality... (Score:5)
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...
LOOK OUT! (Score:1)
haha - what a joke.
Re:Glad we're finally getting rid of those... (Score:1)
Thank you for pointing out my abject stupidity
I honestly didn't even see the title of the article at all
Thanks for being a smart-ass
Be warned alright - of this post (Score:1)
"(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. "
Security through obsecurity is worthless. The point of Open Source is bugs will be spotted and fixed because anyone using the product can know exactly what is happening at a given moment. They can read the code, check exactly what chips are being used, anything else that want. Now a closed system, someone discovers a bug never tells anyone and continues to exploit. Don't blame the spreading of information for security bugs...they are still there in closed systems but only the corporations and an elite few know about them.
Re:Hey! (Score:2)
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.
--
Re:The PowerPC may not be the best choice (Score:2)
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
Goodbye? I think not (Score:4)
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.
WHAT are you talking about??? (Score:1)
MUST we have Linux? (Score:2)
Linux is nice and all.. but I don't really want it running my car [dammfine.com].
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.
What about ZF Linux? (Score:2)
EMJ [emj.com] will be their distributor.
Re:But do we need them? (Score:1)
While you extremely correct about assembly being much more efficient than C, if you had read the article, what is talked about is web pads, etc., that need something like linux; in any case more than you can fit in 2KB.
In the case of a webpad, I could see linux being very useful. Some of the embedded systems ( which he didn't really go into ) I could see something else working better, but then again, I wasn't sure exactly what he had in mind.
DanteAliegriRe:This is posted, but DATA LOSS on Sourceforge.ne (Score:1)
That still does not explain why slashdot will not post the article. I thought they said they where 100% independent. Guess not...
Re:The IBM 405GP - be warned (Score:2)
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..
Your car (Score:2)
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...
C vs ASM (Score:1)
Look at the palm pilot, people wanted to write programs for it and it has a CRT that is small enough that even bare applications are only 2K or smaller even. And most of that is probably setting up the hooks for recieving PalmOS evens and using the hardware correctly like the touch screen and everything else. And that's with gcc, different CRT and now MUCH smaller executables. Now I'm not saying ASM has no place, but I am saying that just because you're some 37337 ASM coder that you should say "Go away C coders, you can't hack it here" that's just stupid. If there is a demand, it will be done.
And about the no terminal thing, I also see people hollaring about "What about the hax0rs beating at my toasters door!!" and that's crap. Like I said, being as small as they are, they probably won't be able to support a terminal of any sort, so no one will be telnetting in to your toaster and setting your house ablaze. Most likely, any connected appliance will have little interaction with the real world short of sending outgoing messages. I mean a toaster has no reason to accept external commands if you're not there anyway. And there are also few homes, in the homes connected vs homes not, that are on the net all the time AND wired for ethernet so that they could put their toaster on the net. But then if someone does that, they'd have to be a geek anyway and they probably know what could go wrong. Just like setting up a fulltime connected anything. For example, most anwering machines allow you to remotely change the message and check messages, so if being connected is so bad for normal people, why don't more people have problems with kiddies changing their messages all the time? It's because people are familiar enough with that technology to reasonably secure it themselves. And when connected embedded appliances become a reality, before the mass population will accept them they will have to be comfortable with them, and with that comes responsibility to correctly use them. So by the time your grandma's toaster IS online, so will everyone else's, and when that happens everyone will probably know how to secure their toaster with RSA so that they can only SSH in to it. Just my $0.02. Please apply appropriate international rate conversions if you are not in the US.
Some PowerPC chips have on-chip memory... (Score:1)
Re:Hey! (Score:2)
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.
Eight Bit Devices Won't Die (Score:4)
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 [microchip.com] 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 [motorola.com] 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.
Linux and the IBM 405GP - you MAY be part right. (Score:2)
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.
Re:Hey! (Score:1)
Re:Goodbye? I think not (Score:1)
You don't need Linux to run your microwave oven. 99% of the microprocessors used in embedded systems don't need that much power
That's likely to change. Now it's 99%, but the number will drop. Many devices will become more powerful, the possibilities creating the needs.
In the near future, even devices that are very simple today, will have added functionality. They will get a (wireless) internet access, and functionality will be added. Microwaves come with access to cookbooks, and will be monitored for defects. Your watch may tell you where the closest place is you can buy a replacement battery when the current one runs out. The toaster downstairs sends you an instant message (to your watch perhaps) when it's finished toasting. Your fridge may call the grocery store when you run out of fresh milk. Possibilities are virtually endless.
It all depends on information: the generation of the information, the transmission of it and how it is parsed. With an embedded linux system more is possible than with simpler devices. So it may be a very good choice for these devices.
----------------------------------------------
Re:Eight Bit Devices Won't Die (Score:1)
Actually I dont think there are that many situations where it would really make sense to replace an 8 bit mcu with a linux bloat system. (sorry
StrongArm. (Score:2)
This is particularly good, because many, many, applications for this chip have already been compiled for this chip [netwinder.org] by Rebel.Com [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 [qnx.com]? Or maybe Compaq could give more though to the ITSY?
Well, the future sure looks energy-efficient. Indeed.
This is all well and good (Score:1)
Hey! (Score:1)
Amazing...they have crappy assembly. The calls have the name of the register in themselves (CPYBX would copy B to X, instead of "MOVE B X" wich is a little more diverse)
JoeLinux
Those are *MY* thoughts. They will not become *YOUR* thoughts until the orbital mind control lasers are in place.
The IBM 405GP - be warned (Score:3)
I've followed the development of the for a while now, even having a few email conversations with Jonathon Thompson [mailto], Quong Ho Thoc [mailto], and Hagr Itstein [mailto] (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 [openbsd.org]), 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 [earthlink.net]
Military disablement [newdimensions.net]
cpsr.org [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 [dgmicro.com] 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 [qnx.com] 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. [qnx.com] [/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.
Re:This is all well and good (Score:1)
This is posted, but DATA LOSS on Sourceforge.net.. (Score:1)
You would almost think that Slashdot and Sourceforge are owned by the same company...Oh...They are.
http://linuxtoday.com/news_story.php3?ltsn=2000-0
Re:The IBM 405GP - be warned (Score:3)
Why to people insist on calling handhelds 'embedded'?
Embedded systems are generally 'computers in things that aren't computers themselves'
like.. the computer in your car. In your clock radio. The microcontroller that runs the robot they sent to mars. The onboard computers on space probes. Small processors (or large) in remote sensors. etc.
THIS is the real use of an embedded systems.. and usually it's either 1) assembled from scratch or 2) using an RTOS, as timing is *everything* with a great many applications.
Linux on a chip? fantastic. I can think of a great many uses for it. 'Embedded systems' isn't one of them.
Re:This is posted, but DATA LOSS on Sourceforge.ne (Score:1)
Re:But do we need them? (Score:2)
Welllll ... (Score:2)
Re[2]: But do we need them? (Score:3)
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?
TI calculators (Score:2)
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.
Re:The IBM 405GP - be warned (Score:3)
Don't forget that most "Linux" security issues are not with the kernel itself, but with other programs which run on it. There would be no reason for these programs to be running on an embedded system. If they are, that's bad design, and it's not the fault of the operating system. You can make any OS insecure if you try.
Not to mention that the number of situations where military/bank grade security is important is going to be relatively small.
2. Chances are that PCI is used because of an industry standard called PC/104 -- basically a PCI bus with a different connector used in embedded systems. Using a different bus would prevent the design from leveraging the existing PC/104 peripherals. It's ironic that you mentioned MCA -- IBM has apparently learned it's lesson there.
3. WinCE? Stop it, you're killing me.
QNX? Well, yes, it has advantages over Linux in some situations, most notably where hard realtime constraints are required. But that isn't the case in most circumstances. Considering that the price of QNX could best be described as "obscene", you aren't going to use it unless you absolutely need it.
Even then, there are other alternatives available for HRT programming, like RTLinux and eCos.
So in short, I think you're wrong.
Re:Goodbye? I think not (Score:1)
These powerful processors are not going to be able to run on a watch battery, unless you plan to replace those batteries every five minutes. And even then devices won't be cheap. Will you be willing to pay $200 to replace your $15.00 watch, with a little bit of added functionality?
For a typical consumer product with an embedded processor, the cost of the processor is somewere between 5% and 10% of the retail cost. To put these types of processors in a device, you need to cost the end product between $500 and $2000 to be able to recoup your design, manufacturing and distribution costs. The only way these types of chips will ever get cheap is if they get into a product where there are 10,000,000+ quantities. For embedded products, this price is too high. I don't doubt that these products will catch on, but I think the time frame is much longer than the original article asserts.
Re:Some PowerPC chips have on-chip memory... (Score:1)
Re:Star Wars Episode II!!! (Score:1)
Wow... it pays tp brpwse at -1
Thank you.
//Frisco
--
Re:Hey! (Score:1)
A number of assemblers do just that. Any decent macro processing language can be made into an assembler by mapping opcodes onto macros that expand into the proper bytes. The old PDP-11 DECUS C compiler did this for the metalanguage it compiled to, MUL tested for mutiplying by some of the small multiples of 2 and used shifts (not every model had hardware multiply, the software subroutine was "expensive").
For processors targeted at smallish apps, general purpose instruction sets/addressing modes don't always make sense. The `HC11 has two 8 bit / one 16 bit GP registers, two 16 bit index registers, and the stack. It understands the low 256 bytes or memory as special, using short addresses to access them. It makes for compact machine code, and makes it hard to target with stack based HLL like C and PASCAL.
Re:This is all well and good (Score:1)
Gestation Period (Score:3)
"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!Re:Hey! (Score:2)
But do we need them? (Score:4)
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?
vs Java (Score:3)
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.
Re:Hey! (Score:1)
Glad we're finally getting rid of those... (Score:5)
Anyone hear of the MachZ ? (Score:1)
Full specs here [zflinux.com]
What's needed is mass market appeal to lower costs (Score:1)
A GNUboy!
Yep, that's right. A small GameBoy-like handheld device running Linux but with a cartridge port. Market it as a game device to sell millions of the things. Sell it with an actual GameBoy emulator to start it off with an installed base of games. Mass sales to regular people (not just geeks) will drive the production costs down and make the things cheep. This will allow geeks to buy them too and do interesting things with them. Add on board IR ports and ethernet I/O for easy data exchange, and flashing of the solid state disk and to control the TV at the local bar.
So long as these pocket PCs remain a specialty device, they'll never gain much popularity before they revise all the hardware to make the new ones incompatible with the old ones.
Re:Re[2]: But do we need them? (Score:1)
Re:The IBM 405GP - be warned (Score:3)
They have some of the qualities of embeded systems (price is a huge factor, and compatability with desktop software is pretty much a non-issue). Moreover the CPUs in succesful PDAs (the Palm line for example) are CPUs that were designed and marketed for the embeded market. They also fit some people's definiton of "embeded", but I admit that is a big strech of the traditonal deinition.
It (or NetBSD) would cut devlopment time for say a car MP3 player that needed to use 802.11 to fetch new songs while parked in the garage... but I wouldn't be very tempted to use it for an anti-lock break system.
If HP had used it for their printers I don't know if the print engine would be worse (I don't know how much RT it needs), but the TCP stack would be marketdly better, as the exiting one screws up if the least bit of stress is put on it (say more then one TCP connection at once is sometimes enough!)
Re:StrongArm. (Score:1)
bc
Re:Welllll ... (Score:2)
Re:Goodbye? I think not (Score:1)
What you describe can be done far more efficiently with current 8-bit microcontroller technology than with bloated internet appliances...
Imagine instead of a microwave that has wireless internet access a microwave with a small 8 bit controller that communicates using a short-range lightweight wireless protocol with the rest of the house. Now somewhere in the house you have a music/movie/recipe/etc storage 'computer' that has broadband internet connectivity. You can still have the microwave monitor itself, display recipes, query the fridge for the correct ingredients, etc but the storage and external access occurs through the home Linux box/firewall.
This alternate model saves massive quantities of power because you don't need a 100 'high power' transmitters to connect to CDPD (or your favorite wireless IP of the future) you don't need 100 CPUs sitting in idle loops, or 16 megs*100 worth of RAM dynamically refreshing itself for every house on your block. You have just saved yourself a couple of kWh's a day in power bill. Not only that but your microwave costs $105 instead of $150.
BTW: Do you really want people to be 'hacking' your microwave?
Re:Hey! (Score:1)
What is elegant about a SPARC?
Re:But do we need them? (Score:1)
Human beings are not helpless? (Score:1)
Don't worry, they're working on that.
But can I buy just *one*? (Score:1)
Re:vs Java (Score:1)
The JINI specification is not OS-centric. A JINI device could be a MAJC chip running a minimal Java VM, or a system-on-a-chip running Linux (with a Java VM). It doesn't really matter as long as there is a VM and some sort of wireless networking in place for exchanging objects. So really, Linux Systems on a chip fit in perfectly with what Sun is doing with JINI.
Re:This is posted, but DATA LOSS on Sourceforge.ne (Score:1)
Equipment dies. Things fail. What happened is that 2 hard drives on the project server crapped out.
I think an advancement in technology is better "News for Nerds" than a hard disk failure. Sourceforge users would more than likely find out from Sourceforge itself, and these things happen once in a while.
Lose the paranoia.
Re:vs Java (Score:1)
The PowerPC may not be the best choice (Score:2)
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.