CodeVision AVR в вопросах и ответах

[Z_h_e]

Наверное у Вас это условие в цикле. Попробуйте вот так.

Код: Выделить всё

 if (PINB.3==0){
      delay_ms(10);
      while (PINB.3==0);
      if (OCR0A<0xff)
      OCR0A=OCR0A+0x01;
      }

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

[a.garkin]

Наверное у Вас это условие в цикле. Попробуйте вот так.

Код: Выделить всё

 if (PINB.3==0){
      delay_ms(10);
      while (PINB.3==0);
      if (OCR0A<0xff)
      OCR0A=OCR0A+0x01;
      }

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

Не вот так работает как надо:

Код: Выделить всё

if (PINB.3==1)
     {
     OCR0A=0x7f;
     } 
     else
     {
     delay_ms(5);
     if (OCR0A<0xff)
     OCR0A=OCR0A+0x01;
     }  

[Z_h_e]

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

[WiseLord]

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

Попробую пояснить, что я имею в виду.

Скажем, банальнейший проект - электронные часы, которые делает почти каждый, кто начинает работать с МК. Между включениями нужно сохранять яркость, режим 12/24, параметры будильника и т.п. Для всего этого надо несколько байтов в EEPROM.

Да, вполне можно использовать автоматическое размещение их в EEPROM. И, по идее, можно даже быть уверенным, что каждый раз при включении эти параметры будут инициализироваться всегда из одних и тех же ячеек, то есть, "своими" данными, а не перепутаются с чем-то ещё.

Но такой вариант подразумевает, что в случае обновления прошивки (FLASH) станет обязательна и перепрошивка EEPROM, т.к. в новой версии могут появиться и другие переменные, причём не просто "далее по EEPROM", а вклинившись между предыдущими. Старый EEPROM будет несовместим с предыдущим. И старые настройки вводить придётся заново.

Поэтому ручной контроль адресов в EEPROM вполне имеет право на жизнь. Как с точки зрения большей совместимости между версиями прошивки, так и с точки зрения возможности редактирования бинарника eeprom сторонним приложением.

Скажем в своих нескольких проектах я всю подобную конфигурацию описываю в одном файле eeprom.h наподобие

Код: Выделить всё

#define EEPROM_BR_STBY				0x32
#define EEPROM_BR_WORK				0x33

В программе переменные привязываются к этим адресам, и этот же хидер является "якорем" для десктопного приложения для редактирования этого же бинарника.

[realm]

По своей теме: еще раз огромное спасибо *Trigger*. Все остальное - дупль пусто.

И еще, может кому-то пригодится.
Обнаружился дополнительный шедевр в CV - он оказывается 0-вую ячейку EEPROM сам блокирует без спроса. И все распологает с адреса 0x01.
НО! самое интересное, что он это делает и с ATXmega, где слет нулевой ячейки профиксен.
Результат - переменные находятся совсем не там, где может показаться на первый взгляд.

[ARV]

Результат - переменные находятся совсем не там, где может показаться на первый взгляд

именно о том и шла речь - оставьте компилятору компиляторово, не майтесь ерундой

Да, вполне можно использовать автоматическое размещение их в EEPROM

мое мнение - можно и нужно

Старый EEPROM будет несовместим с предыдущим. И старые настройки вводить придётся заново.

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

Поэтому ручной контроль адресов в EEPROM вполне имеет право на жизнь

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

и этот же хидер является "якорем" для десктопного приложения для редактирования этого же бинарника

map-файл для этого не годится?

[WiseLord]

когда при обновлении прошивки роутера вы потом заново вводите всякие маски подсети и названия точки доступа - это вас не пугает, а для часов ввести 2 числа будильника - это катастрофа?

Вообще-то, пугает. Да, для часов - это ерунда, но, например, заново настраивать три десятка радиостанций в радиоприёмнике - вот это может раздражать.

map-файл для этого не годится?

А вот это действительно решение. Как-то даже не подумал. По сути, мой вариант с отдельным хидером для адресов - некий суррогат map файла.

В общем, нужно будет попробовать вариани с отдачей всего этого на откуп компилятору. Только вот разобраться с последней проблемой для начала.

Суть в чём. Есть некий проект с парой десятков текстовых переменных, хранящихся в EEPROM. Лежат они там, начиная с определённого адреса, разделённые минимум одним нулевым байтом. Таких файлов EEPROM несколько, каждый представляет собой вариант для какого-то языка - русского, английского, и т.д.

В разных языках строки разной длины. Программа при инициализации проходит по EEPROM, начиная с упомянутого адреса, определяет адреса каждой текстовой метки и заносит их в массив, вроде char **labels. Ну а дальше, в программе всё просто - когда надо вывести пятую метку, вызываем что-то вроде ee_print(labels[5]).

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

[Аlex]

Может, выделить под каждую метку, фиксированную длину ? Да, лишний перерасход памяти, но зато нет нужды переписывать всю область, при изменении одной метки.

Или я что-то недопонимаю

[ARV]

а меня смутило вот это:

А текстам отдать верхнюю половину с фиксированным стартовым адресом

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

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

в своих проектах я решаю подобную проблему путем двух разных сборок - на русском и английском языках. т.е. исходники одинаковые, а строковые константы - разные. переключения языков на лету не предусматриваю...

[Аlex]

А я языковые строки храню во флеши, в виде двумерного массива указателей. И менять язык можно на лету.
Зачем их в EEPROM пихать ?
Даже если очень захочется разрешить их менять пользователям - нет проблем, в современных МК, перезапись флешь - не проблема.

[ARV]

А я языковые строки храню во флеши, в виде двумерного массива указателей.

когда памяти с избытком - почему нет? но EEPROM - самая бестолково используемая память в AVR... и в случае нехватки flash всяким строковым константам там самое место.

И менять язык можно на лету

вот у вас наверняка есть смартфон. да что там смартфон - любой мобильник не 15-летней давности имеет возможность смены языка интерфейса. вот ответьте мне честно: сколько раз за время эксплуатации вы меняли язык интерфейса? а память-то под эти строки по сути попросту пропадает...

реально разве есть такая необходимость?

[Аlex]

Для девайсов, сделанных для себя, я не делаю языки, ибо, кроме Русского, никакого не знаю
Делаю я их часто для пром. устрйоств. А сколько там раз в день/год юзеры меняют язык - честно, я не в курсе. Сказали - "Нужно сделать", я делаю...

Добавлено after 2 minutes 7 seconds:

когда памяти с избытком - почему нет?

Если честно, я никогда не занимался впихиванием невпихуемого. Не хватает - берём жирнее...

[COKPOWEHEU]

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

Если этого можно избежать с минимумом затрат - почему бы и нет?

если взять за основу логику ваших предыдущих рассуждений: потребовалось убрать из ранее существовавших адресов сохранения 1 байт и добавить 3 области для хранения int...

Не могли бы вы пояснить свою мысль, зачем добавились 3 области int?

вы считаете, геморрой с пересчетом адресов в ваших константах будет простым?

В зависимости от реализации. Для #define добавляете sizeof(), для структуры ничего добавлять не надо, разве что для полностью ручного отслеживания будет не так просто.

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

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

[ARV]

Если этого можно избежать с минимумом затрат - почему бы и нет?

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

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

[Z_h_e]

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

Возможно дополнительные затраты такие же, как затраты на то, чтобы сделать ход часов на микроволновке без сетевого питания, хотя бы на пол часа.

[WiseLord]

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

Например, живой пример - мой проект часов на светодиодных матрицах. В виде бегущей строки выводится температура с четырёх разных датчиков. У кого-то это могут быть 3 датчика "дома", "на улице", "на балконе", а у кого-то - 2 датчика "в бане", "в комнате" и т.д. Тут-то и возникает необходимость дать пользователю возможность настроить всё это, и EEPROM для этого идеально подходит. Прошивка FLASH одна для всех, а EEPROM у каждого свой - как в плане и языка вообще, так и тонкой настройки под себя.

Да, пример достаточно специфичен, и не всем такое может понадобиться такое. Но мне, например, идея мультиязычных проектов нравится, и вариант с выносом всех текстов в EEPROM кажется наиболее подходящим.

[ARV]

пример достаточно специфичен, и не всем такое может понадобиться такое

ну так вроде вы и нашли разумное решение проблемы... не зная точно, как сделали вы, но по предыдущему вашему сообщению я для себя нарисовал такой алгоритм:
- всего есть, предположим, N слов для перевода
- всего должно быть, допустим, D языков
- в EEPROM вы просто описываете массив str из char-ов, который инициализируете как-тот так EEPROM char str[] = "слово1\0" "слово2\0" ... "словоN\0" и далее D раз так же
- начало массива компилятор выбирает сам, вы работаете с ним по значению str
- теперь, чтобы выбрать слово 2 на языке 3 вы ищете начало этого слова:

Код: Выделить всё

char *wrd = str;
int idx = N*3 + 2; // это порядковый номер слова в массиве
while(idx){
   while(eeprom_read_byte((void*)wrd)) wrd++;
   idx--; wrd++;
}
// здесь wrd у вас содержит начало нужного слова

я привел код для более привычного мне AVR-GCC, для CodeVision будет проще - не надо использовать функцию eeprom_read_byte, но надо правильно определить указатель wrd

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

но при этом я так и не понимаю, откуда может взяться необходимость размещать массив со словами в определенной области EEPROM...

[WiseLord]

Скажем так, скорее, нужна не столько фиксация адреса, сколько требование к отсутствию после строк других eeprom-переменных. Потому что такая ситуация в EEPROM, как "слово1\0" "слово2\0" ... "словоN\0" var1 var2 var3 в случае увеличения пользователем длины текстовых строк приведёт к "наезжанию" массива строк на другие переменные.

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

Код: Выделить всё

EEPROM char str[] = "слово1\0" "слово2\0" ... "словоN\0"

,а, например

Код: Выделить всё

EEPROM char str[400] = "слово1\0" "слово2\0" ... "словоN\0"

Пожалуй, это будет наиболее оптимально.

[ARV]

если вы хотите гарантий, то есть 2 пути: попроще и покорявее:)
попроще: заведите структуру типа

Код: Выделить всё

EEPROM struct{
   int var; // какие-то настроечные параметры
   ...
   char str[]; // а это тот самый массив строк
} my_config;

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

покорявее: AVR-GCC позволяет напрямую задавать адрес секций памяти, в том числе и для EEPROM. воспользовавшись принудительным назначением вашим "первым" переменным и "последним" строкам отдельных секций памяти, вы сможете задать нужные вам адреса, и линкер все так и построит.

мне больше нравится первый способ

[COKPOWEHEU]

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

Вы определитесь где собираетесь хранить настройки - в flash (как в роутерах) или eeprom (как предлагается тут). Когда осознаете разницу, поймете, почему пример с роутером неудачен. Тем более что там адрес каждой настройки как раз может изменяться хоть в процессе работы, и ничего при этом не теряется.