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.
--
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.
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.
Yea... it's too bad people don't know how to really program anymore.
Asm: it's like moving a mountain with a teaspoon. It takes a longer, but you have control over every bit of dirt.
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.
Doing any "osm type" stories will get all the 31337 TR0LLS really pissed off. Especially if you're a "linux zealot".
haha - what a joke.
One future, two choices. Oppose them or let them destroy us.
LOL
:)
;)
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
I agree Linux may not be the best use here but I'm no expert in embedded systems so I'll stay out of that arguement. Where I do take exception with your comments is
"(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.
Remove the spam reference to email
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.
The 405GP is just a chip; it's no more secure or insecure than any other PowerPC. Likewise, if you want to run WinCE or QNX, go for it. You don't have to use Linux on the chip.
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.
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.
DanteAliegri-- What doesn't kill you hasn't tried hard enough.
Yes Equipment dies. Things fail. That is why you have BACKUPS and redundant systems. My god, VA Linux runs it, so they can't be lacking hw wise.
That still does not explain why slashdot will not post the article. I thought they said they where 100% independent. Guess not...
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
Now I'm no ASM junkie, and I did do a little back in the DOS 3.x days, but everyone seems hell bent on saying C won't work because it's too bloated. But that's not what C is about, that's the CRT that get's bloated, and it can be rewritten to be smaller for a particular platform. I mean, I don't think people will be able to use glibc on anything with 32k, so why complain about it's CRT bloat in the linking stage? It includes stuff that's important on a desktop machine like std io routines and stuff, but for a micro, you'd need a different development library. After all, you don't need terminal support if there is NO terminal. I programmed in C on a TRS-80 CC2 a long time ago on OS/9. Now my computer only had 32K of ram, and things worked there, and compiled binaries were no where near the size of what they are now, but it was a different architecture with a different CRT that suited the environment and created executables from C that were reasonable. If C programming is desired, and it probably will be as faster development is always a cost saver, then someone will develop a lib with a comparable CRT for that platform that will create executables that are good enough to get the job done. That means a CRT that only sets up an environment suitable for the micro and not bloated by all the POSIX and everything else. You'd have to do the same thing in assembly anyway.
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.
Free Online Woodworking Resources Directory
The Motorola MPC555 embedded PowerPC has 32 KBytes of on-chip SRAM and 448 KBytes of on-chip Flash. Too bad it doesn't have an MMU, or Linux (other than uC-Linux) could be ported to it. The MPC555 also has heaping piles of I/O that make it extra tasty!
Yesterday it worked; today it is not working; Windows is like that...
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.
And if you thought HC11 assembly was bad, try PIC assembly -- it's darn near incoherent..
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.
...But we really need to see some scaled-down storage media to match these advances. Whatever happened to IBM AA size giga drives? Maybe I missed the article here. Could someone post something relevant to this?
I thought my School was the only people to still used 68HC11s.
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.
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
This is posted, but the DATA LOSS that Sourceforge.net had is not...
7 -08-033-06-NW-CY
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
Beware of anyone who has their last name as a domainname. ANYONE.
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.
Wow... it pays tp brpwse at -1
Thank you.
//Frisco
--
$HOME is where the
-- silver_p
"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
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.
This months linux journal has a 2-page ad on it (pgs 54-55). I'm no expert on embedded stuff, but it seems to have the same features as the ones mentioned in the article.. except that its x86, like the "STPC Industrial" soc. Anyone know any more about it and how it rates up to the others ?
Full specs here
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.
Don't worry, they're working on that.
I'd like to make a small, low power system to use as a router/gateway and MP3 player system. But finding one that can run Linux is a problem, at least in quantities of one. Any good web sites?
Ok. Reality check.
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.
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."