Transition from 8051 to AVR

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, as I already wrote in my previous post, I am new to AVR. Why I choosed AVR? Becouse it can be very simply programmed home, and it´s very popular from what I read. BUT, I was used from school to 8051 CPU. To be more precise, AT89C51 I think it the correct name.

I was really excited to work with AVR assembly language, but it is like a nightmare to me. If you know 8051, I know you do, you only need MOV instruction 90% of the time. It doesent matter wheather you MOV to special register or SRAM, or even IO port.

Please, don´t take me bad, I mean, I like AVR MCU, and please dont write use C, becouse I like working with ASM.

But I must ask, I need to know, is there any good reason, why there are different instruction names for operations with registers, and operations with IO ports and so on, so different from 8051?

And if I can have one more newbie question, why you must first specify wheather you write or read to a port and than read or write? 8051 has no such thing, and it works the same. If I want to read whatever is on the port, I just mov it to the memory or SFR, just like writing to it.

Please, help me clear things a bit, becouse right now, I am really confused...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The IN/OUT instructions are special because they only have room for one byte of "address". Special addresses have been made for most of the peripheral (I/O) registers to work with these instructions.

Because of the smaller instruction size, the instruction can run faster (take fewer clock cycles) and the standard STS or LDS. These instructions take TWO words of flash, and take TWO cycles to execute. You CAN use them with peripheral (I/O) registers, but they are slower and take more flash space.

You will find this to be a fairly common situation, where code space and speed are enhanced in special situations that are used commonly, This means that the program will run faster than it would if only STS/LDS were available.

IN/OUT vs MOV addr,reg / MOV reg,addr is just a matter of semantics. It is how the original authors chose to create the assembler mnemonics. It all ends up being the same effect.

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

This has to do with the architecture mostly.
The 8051 architecture is set up so that almost all internal memory locations (which aren't that many anyway in classic 8051 design) can shift to the ALU (Arithmetic and Logic Unit) and can be moved from the accumulator to any of the internal memory locations.

In an AVR it works a little different, to be able to access all the internal hardware (which is a WHOLE LOT!) they used an architecture in which the ALU's inputs and output are only connected to the instruction buffer (for constant values) and the 32 working registers. So all operations will have to be done within these registers, as it happens MOV is an ALU instruction.

After that you get the IN and OUT instruction to put a register value over the long internal roads to a memory location, but wait! IN and OUT are only 16 bit words, as are most basic instructions in an AVR... What do you do when you need to access a memory space really far? Such as, say, 12 bits long. 4bits isn't enough to cover all the possible op-codes!
So they added Load and Store commands, which take up more space (2 words in stead of 1) but can contain a lot of extra information. Such as LD, which can load from the memory pointed to by one of the 32bit register pairs (Z {R31:R30} for example).
But they needed to make a command that can hold a constant value as address as well, to make things go fast they decided to not use LD but make another command.

Basically this ends in a whole bunch of different commands just to access memory, but it also ends in your program executing very fast without losing control of the tens or even hundreds of special functions (ADC, internal PullUp, Timers, Analog comparator, internal RAM, internal EEPROM, USART) of an Atmel AVR.

Mainly it's just a matter of integration and speed. They wanted a small chip with a lot of functions without having to wait 10 clock cycles to store something in "exotic" RAM.

And just to be clear: C is nice, but never ever forget about ASM! ;-)

Also: I haven't delved into the Atmel AT98 architecture, nor very deeply into the AVR (not more than I need to program them), so I may have made 1 or 2 mistakes. But basically it's just: they had reasons!

Embedded design is as much a life choice as any other and I demand the right to legally marry my work.
-------
If it helps, I can PM you my answer in a number of different languages. Ask if you have trouble reading my high-speed-babble in English.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Of course ka7ehk makes a good point as well, assembler program could compile a MOV

, to something similar to OUT
, , they chose not to, probably to keep the separation clear.

Anyway, I'm off for tonight as I have most likely made enough of an ass of myself already.

^.^

Embedded design is as much a life choice as any other and I demand the right to legally marry my work.
-------
If it helps, I can PM you my answer in a number of different languages. Ask if you have trouble reading my high-speed-babble in English.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When using AVR assembler2 (from AVRStudio), use the LOAD and STORE macros. These will automate the IN/OUT vs. LDS/STS instruction selection for special function I/O registers. These can save you allot of trouble when using AVR processors with special function I/O registers that exceed the 0x3F IN/OUT address limit.

AVR001: Conditional Assembly and portability macros
http://www.atmel.com/dyn/resourc...
http://www.atmel.com/dyn/resourc...

You might also be interested in the entire application notes page:
http://www.atmel.com/dyn/product...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Addressing the OP's second question:

pokevitek wrote:
And if I can have one more newbie question, why you must first specify wheather you write or read to a port and than read or write? 8051 has no such thing, and it works the same. If I want to read whatever is on the port, I just mov it to the memory or SFR, just like writing to it.

Please, help me clear things a bit, becouse right now, I am really confused...

Well, you don't HAVE to specify that you want to use a port for reading, because that's the powerup default state of the port's direction control bits. But as to why to have a direction control register at all, vs. the 8051's "quasi-bidirectional" ports...

The 8051's lack of direction controls for its base I/O ports freed up four precious "special function register" addresses (which would probably have had to be bit-addressable, no less, and that would have left them with no spare bit-addressable SFR space). It's pretty impressive how much you can do with those quasi-bidirectional ports, but they have some drawbacks:

    Kind of hard to come up with ten or twenty mA of active-High output current from a quasi-bidir pin...
    You have to be aware of the instructions (like "INC") that implicitly read the "last written" port value vs. the ones that actually read the pins
    If you interface pushbutton switch-closures to ground to pins of a port where you want to actively output signals on some of the port pins, you have to keep writing 1s to the positions that have the buttons. There are temporary "strong pullups" that come on for a couple clock cycles (of the twelve that it takes to do an instruction - on an original type 8051, anyway), and these can contend with a grounded switch closure.
    Hard to implement an external passive pullDOWN for the ports (I found one handy for mixing an active-HIGH scanning of a keypad with an LED refreshing scheme)
    AVR port pins are way more polite during system startup than 8051 ones: they don't go thundering up to the supply voltage; they act like open-circuits.
I've had a couple brushes with some newer "extended 8051 variants", where (since there wasn't any internal SFR expansion room anyway) extra I/O port controls were added as part of "on-chip extended memory", and those ports, oddly enough, came with true direction control registers...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You also need to remember where the 8051 was designed and its' history. The 8051 was an Intel design and it was intended as a replacement for the 8048 family. Much of the 8051 design was adapted from the 8048 (with improvements). As one of the very first single chip microcontrollers the 8048/8051 families are quite impressive considering that variants of BOTH are still being made today.