Introduction to P.I.C peripheral buses
 

Hi, I would like to be able to learn about connecting multiple devices up to a microprocessor. Are there any good links or terms to search for? :banghead:

What do you mean by "P.I.C peripheral buses"? What type of devices are you wanting to connect?

Checkout SPI and CAN bus technology.

Thanks for the reply!
 

I did find a few guides ;one being by (Philips Semiconductors , The I2 C bus and how to use it), that is worth noting.

MicroChips product is the one of choice right now and which I have studied on. The power of having a MicroController communicate with other hardware is essential to my goals. I want to be able to use a P.I.C with a SD card ,and every type of external memory there is ,even RAM. I want to build a few data-loggers that use more than one type of memory and also a few different types of Romulators or Eprom emulators. I'm reading the Philips guide and it appears that most of the communication effort goes into actual programming for whatever hardware is used. I shouldn't be , but I am surprised of actually having to write the code for the communication between devices. :o

Somebody has to write it :D

Microchip has plenty of application notes that might be of help.

The term 'devices' as used here is much too broad for there to be a single general purpose solution. Devices, in the sense of peripheral chips, have many different characteristics, and those tend to dictate how a CPU communicates with them. Some things, such as communications controllers, require a means to offload data asynchronously, and operate somewhat autonomously. They are like Linux character devices, and operate on streams of data. Other devices behave like addressable memory. Still others have elements of both characteristics. Some are intended to minimize the connection channel, such as SPI or I2C, or even One-Wire, whereas others have couplings to the CPU using buses that more closely resemble the native address, data & control buses.
Another use of the term 'device' could be described as something more akin to a 'host'. I'm referring to a device on a larger scale, such as another CPU host, a test & measurement instrument, or a modem or other communications subsystem. Often, such kinds of communication ends up being layered. A host may communicate with another host, via an intermediate layer such as ethernet, RS-232, or any of the other networking protocols use in embedded systems. In that case, the CPU communicates with the network device/chip on one level, and with the peer host on another level.
Some buses are intended to be exposed only between the CPU and chips on the same board, or perhaps across some kind of backplane within the same chassis. Other buses expand that capability for use between boards within relatively close proximity, such as SPI & I2C. Still other buses, such as CANbus or GPIB are much more akin to networks, or are full-on networks in their own right.
Embedded systems and single board computers tend to be more focused and specific in nature, as opposed to generalized. If you need to support a wide array of third party hardware, I suggest using a modular approach, where target-specific expansion of some type is used to extend a more generalized central CPU. Don't try to solve all problems with one design. Focus on removing un-needed components and minimizing the design, rather than trying to accommodate perceived solutions that may never materialize.
--- rod.

Exactly. Keep in mind that these mcus are not that powerful.... every byte and clock cycle counts. it's pays to write mcu and application specific versions of code to squeeze every ounce of performance out of it. Also mcu layout and design varies so much between chips, even between members in the same family, that it makes more sense to build everything from the ground up.

If you really don't want to bother with low level programming then look into the arduino boot loader for atmel mcus.