On 26 Mar 2007 22:32:44 -0700, "Baron Samedi"
<Papa.Legba.666@gmail.com> wrote:

>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.
>
[ text deleted ]
>of?
>
>Thanks very much in advance
>
	If you are referring to architectures then there theses
references to Product Line Architectures, which is widely used in
mobile phones.

http://sureshkrishna.wordpress.com/2006/12/09/product-line-architecture-in-automobile-industry/
	www-nrc.nokia.com/Vivian/Public/Misc/artMyllVR.pdf

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

Baron Samedi wrote:
> On 27 Mar, 16:08, "Boudewijn Dijkstra" <boudew...@indes.com> wrote:
>> Op Tue, 27 Mar 2007 07:32:44 +0200 schreef Baron Samedi  
>> <Papa.Legba....@gmail.com>:
>>
>>> 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.
>> Specifically which part(s) of a mobile phone?
> 
> 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?

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<<, 
if you decide to use C++). In the beginning, it can be a very thin 
layer, and get more sophisticated later (heap debugging, log filtering / 
compression).  In the stack, responsibilites for memory should be clear 
enough, and timing is important.  Properly debugged memory pool or heap 
operation seems better to me than gargabe collection.

For logging, I found the interface of the mozilla project "log4cxx" 
(log4net, log4c, log4j etc) quite useful; the actual code was too 
heavyweight for our application, so we reimplemented the interface in a 
reduced, lightweight version.

Good luck,

	Tobias

Baron Samedi wrote:
> 
... snip ...
> 
> All sofwtare, including HAl - and above - needs memory management,
         ^^
> debug trace log,e tc, and taht is what I woudl liek to discuss...
                  ^^^^       ^^               ^^   ^^

Do you never read what you type :-)

-- 
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>



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

Op Fri, 30 Mar 2007 07:31:26 +0200 schreef Baron Samedi  
<Papa.Legba.666@gmail.com>:
> On 27 Mar, 16:08, "Boudewijn Dijkstra" <boudew...@indes.com> wrote:
>> Op Tue, 27 Mar 2007 07:32:44 +0200 schreef Baron Samedi
>> <Papa.Legba....@gmail.com>:
>>
>> > 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.
>>
>> Specifically which part(s) of a mobile phone?
>
> 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?

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

>> > 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.
>>
>> If your mobile phone is successful enough, the cost of 'scaffolding'
>> overhead is probably more than the cost of porting to a different OS.
>
> 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 ..

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&trade; programming practise.

> 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...
>
>
>> > 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.
>>
>> Here you are assuming a heap-based memory allocation algorithm.  I
>> wouldn't call this "reasonably generic".
>>
> Then what do you suggest?  I think that we need memory pools which
> allocate dynamically at compile time, then manage that at run-time.

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/

On 28 Mar, 05:24, "Paul E. Bennett" <p...@amleth.demon.co.uk> wrote:
> Baron Samedi wrote:
> > 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.
>
> When you do you should write a book about it. There has, to date, been very
> little agreement on what such a common architecture might be. There are
> many models and overviews of a variety of architectures and each seems to
> come to prominence with the whim of "the latest fashion".  

Agreed. People disagree. But surely tehre are some central things
which we can all agree on, like memory management & tracing?

Thsi is not an academic exercise and I don't want *the* solution, just
smethign good enough for the real world, whcih will make our lives as
develoeprs and testers easier.




>
> A book I am reading at present, "System Safety: HAZOP and Software HAZOP" by
> Felix Redmill, Morris Chudleigh and James Catmur, has a nice chapter on
> system representation which leads into a natural style for proper system
> architectural decomposition.
>
> book-ref:
> <http://www.amazon.co.uk/s/ref=nb_ss_w_h_/202-0790886-2346224?url=sear...>
>
> --
> ********************************************************************
> Paul E. Bennett ....................<email:/...@amleth.demon.co.uk>
> Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
> Mob: +44 (0)7811-639972
> Tel: +44 (0)1235-811095
> Going Forth Safely ..... EBA.www.electric-boat-association.org.uk..
> ********************************************************************

On 28 Mar, 03:24, David R Brooks <daveb...@iinet.net.au> wrote:
> Vladimir Vassilevsky wrote:
>
> > Baron Samedi wrote:
>
> >> I am trying to come up with an overview of a common software
> >> architecture, which I would like to keep reasonably generic.
>
> > 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.
>
> >> 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.
>
> > 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.
>
> >> 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.
>
> > And I am thinking about the generic interface to the hardware and at the
> > board level.
>
> >> Can anyone suggest anything else, of a good web site or book
> >> discussing this topic?
>
> > I doubt if you will find any understanding in this newsgroup.
>
> >> If anyone knows of any freely reusable
> >> software, that would be a great bonus.
>
> > Free cheese is in the mouse trap.
>
> >> 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.
>
> > YES! That is what I am talking about.
>
> >> Does anyone have any suggestions for finding or designing a decent
> >> framework which could be used to hang each new embedded project off
> >> of?
>
> 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.- 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...

>
> - Show quoted text -

On 27 Mar, 16:08, "Boudewijn Dijkstra" <boudew...@indes.com> wrote:
> Op Tue, 27 Mar 2007 07:32:44 +0200 schreef Baron Samedi  
> <Papa.Legba....@gmail.com>:
>
> > 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.
>
> Specifically which part(s) of a mobile phone?

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?



>
> > 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.
>
> If your mobile phone is successful enough, the cost of 'scaffolding'  
> overhead is probably more than the cost of porting to a different OS.

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...


> > 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.
>
> Here you are assuming a heap-based memory allocation algorithm.  I  
> wouldn't call this "reasonably generic".
>
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

look up nesC and TinyOS

-- 
	mac the na�f

Mobile phone stacks -> http://www.trolltech.com/



On Tue, 27 Mar 2007 11:24:56 -0800, David R Brooks
<davebXXX@iinet.net.au> wrote:

>Vladimir Vassilevsky wrote:
>> 
>> 
>> Baron Samedi wrote:
>> 
>>> I am trying to come up with an overview of a common software
>>> architecture, which I would like to keep reasonably generic.
>> 
>> 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.
>> 
>>> 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.
>> 
>> 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.
>> 
>>> 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.
>> 
>> And I am thinking about the generic interface to the hardware and at the 
>> board level.
>> 
>>> Can anyone suggest anything else, of a good web site or book
>>> discussing this topic?
>> 
>> I doubt if you will find any understanding in this newsgroup.
>> 
>>> If anyone knows of any freely reusable
>>> software, that would be a great bonus.
>> 
>> Free cheese is in the mouse trap.
>> 
>>> 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.
>> 
>> YES! That is what I am talking about.
>> 
>>> Does anyone have any suggestions for finding or designing a decent
>>> framework which could be used to hang each new embedded project off
>>> of?
>> 
>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.

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