There is the term "multiprocessor system". These can be "tightly coupled" or "loosely coupled". A book on Computer Architecture should discuss those terms.
Why even use a different one rather than sticking with the term you already have?
Just because the various processes now run on different CPUs doesn't make their communication no longer be inter-process-communcation. IPC implementation will obviously be more complicated, due to the presence of more than one processor actually working in parallel, but's it's still IPC. That would change only if you had an OS that supported several CPUs running several threads of the same processes.
[And since none of this would usually be particularly relevant to embedded computing, I suggest you ask further questions elsewhere.]
--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
I think you should go else where to ask what is embedded computing! I presume you mean embedded systems because to my knowledge shared memory , sockets, pipes CPU and how a system communicates with each other belongs to Embedded Systems.
I'm always looking for good names that provide concise distinctions, so this question rings a chord.
Along the lines of your question, I like to distinguish between IPC (Inter Process Communications), a broadly applied term, and ITC (Inter Thread Communications). The difference being that threads share a single address space whereas processes do not (ignoring shared memory segments for the moment).
In my mind, your question needs needs more background. CPU's can be connected and communicate in many different ways, none of which you specified. In the most general sense, I think you would call it "data communications". This, however, usually conjours up pictures of WANs and LANs.
Symetrical Multi Processing (SMP) systems have more than one processor sharing the same address space. In this case the processors communicate through the RAM that they share over a common bus. Also typical of SMP configurations is that the CPUs run a single copy of the operating system, and the operating system schedules threads among the CPU's. These configurations are generally availabe in high end desktop computers.
There are also other configurations where CPUs share RAM but execute independently, the logical address spaces of the CPUs are not necessarily the same, and indeed the CPUs themselves may be of different types. Such configurations are common in VME and similalr bus based systems. These configurations are common in big expensive fast real-time systems.
More common of this news group are systems that communicate over some sort of serial data link e.g. UART/RS232, I2C, SPI and HDLC.
Blah blah blah ... sorry for the rambling "non-answer" :-)
--
Michael N. Moran (h) 770 516 7918
5009 Old Field Ct. (c) 678 521 5460
Kennesaw, GA, USA 30144
"... abstractions save us time working, but they don't
save us time learning."
Joel Spolsky, The Law of Leaky Abstractions
The Beatles were wrong: 1 & 1 & 1 is 1
I have a PC104, PowerPC, Network Processor from Intel, which runs a Real Time Operating system. And embedded linux running on a 8240, i communicate over LAN and rs232 between the devices.
I want to be able to communicate within the system.
What would you call the communication term between the device?
Multiprocessor system? System communicating ? Embedded Communication ? IPC over a system?
I think you should go else where to ask what is embedded computing! I presume you mean embedded systems because to my knowledge shared memory , sockets, pipes CPU and how a system communicates with each other belongs to Embedded Systems.
Quite a bit of diversity. This is a single embedded system?
I don't quite know what to make of this statement. What do you mean by you "want to be able to communicate within the system?"
Sounds like a multiprocessor system.
Hmmm.
Hmmm.
I don't know what this means.
The only thing that I can think of that might even come close is "Distributed Computing", but that is not a term I usually associate with embedded systems, and its not really a term for communications.
Given that the mediums are LAN and RS232, and not knowing anything more about the application, I'd just call it data communications.
--
Michael N. Moran (h) 770 516 7918
5009 Old Field Ct. (c) 678 521 5460
Kennesaw, GA, USA 30144
"... abstractions save us time working, but they don't
save us time learning."
Joel Spolsky, The Law of Leaky Abstractions
The Beatles were wrong: 1 & 1 & 1 is 1
I have never heard this distinction made along the lines of data and commands. The term "data communications" refers to the transfer of information independent of whether that data is command or data.
I *have* heard of the following types of data communication which have to do with the delivery requirements/semantics.
At-Most-Once At-Least-Once Exactly-Once
With at-most-once transfers, a single "packet" of data is sent toward the receiver, and may or may not be actually received depending upon the network between the sender and receiver.
At-least-once transfers operate by sending the same packet several times in the hope that at least one copy of the packet is received.
Exactly-once tranfers follow a protocol of data transfer, acknowledglements and timers that, short of a major connectivity problem, ensure that exactly one copy of the packet is delivered to the receiving application.
--
Michael N. Moran (h) 770 516 7918
5009 Old Field Ct. (c) 678 521 5460
Kennesaw, GA, USA 30144
"... abstractions save us time working, but they don't
save us time learning."
Joel Spolsky, The Law of Leaky Abstractions
The Beatles were wrong: 1 & 1 & 1 is 1
I worked on a similar system. Very interesting project if you ever get a chance to do it. We have Mips, PPC, Linux with x86 SMP, Other RTOS with X86 etc. This kind of system is very typical for big telecom equipements. Fews CPU cards even had
2 GB of RAM in it.
Very interesting to debug. All kind of messages flying everywhere. Application might be blocked on something and claim to miss the messages from somethere else, etc, etc. Have to generate a few custome tools to debug all kind of distributed messaging issues. It is amazed that the system works at all. I thought we would be crushed to dead by the complexity of the system.
-- SLink create hyperlinks for all functions, macros, variables from thousands of files. Browse hyperlinked source code for .NET CLI, Mozilla, Apache, NetBSD, Ethereal, Chorus OS at
Interesting, telecom happens to be my background, although I've never worked on a system with *that* many different processors.
Back to the OP's question, how about:
"Distributed Computing in a Heterogeneous Computing Environment"
1/2 :-)
While I laugh at this description, it truly is a discription of some of the problems that must be solved in these kinds of systems. The trick is to get management to understand the impact on the schedule.
Indeed. Complexity managment is the name-of-the-game in telecom. The trick is to not only meet the initial "first release" requirements, but to design a framework that will allow the "next generation" requirements to be met without starting from scratch. Solid system architecture is the key to long term success.
--
Michael N. Moran (h) 770 516 7918
5009 Old Field Ct. (c) 678 521 5460
Kennesaw, GA, USA 30144
"... abstractions save us time working, but they don't
save us time learning."
Joel Spolsky, The Law of Leaky Abstractions
The Beatles were wrong: 1 & 1 & 1 is 1
I have work for embeded systems for the last 7 years and it is very common to combine different processors for example C16x, PowerPC, Intel PC , TMS320C25 in one system. The first problem you have is the byte order, but that is not the topic here
That was one Telecom project that i worked on which combined the Processors above.
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.