Intel, AVR, and PIC architecture differences

avr architecture

I have a fair amount of exposure to the intel architectured microprocessor(specifically INTEL 80C188EB) in school. Recently, I got into interest with AVR and PIC. I understand that AVR and PIC devices are microcontrollers while Intel 80C188EB is just a microprocessor. With the 80C188EB, I can interface with a lot of external peripheral devices using the data bus, address bus, and control signals (read and write). Since AVR and PIC devices are microcontrollers, they have integrated some peripheral features and this takes away hassel. So my question is, what if we want more peripheral features with those AVR and PIC devices, how are they interfaced with the microcontroller (as in the 80C188EB case, there are actual pins for the data bus, address bus, and control signals to connect to, but this is not the case with these microcontrollers)?

For example, interfacing a 74HC139 1 out of 4 address decoder can be easily done with the intel processor. However, with AVR and PIC I'm not so sure.

I'm really confused now

pic avr io expand

Lets start by defining a microcontroller as: "cpu, ROM and RAM and peripherals are on chip, package pins are i/o to the peripherals" and microprocessor as: "cpu is on chip, package pins provides general-purpose memory and i/o buses for external applications to connect to memory and peripherals as needed".

Between these two limits are chips which blur the definitions; you can choose to lose some i/o pins and gain some address bus, so you can expand the ROM/RAM/IO if you need to. Nothing comes free, though, and having this flexibility tends to put up the package size & pin count.

When you have an application you choose the chip to fit; if it needs more memory or i/o than is available on a 'pure' microcontroller, you have to choose something that has more 'microprocessor' characteristics, and put other chips in place to provide the i/o peripherals you have lost.

What you will also find in the microcontroller domain is various techniques for expanding i/o and memory space without all the pins needed for an address bus; examples are I2C (i-squared c) (from Philips originally for use inside televisions) which is two-wire, SPI (Motorola), etc. Nothing in life is free; these may use few pins, but the bandwidth tends to be limited to 100-1000 kbits/s maximum. However you can get chips which understand these protocols and provide some i/o pins, EEPROM memory which can be very useful in situations with limited pins free. They are also useful for comms between microcontrollers.

Beyond that there are homebrew methods you could use to extend the i/o of a microcontroller by using (say) 3 i/o pins to drive a hc138 decoder, one to specify read/write, 8i/o pins as bidirectional i/o to a shard data bus, one to specify 'do a read or write cycle'. With 13 pins and two external decoders you can get access to 8 addresses each of read and write registers. You have to program this 'bus' yourself, your software would have to set the 3 address bits, set the R/W line, set the 'cycle' pin low, read the 'data bus' pins, set the cycle line high, etc., so the bandwidth will be limited; it would probably be better to choose a chip with more microprocessor charactersitics which provides these functions in a hardware address bus.

HTH
Barny

pic+avr+architecture

barny451, really appreciated for your detailed explanation
just another quick question, how easy it is to move from one device to another within the same family, such as from one ATmega to another ATmega? I mean after a design is complete, I might need to upgrade for performance or downgrade for cost, without modifying too much on the whole design.

architecture avr

how easy it is to move from one device to another within the same family, such as from one ATmega to another ATmega?

Click to expand...

It's very easy. Problem is to move from e.g. PIC to AVR or INTEL, but all ATMEGA's have same philosophy of working so when you move to more powerfull mcu you need to learn just the diferece between those two.


Mr.Cube

pic avr bus

The most common minor variation is Flash/RAM size, which has a very clear size vs price tradeoff. Variants on clock speed too, sometimes.

However anything else is likely to need a different core, so don't expect to develop your application software then choose a chip to fit it.

Any other sort of variation than flash/ram/speed is likely to be in a different package, meaning a different PCB layout.

If its particularly critical to your application to get minimum price/maximum performance, you probably need to have the chip selected which 'should do the job', and an up- or down-scale of it depending on neccessity/opportunity to choose an alternative.

HTH
Barny