It's running 2.5 million lines of C on a RAD750 processor manufactured by BAE. The JPL has a bit more information but I do suspect many of the details are not publicized. It does appear that the testing scripts were written in Python.
The underlying operating system is Wind River's VxWorks RTOS. The RTOS in question can be programmed in C, C++, Ada or Java....
The code is based on that of MER (Spirit and Opportunity), which were based off of their first lander, MPF (Sojourner). It's 3.5 million lines of C (much of it autogenerated), running on an RA50 processor manufactured by BAE and the VxWorks operating system. Over a million lines were hand coded.
The code is implemented as 150 separate modules, each ...
Almost everyone will now say the blessing:
That's part of it; deterministic resource use is important on devices with limited resources to begin with, but there are other reasons.
Direct access to low level hardware API's.
You can find a C compiler for the vast majority of these devices. This is not true for any high level language in my ...
While there may be faster options than CRC, if you use them then you are likely to end up sacrificing some degree of error detection capability. Depending on what your error detection requirements are, an alternative may be to use CRC code optimised to your application instead.
For a comparison of CRC with other options, see the excellent answer by
I would abstract away from the hardware dependencies at the earliest possible step, and build the system on software emulation/test harnesses, enabling all sorts of test frameworks. Often my developement PC was used to test as much as 95% or more of the complete system. The cost of the extra overhead (another layer of abstraction) was easily won back by the ...
This is an excellent question.
To tackle your answer one language at a time;
Vietnamese is not using ideographic characters anymore, but its Latin set is quite wide: look at the example to see how many diacritics it uses:
Tiếng Việt, hay Việt ngữ, là ngôn ngữ của người Việt (người Kinh) và là ngôn ngữ chính thức tại Việt Nam. Đây là tiếng mẹ ...
(Edit: 12/7/2017, a year later, I found an authoritative answer)
In an article on software development for NASA space missions. https://www.nasa.gov/pdf/418878main_FSWC_Final_Report.pdf On page 31, the following table is in the graph showing a decent fit to a logarithmic increase in lines of code : (So, my 3K estimate was right on the money.)
First off, you should know that trying to understand code you didn't write is 5x harder than writing it yourself. You can learn C by reading production code, but it's going to take a lot longer than learning by doing.
Being degenerated by the Ruby's philosophy of TDD/BDD, I'm unable to understand how people write and test code like this. I'm not saying it'...
Unless you have at least 3 use-cases where the algorithms will be used with different types and sizes, you are not going to do good job of the genericity anyway. So don't bother too much.
I'd recommend writing it in plain C using custom typedefs for all types (except things that are obviously size_t, int or such) and #defines for any relevant sizes. Than ...
The heart of a CPU is the ALU. It's responsible for taking an instruction (like MOV) which is just some pre-defined series of binary digits, and also taking 0, 1, or 2 operands, and performing the applicable operation on them. The simplest instruction could be a NOP (no operation) which essentially does nothing. Another typical operation is ADD (adds two ...
The convention I use is:
Public function (in header file):
Classname_functionname(struct Classname * me, other args...);
Private function (static in implementation file)
static functionname(struct Classname * me, other args...)
Don't focus on case. The point is to distinguish two public methods from two classes by prepending a prefix (...
Here's a simple function that's supposed to generate a checksum over len bytes.
int checksum(void *p, int len)
int accum = 0;
unsigned char* pp = (unsigned char*)p;
for (i = 0; i <= len; i++)
accum += *pp++;
It has a fencepost bug: in the for statement, the test should be i < len.
A necessary tool to develop is a signal injector. The embedded system will have some way of interfacing with a host system (typically via a serial port reserved for debugging). Use this to send test data (best option is terse ascii formatted so it is easily simulated by humans too).
I completely disagree with this part of your question: "automation would ...
A large variety of answers here... mostly addressing the issue in a variety of ways.
I've been writing embedded low level software and firmware for over 25 years in a variety of languages - mostly C (but with diversions into Ada, Occam2, PL/M, and a variety of assemblers along the way).
After a long period of thought and trial and error, I have settled ...
Use C++, do not use any embedded/layered anything.
I am going to answer the question in the negative, and tell you to use C++, hire appropriate resources, and do not layer something else on top. Most of your criteria already fit C++ anyways: strong typing, minimal runtime, etc. (Typing not as strong as Haskell, but better than most scripting languages)
This article in Wired makes it clear that the code was written in Fortran 5 and later ported to Fortran 77 and some elements are now in a version of C:
The spacecrafts’ original control and analysis software was written in Fortran 5 (later ported to Fortran 77). Some of the software is still in Fortran, though other pieces have now been ported to the ...
Are you programming for embedded systems? If not then modern hardware is at the point where quibbling over mundane details like that is likely not sensical unless of course you are working on high frequency trading where nanoseconds count.
Please remember that code is written for PEOPLE not for MACHINES. A process being a couple of milliseconds faster ...
I agree with you that it's overly pessimistic, but some (potentially historical) reasons:
DO-178C Level A code requires Source Code to Object Code Traceability, which is much harder to prove manually with optimized code (and qualified compilers are very expensive)
optimised code is harder to debug, which might prohibit scripted debugging opportunities
One reason for the domination is that it has the right kind of tools for the task. After having developed in embedded platforms in both Java and C/C++, I can tell you that the bare to the bones approach of C++ is just more natural. Saving the developer from feeling that he or she is jumping through hoops because the language is too high level is quite an ...
Simple one bit parity (basically XORing the data over itself over and over) is about as fast as one can get. You do lose a lot of the error checking of a CRC though.
char checksum = 0;
for each (char c in buffer)
checksum ^= c;
I'm going to make the case that Lua is by far your best bet. You can compile Lua anywhere that C can run and it's one of the lightest scripting languages out there. It's massively flexible as a language and the skills are quite transferable as well. There's even a specifically embedded version of Lua.
Addendum: It is apparently possible to get the memory ...
"General purpose" is defined in the license itself. The Java 7 SE license has this:
"General Purpose Desktop Computers and Servers" means computers, including desktop and laptop computers, or servers, used for general computing functions under end user control (such as but not specifically limited to email, general purpose Internet browsing, and office ...
I could give you some rough guidelines as to how to create the equivalent GUI for a CLI app, design-wise. How you would actually make the calls is out of the scope of this answer.
switches like -p -v etc are checkboxes
mutually exclusive options are a group of radio buttons
parameters that are a filename are a textbox with a "choose" button that shows a ...
Where I work, we create embedded systems and are also using scrum for our development. You're looking at things from a technical perspective, not a feature perspective.
The first thing you should ask is "Why do we need to implement this?" For example:
Why do you need SPI? Is it going to be used for EEPROM so you can store serial numbers? Or maybe hook up ...
If you don't provide a way to dispose the object, you are passing a clear message that they have "infinite" lifetime once created. If this makes sense to your application, I say: do it.
Glampert is right; there is no need for destructors here. They would just create code bloat and a pitfall for users (using an object after its destructor is called is ...
I think two techniques are key:
Develop a complete simulator or test-environment for the hardware, so that you can develop the software as if you have real hardware. Don't skimp or take shortcuts here: developing a good simulator will pay off.
Write lots of unit tests against the simulator.
Once you have these things going, and people are confident that ...
C requires very little runtime support in and of itself, so the overhead is much lower. You're not spending memory or storage on runtime support, spending time / effort to minimize that support, or having to allow for it in the design of your project.
A really good paper comparing the performance of various checksums and CRCs in an embedded context:
The Effectiveness of Checksums
for Embedded Networks
Some quotes from the conclusions (based on their studies of undetected error probabilities):
When burst errors dominate
XOR, two’s complement addition, and CRC checksums
provide better error ...