IAR и запись в EEPROM, Вопрос по реализации записи в eeprom в IAR Опции

[arttab]

В моей проге есть запись по команде в еепром:
1. посылаю команду
2. Байтики принемает уарт и они вне прерывания обрабатываются функцией приемника
3. При получении нужной команды в еепром пишется байт (пишется средствами IAR) и отсылаеются байтики о выполнении. Отсылается не дожидаясь окончания записи (флаг не проверяю).

Задержка между окончанием приема команды на запись до отправки ответа около 7.5 мсек. если не пишу, а отвечаю сразу, то 0,3мсек.
Вопрос: чем вызвана такая большая задержка? Кварц 8 МГц. Время записи одного байта должно быть 1 мсек. МЕГА8

Это не просто любопытство - есть проблемы при записи в еепром в других частях проги. Пытаюсь разобраться.

[KRS]

А почему вы думаете что время записи 1 ms?
уже давно у всех новых атмелов еепром тактируется от внутреннего генератора и время записи
примерно 8.5 ms

[arttab]

Кое что дошло. для МЕГИ8 время записи байта в еепром до 9 мсек. и оно определяется внутреним генератором и свойствами самой еепром.

Вопрос: надо ли запрещать прерывания при записи в еепром или все проходит нормально?

[BVU]

Кое что дошло. для МЕГИ8 время записи байта в еепром до 9 мсек. и оно определяется внутреним генератором и свойствами самой еепром.

Вопрос: надо ли запрещать прерывания при записи в еепром или все проходит нормально?

Для начала посмотрите ассемблерный код Вашей программы на запись в eprom, если там нет команды запрещения прерывания, сделайте самостоятельно запрещение прерывания при записи в eprom в своем коде. Это обязательно!

[arttab]

Спасибо всем!
IAR сам не запрещает прорывания ни дожидается окончания записи

сделал так:
__disable_interrupt(); //CLI

здесь пишу

while(EECR&(1<<EEWE));
__enable_interrupt();

[KRS]

Запрещать прерывания нужно только
что бы биты EEMWE и EEWE установились подряд!

Код

__disable_interrupt();

/* Write logical one to EEMWE */
EECR |= (1<<EEMWE);
/* Start eeprom write by setting EEWE */
EECR |= (1<<EEWE);

__enable_interrupt();

а вот пока ждется окончание записи наоборот имеет смысл прервания разрешать! а то все уснет на 9 ms
(если только конечно в перываниях еепром не пишется)

[arttab]

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

[IgorKossak]

Посмотрите также здесь.
Это я когда-то выкладывал исправленный файл иаровского исходника для работы с ЕЕПРОМ.

[arttab]

Посмотрите также здесь.
Это я когда-то выкладывал исправленный файл иаровского исходника для работы с ЕЕПРОМ.

Этим файлом надо заменить старый в ИАРЕ? как он работает (что исправлено от родного)? Бегло глянул - прерывания не запрещает.

[IgorKossak]

Этим файлом надо заменить старый в ИАРЕ? как он работает (что исправлено от родного)? Бегло глянул - прерывания не запрещает.

Исправлений как раз много и прерывания запрещает как положено.
А смотреть намного удобнее не бегло, а какой-нибудь утилитой сравнения\слияния (WinMerge, KDiff3, CS Visual Diff, ...).

[arttab]

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

[IgorKossak]

Копаться в чужом тексте дело не благодарное.

Ну я же дал себе труд покопаться в иаровском тексте. И нисколько не жалею. Надо же как-то квалификацию поднимать.

Жаль что нет описания изменений, но все равно спасибо.

А описание можно свести к двум пунктам:
1) любая критическая работа с ЕЕПРОМ (за исключением кристаллов AT86RF401), требующая непрерываемости, обрамлена в обёртку типа:
сохранить SREG
CLI
критическая работа с ЕЕПРОМ
восстановить SREG
2) исправлена ошибка в подпрограмме записи в ЕЕПРОМ 64-битных чисел.

[arttab]

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

[_Bill]

Спасибо всем!
IAR сам не запрещает прорывания ни дожидается окончания записи

сделал так:
__disable_interrupt(); //CLI

здесь пишу

while(EECR&(1<<EEWE));
__enable_interrupt();

А зачем так сложно? Гораздо проще объявить переменную в EEPROM. Тогда обращения к ней IAR делает автоматически все сам, со всеми прибамбасами.

[arttab]

А зачем так сложно? Гораздо проще объявить переменную в EEPROM. Тогда обращения к ней IAR делает автоматически все сам, со всеми прибамбасами.

Я так тоже думал...
Я обявил масив в еепром и пишу в него так:
void Conf_B_B(unsigned char z, unsigned char y)
{
unsigned char __eeprom* ub;
unsigned char* uc;
unsigned char i=6;

ub = Conf_BR + z;
uc = str + y;
*(ub) = *(uc);

__disable_interrupt(); //CLI
while (i)
{*(ub) = *(uc);
uc++;
ub++;
i--;}

while(EECR&(1<<EEWE));
__enable_interrupt();
}
Пришлось самому прерывания запрещать

[aleksey_g]

Я так тоже думал...
Пришлось самому прерывания запрещать

Уважаемый arttab, похоже неправда Ваша!
Вот что мне нагенерил ИАР4.12А:

0000B8 99F9 SBIC 0x1F,1
0000BA CFFE RJMP 0x0B8
0000BC 9508 RET
0000BE 9543 INC R20
0000C0 BD41 OUT EEAR,R20
0000C2 94F8 CLI
0000C4 9AFA SBI 0x1F,2
0000C6 9AF9 SBI 0x1F,1
0000C8 BE0F OUT SREG,R0
0000CA 9508 RET
__eeput16_8:
0000CC B60F IN R0,SREG
0000CE DFF4 RCALL 0x0B8
0000D0 BD00 OUT EEDR,R16
0000D2 DFF6 RCALL 0x0C0
0000D4 DFF1 RCALL 0x0B8
0000D6 BD10 OUT EEDR,R17
0000D8 CFF2 RJMP 0x0BE

[arttab]

у меня IAR 3.10C

[_Bill]

у меня IAR 3.10C

Обращение к EEPROM делается при помощи библиотечных служебных функций. А они слабо зависят (практически не зависят) от версии компилятора.

[arttab]

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

[CSB]

Посмотрите также здесь.
Это я когда-то выкладывал исправленный файл иаровского исходника для работы с ЕЕПРОМ.

Как подключить к проекту на С файл eeprom.s90?

[arttab]

пока не подключал. переносимось проекта теряется. Так можно "свинью" подложить нечаяно - исходники на др. комп и привет.

[IgorKossak]

Посмотрите также здесь.
Это я когда-то выкладывал исправленный файл иаровского исходника для работы с ЕЕПРОМ.

Как подключить к проекту на С файл eeprom.s90?

Точно так же, как Вы подключаете к проекту любой *.C файл.
После включения файла в проект и сборки всего проекта линкер проигнорирует все функции работы с eeprom из библиотеки и включит исправленные.
При этом желательно не заменять стандартный файл eeprom.s90 в папке avr\src\lib, а записать его в рабочую папку проекта.

пока не подключал. переносимось проекта теряется. Так можно "свинью" подложить нечаяно - исходники на др. комп и привет.

Чего это вдруг теряется? Переносите eeprom.s90 (если о нём речь) вместе с другими файлами.
Или Вы имели в виду переносимость на другую платформу?

[arttab]

Если кто дернет файл с из проекта или не подключит в проект будеут глюки.

[arttab]

Подключил. вылетает ошибка:
Error[2]: Failed to open #include file 'macros.m90'
на
#include "macros.m90"
это он ищит локально библиотеку и не может найти?

[IgorKossak]

Если кто дернет файл с из проекта или не подключит в проект будеут глюки.

Странные у Вас отношения
Кто-то приходит, что-то дёргает.

Подключил. вылетает ошибка:
Error[2]: Failed to open #include file 'macros.m90'
на
#include "macros.m90"
это он ищит локально библиотеку и не может найти?

Это файл макросов, лежит в папке avr\src\lib.
Его можно в рабочую папку не переписывать, достаточно указать к нему путь (Project\Options\Assembler\Preprocessor)

[arttab]

спасиба. разобрался. код на 2 байта вырос

[Rash]

Как подключить к проекту на С файл eeprom.s90?

Ни как не могу подключить этот файл к проекту (eeprom.s90) без ошибок, если он лежит в папке проекта, а не заменён в avr\src\lib. Мож выложит кто примерчик проета с этим подключённым файлом?

[IgorKossak]

Ни как не могу подключить этот файл к проекту (eeprom.s90) без ошибок, если он лежит в папке проекта, а не заменён в avr\src\lib. Мож выложит кто примерчик проета с этим подключённым файлом?

Project->Options->Assembler->Preprocessor->Include Directories...
добавить новой строкой $TOOLKIT_DIR$\src\lib
Предполагаю, что ошибка состоит в том, что не находится файл macros.m90

[Rash]

Project->Options->Assembler->Preprocessor->Include Directories...
добавить новой строкой $TOOLKIT_DIR$\src\lib
Предполагаю, что ошибка состоит в том, что не находится файл macros.m90

Это я сделал, ошибка ушла, выдаёт ошибки когда коментарии после точки запятой (;) заменил всё на (//), после этого стало выдавать ошибки на объявленные переменные в EEPROM

Код

__eeprom volatile int           ee_iDelayHS    = 200;  
__eeprom volatile long          ee_iPhoneMask1 = 0x333;
__eeprom volatile long          ee_iPhoneMask2 = 0x555;
__eeprom volatile unsigned char ee_cNumMack1   = 3;  
...

если заменить файл непосредственно в ...\src\lib, то всё нормально и на коментарии после точки запятой (;) не ругается

[IgorKossak]

Это я сделал, ошибка ушла, выдаёт ошибки когда коментарии после точки запятой (;)

Это в Сишном файле??? Так и должно ругаться. В ассемблерном всё в порядке.

заменил всё на (//), после этого стало выдавать ошибки на объявленные переменные в EEPROM

Код

__eeprom volatile int           ee_iDelayHS    = 200;  
__eeprom volatile long          ee_iPhoneMask1 = 0x333;
__eeprom volatile long          ee_iPhoneMask2 = 0x555;
__eeprom volatile unsigned char ee_cNumMack1   = 3;  
...

У меня такого не наблюдается.

[Rash]

Это в Сишном файле??? Так и должно ругаться. В ассемблерном всё в порядке.

У меня такого не наблюдается.

поэтому и прошу пример. а ошибки следующие

в файле eeprom.s90 ошибка в 1-ой же строке

Код

    MODULE  ?EEPROM_8

Error[Pe077]: this declaration has no storage class or type specifier D:\...\eeprom.s90 31
Error[Pe065]: expected a ";" D:\...\eeprom.s90 31
т.е. нехватает точки запятой , значит воспринимаеться как Си а не ассемблер

в моём файле

Код

__eeprom volatile int           ee_iDelayHS    = 200;

Warning[Pe012]: parsing restarts here after previous syntax error D:\Program AVR\IAR\Kommytator_17_04_2007\InNumber.c 62
наверное из-за ошибки в eeprom.s90

[IgorKossak]

поэтому и прошу пример.

Приаттачте лучше в архиве свой проект, если он не секретный.
Разберусь, скажу в чём дело.

[Rash]

вложил

Сообщение отредактировал Rash - Feb 13 2008, 14:04

[IgorKossak]

вложил

Первое, что бросилось в глаза.
eeprom.s90 это исходный файл на асме, который нужно добавить в проект через Project->Add Files..., а не включать в Сишный файл при помощи #include
После такой манипуляции всё собралось без ошибок

[Rash]

Первое, что бросилось в глаза.
eeprom.s90 это исходный файл на асме, который нужно добавить в проект через Project->Add Files..., а не включать в Сишный файл при помощи #include
После такой манипуляции всё собралось без ошибок

спасибо большое, теперь будем знать

[Baser]

Решил я тут разобраться с тем, как ИАР реализовал свои функции работы с EEPROM, потому что раньше применял свои функции, а теперь решил применить ИАРовские. Почитал документы, поизучал исходники, посмотрел конференцию. Нашел сообщения и файл коллеги IgorKossak который он всем рекомендует. И как-то из последних сообщений выходит, что у ИАРа библиотеки неправильные.
Решил я поэтому опубликовать свои выводы, поскольку получается, что библиотеки то правильные (здесь я не говорю об их ошибке с записью long long - ошибка она и есть ошибка), просто границы применимости у них различные.
Возмем, к примеру, чтение и запись char в eeprom, размером более 256 байт.

Оригинальная библиотека ИАР АВР 4.21А (если убрать все лишние переходы):

Код

?eewait:
        SBIC    EECR,EEWE
        RJMP    ?eewait
        RET

__eeget8_16:
        RCALL   ?eewait
        OUT     EEARL,r20
        OUT     EEARH,r21
        SBI     EECR,EERE
        IN      r16,EEDR
        RET

__eeput8_16:
        IN      r0,SREG
        RCALL   ?eewait
        OUT     EEDR,r16
        OUT     EEARL,r20
        OUT     EEARH,r21
        CLI
        SBI     EECR,EEMWE
        SBI     EECR,EEWE
        OUT     SREG,r0
        RET

Анализируя этот код можно определить область применимости этих процедур:
Эти функции можно применять (без дополнительного запрещения прерываний) только в одном потоке, т.е. или в main или в прерываниях одного уровня. Применение даже только чтения и в основном цикле и в прерывании периодически будет приводить к краху чтения. Дополнительное ограничение - функцию записи нельзя применять при наличии самопрограммирования флеша (команд SPM) в другом потоке.

Возмем теперь исправленный вариант от IgorKossak. Исправления следующие:

описание (исправлений) можно свести к двум пунктам:
1) любая критическая работа с ЕЕПРОМ (за исключением кристаллов AT86RF401), требующая непрерываемости, обрамлена в обёртку типа:
сохранить SREG
CLI
критическая работа с ЕЕПРОМ
восстановить SREG
2) исправлена ошибка в подпрограмме записи в ЕЕПРОМ 64-битных чисел.

Код

?eewait:
        CLI
        SBIS    EECR,EEWE
        RET
        OUT     SREG,r0
        RJMP    ?eewait

__eeget8_16:
        PUSH    r0
        IN      r0,SREG
        RCALL   ?eewait
        OUT     EEARL,r20
        OUT     EEARH,r21
        SBI     EECR,EERE
        IN      r16,EEDR
        OUT     SREG,r0
        POP     r0
        RET

__eeput8_16:
        IN      r0,SREG
        RCALL   ?eewait
        OUT     EEDR,r16
        OUT     EEARL,r20
        OUT     EEARH,r21
        SBI     EECR,EEMWE
        SBI     EECR,EEWE
        OUT     SREG,r0
        RET

Запрещение прерываний на все время работы функций вместе и изящным решением "прозрачного" для прерываний ожидания готовности. Расширение границ применяемости налицо. Теперь работу с EEPROM можно производить в нескольких параллельных потоках. То, что при этом может происходить "замирание" обработки прерывания на время ожидания готовности - дело программиста: применять или нет.
Теперь любой, кому придет в голову эта бредовая идея, может писать EEPROM в прерываниях без фатальных последствий для своей программы
А вот проверки готовности флеша (от SPM) тут тоже нет. И это нужно помнить.

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


з.ы. меня сначала смутил тот момент, что сохранение регистра r0, IgorKossak добавил только в __eeget8_16
Но при проверке оказалось, что компилятор не проверяет asm файл с текстом неоригинальной программы, а тупо смотрит на имя функции. Если в прерывании есть __eeput8_16, то сохраняет r0, хотя вы его в своей функции можете и не применять, а применять кучу других регистров, которые компилятор и не подумает сохранить. А если видит __eeget8_16, то r0 не сохраняет (в оригинальной функции его нет).