Embedded rules programming
Salvatore Di Fazio
what are the rules to make a good embedded system?
Tnx
FreeRTOS.org
news:1154539266.8...@m79g2000cwm.googlegroups.com...
> Hi,
> what are the rules to make a good embedded system?
> Tnx
>
Rule 1:
Make sure that once it is installed nobody can see it - i.e. there are no
tell tale bulges.
Regards,
Richard.
http://www.FreeRTOS.org
for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
Microblaze, Coldfire, AVR, x86, 8051 & PIC18 * * * *
Widget
"Salvatore Di Fazio" <salvator...@gmail.com> wrote in message
news:1154539266.8...@m79g2000cwm.googlegroups.com...
> what are the rules to make a good embedded system?
> Tnx
>
Keep it simple (KISS)
--
Posted via a free Usenet account from http://www.teranews.com
Jim Stewart
> Hi,
> what are the rules to make a good embedded system?
Hire engineers that did their own homework
in college.
martin griffith
<wid...@alibaba.com> wrote:
>
>"Salvatore Di Fazio" <salvator...@gmail.com> wrote in message
>news:1154539266.8...@m79g2000cwm.googlegroups.com...
>> Hi,
>> what are the rules to make a good embedded system?
>> Tnx
>>
>
>Keep it simple (KISS)
and do everything in the ISR
martin
larwe
Jim Stewart wrote:
> > what are the rules to make a good embedded system?
>
> 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.
Salvatore Di Fazio
I talk about rules like:
1 - Implement a Command Queue
2 - Implement a hand shake system
and other things like these.
Tnx
PeteS
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
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.
It's a system that get many commands from a serial port, analyse the
command and fowards these to another system.
Tnx
FreeRTOS.org
> 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.
Donald
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.
Grant Edwards
> what are the rules to make a good embedded system?
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
visi.com impression...
Grant Edwards
> No guys, :)
>
> I talk about rules like:
>
> 1 - Implement a Command Queue
> 2 - Implement a hand shake system
Sorry, I've been doing embedded SW for 25 years, but I've no
clue what you're talking about.
> and other things like these.
??
--
Grant Edwards grante Yow! BRILL CREAM is
at CREAM O' WHEAT in another
visi.com DIMENSION...
Travis Hayes
> It's a system that get many commands from a serial port, analyse the
> command and fowards these to another system.
> Tnx
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.
Alan Cohen
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.
Chris Hills
Salvatore Di Fazio <salvator...@gmail.com> writes
Command, Queue and handshake.....
Try here
:-)
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch...@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Tom Lucas
news:mK+bRtCo...@phaedsys.demon.co.uk...
> In article <1154542994....@m73g2000cwd.googlegroups.com>,
> Salvatore Di Fazio <salvator...@gmail.com> writes
>>No guys, :)
>>
>>I talk about rules like:
>>
>>1 - Implement a Command Queue
>>2 - Implement a hand shake system
>>
>>and other things like these.
>
> Command, Queue and handshake.....
> Try here
>
> http://www.ugle.org.uk
>
> :-)
Sssssssh! That's supposed to be a secret.
Michael R. Kesti
<snip>
>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.
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
| two, one and one make one."
mrkesti at hotmail dot com | - The Who, Bargain