Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.
Same as technique of writing any good software. It's no different in that respect just because it runs on a microcontroller.
There are many books on software programming that would show this information. It is a complete career for many, so not something
that can be listed as just a few tips. I'd suggest to try to look at a computer science degree book-list to try to identify
some good books (I'm not a computer scientist so I don't have any specific book list to offer you).
Personally I wouldn't trust web links until I'd done some investigation into what is best practice, and for that I'd look towards
university reading lists as at least a start. Otherwise, how do you know which web links have good information, and which ones have
poor information.
I have more than 8 years of experience in firmware writing, yet i want to improve my skill to write firmware.
Please suggest,
What is the standard way of writing good,optimized and well organized embedded firmware? Suggest some good tips, links, pdfs or books.
For embedded (and other work) some ideas are pretty universal:
1. KISS
2. Fully understand the hardware - electronics knowledge and design knowledge
3. Design before coding (I personally favour flowcharts - lots of them)
4. Use a well respected and supported toolchain
5. NEVER bodge anything - it always comes back and bites you - you must invest to accumulate
6. For production understand local and global laws and regulations and design them in
7. Design to last - not to maintain and repair
8. Again for production - beware of patent terrorists
9. Assemble everything you need to build a prototype and verify supplies
10. Break the design into component assemblies and develop each individually
11. When you do start coding - KISS KISS KISS - lots of very short functions help
12. Ignore chip limitations at this stage - get it working first then optimise
(I develop with the best featured chip then trim down for a final design - PICs are very good for that approach)
13. TEST TEST TEST - Generate lots of test data and conditions and try and break your final prototype
14. Get others to try and break it for you
15. DOCUMENT DOCUMENT DOCUMENT for you, your users etc. No documentation = no viable product.
When writing code write the document line by line with it as you go - there is no substitute for that
The style and approach I've come to believe works best is:
Top down design - bottom up construct.
Top down to understand what you want to achieve
Bottom up to get the code and electronics functioning reliably
If the reason to do it is to sell a product remember:
Nobody wants a cheap product - what they want is a product that works.
You should note - the firmware is a small part of a complex whole in embedded programming.
You need to do it all.
As with any sort of work - always buy the very best tools you can.
(Best may not mean most expensive - but it can)
When I wrote my software 30 years ago, there were almost no comments. Picking it back up a few years ago , the only thing that helped me was my LABELS. without them I would have never been able to figure out what I was doing back then.
There are numerous books that I think are worth recommending, provided that english language is not a problem for the reader. One book which I bought and found to be helpful and aligned with many of my own principles is "Better Embedded System Software" by PhD Philip Koopman. You can find/google it on the web for some excerpts or to purchase. There are also several good books by an embedded specialist named Jack Ganssle. These are all general practices books and not specific to any one development toolset or processor, and they cover a broad area of best practices.
When I wrote my software 30 years ago, there were almost no comments. Picking it back up a few years ago , the only thing that helped me was my LABELS. without them I would have never been able to figure out what I was doing back then.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
