2
\$\begingroup\$

On the 8bit Atmel AVR MCUS (specifically mega and xmega series), is it possible to simultaneously modify multiple ports in a single instruction cycle?

For example, I have a 512kB RAM chip which requires 19 address lines. This requires multiple 8bit ports to adequately address. Is it possible, in a single instruction cycle, to set all 19 bits to a specific address? I understand I can set the high bits, then the middle bits, then the low bits and increment the low end port to step through the RAM however the mapping may not be sequential. Can I, again to take a random example, have the RAM place the 1st byte, then the 510th byte then the 294th byte on the data bus in three sequential CPU clock cycles?

Thanks!

\$\endgroup\$
  • 1
    \$\begingroup\$ Trying to hang a large external SRAM off of these chips is basically starting off with a poorly conceived design. Pick something with an external memory space and a sufficient linear address space - 32 bit cores are not expensive these days. \$\endgroup\$ – Chris Stratton Mar 12 '16 at 20:12
5
\$\begingroup\$

No.

The AVR has an 8bit data bus and that means it can only write to one 8bit register at a time. There is no way of programming three bytes at the same time.


If you are accessing that much memory, I would suggest you consider going for a 32bit MCU. It is possible to get 32bit AVR Processors if you want a similar CPU. Alternatively there are many relatively simple/cheap 32bit ARM processors from many manufacturers. Take your pick.

\$\endgroup\$
  • \$\begingroup\$ There are some applications where a CPU may need to access many small items from a large memory; an 8-bit CPU may be perfectly adequate for purposes like spooling out uncompressed audio data from a memory device of nearly any size if one adds some external latches for upper address bits. \$\endgroup\$ – supercat Mar 12 '16 at 19:54
  • \$\begingroup\$ @supercat I agree - in fact some AVRs have an XMEM interface which allows 64kB of external RAM (more if you use additional banking bits) to be mapped into the CPUs address space directly which uses latches to reduce the number of IO pins requires. While a great option for some situations, it doesn't achieve what the question was asking which is truly random, single cycle access of the whole memory space. \$\endgroup\$ – Tom Carpenter Mar 12 '16 at 20:00
  • 1
    \$\begingroup\$ @supercat - while it is possible to make do with an 8-bit CPU, there's not much if any cost advantage to doing so today, so it makes little sense in situations where the workarounds add a lot of complexity and muddy up the software situation. \$\endgroup\$ – Chris Stratton Mar 12 '16 at 20:14
2
\$\begingroup\$

The AVR XMEGA has an External Bus Interface that addresses up to 16MB. External memory can be accessed with a single CPU instruction. A read takes 2 CPU clock cycles (writes only take 1 cycle) but the XMEGA can be clocked at 32MHz, making it equivalent to a single cycle on a 16MHz AVR.

XMEGA External Bus Interface

enter image description here

However since the external memory is mapped into the 64k data memory space, only 48-55.5kB (depending on how much data memory space is used for internal IO/EEPROM/RAM) can be randomly accessed without changing banks. The lower 8.5-16k is not normally available. To access the entire 512k you would have to manually control address line A15, making the bank size 32kB (mapped into the upper 32k of data memory space).

Some older AVRs such as the ATMega128 also have an external bus interface, but with more limited addressing capabilities. These may be slower due to having to manually control more upper address lines, and also because they have a lower clock speed. But if speed is that critical you shouldn't be using an 8 bit AVR anyway!

\$\endgroup\$
  • \$\begingroup\$ Thanks Bruce - I read that the XMEGA could address 16MB but I wasn't sure how that worked with the 8bit bus. This explains it perfectly! \$\endgroup\$ – user3081739 Mar 12 '16 at 20:41
2
\$\begingroup\$

A memory chip isn't generally going to care if all the address wires switch at the same time. The most that would typically be required would be that all address wires be set to their proper levels before an access is initiated, and that they remain at their proper levels for some amount of time after the access is complete. In many cases, the requirements for read accesses are even looser than that: if the address on the bus changes during a read, many devices will effectively automatically initiate an access with the new address, and prevent valid data within some period of time of the last change to the address bus.

Since using one I/O pin for each address line would gobble up a lot of I/O, it may be helpful to add one or more latches or registers. For example, one could address up to 16MB of memory while using nine pins for addressing. Connect eight of them to address bits 0-7 as well as the inputs of a 74HC373 and a 74HC374. Feed the remaining pin to the load-enable and clock signals of those chips. Connect the outputs of the 74HC373 to address bits 8-15, and those of the 74HC374 to address bits 16-23.

To access a particular byte, start with "Clock/LE" low and do the following in order:

  1. Output bits 16-23 of the desired address.
  2. Drive "Clock/LE" high.
  3. Output bits 8-15 of the desired address.
  4. Drive "Clock/LE" low.
  5. Outputs bits 0-7 of the desired address
  6. Hit whatever other pins are necessary to trigger the desired access.

Additional accesses within a 256-byte range may be accomplished by repeating steps 5-6 (omitting steps 1-4).

A variety of arrangements are possible depending upon speed requirements and the number of I/O pins you have available.

\$\endgroup\$
  • \$\begingroup\$ Good point that it doesn't all have to happen at once - and if the typical access is to a degree sequential, the time overhead of infrequently latching a new "bank" value into the higher lines can be low. However, there's not a lot of justification today for sticking with an 8-bit part in a situation where that is limiting - they don't really tend to be cheaper. \$\endgroup\$ – Chris Stratton Mar 12 '16 at 20:16
  • \$\begingroup\$ Good point supercat - it won't meet my needs for this project, but I'll keep it in the back of my mind! \$\endgroup\$ – user3081739 Mar 12 '16 at 20:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.