performance enhancements for embedded software

Gurus,

I would like to know what all areas we should be looking into to increase or improve the performance of an embedded system software dealing with rtos mainly.I am aware am asking a too much generic topic,but I believe the performance enhancement techniques can be generic to a extent.When I say performance I mean the speed with which the device functionalities work and also reduce memory consumption(I mean use memory in a optimised way). One such example of performance improvement will be to speed up the bootup time of the device,the channel switching time in a TV like this. I am working in a consumer electronics device related software development where I was asked to reduce the bootup time.I am clueless where to look into.Only one tip came to my mind,thats use uncompressed binary image for booting so I can reduce the uncompressing time.But thats too much less to achieve the result in improving the booting time. I am looking farward for some tips for enhancing performance and memory optimisation with respect to embedded softwares involving RTOS. Looking farward for all your replys and advanced thanks for the same, Regards, s.subbarayan

Reply to
ssubbarayan
Loading thread data ...

Hello ,

Here is some list of techniques to reduce the boot time.

formatting link

Best Regards, Vivekanandan M

Reply to
Vivekanandan M

Here you put your finger on the problem: you are clueless where to look into. Like with all optimization issues, you can't do it unless you know

*exactly* where the time is spent. So before doing anything else - reading books, posting usenet messages, etc - start with measuring what your code is doing. See if you can hook up a profiler or try to do some tricks with spare I/O lines and a logical analizer. Your first task is to get a good understanding of what part of your code is taking most of the time.

I can't tell from here. Maybe decompressing your image takes 5 msecs, while polling your bus takes half a minute. That's something only you can tell.

--
:wq
^X^Cy^K^X^C^C^C^C
Reply to
Ico

Step 1: Find the processor clock crystal Step 2: Unsolder it. Step 3: Solder in a new one 20% faster. Step 4: Profit.

(:

Reply to
Jim Stewart

You should look in only *one* area: at the actual system in question. Your question is impossibly generic because you're trying to do the third step before the first. The rules of "optimization" remain:

1) Don't do it. 2) Don't do it just yet. 3) If you still think you must do, *measure* first, before you begin.

If you want to reduce boot-up time, e.g., you can't even start to optimize before you know what's taking the system so long in the first place. So find out. You need to run a measurement campaign or some simulation/analysis to find out what exactly happens during that time, and how long each bit of it takes.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

You don't even have to do a full and detailed measurement or keep accurate notes. Sometimes it's just enough to print out a line and time to the console at the start of every major operation and eyeballing it. If you see a long delay between two lines, then its a good bet that this is the area to focus on. I think some people avoid this step because it seems like it is hard to do, or hard to do accurately, or that they need to attach a lot of probe lines to an oscilloscope.

Rules of thumb:

- Understand the code. Don't do anything else until this is done.

- Measure and know where the slowdowns are.

- Use the above two concepts to identify the paths and startup dependencies.

- Start by reducing the longest paths.

- Prefer polling for a device to be ready instead of delaying a fixed amount of time.

- Prefer interrupts to polling.

- If you've got interrupts or an RTOS, then do things in parallel. Shuffle around the paths to help this.

- If some component is optional, then don't initialize it until it is needed.

- Make sure caching is turned on :-)

-- Darin Johnson

Reply to
Darin Johnson

Long ago, I had to solder in 20% slower crystals into a PCs that didn't work reliability at 10 MHz. They were absolutely reliable at 8 MHz.

Reply to
me

I wondered for a long time if anyone would take the post seriously and actually do it...

About 25 years ago I had an Epson MX80 printer. I was able to use this trick and get it to print about 25% faster.

Reply to
Jim Stewart

Jim Stewart wrote in news:WeidndZ-

9MlfI07ZnZ2dnUVZ snipped-for-privacy@omsoft.com:

I was wondering if anyone would get the underpants gnome reference

--
Scott
Reverse name to reply
Reply to
Scott Seidman

Year: 1984 PC: IBM AT Original speed: 6 MHz (12 MHz crystal ?)

This particular PC model was strongly rumored to have been designed to run at 8 MHz, but internal IBM problems (this upstart PC division cannot be allowed to compete with our proper machines!) made sure that it was downclocked to 6 MHz.

Every single 6 MHz AT that I tried to speedup ran stably at 8 MHz, most of them handled 9 MHz and a few would even handle 10 MHz. :-)

One small company even sold a variable frequency replacement for the original (socketed) crystal, where a small pot allowed you to set any desired CPU frequency up to 12 MHz or so.

Terje

--
- 
"almost all programming can be viewed as an exercise in caching"
Reply to
Terje Mathisen

Boot time is becoming more of a problem as more and more appliances take "off" to mean zero current flow, not just suspend. Here are two related ideas.

Off-load as much of the UI as possible to a single chip controller. They boot in a blink and as long as the UI is mostly useable, the consumer won't notice the actual boot time of the appliance. For example, you could have the displays and buttons on a DVD player controlled by an AVR. Immediately on power-on, the consumer can press the Open-Drawer button and have the drawer open. By the time the consumer gets the DVD in and spun up, the rest of the appliance is up and ready to go.

The second idea is just the first but carve out a piece of the main processor to do the UI. Say you're using Linux and an ARM processor. Immediately after boot you can allocate a timer and its interrupt to poll the UI hardware and respond to the user. You need to "hide" this timer and interrupt from the Linux boot process until Linux is fully up and can take over the full UI. "Hiding" a timer and interrupt from Linux is NOT a trivial task and, sad to say, I don't know of anyone who's tried this approach.

Good luck with your project and don't forget to post your approach so we can all learn from it.

Bob Smith

Reply to
Bob Smith

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.