artemkad

Огласите хотя бы один способ. PUSH/POP-нуть глобальные временные регистры EEAR, EEDR... Он это должен сделать тогда и только тогда когда вызов идет из прерывания. Во всех остальных случаях это будут ненужные накладные расходы. Как компилятор определит, что вызов делается из прерывания? Вы сами руцями указываете ему, что процедура является обработчиком... Даже при разрешенных прерываниях? Даже если ожидаемое событие все равно глобально должно поменять весь алгоритм работы? :blink: ?? Ожидается готовность eeprom. Что значит при разрешенных прерываниях? Мы уже внутри обработчика. Именно так. Внутри обработчика (предворительно исключив собственную рекурсию если она могла быть) разрешается прерывание. Чего тут непонятного :blink: ?

Огласите хотя бы один способ. PUSH/POP-нуть глобальные временные регистры EEAR, EEDR... Ну, не знал, что чтение в прерывании флагов сохраняемых в EEPROM в каком-то другом месте это глюк :cranky: ... Теперь знаете - вы сами на него напоролись. Для обхода приходится запрещать прерывания в основном цикле, хотя без этого можно было обойтись. Обращение к eeprom требует ожидания готовности eeprom, а ожидание чего-либо находясь в прерывании - ошибка алгоритма. Даже при разрешенных прерываниях? Даже если ожидаемое событие все равно глобально должно поменять весь алгоритм работы? :blink: Исправить эти грабли не сложно - сложнее на них не наступить особенно когда о "такой малости" в доках ни слова...

Последняя не профи. Компилятор должен был запретить прерывания при всех обращениях в основном цикле... Как - это уже отдельная тема. У компилятора более чем один способ решить этот вопрос. Ну, не знал, что чтение в прерывании флагов сохраняемых в EEPROM в каком-то другом месте это глюк :cranky: ... Вы не поверите - компилятор делает так-же ... Вот только представте, что произойдет если EEPROM_write было вызвано при не запрещенных прерываниях, а в прерывании вызвано EEPROM_read. И это самое прерывание попало между EEAR=adres; и EEDR=data; Результат ясен? Тоже самое когда без запрета прерывания будет вызван EEPROM_read. Только там последствия сразу не столь разрушительные....

При чтении ЕЕPROM в прерывании нет сохранения регистров адреса/данных(EEAR EEDR). Или что то-же самое - не защищаются от прерываний участок с момента записи EEAR EEDR до собственно подачи комманды чтения/записи. Результат - при работе с ЕЕPROM в прерывании возможна ситация когда разрушаются адрес или данные в операции чтения/записи из основного цикла. В связи с редкостью подобного события возможен крайне трудноуловимый глюк :angry2: ...

При качественном проектировании это нельзя допустить. Слово "качественное проектирование" как-то неуместно. Ежу понятно, что если можно использовать кварц, то кварц и используется. НО кварц это как минимум дополнительный элемент (площадь, ненадежность, цена) и кварц это задействованные лишние одна или две ноги (а ног всегда мало). То бишь "качественное проектирование" при использовании кварца может вылиться в использование более многоногого МК что очень часто от "плохо" до "недопустимо". Назвать такой выход "качественным" в ситуации когда такого размена можно избежать я НИКАК не могу. Не уверен, что этот параметр может повлиять настолько, да и стареют RC одновременно... Чтобы нормально спроектировать даже несложную систему, нужно быть уверенным в параметрах компонентов. Уверен я бываю только после недели собственноручных испытаний :glare: . Для Вас достаточно уверенности Atmel которая, заложив в доках точность коллибровки RC и его изменение от Vсс T и OSCCAL, ни в одном чипе не обмолвилась о нестабильности этого генератора из-за старения? Я думаю, что указанная нестабильность не выше нестабильности по причине Vсс и T.... Для этого они должны быть известны и они должны быть. Для LIN протовола это просто, а вот при общении с каким нибудь GSM модулем(мобилкой) весьма проблематично Прочитайте посты #1 и #5 данной темы. А в "мабилле" тоже кварц имеется... В "мабилле" есть, но в "мабиллу" никто и не влазит. Речь о связи с нею....

Неудобно по трём основным причинам: 1. Нужен термодатчик; Да, это нужно. Правда его точность может быть никакая :) . С этим проблем нет - либо это напряжение "плывет" в пределах 10% (что меняет частоту на доли %) либо Мега меряет свое питание внутренним АЦП (через BANDGAP) даже без потери на это порта.... Насколько помню чатота RC во всем диапазоне температур и напряжений уплывает МАКСИМУМ на 5%(разность между крайними точками поверхности). Тобишь (т.к. и так "практически почти хватает") достаточно грубой коррекции частоты в нескольких точках T-U диапазона. Т.е. это не юстировка частоты - это коррекция при которой локальная ошибка в 0,5-1% (четверть ошибки по каждой из возмущающих параметров) более чем допустимы. Ну и можно допустить, что около коллиброванного значения наклоны кривых в разных чипах имеют достаточно высокую повторяемость. Не уверен, что этот параметр может повлиять настолько, да и стареют RC одновременно... Для этого они должны быть известны и они должны быть. Для LIN протовола это просто, а вот при общении с каким нибудь GSM модулем(мобилкой) весьма проблематично

Точно - в другом месте ;) . А вставка лишнего nop-а перед вызываемой функцией благотворно влияет на карму Меги168 (она видать очень любит четные CALL-ы) поэтому она благополучно не замечает того другого ошибочного места. IAR-овцы тоже ошиблись когда патч на релиз выкладывали - у них всегда константные исполнимые вектора везде великолепно работали... "Доктор, не делайте из меня эйдиота" :) .

А чего именно 3 класс? Потому как 2 класс с 0603 как-то плохо совместим ;) Вы мне еще многослойку с золочением контактов вместо банальной односторонки посоветуйте.... :tongue:

Всвязи с непредвиденным увеличением объема разработок есть желание привлечь для разводки печатных плат стороннего специалиста. Работа разовая (а может и нет :glare: ) на 2-3 небольшие платы (в смысле места то-же не густо). SMD, 0603, максимум 3 класс сложности (на многослойку можно даже не расчитывать :a14: ), под автоматический односторонний монтаж на линии...

Дык описываю массив структур типа token Там выше описана структура struct token { const char __flash *str; void (*fun)(void); }; Иначе это было-бы описание простого типа (например через typedef) с именем token. По крайней мере так IAR не ругается :)

Наблюдая как этот код зависает в МК мне от его правильности как-то не легче :( ... Ну предположим там был (*token_table[Response].fun)() Поэтому в настоящем коде вместо ldi константа было ldi r30, 0x02 ldi r31, 0x02 mov r16, r24 ldi r17, 0 lsl r16 rol r17 lsl r16 rol r17 add r30,r16 adc r31,r17 и далее те самые lpm r16,z+ lpm r17,z movw r26,r16 movw r30,r26 icall но это дела не меняет - если все адреса функций в таблице четные то программа не висла, если в разнобой - певый же нечетный чаще всего зависал... Причем больше всего бесило, что иногда и не зависал. Хотя сейчас я понимаю, что оптимизатор IARa мог просто удачно на тот момент перетасовать код. Лучший критерий - программа в МК это очень ярко показывает....

Естественно есть прототипы описаные до констант - иначе компилятор выругается.... По поводу & - ......... Кстати, обращу внимание - это рабочий вариант. А вот если убрать nop из первой функции (длина которой станет 1 слово), то при вызове второй МК отправляется в "спячку" :( ... Собственно так и "спасаюсь" - все адреса функций в таблице нопами делаю четными. Но иногда ( когда IAR "с оптимизирует" очередную константу перед этим кодом) приходится увеличивать константы "загоняя" адрес первой функции в нужный диапазон.... Естественно с оптимизацией тут уже почти никак :( . Вот если-бы можно было указать выравнивание кода процедур или явно указать их адреса....

Примерно так: // Структура таблицы ключевых слов struct token { const char __flash *str; void (*fun)(void); }; // Таблица ключевых слов и их обработчиков __root __flash const struct token token_table[] = {CR_LF,fun_VOID, OK, fun_OK, .............................................................. } void fun_VOID(void) { asm("nop"); // Лекарство от зависания :( !!! return; } /* Обработчик "OK" */ void fun_OK(void) { if(error_cnt) error_cnt --; (*fun_OK_addr)(); // Запуск обработчика по указателю asm("nop"); // Лекарство от зависания :( !!! return; } .......................................... // а вот так вызывается в коде из таблицы.... void (*p)(void); Response--; p = token_table[Response].fun; (*p)(); // token_table[Response].fun(); - тоже самое, но так вроде стабильнее ;( ............................................. К сожалению с кодом проблемы - надо перекомпилировать и много кода сюда писать....

А шут его знает, вроде АВР :-) ... Адрес естественно в словах. Собственно патч по этому поводу у них на -про версию ВРОДИ-бы здесь: ftp://ftp.iar.se/WWWfiles/avr/PatchReadme_412b.html Так, что читайте "описание от производителей". Лично мне поймать условие когда 100% код виснет так и не удалось (не помог и асм полученного кода :( ). А вот что делать с -евал версией? Кстати, в 4,20 -евал этот баг все еще присутствует.... Да, и еще любопытный вопрос - если в 4.20 EV баг все еще есть, где гарантия, что тот патч решает проблему в полной версии?

Да я ж говорю - код зависает. Насколько я понял зависит от адреса вызываемой функции. Если по четному, то вызывается нормально, а если по нечетному - то ИНОГДА зависает. Вот лишними nop-ами и приходится ровнять код вызываемых процедур (меняю одни, а подвисают другие....) - иначе не работает... А если учесть, что эта зараза константы втыкает перед кодом, то по мере развития проекта перетыкивать nop-ы приходится регулярно :-(

Может кто подскажет как бороться с зависанием полученного кода если в нем использованы указатели на функцию. Бо шаманить с лишними nop-ами уже порядком надоело... :angry2: