Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I am developing an embedded real time system software (in C language). I have designed the s/w architecture - we know various objects required, interactions required between various objects and IPC communication between tasks. Based on this information, i need to decide on the operating system(RTOS), microprocessor and memory size requirements.

(Most likely i would be using Quadros, as it has been suggested by the client based on their prior experience in similar projects)

But i am confused about which one to begin with, since choice of one could impact the selection of other.

Could you also guide me on parameters to consider to estimate the memory requirements from the s/w design (lower limit and upper limit of memory requirement) ?

(Cost of the component(s) could be ignored for this evaluation)

share|improve this question
    
Surely you can look up the installed size of each OS on each architecture, and estimate and add up the size of the data you'll be keeping in RAM. Which only leaves guessing at the installed size of your software, no? –  dmckee Feb 22 '10 at 15:23
    
It also occurs to me that you might actually find more expertise in this matter on the Stack Overflow. However, I do not have the mojo to vote to migrate...you could flag down a moderator to ask for help if you don't get a good response here. –  dmckee Feb 22 '10 at 15:39
    
@dmckee, Based on your comment, here is my understanding: - start with selection of processor first - compute size of OS on each of them to get the memory requirements - Add s/w size to get total memory required Is this understanding correct ? But real time OS could be configured to get only the needed components. In that case it wouldn't it be difficult to experiment and come up with base memory requirement? –  James Feb 22 '10 at 16:19

2 Answers 2

up vote 2 down vote accepted

Memory is cheaper than your time, at least for the first few systems produced. Stuff the maximum of everything you can onto the board for your prototype system and instrument the heck out of your code. You can buy less well populated boards for production but now you want mega resources.

  • Allocate much bigger stacks than you think you'll ever need and pre-fill them with a bunch of repeating text, such as the name of the thread that owns that stack. How much of that gets over-written will show you how much stack each thread used. Apply a comfortable factor-of-safety to that number to get your final allocation.
  • Allocate lots of heap. Better yet, instead of using heap at run time, pre-allocate heap at start-up to one (or several) memory pools of a (or several) fixed block sizes. Allocate and de-allocate only from those at run time.
  • Log memory use into a big (or circular) buffer, or log the requester's ID into a preamble distinct from the block's actual data space -- anything that will leave tracks you can find later to help analyze memory demand, memory starvation, or crashes.
  • Keep buffers out of your stacks so overruns won't bring everything to a screeching halt, or worse, incur wild transfers of control.
  • Beat on the system. Put it through whatever scenarios you think will stress the stack and memory requirements. Enroll some typical and non-typical users to do the same. Some of them will try do things you didn't anticipate. Encourage that.

When you've done all that you'll have a far better handle on your memory requirements than you can get now.


(Edit; commenting not available to me)

James:

'we would like to get rough estimate of the hardware and cost involved at this stage. Do you think this would be possible ?'

The short answer is yes, RAM is likely to be a small part of your hardware cost, so go ahead and over-estimate - you should still be close.

As a rough check, you might get a crude estimate for the static memory requirements - code and static data - by writing and compiling a few functions to get a rough source-lines to memory ratio, and extrapolating. You'll need a rough count and some educated guesstimates about how your design will expand into functions and lines of code. Can you make an educated guesses about your design's run-time use of dynamic structures - stacks and heaps or pools? I'd probably at least double or quadruple my estimates.

Can you implement the system on an existing computer, short-circuiting functions (by compiling the code with a short return rather than #ifdef'ing it out) that don't make sense in that environment?

If you really need to estimate without implementing much, I think you're going to stuck with extrapolating.

share|improve this answer
    
@Jrobert, I agree this is good approach to get the memory estimate. i would have to implement the code and have the development environment ready to experiment this. So far, only s/w design has been done and we would like to get rough estimate of the hardware and cost involved at this stage. Do you think this would be possible ? –  James Feb 23 '10 at 10:17
    
@Jrobert, Could you clarify what you mean by implementing system on existing computer? I have not chosen OS and development environment yet. Did you mean estimating kernel size would be easier to predict and and use your procedure on any compiler, any OS to determine the memory used by dummy application which roughly simultates the real application ? –  James Feb 23 '10 at 16:34
    
Essentially, yes. To estimate code-size, you have to start from somewhere. Why not your development machine? If your target will differ significantly, a DSP, for example, than at some point you'll need to estimate how your target's code size will compare to that of the development system, but you'll at least have some idea from seeing a few functions' worth of code size. But I'm still left wondering whether/why, at today's memory prices, you feel the system cost will be sensitive enough to code-size that you'd need to go through this exercise? –  JRobert Feb 23 '10 at 17:39
    
I think it makes sense to postpone memory size decision since memory cost is much smaller than OS or processor cost. Could you share some thoughts about parameters to think of in selection of processor and Operating System ? –  James Feb 24 '10 at 12:05
    
Do you need all the speed you can get (DSP, perhaps) or will a common, off-the-shelf, single board computer support your product? With an 'x86 board, you likely already have a capable toolset on your development machine. You might need an embedded-system linker-relocater to replace the host (unix/MacOS/Windows) linker and a remote debugger, if not already provided. Will the board be available for the foreseeable life of the product? Or is the product a one-off or a short run? Then hardware is cheaper than you are; get all the capabilities you can to make the design & bring-up easier. –  JRobert Feb 24 '10 at 16:36

It sounds like you have already made some design choices.

we know various objects required, interactions required between various objects and IPC communication between tasks.

you need a multi-threaded OS and a uC that will run it, usually meaning you want to aim for a processor with an MMU. OS options are things like Quadros, QNX, linux, wince, etc.

Based on what your "objects" (modules is better term for C :) ) are doing you can likely determine what type of architecture you need. Is a 16bit arch enough? need more memory or work with larger numbers then is 32bit the right answer? lots of floating point work? then you likely need a processor with a FPU. Doing lots of DSP like work? maybe you need a DSP or a uC with DSP like instructions or a co-proc. Running a graphical display? need a SoC with a built in LCD controller or expect to do it externally. Doing heavy 2D graphics? need a SoC with some graphics acceleration.

Make a list of the features you need and estimate how much of your code falls into the categories like integer operations, looping, floating point ops, graphical operations, DSP operations, etc.

This should allow you to class the level of device you need. For some architectures you could cross compile some code using GCC and emulate it using qemu on top of linux. This probably is only worth it if you need to test the performance of a critical algorithm on a particular architecture. This can help you scale the speed you need for your application.

The second consideration should be power usage and support for power management. Combined with the required performance you can make the choice of DSP, uC, application processor, etc.

As others have said i would not worry about memory usage, just aim big, often different ram sizes are pin compatible so you can just cut the ram down for production. The only real questions to answer up front here are:

*How big of an address space do i need? 16bit? 32bit? etc

*Do i need external ram or will a uC internal ram be enough? <--answer this after you choose an architecture and can go SoC hunting.

For the most part choosing among processors in the same class is a "holy war" aka in the 32bit risc market some will back ARM, some will back coldfire, some may even back PIC32. At the end of the day likely any would work. You have to choose based on available SoCs with the required peripherals, ease of development (how good is the tool chain) and cost.

The same can be true of OS choice, linux vs QNX vs quadros is a toss up for most applications, usually the best answer is the one you have the most experience with. Even if it ends up being slightly more expensive the reduction in development time often offsets the build cost. Do make sure the OS has the required features, shared libraries, inter-process communication, pipes, whatever you need.

As a general rule i would select your architecture first. This will have a much higher impact on the performance of your device than the operating system will. In addition operating systems in this space are often supported on many architectures. Also the better OS's are POSIX compliant, written correctly the bulk of your code should be able to run on multiple OS's.

Don't feel bad if you have to make several attempts to make the correct choice. You may find a core that perfectly fits your code needs but find after some research that it doesn't support some minor feature you need, or there isn't an available SoC with the peripherals you need, or even that the thing is back ordered for 6 months. Just make sure after making the initial choice that you research how the design will come together based on that part so that you see the stumbling block now rather than half way through development.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.