Products > Programming

Embedded program design thinking

(1/4) > >>

BlogRahul:
Hi everyone
This is my first post I hope I will get good advice and suggestion. I am looking experts advice on designing Embedded C program. How do you design program to solve a problem? What are step's for designing a program to solve a problem?

lapm:
Im not super experienced on embedded. But here's my 0.01 snt.

Major difference on embedded vs. normal programming is hardware limitations. No gigs of ram usually, no gigahertz of CPU cycles to burn usually, often no OS to relay on common tasks, etc...

Otherwise it goes much like any software development. Chip big problem into series of small problems.


Another special requirement in embedded is need to read and understand datasheets about subsystems you are using or hoping to use. Want to use serial port? How to initialize it to know state you expect it to be, etc.


Especially in lower end of embedded controllers its very much a optimization game. Cram your desired functionality as small amount of memory as possible. If you cant, then something must be left out.



Elicia WHite wrote nice book about designing embedded systems, i have read this book and do think highly of it.  https://www.oreilly.com/library/view/making-embedded-systems/9781449308889/

Berni:
Its the same as any other C programming with the only difference that you don't have massive amount of RAM available, no standard OS libraries and that you need to include hardware drivers as part of your code.

The main benefit being that you can get your app to run on really cheap and slow hardware while at the same time having very tight control over the timings of stuff.

For very large and complex applications its sometimes a good idea to take a middleground of using an RTOS. This provides multithreading support that you would enjoy under a OS, but does not provide drivers and all the nitty gritty low level stuff, so you still have the flexibility to have tight control over everything while using only mere kilobytes of RAM extra.

tggzzz:
For an embedded system, before you consider a programming language you can benefit from defining your problem and solution in terms of:

* events: inputs and messages between processes
* states: as in a finite state machine (FSM)
* actions: what happens when an event is received in a each state
* processes: an "engine" that implements one action at a time, from beginning to end
* threads: independent processes that can execute simultaneously
* algorithms: what processing is necessary to implement an event
* timing
Then, if you use C, either use an RTOS or make very sure you understand what the various C keywords don't guarantee. Most people think they understand them, most don't.

dmills:
In particular understand what 'volatile' does NOT mean when it comes to multi threaded applications (Also any type larger then the machine word size), it does not mean 'atomic'...

Navigation

[0] Message Index

[#] Next page