Как задать значение переменной в SRAM при ее объявлении?

Question

[Serpens412]

Только недавно начал изучать ассемблер AVR, под контроллер Atmega8, использую компилятор AVR-GCC. И возник вопрос - как можно задать значение переменной в SRAM при объявлении в секции .data? Под компилятор AVRASM2 это делается, как я понял, примерно так:

.DSEG
variable: .byte 0xff

Однако, подобный код для AVR-GCC не приводит к похожему результату:

.data
variable: .byte 0xff

Фактически, по адресу 0x0060 лежит какой-то мусор, который никак не относится к тому, что я туда хотел положить. Однако, если мы посмотри размер программы с помощью avr-size, мы увидим, что у нас в секции .data занято 2 байта:

AVR Memory Usage
----------------
Device: atmega8

Program:      64 bytes (0.8% Full)
(.text + .data + .bootloader)

Data:          2 bytes (0.2% Full)
(.data + .bss + .noinit)

Если из объявления убрать значение переменной (0xff), то в секции дата будет 0 байт. В файле .lst мы видим такую картину в секции .data:

Disassembly of section .data:

00800060 <_edata-0x2>:
  800060:	ff 00       	.word	0x00ff	; ????

Почему компилятор пытается засунуть в память слово, и почему эти данные (ни слово, ни байт) в конечном итоге не попадают в память? И стоит ли вообще так объявлять данные, возможно, лучше при инициализации полностью очищать SRAM при старте контроллера?

Answer 1

[jcmvbkbc]

Фактически, по адресу 0x0060 лежит какой-то мусор, который никак не относится к тому, что я туда хотел положить.

Откуда взялся адрес 0x0060 и как вы поняли что там лежит?

TL;DR: код копирующий данные из FLASH в SRAM и обнуляющий .bss не линкуется по умолчанию. gcc вставляет ссылку на неопределённые символы __do_copy_data и __do_clear_bss в каждую единицу трансляции, в которой определяются объекты в секции .data и .bss соответственно. В написанных руками ассемблерных файлах их можно упомянуть явно.

Comments

[Serpens412]

Адрес 0x0060 - это адрес переменной variable в SRAM. У Atmega8 SRAM начинается с этого адреса (стр 18 даташита), соответственно, первая переменная будет записана туда. Файл .lst это подтверждает - переменная variables заменяется компилятором на адрес 0x0060.

Что там лежит, я понял по следующему коду:

#include 	<avr/io.h>

// ================= Секция SRAM =================
		.section .data
variable: .byte 0xff

// ================= Секция FLASH ================
		.section .text
		.global main

main:	// Устанавливаем PORTD на вывод.
		ldi		r16, 0xff 				
		out		_SFR_IO_ADDR(DDRD), r16
		// Все выводы PORTD устанавливаем в ноль.
		clr		r16
		out		_SFR_IO_ADDR(PORTD), r16

		// Загружаем из SRAM значение, лежащее по адресу variable.
		// Ожидаем, что все выводы порта D примут значение 1...
		lds		r16, variable
		out		_SFR_IO_ADDR(PORTD), r16

		// ... но этого не происходит.
		rjmp 	while

// Бесконечный цикл.
while:	rjmp	while

Следовательно, если бы у нас в памяти по адресу, на который указывает variable, лежало значение 0xff, то все выводы PORTD встали бы в единицу. Однако, этого не происходит.

Вот так выглядит процедура main в lst файле:

38:	0f ef       	ldi	r16, 0xFF	; 255
  3a:	01 bb       	out	0x11, r16	; 17
  3c:	00 27       	eor	r16, r16
  3e:	02 bb       	out	0x12, r16	; 18
  40:	00 91 60 00 	lds	r16, 0x0060	; 0x800060 <__EEPROM_REGION_LENGTH__+0x7f0060>
  44:	02 bb       	out	0x12, r16	; 18
  46:	00 c0       	rjmp	.+0      	; 0x48 <while>

Это точно не проблема самого порта - я проверял это, установив туда значение 0xff, предварительно загруженное с помощью команды ldi в РОН. Также корректно ведет себя код, если перед тем, как загрузить в РОН из SRAM значение variable, предварительно загрузить его в SRAM с помощью команды sts. Тоесть, значение не устанавливается только при инициализации в секции .data,

[jcmvbkbc]

Тоесть, значение не устанавливается только при инициализации в сегции .data

Ок. Как вы прошиваете получившийся программный образ и как он запускается? -- это я к тому, что в SRAM данные должны быть скопированы из флэша при старте программы -- где это происходит?

Вот я гляжу в AVR ELF одного из своих проектов и вижу следующее:

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .data         00000124  00800100  00001db0  00001e44  2**0
                  CONTENTS, ALLOC, LOAD, DATA
...

00000000 <__vectors>:
       0:       19 c0           rjmp    .+50            ; 0x34 <__ctors_end>

...

00000034 <__ctors_end>:
      34:       11 24           eor     r1, r1
      36:       1f be           out     0x3f, r1        ; 63
      38:       cf ef           ldi     r28, 0xFF       ; 255
      3a:       d4 e0           ldi     r29, 0x04       ; 4
      3c:       de bf           out     0x3e, r29       ; 62
      3e:       cd bf           out     0x3d, r28       ; 61

00000040 <__do_copy_data>:
      40:       12 e0           ldi     r17, 0x02       ; 2
      42:       a0 e0           ldi     r26, 0x00       ; 0
      44:       b1 e0           ldi     r27, 0x01       ; 1
      46:       e0 eb           ldi     r30, 0xB0       ; 176
      48:       fd e1           ldi     r31, 0x1D       ; 29
      4a:       02 c0           rjmp    .+4             ; 0x50 <__do_copy_data+0x10>
      4c:       05 90           lpm     r0, Z+
      4e:       0d 92           st      X+, r0
      50:       a4 32           cpi     r26, 0x24       ; 36
      52:       b1 07           cpc     r27, r17
      54:       d9 f7           brne    .-10            ; 0x4c <__do_copy_data+0xc>

-- это код копируюший данные .data из флэша в SRAM, прямо из вектора reset мы в него приходим.
По дампу хорошо видно LMA данных загружаемый в регистровую пару Z (по адресам 46-48), VMA загружаемый в регистровую пару X (по адресам 42-44) и конечный адрес данных (проверяемый по адресам 50-52).

[Serpens412]

Запускается очень просто - подачей питания на микроконтроллер) К каждому выводу порта D подключено по светодиоду, по ним я и определяю, в каком состоянии находится каждый выход.

Собираю с помощью утилит из avr-toolchain:

avr-gcc -mmcu=atmega8 -Xassembler -ggdb -o bin\Test.o test.S
avr-gcc -g -mmcu=avr4  -o bin\Test.elf bin\Test.o
avr-objcopy -j .text -j .data -O ihex bin\Test.elf bin\Test.hex

Полученный hex загружаю в контроллер с помощью программатора usbasp:

avrdude -p atmega8 -c usbasp -U flash:w:bin\Test.hex

[jcmvbkbc]

Запускается очень просто - подачей питания на микроконтроллер)

Я не про то. Что конкретно запускается из вектора reset? Я в предыдущий коммент добавил что происходит у меня в рабочем проекте для сравнения.

[Serpens412]

Действительно, кода, подобного <__do_copy_data> у меня нет - после инициализации стека он идет сразу в main:

Disassembly of section .text:

00000000 <__ctors_end>:
   0:	12 c0       	rjmp	.+36     	; 0x26 <__init>
 // Тут идет таблица прерываний...

00000026 <__init>:
  26:	11 24       	eor	r1, r1
  28:	1f be       	out	0x3f, r1	; 63
  2a:	cf e5       	ldi	r28, 0x5F	; 95
  2c:	d4 e0       	ldi	r29, 0x04	; 4
  2e:	de bf       	out	0x3e, r29	; 62
  30:	cd bf       	out	0x3d, r28	; 61
  32:	02 d0       	rcall	.+4      	; 0x38 <main>

Это странно - нигде не встречал информацию о том, что для загрузки в SRAM нужно что-то отдельно прописывать в компилятор.

[jcmvbkbc]

нигде не встречал информацию о том, что для загрузки в SRAM нужно что-то отдельно прописывать в компилятор.

Я ничего специально не прописывал, этот код пришёл из библиотеки. Вот такой у меня Makefile: https://github.com/jcmvbkbc/stove/blob/master/sw/s...

avr-gcc -g -mmcu=avr4

avr4 слегка смущает тут. От этого же зависит скрипт линковщика и всё такое.

[Serpens412]

Я ничего специально не прописывал, этот код пришёл из библиотеки.

Возможно, gcc так компилирует код на Си.

avr4 слегка смущает тут.

С этим все впорядке - это архитектура процессора. Я заменил на atmega8, и добавил -c при создании файла .o - результат не изменился. В map файле это хорошо видно - все библиотеки подгружаются из /lib/gcc/avr/5.4.0/../../../../avr/lib/avr4/. В том числе и библиотека libgcc.a, которая, если верить документации, и должна в секции .init4 подгружать данные в SRAM.

Спасибо за Ваши ответы, благодаря им смог докопаться до истины. Для того, чтобы компилятор добавил процедуру __do_copy_data, ее надо явно объявить:
.global __do_copy_data

Тогда компилятор добавит код заполнения данных в SRAM из Flash, о котором Вы писали ранее.

[jcmvbkbc]

Для того, чтобы компилятор добавил процедуру __do_copy_data, ее надо явно объявить:
.global __do_copy_data
Тогда компилятор добавит код заполнения данных в SRAM из Flash, о котором Вы писали ранее.

Serpens412, да, .global __do_copy_data создаёт ссылку на символ и линковщик его прилинковывает к программе.

Возможно, gcc так компилирует код на Си

Да, действительно. Занятный метод оптимизации.