Embedded system design question

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi,

I need to design a system as depicted below. Multiple applications
communicating with a middle layer which in turn communicates with
drivers(Note: The communication between app<-->middle<-->driver is
full duplex).
Do I need to have a function call interface between application and
middle layer or should the middle layer be a task (multiple tasks).
Ideally all applications should have a single interface to the middle
layer. What IPC mechanism would be best suited for this design. Should
it be a task based design or function calls or both?

........      ...........      ........
| app 1|     | app 2|     | app 3|
..........     ...........     ..........
\       /       \      /       \     /
 \     /         \    /         \   /
------------------------------------------
|         middle layer              |
------------------------------------------
\       /                  \        /
..\..../..                  \....../....
| drv 1|                   | drv2 |
..........                  ...........

Thanks,
asm


Re: Embedded system design question



Quoted text here. Click to load it

The answer depends on what do you like: the clarity of the concept or
the minimal overhead. If you want it all uniform, neat and clean, then
the best solution is the multitasker communicating by the messages. The
drivers communicate to HAL, the HAL communicates to applications. An
application must "open" the relevant drivers so HAL knows how which
messages should be directed where.

Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

Re: Embedded system design question
On 31 Oct 2007 15:03:03 -0700, I said, "Pick a card, any card" and
snipped-for-privacy@mail.com instead replied:

Quoted text here. Click to load it

Are you designing your protocols from scratch or are you open to
using existing ones?
--
Ray

Re: Embedded system design question

Quoted text here. Click to load it

Of late I have preferred to have all layers communicate through function
calls.  If it is necessary to have a task behind the function calls, then
I put one there and have the functions send OS messages (or set
semaphores, or whatever).  That way I have a nice consistent API no matter
what odd things I may choose to do "under the hood".

This can increase your overhead a bit if _all_ your function calls are
just wrappers for OS operations, but it can decrease it in the cases where
you can get by with setting an atomic value and giving the underlying task
a kick instead of queuing up a full-fledged message.

--
Tim Wescott
Control systems and communications consulting
We've slightly trimmed the long signature. Click to see the full one.
Re: Embedded system design question
Quoted text here. Click to load it


Hi,

I was thinking on similar lines. Probably have a single API interface
to middle layer and resgister call backs with middle layer.
The call back would post messages on a message queue (one for each
application). In the reverse direction appl->middle layer an api could
be used for middle layer services. I am not sure about the middle
layer <--> driver interface. Note that two way communication is needed
between
middle layer and driver also. One important design goal is not to make
any of the layer a bottle neck for others.Would it be better to have
the drivers as tasks or just function calls ? How does the driver code
normally execute ( as task ?) in current embedded systems ?

Thanks,
Arut


Re: Embedded system design question
Quoted text here. Click to load it

I think, the below design will be fine.

1) 3 separate taks for the apps,
   1 task for the middle layer and
    2 more taksks if required, else the 2 driver can handle
    the stream of data directly.
    The priorities of the differenct apps/taks should be set.
    Need to configure the Scheduler accordingly.
2) Separate Message Queues for every task to
    communicate with a common task(middle task) .
    which will receive and inturn communicate with the
    lower level drivers based on the Source Id and Target Id.
    Or
    2 message queues receiving high priority and low priority
    messages separately from the upper app tasks,
    which will receive and inturn communicate with the
    lower level drivers based on the Source Id and Target Id.

Maybe something as below .

Task1 <-> Driver1 = Duplex Communication via Middle Layer
-----------------------------------------------------------------------------
Task1 (MsgQPost - T1_Tx)
MiddleLayer(MsgQPend - T1_Tx) will get from the task 1
MiddleLayer(MsgQPost -D1_Rx )  will post the processed info to driver1
Queue
Driver1(MsgQPend - D1_Rx, Target - D1)

Driver1(MsgQPost - D1_Rx)
MiddleLayer(MsgQPend - D1_Rx) will get from the driver1
MiddleLayer(MsgQPost - T1_Rx) will post the processed info to Task1
Queue
Task1 (MsgQPend - T1_Rx, Target - T1)

Task2 <-> Driver1 = Duplex Communication via Middle Layer
-----------------------------------------------------------------------------
Task2 (MsgQPost - T2_Tx)
MiddleLayer(MsgQPend - T2_Tx) will get from the task 2
MiddleLayer(MsgQPost -D1_Rx )  will post the processed info to driver1
Queue
Driver1(MsgQPend - D1_Rx, Target - D1)

Driver1(MsgQPost - D1_Rx)
MiddleLayer(MsgQPend - D1_Rx) will get from the driver1
MiddleLayer(MsgQPost - T2_Rx) will post the processed info to Task2
Queue
Task2 (MsgQPend - T2_Rx, Target - T2)

Is this design fine for you ?

Karthik Balaguru


Re: Embedded system design question
Quoted text here. Click to load it

Hmm .
Other than that, You can also, make a design using Dispatcher.
The Dispatcher in the middle that will do the following set of
operations -
1)Message receiver
2)Decoder
3)Encoder
4)Message transmitter

Dispatcher design is also a good design but, the dispatcher
should be carefully designed. Dispatcher plays the role of the
middle layer. The drawback with the dispatcher approach is, it
overloads  the dispatcher(middle layer) as it has to handle all
the intertask communication related operations  and hence it
will have its impacts in realtime systems.

So, making a modular design without using a Dispatcher
in the middle will be very efficient if you intend to avoid
overloading. It depends on the setup you have . (Memory,
RTOS,Number of Taks, No of drivers / Peripherals, DMA)
And, it all depends on the type of requirements
you have . Many schemes are available .

Karthik Balaguru


Re: Embedded system design question
Quoted text here. Click to load it


I would recommend using function calls. They would be far more type
safe, efficient and simple to develop.

The following article might help with the layer organization:

http://www.eventhelix.com/RealtimeMantra/PatternCatalog/protocol_layer.htm

--
EventStudio 4.0 - http://www.EventHelix.com/EventStudio
Embedded System Modeling with Text Based Sequence Diagrams


Site Timeline