Embedded rules programming

Hi, what are the rules to make a good embedded system? Tnx

Reply to
Salvatore Di Fazio
Loading thread data ...

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

Regards, Richard.

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

Reply to
FreeRTOS.org

Keep it simple (KISS)

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

Hire engineers that did their own homework in college.

Reply to
Jim Stewart

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.

Reply to
larwe

No guys, :)

I talk about rules like:

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

and other things like these.

Tnx

Reply to
Salvatore Di Fazio

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

Reply to
PeteS

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

Reply to
Salvatore Di Fazio

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.

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

Reply to
FreeRTOS.org

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.

Reply to
Donald

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
 Click to see the full signature
Reply to
Grant Edwards

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
 Click to see the full signature
Reply to
Grant Edwards

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.

Reply to
Travis Hayes

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:

Reply to
Alan Cohen

In article , Salvatore Di Fazio writes

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

formatting link

:-)

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

Sssssssh! That's supposed to be a secret.

Reply to
Tom Lucas

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
 Click to see the full signature
Reply to
Michael R. Kesti

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.