Embedded rules programming

Rule 1: Make sure that once it is installed nobody can see it - i.e. there are no tell tale bulges.

Regards, Richard.

for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430 Microblaze, Coldfire, AVR, x86, 8051 & PIC18 * * * *

Keep it simple (KISS)

--
Posted via a free Usenet account from http://www.teranews.com

Hire engineers that did their own homework in college.

Not a universal rule, some managers would prefer to hire engineers that did _other people's_ homework in college. Easier to get them to live with others taking credit.

No guys, :)

I talk about rules like:

1 - Implement a Command Queue 2 - Implement a hand shake system

and other things like these.

Tnx

Given the scope of the term 'embedded systems', I am not sure it is possible to give any particular rules.

Give an example of such a system (the way you envisage embedded), and I am sure the worthy denizens (and some less worthy, perhaps) of usenet will give their ideas on the subject, but the rules for any system depend to a great deal (entirely?) on what it's purpose is, and what parts are used to implement it.

Cheers

PeteS

It's a system that get many commands from a serial port, analyse the command and fowards these to another system. Tnx

So a more serious response:

Rule 1: Learn how to specify and agree system requirements, and monitor requirements creep. Rule 2: Ensure the resultant system can be sold for several times more than it cost to produce.

From your requirements I don't know if I need a 4bit blob processor, or a Cray super computer.

Regards, Richard.

for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430 Microblaze, Coldfire, AVR, x86, 8051 & PIC18 * * * *

1) On Time. 2) Within Budget. 3) Works.

Pick only two.

You are focusing on #3 in your request.

What is your "embedded system" going to do, will determin what rules you may or may not need.

Understand the hardware.

Understand the application area.

Understand how to use the toolchain and programming language.

Know what code the compiler is going to generate for each line you write (roughly anyway).

Easy to read code is important, so always start by doing everything the simplest, most straightforward way. If that's too slow, you've probably picked the wrong algorithm

--
Grant Edwards                   grante             Yow!  ... Just enough
                                  at               time to do my LIBERACE

Sorry, I've been doing embedded SW for 25 years, but I've no clue what you're talking about.

??

--
Grant Edwards                   grante             Yow!  BRILL CREAM is
                                  at               CREAM O' WHEAT in another

Well, that's a start on what your system actually does...

For your system, here are a couple of pointers: When communicating with the outside world, be liberal in what you accept and strict in what you send. Your design should be very forgiving of what it receives, and must only send proper data. This also applies to timing: your receiver should expect data at any time, but your transmitter must only send when the rules state it's ok. There are some subtleties when you include handshaking or other out of band signalling, but for a plain jane serial port, this will do.

A good rule of system design in general, and a pointer to get constructive help from this group: Have a clear definintion of what the system is expected to do. Your hardware and software design will reflect the design requirements, so your system can never be better than the specifications. If you have a hard time describing it in English (or your favorite language) that usually indicates some muddy thinking that can only get worse while translating the ideas from spoken or written language to hardware and software.

Good question!

These are some of my own personal rules. They're neither easy nor perfect.

1. Use state machines when possible. -- work with the customer to define all possible states before coding
2. The customer usually doesn't know what they really want until they have it in their hand, i.e., they don't really know what they want at the beginning of a product. Plan for customer revisions to the spec.
3. Start by using the tools that get you finished the fastest, even if it means you'll have to go back and rewrite the code, redesign the circuit, and so forth.
4. Work on the stuff that you have the least experience with at the beginning of the project. The earlier the surprises come, the better.
5. Write the test plan before starting to code.

Salvatore Di Fazio wrote:

In article , Salvatore Di Fazio writes

Command, Queue and handshake..... Try here

:-)

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/

Sssssssh! That's supposed to be a secret.

The way I like to say this is, "Don't begin coding until there is nothing else that you can do."

--
========================================================================
          Michael Kesti            |  "And like, one and one don't make