Shared Memory for Application/Communication decoupling
- From: Christian Walter <wolti@xxxxxx>
- Date: Thu, 07 Dec 2006 23:52:39 +0100
Hello,
We are currently evaluating design options and are in the problem of choosing a communication model between the application task and the communication task. The basic requirements are as following:
* The system should support different fieldbus protocol in the
future.
* The system must support Modbus RTU/TCP right now.
* Values must be consistent on the interface side at any time.
* All relevant data values must be communicated.
* Two-way communication must be possible. Reading on the fieldbus
side is more important.
* Lower bound for update of data on the interface side is 1 second.
We thought about using a Shared Memory Architecture between the two tasks which solves (In my opinion) the following problems:
- Handling consistency is easy because the data is essentially
duplicated.
- It is easy to meet protocol deadlines because values can always
be read from the memory.
- The application task can take the values if it is ready for them.
(For example at the end of the calculation if calibrations settings
have changed).
- It works as a firewall (temporal) between the two tasks.
The other suggested way is using Message-Queues. The problem I see with them is that it is difficult to handle consistency and it also leads to a tight coupling in the time domain. For example if the communication task needs a value the other task must supply it. What if the other task needs some values and the communication side wants to write them? In this case we need some double-buffering again because otherwise the other task would work with inconsistent values.
What is your opinion on this issue? I would like to go with SHM but then we would need to different IPC mechanisms in the software. Internally in the application task SHM would be to heavy and message queues (and of course simple function calls) are more appropriate. Does this violate system uniformity (What is the correct English term for that) in the sense that one should not use different concepts for the same thing (IPC)?
Kind regards,
Christian Walter
.
- Follow-Ups:
- Re: Shared Memory for Application/Communication decoupling
- From: Boudewijn Dijkstra
- Re: Shared Memory for Application/Communication decoupling
- Prev by Date: Re: Math computing time statistics for ARM7TDMI and MSP430
- Next by Date: Re: Math computing time statistics for ARM7TDMI and MSP430
- Previous by thread: Intel 8096 ports 3 and 4 on romless parts
- Next by thread: Re: Shared Memory for Application/Communication decoupling
- Index(es):