Common software architecture for embedded systems

I am trying to come up with an overview of a common software architecture, which I would like to keep reasonably generic. That being said, it is intended for embedded systems, specifically mobile (cell) 'phones.

Irrespective of the actual software project, there are certain common functionalities which should be present in most systems. The operating system (currently VxWorks, but that could change) should take care of things like message passing, process scheduling, timers, etc. However, before beginning a project, it might be nice to have a skeleton which sits above that, as a sort of scaffolding upon which to build development.

I am thinking, for instance, of a decent memory management system, with defragmentation, checking for leaks, double-free and the like, some debug trace logging and so on.

Can anyone suggest anything else, of a good web site or book discussing this topic? If anyone knows of any freely reusable software, that would be a great bonus.

If not, I was thinking of going C++ (not meaning to re-ignite the perennial C vs. C++ debate), so that anything that I missed could be easily added into base classes later. I rather thought hat I might base upon "Design Patterns" by Gamma, et al

formatting link

Does anyone have any suggestions for finding or designing a decent framework which could be used to hang each new embedded project off of?

Thanks very much in advance

Reply to
Baron Samedi
Loading thread data ...

Op Tue, 27 Mar 2007 07:32:44 +0200 schreef Baron Samedi =

:

Specifically which part(s) of a mobile phone?

If your mobile phone is successful enough, the cost of 'scaffolding' =

overhead is probably more than the cost of porting to a different OS.

Here you are assuming a heap-based memory allocation algorithm. I =

wouldn't call this "reasonably generic".

--
Gemaakt met Opera's revolutionaire e-mailprogramma:  =

http://www.opera.com/mail/
 Click to see the full signature
Reply to
Boudewijn Dijkstra

I am trying to do it too. The main problem: keeping everything generic and universal requires a big amount of effort. Most of the developers do not change the board/platform very often, and they think that it is much easier to do the quick fixes and hacks rather then keep everything consistent and universal. That may be true or not true depending on the project.

Agreed. This is what I call the development framework. Again, developing a sensible framework requires a great deal of the experience. If it is done right, it saves a lot of effort on the subsequent steps. However many people see that development as the overhead not related to the project itself.

And I am thinking about the generic interface to the hardware and at the board level.

I doubt if you will find any understanding in this newsgroup.

Free cheese is in the mouse trap.

YES! That is what I am talking about.

My real email address is at the web site.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

One problem is that "real" systems are not built on development boards. For example, the firm I work with builds engine management computers. We recently went through the process of separating out the hardware-specific parts (we called it HAL, Hardware Abstraction Layer). But this is highly specific to our application area: for example, HAL includes management of whatever hardware observes the engine crank position and generates ignition pulses, etc. Other market segments would, I expect, have similarly specific requirements.

Reply to
David R Brooks

Hi, I am having a copy of the book on CODARTS by HASSAN GAMMA.Excellent book I would say from what I understood.It gives good examples of how to go about designing a RTOS based frame work.The book also gives examples on How to design for control systems of ship,some stuff on communication.

Search in google for CODARTS(concurrent design and real time systems) or HASSAN GAMMA.The previous company where I worked for mainly in the consumer electronics industry,have taken the guidelines mentioned in this book and has got a framework which has churned out several products and seems to be working well till date(We used C++ with vxworks).

Regards, s.subbarayan

Reply to
ssubbarayan

Mobile phone stacks ->

formatting link

Reply to
The Real Andy

look up nesC and TinyOS

--
	mac the naïf
Reply to
Alex Colvin

Protocol stack, from Layer 1 to Layer 3. Also teh upper layers - internally, the MMI sends 27.007 AT commands to tthe protocol stack. And why not cater for the devicde drivers too, for BlueTooth, etc?

Well, I am working for a small Asian company who just finished a disastrous first project, which I do not want to see repeated. I just want something generic, since we are customer driven and they may ask for Synmbia, VxWorks, their own o/s ..

What I really trying to do is to herd cats. We have lots of reasonably good programmers who don't really know how to work on a team. I am hoping that a framework will save development time and effort, while constraining them somewhat. But I am in danger of starting a new thread here ... my main goal will be to introduce proper software development Processes (design/review/test/etc), but let's just stick with the framework for this discussion...

Then what do you suggest? I think that we need memory pools which allocate dynamically at compile time, then manage that at run-time.

Thansk for the feedback

Reply to
Baron Samedi

Hide quoted text -

Yes, we have a HAL too - I guess that everyone does.

All sofwtare, including HAl - and above - needs memory management, debug trace log,e tc, and taht is what I woudl liek to discuss...

Reply to
Baron Samedi

So you need something like a driver framework? A protocol stack can be seen as a software-only driver.

You want common things to have a little more abstraction, so that similar things don't have to be created from scratch. Regardless of whether this should be called 'scaffolding', this is usually Good? programming practise.

I was mainly referring to defragmentation.

  • Fragmentation is impossible in proper pool-based allocation.
  • Leaks can be identified by use of an 'owner' field per allocation.
  • Double-free can be solved with a little indirection.
--
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/
Reply to
Boudewijn Dijkstra

... snip ...

^^

^^^^ ^^ ^^ ^^

Do you never read what you type :-)

--
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
Reply to
CBFalconer

I have worked with Protocol Stack software for mobile phones, though not in the last years. It will be a lot of work for your "herd of cats", to do it again from scratch, but it will be interesting and hopefully fun.

In the protocol stacks, the threads are well-defined, the interaction will be message-driven and the architecture can be derived more or less from the specs.

For Layer 2-3, I suggest thread functions that take a message as an argument and process it, keeping some state, of course. This will allow you to test them in simple PC applications, and the code is OS-independent with respect to message-passing and thread control. I have never seen or used this in real code, but I wish the code had been that way. It would have worked well.

Layer 1 is very timer-related code, and also quite hardware dependend, probably mostly located in the interrupt handlers. It is difficult to get right and needs a large part of the CPU time.

GPRS and 3G will need good handling of the data streams; I have not much experience with this, but have a good eye on it while designing.

For memory management and logging, I suggest you define your own interface similar to malloc/free and printf (or new/delete and cout

Reply to
Tobias Rischer

[ text deleted ]

If you are referring to architectures then there theses references to Product Line Architectures, which is widely used in mobile phones.

formatting link
www-nrc.nokia.com/Vivian/Public/Misc/artMyllVR.pdf

+====================================+ I hate junk email. Please direct any genuine email to: kenlee at hotpop.com
Reply to
Ken Lee

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.