Присваивание это просто запись, а то, что Вы описали, называется чтение-модификация-запись. Т. е. надо так, как Вам советовали:

Ну вот... О1 и уже не работает. прикладываю проект для студии целиком. На самом деле действительно интересно что происходит. С кейлом таких чудес небыло ни разу. Не суть, просто хочу понять что происходит...
 tr.rar ( 21.31 килобайт ) Кол-во скачиваний: 49



Ну пусть так. Однако серийное изделие (лет более 5-ти) на Тини24 работает и повторяется .... правда перепер на STM8S0003F, но это детали... и на тини отлично все работает. Версия компилятора не изменилась. В чем смысл тогда?

оптимизация Os сильно убыстряет циклы мигания


Это почему?

Да, нужен. смотрите еще раз:

А теперь смотрите на свой код:
Видите разницу около 0x0A?

Естественно. Ваша функция delay не делает с точки зрения компилятора ничего полезного. Наоборот, она делает маленькую быструю программу большой и медленной. Оптимизатор выкинул ее нафиг.

Изучайте <util/delay.h>

Там настолько плохой компилятор, что не умеет выкидывать пустые циклы?

Откройте листинги, сравните, найдите разницу.

так предлагаете unsigned char *0x0A или как? Читает и пишет правильно.



а на мой взгляд делей делает очень полезную штуку. как компилятору сказать?

в смысле цикл тот


и еще, delay_ms... сразу дало большой довесок коду. включил оптимизацию, но это привело программу в нерабочий вид. хотя код ужало. в чем смысл?

В чтении документации. В ней все написано. И про большой код и про оптимизацию. И смею вас заверить - delay_ms работает именно так, как описано в документации. Что вы понимаете под нерабочим видом программы телепатировать не получается.

Переносимость меня абсолютно не волнует. А вот "зависеть от трюков" это видимо действительно было, примеры в ДШ даны для IAR и поэтому в IAR работают без нареканий.

Ну а по поводу того, что программа перестает работать при включении оптимизации - это нормально. Проблему можно легко вычислить воспользовавшись средствами отладки. Есть подозрение что виновата переменная consol, попробуйте в ее объявление добавить квалификатор volatile.

Сообщение отредактировал Bear_ku - Dec 17 2014, 03:55

Я делал один проект. Сначала взял ATMEGA8535. Проект писал в IAR. Когда прошил программу, все работало, кроме записи в EEPROM. Стал разбираться. Залил давний проект, написанный на асме. Запись в EEPROM работает. Стал сверять в дизасме. Вроде все нормально, а запись EEPROM не работает. Решил проверить эту же программу, но скомпилированную под ATMEGA32. Запись в EEPROM нормально работает. Выходит, что библиотеку записи в EEPROM нужно написать на асме. Но я в IAR так и не смог пока разобраться, как правильно писать и использовать функции на асме. Да и в тот раз обошелся ATMEGA32A. И некогда мне было с асмом в IAR разбираться.
Еще один случай. Умер один человек, мне достались его проекты. Написаны в IAR. Его девайсы сделаны на ATMEGA1280. Для сохранения данных использовались внешние EEPROM. То есть, когда-то этот человек тоже испытывал трудности с записью в EEPROM в проектах, созданных в IAR, на некоторых МК AVR.

Я порой вам удивляюсь. ИАР еще пятнадцать лет назад имел квалификатор __eeprom. Достаточно было прочитать документацию, объявить переменную с таким квалификатором и просто читать-писать ее как обычную переменную. Компилятор подставлял доступ к eeprom куда нужно сам и этот доступ всегда 100% работал. Вот какой смысл было изобретать велосипед и реализовывать свои процедуры чтения/записи? Причем судя по вашему описанию велосипед-то получился с квадратными колесами.

Хочу напомнить, что у IAR EWAVR в хидере intrinsics.h (он ко всем типам МК относится) определены следующие макросы:

С одной стороны полезно на это посмотреть, а то и позаимствовать.
С другой стороны, когда используется именно этот компилятор, можно этими макросами пользоваться.

Сергей, вы заранее не исходите из ваших предположений, ладно?
Все на месте, один и тот же проект, на ATMEGA8535 запись в EEPROM не работает, на ATMEGA32\A работает.

Этот случай давно был. На сахаре мне тогда ответили, что, возможно, придется писать свою библиотеку для работы с EEPROM на асме.

Проблема именно в том, что у топикстартера компилятор не IAR, а GCC:

Однако те макросы, которые я привела из IAR, легко вживляемы в GCC.
А вот __eeprom приживить едва ли будет возможно, т.к. это не просто определение типа, а в придачу встроенные возможности.

Видимо недопонял. Получается, была ошибка в компиляторе?

Ксения, с топикстартером уже давно разобрались и перешли к стадии "бойцы вспоминают минувшие дни". Практически дословно содержимое вашего макроса уже было в этой теме на прошлой странице. И там же было обсосано, почему так лучше не делать.

Получается, что так. Досконально я не разбирался. Включал разные степени оптимизации кода. Смотрел в дизасме. А так как проект тогда оброс некоторыми дополнительными функциями, и размер кода увеличился, и запись в EEPROM заработала на другом МК, мне тем более пришлось взять вместо ATMEGA8535, ATMEGA32A. Кстати, прикол в том, что запись в EEPROM работает на МК, выпущенных позднее ATMEGA8535.
Нужно уделить время, сесть и понять разницу между моим рабочим проектом на асме и дизасмом в IAR. Тогда не до этого было. Сейчас тоже со свободным временем не очень...

Сообщение отредактировал demiurg1978 - Dec 17 2014, 09:37