[juvf 10]

Во-первых, зачем на ЯВУ знать адреса переменных? Мне вот обычно фиолетово как они расположены.

В еепром кофигурацию прибора (адрес свой, адрес сервера, всякие периоды, коефициенты и т.п.). Я вычитываю в ПК дамп памяти и в пк разбераю - что есть что, также дамп из пк записываю в мк. Нужно знать, где и что.

 

Во-вторых, есть директивы, привязывающие переменные к фиксированным адресам

#pragma location = 0x100C

не сработала эта деректива с __еепром

 

Сделайте одну структуру для всех переменных в eeprom, в структуре компилятор переставлять поля не станет.

Да, так и придется делать. Спасибо

[scifi 1]

но как ему это подсказать, я не знаю.

Вернее, возможно ли это в принципе. Скорее всего нет, конечно. Я бы не стал тратить на это время. Если реально поджимает, программирование на ассмблере куда реалистичнее. Всё-таки основное свойство компилятора - выдавать корректный код, и яр для стм8 с этим справляется. Выдавать более оптимальный код - это следующая задача, и руки у них до этого не дошли, очевидно. Кстати, яр для Coldfire может отлично оптимизировать, но при этом иногда выдаёт нерабочикй код (md5, к примеру) :laughing:

[pittyalex 0]

В еепром кофигурацию прибора (адрес свой, адрес сервера, всякие периоды, коефициенты и т.п.). Я вычитываю в ПК дамп памяти и в пк разбераю - что есть что, также дамп из пк записываю в мк. Нужно знать, где и что.

 

 

#pragma location = 0x100C

не сработала эта деректива с __еепром

 

Да, так и придется делать. Спасибо

 

Попробовал сделать по стандартной схеме:

 

__eeprom __no_init uint16_t countStarts @0x4030; //0,1

__eeprom __no_init uint16_t period@ 0x4040; //2,3

 

 

И всё заработало.

А у вас что за камень, где еепром с адреса 0х1000??? Может поэтму у вас компилятор отказался выполнять такую директиву? Стандартно у СТМ8 адрес 0х1000 попадает в RAM, а еепром начинается с 0х4000, флеш с 0х8000, так что я так и не понял, куда это вы хотели писать... на всех стм8 вроде как область памяти 0х1000 не задействована (ну нет у них 4кБ ОЗУ, или я не помню, может в самых старших моделях).

[razrab83 17]

У меня @0x4030 - такой "стандартный" способ не работает, не знаю почему

 

__eeprom __no_init uint16_t countStarts @0x1004;

ошибка компилятора

Error[Li005]: no definition for "countStarts" [referenced from C:\Users\stm8\stm8L_sh\Debug\Obj\main.o]

 

Камень stm8l051. см рис. Без явного указания адреса компилятор сам делает мэп в область 0х1000

"P6-P8":                                   0x19
.eeprom.noinit      uninit   0x001000    0x10  varInEeprom.o [1]
  .eeprom.noinit      uninit   0x001010     0x2  varInEeprom.o [1]

Изменено 20 ноября, 2017 пользователем razrab83

[scifi 1]

Попробовал сделать по стандартной схеме:

 

__eeprom __no_init uint16_t countStarts @0x4030; //0,1

__eeprom __no_init uint16_t period@ 0x4040; //2,3

 

И всё заработало.

Не понимаю я, зачем нужны все эти выкрутасы.

struct eeprom_layout
{
   int i;
   float f;
   char str[16];
};

struct eeprom_layout volatile* const eeprom = (void volatile*)0x4000;

void f(void)
{
   int j = eeprom->i;

[jcxz 184]

Я понимаю, что компилятор не может догадаться, что размер массива меньше байта, поэтому индекс не может (не должен) быть больше размера массива, т.е. байта и нет необходимости выполнять 16 битное умножение, но как ему это подсказать, я не знаю.

А какой версией IAR это скомпилено?

Предполагаю что старой (v2.xx) и без оптимизации.

У меня подобный код (с кучей 16-битных операций) генерит старый v2.20 и с выключенной оптимизацией.

Со включенной оптимизацией уже гораздо лучше. А новый IAR (3.с чем-то) генерит гораздо лучше.

[juvf 10]

struct eeprom_layout volatile* const eeprom = (void volatile*)0x4000;

-это даже не компиляется. ))

 

Не понимаю я, зачем нужны все эти выкрутасы.

за тем, что еппром != озу. ваш код будет работать с переменной в ОЗУ. А 0х4000 (или 0х1000) - это епром.

 

 

[scifi 1]

-это даже не компиляется. ))

Сочувствую. У меня компиляется.

 

за тем, что еппром != озу. ваш код будет работать с переменной в ОЗУ. А 0х4000 (или 0х1000) - это епром.

Снова сочувствую, у меня работает. Прежде чем будет новая порция негатива, уточню, что для записи в EEPROM использую специально для этого сделанные функции. Зачем их прятать за оператором присваивания, снова не пойму.

[VladislavS 29]

Зачем их прятать за оператором присваивания, снова не пойму.

Затем же за чем придумали языки высокого уровня.

[juvf 10]

Прежде чем будет новая порция негатива

где вы видите негатив?

 

, уточню, что для записи в EEPROM использую специально для этого сделанные функции. Зачем их прятать за оператором присваивания, снова не пойму.

ах да, сорри, проглядел ваш const.

 

Речь идет о том, как разместить переменные по заданному адресу в флеше с модификатором __eeprom, вы взамен переменных предлагаете константные переменные . Что к чему?

[scifi 1]

ах да, сорри, проглядел ваш const.

 

Речь идет о том, как разместить переменные по заданному адресу в флеше с модификатором __eeprom, вы взамен переменных предлагаете константные переменные . Что к чему?

Вы много чего ещё проглядели.

[juvf 10]

Вы много чего ещё проглядели.

Это вы проглядели о чем речь и не в тему постите

[pittyalex 0]

А какой версией IAR это скомпилено?

Предполагаю что старой (v2.xx) и без оптимизации.

У меня подобный код (с кучей 16-битных операций) генерит старый v2.20 и с выключенной оптимизацией.

Со включенной оптимизацией уже гораздо лучше. А новый IAR (3.с чем-то) генерит гораздо лучше.

С выключенной оптимизацией и самая последняя версия.

[jcxz 184]

С выключенной оптимизацией и самая последняя версия.

Хм... Включать не пробовали? :laughing:

[pittyalex 0]

Хм... Включать не пробовали? :laughing:

Нет, после включения оптимизации иногда код понять совершенно не возможно, да и не всегда потом, говорят, работает. Пока места хватает и производительности, не вижу смысла включать. В) ХОтя если будет время, надо будет на том же самом месте эксперимент поставить. Спасибо за "наводку".