Slashdot Mirror
What's Inside the Mars Rovers
Captain Zion writes "Space.com has a story about the hardware and software of Mars Rovers Spirit and Opportunity. Basically, they're radiation-shielded, 20MHz PowerPC machines wirh 128Mb RAM and 256Mb of flash memory, running VxWorks. I wonder if I could make a nice firewall with one of these for my home network..."
> Does a 20mhz processor really need 128mb of ram?
A processor of any speed doesn't need RAM of any size.
The application you want to run needs both processing power and memory. How much of each? Depends on the application.
These sigs are more interesting tha
That's an excellent point. A lot of people are thinking instruction = 1 cycle. The real world is that it's not unusual for an instruction to take 2, 4, 10, or even 100 cycles. The reality of the matter is that instructions can be anything from a single two bit sum to a floating point division. I see this mistake a lot... bravo for applying what you read against the supposition of a simplification.
Basically, they're radiation-shielded, 20MHz PowerPC machines wirh 128Mb RAM and 256Mb of flash memory, running VxWorks.
Mb = Megabits
MB = Megabytes.
The article writes out megabytes, so MB should be used, not Mb!
"Mod, mod, mod...and another troll bites the dust."
The CPU is fabricated to withstand the radiation, a brief summary can be found here or by googling
Music is everybody's possession.
It's only publishers who think that people own it.
Fuck Beta
~John Lenno
Flying VxWorks to Mars
AH dude... Microsoft is totally different... VxWorks is based on the fact that all memory is linearly accessable.. there is no memory protection... that works great when all your apps are written in-house, and you know the timer ain't gonna trash the motor controller...
But try that on an OS for a desktop system, and your email program just may blow up your paint program... (remember Windows 3.1's stability? Make that 10x worse)... You can't use VxWorks for the desktop as Windows is used today... it needs a lot of protection... The ease of upgrading is due to the lack of protection...
---
Programming is like sex... Make one mistake and support it the rest of your life.
you seem to assume that real time OS are faster than non real time Oses, that's usually not the case. the difference between the two is that a RTOS has a guarenteed response time, not a faster one...
it is not uncommon on so hard real time system to disable processor cache, it makes the processor slower, but the response time to an interrupt is easier to calculate. In RTOS interrupt latency must be PROVEN not to be longer than a constraint.
If I'm not mistaken, virtually all probes have some sort of radioisotope heater...
Radioactivity is NOT radioactivity when you are considering things like this. Saying the people who don't want nuclear powered rockets should hate this as well or else they are hypocrites is tantamount to saying that the people who don't like oil spills should bitch about how some motor oil ALWAYS stays in the plastic container it is shipped in. Not quite the same problem. Afterall, these things aren't much more radioactive than a Coleman lantern wick or a smoke detector element...
If I recall correctly, the Shuttle has 5 GPC's (General Purpose Computers), three of which are "online" at any one time.
The online GPC's each carry out the same set of calculations (potentially each uses code designed to do the same thing, but written by different programmers), and they compare each others results. If any single GPC is considered to be too far wrong, the offline GPC's submit their answers. The three GPC's that are in closest agreement then become the new online GPC's, and the remaining two go offline. The GPC's can reboot themselves if they are too far out of whack, if they fail in one of the "results elections", and of course when they are told to do so by the crew.
Also, whenever a GPC is sent offline by one of the others, a specific caution indicator (and potentially the master caution indicator and klaxon) is activated, and the relevant error codes are shown on one of the forward CRT's. The error codes, along with other information such as the currently running program and the current mission phase, determine the crew's actions. Actions can be as simple as disabling the master caution klaxon for the current alert, all the way to hand-checking certain results and manual GPC restarts.
This is all from memory (from about 5 years back), so some of this may have changed recently, particularly on Atlantis with the "glass cockpit" upgrade that happened 18 months or so ago, but the general gist should be about right (and I'm sure I'll soon know if it isn't!!)
Disclaimer: I meant what I thought, not what I wrote! What? You can't read my Mind? Oh dear!
Actually they are running at 20MHz. I've seen several write ups which clearly state that. The RAD6000 can apparently run at up to 33MHz, with a claimed 35MIPS. The rovers are "underclocked", probably due to power budget concerns.
0 0/ra d6000.html
Go to
http://www.iews.na.baesystems.com/space/rad60
and click on the rover picture to get a PDF brochure, which gives the 33MHz/35MIPS figure.
Rootbear
No, they're not.
The processors in MER are RAD6000's, which are radiation-hardened versions of the RS/6000, the predecessor to the PowerPC (see this for details). The RAD6000's younger brother, the RAD750, is indeed a rad-hardened PowerPC.
As an aside, there is a big difference between a radiation-shielded processor and a radiation-hardened processor. Shielding implies just sticking some kind of rad-absorbent material between the processor and the environment. A rad-hardened processor is actually manufactured in a different way - different gate layout, different design rules, often different materials (Silicon-on-Insulator is popular). These things are done to minimize or prevent the effects of single-event upsets (when a bit is flipped by high-energy particles) and single-event latchups (which basically turn a couple of gates into a glorified short-to-ground). The materials changes may also improve the overall total dose tolerance of the processor. The work required for redesign is one of the reasons that space-qualified rad-hard processors lag the commercial market. The NASA Office of Logic Design has some good papers on space processors available online if you're interested in learning more.
Writing to flash takes a long time. The difference between RAM and flash will be very noticable, even for a 20MHz processor. For example, a write to the Fujitsu "high-speed" flash devices takes 12.6uS (per 16-bit word), according to Fujitsu's specs. For a 20 MIPs processor, 1 instruction is 50 nS, so modern RAM can "keep up" with it. In this situation, writing to flash would be more than 250 times slower than RAM, even with very fast flash.
Disclaimer: Even faster flash devices may exist, but I don't know about them.
Radioisotope thermoelectric power units need to be hot enough to allow for electricity to be generated by thermocouples placed between the unit and the heat sink (space). A quick Google search gives 200-500 watts of power generated from multiple interleaved stacks of plutonium-238 or strontium-90, average radioactive source strength of around 50,000 curies, depending on design.
Radioisotope heaters use much less material, as they only need enough heat to keep the warm electronics box above -40F or so. From the Environmental Impact Statement in the Federal Register ([wais.access.gpo.gov][DOCID:fr10de02-54]):
"Each rover would employ two [calibration] instruments that use small quantities of cobalt-57 (not exceeding 350 millicuries) and curium-244 (not exceeding 50 millicuries) as instrument sources. Each rover would have up to 11 RHUs that use plutonium dioxide to provide heat to the electronics and batteries on board the rover. The radioisotope inventory of 11 RHUs would total approximately 365 curies of plutonium."
Nothing you'd like to swallow, but still, much smaller than a radioisotope power unit.
The man who does not read good books has no advantage over the man who cannot read them. - Mark Twain
...as the substrate of the chip, rather than a silicon wafer, so the chip was a "sapphire" chip rather than a silicon chip (although doped silicon could then be used to form transistors, as could Gallium Arsenide or Germanium, through the regular lithographic process).
This is the classic "Silicon On Insulator." IBM has a process of embedding a layer of glass beneath the surface of a standard silicon wafer, allowing SOI using silicon substrates. This and their work with copper set them apart from the other large silicon transisitor foundries (TSMC, Intel, etc.).
The processors on the rovers are probably SOI, but I don't know which process is used.
One chart I've seen of IBM's POWER chips and their derivatives had an entire section devoted to the PPC chips, and the RAD6000 wasn't included in these, but was an offshoot to the side, branching just before the PPC601.
By all other standards however, they seem to be closely related in time and technology to the 601, which powered Powermac 6100, 7100, 8100, 9150, 7200, 8200 and 7500 PPCs, as well as I think, one of IBM's thinkpads.
Those 601s are a very nice chip, and quite underestimated at what they can do at low clock speeds. If the RAD6000 is anywhere similar, I can understand why it was picked.
I would have thought that the memory would be swapped out
Swapped out? To where? You're being a bit recursive here. The operation failing is the initialization and reading of the flash. You can't swap to flash while you're initializing it.
However, I doubt they implemented virtual memory on the thing. It's far too much overhead in the OS to actually implement paging, etc. They were probably just very, very careful about the amount of memory in use at any one time, as with most embedded systems. Someone, however, didn't check that in a massively fragmented flash filesystem, the directory read wouldn't take up the entire RAM. Oops.
The RSC design played a key role in bringing Apple and Motorola together with IBM to create the PowerPC line of CPUs. The 601 was the first PPC and was basically a redesign of RSC. It supported both POWER and PPC architectures, although there were deviances from PPC since the architecture was actually being defined at the time we were working on the chip.
The RAD6000 version of the design happened because IBM wanted to pursue some government contracts, so had the RSC specially qualified. Another group then took the design and performed the radiation hardening.
After Pathfinder we had some cool IBM/Mars posters hanging around the building, but oddly enough they vanished very quickly...
"I want my job to be the guy who kicks George Bush in the face all day, only stopping to make out with him."
Are all the millions of dollars spent on full for the rockets?! Why the fuck is my home system more advanced than NASA's? You'd think they'd of at least used a design similar to a Dual G4 or maybe even a Dual Xeon or P4. Can someone explain to me why NASA gets millions of dollars if they are using 1990 equipment?
A) They don't need to play Doom 3 up there. 20MHz is sufficient for almost anything you would want to do on Mars. Why send up more than you need to?
B) Your computer runs far hotter and consumes far more power than the Mars rovers do. Power is at a premium when you're millions of miles away from the nearest electrical outlet.
C) The rovers are radiation-hardened. Your system is not. Your computer would last about twelve minutes in space before it locked up. A big part of radiation hardening is using larger (and therefore slower) transistors.
D) It takes years to certify a particular piece of equipment as spaceworthy. NASA isn't going to just pop in the latest and greatest Athlon and assume it will work "because the last one did". That means that anything flying into space is automatically going to be at least a few years behind the curve.
ZFS: because love is never having to say fsck
Your comments about VxWorks show me that you don't have a well establish practical Real Time OS (RTOS)experience and are trying to to compare an RTOS to a Server or Desktop OS. That is quite a bit misleading. For example,
;-P
consider the use of malloc()/free(). In an RTOS it does not much sense to dynamically allocate and free memory at run time. Same thing applied to other sytem resources, like tasks/processes. This takes quite a bit of time from a Real Time point of view to create new tasks, semaphores, objects, memory allocation, etc.. Most RTOS engineers, who know what they are doing, pre-allocate all the memory they need at boot time, start all the processes they will need, etc. In order words you allocate all your system resources at boot time so you keep your real time characteristics. An RTOS system is static. no dynamically process allocation, memory allocation (i.e. unexpectantly running out of memory), etc. You start everything up and account for your needs. A very different model from probably what you are used to in a Desktop/Server OS. Think about it as static appliance. Give me one good reason why you can't preallocate memory and all the tasks you will need?
Yes memory protection has its benefits. Speed is not one of them. Remember this is an RTOS. How many RTOS do you know of that support memory protection? hmm.. 1 I believe. Which is VxWorks AE. Which you say is slow. gee. If you want a low latency fast RTOS, memory protection quickly falls off your "must have" list.
So VxWorks supports FAT16. So that makes it suck?
It also supports FAT32, NFS, a Flash Filesystem, etc. So all those points make it such too. I see your reasoning.
VxWorks, every other true RTOS, does not use the system clock exclusively to multitask a you say. In fact, round robin multitasking which uses the system clock is turned off by default Unlike a server/desktop OS, a context switch is not generated strictly via an interrupt (system clock, device interrupts). context switches can occur at any time as your code generates events. For example, giving a semaphore to unblock a test, sending message to a message queue which unblocks a waiting receiver, trying to get hold of an object which is in use (this would block you). This does not require a high latency and it almost immediate. This is because all code runs in processor supervisor mode. i.e. no traps to communicate from one task to another. This goes along with the no memory protections reasoning. It has benefits. Let me guess you didn't read the manual or take a vxWorks 101 class, right?
Nasa has been using vxWorks primarly on most of their projects since 1980! I think that says alot by itself. Thank you for your "expert" opinion in helping people judge the quality of an RTOS.
I know we're not the only ones to have been burned by Wind River's malloc. I know several major companies that also had to replace Wind River's code.
As far as being able to dynamically replace code, VxWorks isn't alone in that. Numerous other RTOSes out there can do the same thing, including QNX. QNX even supports the concept of a hot standby process to take over if the main process dies.
To give you an idea about how Wind River's malloc works, they keep a sorted linked list of fragments from the smallest to the largest. When you try and allocate a block, it walks the linked list until it finds a block large enough. Likewise, when you free a block it checks if it can coalesc the block with a neighboring block. It then goes through the linked list looking for a slot to insert the free block.
Yes, VxWorks may have been around since the 80's, but that's part of the problem too and it is showing its age. In the 80s embedded processors typically did not have MMUs. Now MMUs are quite common in the more powerful embedded processors.
You say you can't have low latency and memory protection? QNX proves that you can. It is low latency and *very* robust. If your driver dies, no problem, restart it. Timesys Linux also has a very low latency, although not as low as QNX. Timesys also has an interesting feature where you can guarantee CPU and networking resources. I can schedule a task to be guaranteed 5.8ms of execution every 8.3ms and it will guarantee that that task will get the CPU time allotted to it with the desired resolution. This is without increasing the system tick rate (usually 10ms). Timesys can also schedule a task to be higher priority than an interrupt. I'm not as familiar with QNXs scheduler, but it's also quite flexible from what I've heard.
As far as FAT, it is not a robust filesystem. It never has been. If the FAT gets corrupted or a directory entry gets corrupted it's difficult to recover. Other than possibly having 2 copies of the FAT cluster table, any corruption can be difficult to repair. If the FAT table gets corrupted, which table is corrupt and which is not? If a directory entry gets corrupted, it can be impossible to fix. For flash memory, unless you are using a device with special wear-leveling, FAT is about the worst choice since any file write that changes the size of a file requires a write to the directory entry and possibly the FAT table. If the table gets corrupted and you don't run a repair operation (which often ends up leaving orphaned files as lost clusters), the file system can happily corrupt itself to death. Why do you think every time DOS/Windows9x/ME crashed it had to repair the disk with scandisk? FAT is a poorly designed file system that was originally designed for 160K floppies and scales poorly. FAT32 is an improvement, but it's still not very robust. For flash, something like Linux's journalling flash file system 2 (JFFS2). More information on VxWorks file system support can be found here.
Basic VxWorks information can be found http://www.slac.stanford.edu/exp/glast/flight/docs /VxWorks_2.2/vxworks/guide/.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.