pgm_read_xxxx и PROGMEM в winavr20071221, В листинге нет инструкций LPM Опции

[Steel_monkey]

Пишу простейшую програмку. Хочу запихать небольшой массив во флэш, и читать оттуда данные без записи всего массива в ОЗУ.

Мои действия?
1. Присоединяю библиотеку avr/pgmspace.h
2. Обьявляю массив:
uint16_t left[] PROGMEM = {60,0x93,45,70};
3. В программе читаю из массива:
REQUIRED_LEFT=pgm_read_word(&left[1]);
Переменная, куда читаю, точно такого же типа, что и в массиве.
Смотрю в файл main.lst

254:main.c **** REQUIRED_LEFT=pgm_read_word(&left[1]);
905 .LM96:
906 03b0 80E0 /* #NOAPP */
907 03b2 90E0 mov r18,r26
908 03b4 FC01 subi r18,lo8(-(1))
909 sts point.1941,r18
911 03b8 5491 .LM97:
912 cpi r18,lo8(4)
913 brlo .L50
915 03ba 5093 0000 .LM98:
916 03be 4093 0000 sts point.1941,__zero_reg__

В файле нет инструкции LPM.

4. Убираем закорючку:
REQUIRED_LEFT=pgm_read_word(left[1]);

Тогда это превращается в

254:main.c **** REQUIRED_LEFT=pgm_read_word(left[1]);
905 .LM96:
906 03b0 E3E9 /* #NOAPP */
907 03b2 F0E0 mov r18,r26
908 subi r18,lo8(-(1))
909 03b4 8591 sts point.1941,r18
911 .LM97:
912 cpi r18,lo8(4)
913 brlo .L50
915 03bc 8093 0000 .LM98:

Инструкция LPM в коде так и не появилась.

[_Pasha]

Я думаю, в обоих случаях j будет выкинуто, а цикл заменен на бесконечный.

Если бы было написано j < 255, то бесконечный цикл получился бы только если в опциях компилятора задано "char по умолчанию знаковый". В противном случае оба цикла вроде как должны бы получиться одинаковыми. Или я что-то упустил?

1. Ошибся я, j<254
2. uint8_t обрабатывается как 16-битовое, отсюда увеличение кода.

3. По поводу Lpm/Elpm, данный факт может сослужить плохую службу только в граничных ситациях, когда надо оценивать объем кода, а тут вдруг массив то есть / то нету. Это плохо. Имхо, единственный выход - избежать константных выражений.

[aesok]

1. Ошибся я, j<254
2. uint8_t обрабатывается как 16-битовое, отсюда увеличение кода.

Не верю. AVR-GCC 4.3

main.c

Код

void do_something(void)  __attribute__((noinline));
void do_something(void)
{
  asm("");
}

int
main (void)
{
  unsigned char j;
  for(j=0;j<100;j++){do_something();}


  signed char jj;
  for(jj=0;jj<100;jj++){do_something();}

  return 0;
}

main.lst

Код

...
  d2:    10 e0           ldi    r17, 0x00; 0
  unsigned char j;
  for(j=0;j<100;j++){do_something();}
  d4:    0e 94 67 00     call    0xce; 0xce <do_something>
  d8:    1f 5f           subi    r17, 0xFF; 255
  da:    14 36           cpi    r17, 0x64; 100
  dc:    d9 f7           brne    .-10     ; 0xd4 <main+0x4>
  de:    10 e0           ldi    r17, 0x00; 0


  signed char jj;
  for(jj=0;jj<100;jj++){do_something();}
  e0:    0e 94 67 00     call    0xce; 0xce <do_something>
  e4:    1f 5f           subi    r17, 0xFF; 255
  e6:    14 36           cpi    r17, 0x64; 100
  e8:    d9 f7           brne    .-10     ; 0xe0 <main+0x10>
...

Анатолий.

Сообщение отредактировал aesok - Mar 4 2008, 15:31

[_Pasha]

Не верю. AVR-GCC 4.3

И правильно делаете
Пытался смоделировать ту ситуацию повторно - не получилось. Теперь совсем ничего не понимаю

Попытка не защитана signed char всегда меньше 254 (за исключением платформ, где char имеет размер более 8 битов).

В командной строке задавал чтобы unsigned chars было

[ReAl]

В командной строке задавал чтобы unsigned chars было

А вот к этому привыкать не рекомендую.
Я расматриваю такой ключ как "аварийный", когда надо скомпилировать чей-то чужой код, в котором был написан просто char, подразумевая, что он unsigned.

Свой код лучше сразу писать с явным указанием. Чем потом глюки ловить, лучше сразу явно указать знаковость. Просто char я использую нечасто и только тогда (но не всегда "тогда"), когда в нём должны храниться именно символы.
Когда-то давно я использовал и uchar/schar, и u08/i08, теперь окончательно устаканился на stdint.h, введённом в С99 - uint8_t и компания. Настолько окончательно, что когда недавно поднимал небольшой старый проект для мелких изменений и перевода под avr-gcc - просто взял и прошёся по всему тексту заменой на новые типы , иначе глаза постоянно спотыкались.

Рано или поздно захочется перейти на другйо кристалл/компилятор и можно просто забыть, что давно отлаженные куски писались с рассчётом на беззнаковый char, а у новой платформы он знаковый.
Хорошо ещё если компилятор сможет предупреждения выдать (condition always true для j < 255), но есть места, где для него неочевидно, что имел ввиду автор кода (например, p[j]).

[_Pasha]

Когда-то давно я использовал и uchar/schar, и u08/i08, теперь окончательно устаканился на stdint.h, введённом в С99 - uint8_t и компания.

Спасибо за совет.
Вот что интересно. Я постоянно с пиками пересекаюсь. И ихний "С18" использую. Дык там в аппликухах "uint8_t и компания" никто не пользует. Бардак, однако...

[mdmitry]

Дык там в аппликухах "uint8_t и компания" никто не пользует.

Так уши от gcc растут.
поддерживаю стиль, пропагандируемый ReAl. Переносимость улучшается, со временем очень привыкаешь к этим int_t