Embedded system design question

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

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

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

-- Ray

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
http://www.wescottdesign.com

Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html

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

--=AD--

--=AD--

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

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

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:

-- EventStudio 4.0 -

Embedded System Modeling with Text Based Sequence Diagrams