Where is the data segment assembled (avr assembly)

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

Hello.

I am one of the billion newbies here.
So I am asking a question.
When I assemble this code (for ATmega8)

.DSEG
.DB     "an interesting row o' bytes"

and then look at the "mytest.hex" using the XVI 32 (hex editor), there is no such text as I defined.

How does this work?

This topic has a solution.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

.DSEG is SRAM segment i.e. volatile RAM memory.

 

If you want to store a message,   put it in .CSEG or .ESEG

 

Note that you need LPM to read from Flash.    Or a specific subroutine to read from EEPROM.

 

I have never tried "storing" data in .DSEG.    You normally just use .DSEG to allocate space for buffers, variables etc.

Try it with the Simulator.    It can obviously never work in real life,   but the Simulator might initialise the simulated Data memory.

After all,   it does not initialise the simulated EEPROM memory.

 

Oh,  and when you have stored your message in Flash,  remember that Flash is principally WORD orientated.    So if you look at the WORDs,  each pair of 'letters' is transposed.

 

David.

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

Thanks, I didn't realize that SRAM is volatile as I thought it is connected to Flash, separated only "virtually".
 

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

That is one of the "conceptual differences" between a PC and most smaller micros. Look up Harvard architecture and compare to VonNeuann architecture. 

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

If you do want "initial values" in RAM (.dseg) then, because it's assembler not C, YOU have to put them there. You would build an initial value table in flash (.cseg) then in the early stages of your code you run a loop with two index pointers. One pointing to the base of RAM where you have prepared space to hold the "variables" and one (Z) pointing to the fixed values in flash. It then LPM's from the flash and ST's to the RAM.

 

This is one of the places where C makes life easy for you. In C if you just:

char text[] = "hello world";
int nums[] = { 1, 23, 456, 7890 };

then the compiler adds this code before entry to "main":

00000060 <__do_copy_data>:
  60:	10 e0       	ldi	r17, 0x00	; 0
  62:	a0 e6       	ldi	r26, 0x60	; 96
  64:	b0 e0       	ldi	r27, 0x00	; 0
  66:	e8 e8       	ldi	r30, 0x88	; 136
  68:	f0 e0       	ldi	r31, 0x00	; 0
  6a:	02 c0       	rjmp	.+4      	; 0x70 <__do_copy_data+0x10>
  6c:	05 90       	lpm	r0, Z+
  6e:	0d 92       	st	X+, r0
  70:	a4 37       	cpi	r26, 0x74	; 116
  72:	b1 07       	cpc	r27, r17
  74:	d9 f7       	brne	.-10     	; 0x6c <__do_copy_data+0xc>
  76:	0e 94 41 00 	call	0x82	; 0x82 <main>

It has Z pointing at the initial vales in flash (0x0088) and the X pointing at where to put them in RAM (0x0060).

 

If you use avr-as as your assembler you can benefit from this yourself. Just add a C file to the project with variable definitions such as I showed above and the linker will add _do_copy_data to the generated code (assuming you don't use -nostartfiles).

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

ka7ehk wrote:

That is one of the "conceptual differences" between a PC and most smaller micros. Look up Harvard architecture and compare to VonNeuann architecture. 

 

Jim

 

Whatever the architecture,   you can't put data into RAM without the CPU.     As Cliff has said,   the C compiler Run Time Startup (crts.o) does this bit for you.

 

Ok,   with VonNeuman,   copying from ROM to RAM or RAM to ROM uses the same instruction opcodes.

With Harvard,   you have to tell the CPU that it is using separate data buses.     With the AVR,  this means using LPM and SPM opcodes.

 

I suggest that you start with simple C programs.    Assembler is something that is useful to read but seldom necessary to write.     (and it is a lot more fiddly)

 

David.