Для ibiza11
1. регистр mrak находится в области, для которой команды работы с непосредственными данными не допускаются (см. файл defname_flasher8u.txt )
2. подпрограмма сканера дисплея (он же программный ШИМ) работает автономно в фоновом режиме.
Для загрузки начальных данных, не нарушая общего алгоритма и используется такой вариант - но только на этапе инициализации начального состояния системы. Когда работа просто по переходу достаточно ret, но в рабочем режиме это точка выхода по прерыванию поэтому и стоит reti. Разрешение на запуск тамера дается только после всех процедур загрузки начальных значений данных/режимов работы, а затем уже разрешение прерываний по таймеру, глобальных, сброс предделителя (можно и без него) и запуск таймера.
Флаг OCF0A при начальном запуске равен 0 (см. даташит 8246B–AVR–09/11 стр 87).

Кстати мняв и есть автор.

Engineer_Keen
Чего касательно задержек... всяких... тема отдельных тестов.
В том числе и работа с общими фрагментами только одного (не всех) каналов при остальных с линейным участком (без DR_CALL (оно же com_call kanalN,метка)).
Если подтвердится - харакири для тиньки... Но это опять по свободке.

С прискорбием соощаю о всеж-таки аппаратной проблеме у ATtiny2313...
Возможно это какой - то вариант сбоя антихакерской защиты (чтение программного кода программой пользователя).
Но для моего варианта применения такой "фокус" означает непригодность данного МК для простейшей "мигалки"...
Суть эффекта - при очередном обращении к памяти программ как к источнику данных в ячейки ОЗУ (куда эти данные должны помещаться) записывается блокирующий код 0хFF как-бы еще и с каким-то зарядом (равноценно если бы это было не ОЗУ а eeprom). Через час-полтора работы этот заряд рассасывается и канал начинает молотить свою программу, естесственно с определенной задержкой.
Только вот по каким принципам формируется эта пакость неизвестно - ведь у каждого МК свои каналы (ячейки ОЗУ) блокируются. Добраться до сути вероятно помогла бы отладка на живом кристалле с помощью внутрисхемной отладки - но такими возможностями не располагаю, да и надо-ли копать, все равно аппаратный дефект выполнения от его понимания не устранить.
Прийдется переводить программу на mcs51!

Не верю...

Для неверующих - в начале темы схемка и архив с проектом - можно проверить
Только проект настроен для размещения на диске D.
Для пакости даже полностью разделял используемые регистры.
Кстати, насчет заряда в ... области - через час-полтора с момента включения "блокированные" каналы оживают и начинают спокойненько работать (естественно с соответствующим смещением по времени).

Бред. Напишите проверочную программу (максимально простую) для демонстрации эффекта. Убедитесь, что это не так.

Бред-не бред, а ФАКт проверенный макетом...
Выполнение безусловного прыжка (выполняется всегда без замечаний) отличается от проблемного только записью адреса возврата в собственную область ОЗУ т.е. что там, что там прыжок по ПЗУ со считыванием новой порции кодов... Да и не все каналы ведут себя одинаково, а только "избранные", причем от кристалла к кристаллу эта "избранность" меняется.
Особо спорить не буду - просто отмечаю событие, кому захочется поглубже выяснить - не вопрос, но использовать LPM в сложных переходах буду с большой подозрительностью. Всеж-таки в моей задаче не простое чтение данных, а частоповторяющийся доступ к разным участкам ПЗУ в произвольном порядке.

Лучше не надо. Я просто уверен, что у вас происходит срыв стека, или что-то в этом роде. Потому, что повторить это на тестовой программе вы не сможете. Так что разбирайте код.

Было б хорошо, если б эта ошибка в симуляторе также как и в макете вылазила - однако такового не наблюдается - все работает "по правилам" - и стек на своем месте и данные откуда надо берутся и куда им указанно попадают и перекрытия регистров нету - а единственное прерывание по совпадению даже в симуляторе правильно выполняется.
Дело как раз в том, что в реальном макете такого благополучия не наблюдается, а ведь симулятор простые команды выполняет все-же правильно, да и содержимое регистрового файла, ОЗУ, выделенной области стека и РСФ вполне однозначно видны в соответствующих окнах.
В том то и заморочка - теоретически и на прогоне в IDE эффекта нет, а на практике - вполне ощутимо наблюдается. Да и закорачивание обесточенной ИС с логической точки зрения бессмысленно, однако дает ощутимый результат на практике...

Обычная ошибка использования озу и стека.
Симулятор не показывает ошибок, т.к не отслеживает содержимое стека.
У 2313 всего 128 ячеек. при активном использовании подпрограмм и прерываний напалзание гарантировано.

Да ну полно уже...
А то вы не знаете об ограичениях симуляторов...
Смахивает на... "В Протэзе робит, а в железе - не!"...

ur5fia
"Симулятор не показывает ошибок, т.к не отслеживает содержимое стека."
- вот это абсолютный бред - AVRstudio4.19 в окошке memory -> data прекрасно показывает все, что касается текущего содержимого ОЗУ. В том числе и содержимое стека (касается как avr simulator так и avr simulator2).

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

BOB51, да напишите вы уже цикл из 10 строк, пишущий/читающий по-вашему проблемные области. Чтобы мы могли воспроизвести. И я либо ткну носом в ошибку, либо достану свой пыльный программатор и зашью им 2313.

Вот еще раз :

это архивчик с проектом AVR studio базовое размещение в корневом каталоге диска D (просто там у меня все папки проектов - если интересно переделаю под размещение на C ).
проблемный участок - выполнение модуля перехода на "общий фрагмент" по тексту
" dr_call:2" (строка 186) в разделе (файле) preparing8ut.txt, возможно какой-то сбой после его выполнения на участке
repin:
-----
-----
ret (строки 121-139 того же файла) выражающийся в заполнении ячеек tmp_lev_N и cnt_frame_N какого-либо из каналов ( N=0-7).
В последующем обработчик
komsel:
----(строки 100-109 того же файла)
не в состоянии длительное время изменить содержимое в соответствующем cnt_frame_ (это единственное с моей точки зрения основание для зависания на время более 12секунд, кроме еще менее вероятного декремента из ранее считанного из cnt_frame_ значения 0)
Честно говоря меня сей казус таки достал... Оно просто из принципа - неужто где-то чегось упустил... так перед написанием темы достаточно много тестов провел, в том числе и с вариациями схемотехники (и кварц и сброс и дросселек в цепи питания)...
По отдельности каждый из фрагментов работает нормально, проблемка вылазит, когда все 8 каналов одновременно хотят на "общий фрагмент" прыгнуть... и прыгают... только вот какой-то (или несколько) "зависают" на часик-полтора. Потому здесь 10 строчками не обойтись - требуется полная нагрузка и обязательно с вариантом общего фрагмента с сохранением адреса возврата ("линейный" прыжок такого действа не производит) - это в тестовом образце программы рисунка (progpak_tst1.txt).
Надо на время от этого дела отключиться - мож вылежится, чего и прояснится... хоша, если я прав... там уже ничего не поможет... жаль...
Просто похоже легче на 51-ю перевести будет - там работа с данными в области памяти программ на такой режим более подготовлена.

Посмотрел в тексте и симуляторе - где инициализация стека - не нашел - извиняюсь уже нашел
И где такой стиль написания программ применяется никогда не видел - txt файлы вместо asm или inc.
Равнялся в ассемблере для AVR на Чена - типа как тут: http://elm-chan.org/works/rsm/report_e.html
На подобный баг tiny2313 не нарывался - не хвастаюсь, тысячи устройств на сабже работают годами не выключаясь, как и подобные на tiny13.

oleg110592

Инициализация указателя стека в файле hard_set8ut.txt , хотя согласно даташиту на ATtiny2313 этого и не требуется - по умолчанию после сброса там автоматически установлен конец ОЗУ.
А вот касательно стека возврата из "общих фрагментов" - то уже в другом месте (preparing8ut.txt).

Касательно стиля написания - мой собственный вариант на основе обработки заголовочных файлов microchip и рекомендаций В.Тимофеева ( http://pic24.ru/doku.php/articles/list ) + особенности работы с ассемблером c51asm для mcs51 от atmel - работаю со всеми тремя семействами pic-avr-mcs51 вот и слепил, чего получше (с моей "колокольни")

По возрасту (50) или по ленивости не пишу уже на ассемблере - пользую Си компиляторы (там своих багов хватает), для тини и мега48 еще и AB применяю вместо ассемблера. Рекомендую для вылавливания бага в вашей программе задействовать USART для вывода отладочной и другой информации - мне очень помогает.

Век живи, век учись - а дурнем все равно будеш...
Перекопал я программу под mcs51 (конкретно под AT89C2051), естесственно с учетом ее особенностей упора на акумулятор... пришлось несколько переделать анализатор задач...
Работает... Быстродействие конечно - не разгонишся, зато все прекрасно выполняется.
Затем провел обратную адаптацию под тиньку и... все прекрасно заработало!
Для симулятора что первый вариант, что последний - абсолютно одинаковы, а вот "железо" все-же так не считает... Вывод - не усложнять код без наличия предварительных макетных испытаний (кто знает, на какие нюансы напороться можно).
Для любителей закопаться архивчики проектов.

На схему вам правильно указали - нельзя так кнопку ставить, после дросселя. Я в свое время пожег много памяти РУ5, когда проверял, как срабатывает защита блока питания от КЗ. Если надо именно коротить питание - ставьте тиристор. Ключ+дроссель+дребезг кнопки = повышающий преобразователь, после чего КМОП может склеить ласты, но если выживет, могут начаться чудеса.

Ваш код я не смотрел и не буду, своих тараканов в голове хватает. Такие глюки случались и в моей практике. Были и поражения. Поэтому сильно умничать и хвастаться мне нечем. Ваш случай очень похож на использование ОЗУ без инициализации, т.к. состояние зависит от обесточивания процессора. Статическое ОЗУ после выключения питания (а конкретнее, после снижения напряжения ниже 1.5 вольт) сохраняет состояние примерно 10-20 секунд.

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

PS. Позволил себе потерять 10 минут, чтобы просмотреть ваш код. Эх, за что же вы так себя-то не любите? Такой код надо показывать заказчику или начальству, чтобы уважали, платили, и не задавали лишних вопросов. А для себя, любимого, надо писать так, чтобы через год можно было быстро понять структуру, выдрать полезности, поправить и т.п.

прочитал, ничего не понял в глюк исполнения ядром МК каких-то команд не верю... но вот какой вопрос снова возник у меня (ранее я над этим думал сам, но тестировать было лень) - кто-нибудь знает ответ на конкретный вопрос: существует ли в AVR разница между reti и sei; ret ? соответственно, обратный вопрос: допустимо ли использовать reti вместо ret в обычных подпрограммах, если состояние флага i безразлично или как раз должно устанавливаться?

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

почему я об этом подумал? например, потому, что в доках на семейство MCS51 написано, что команда возврата из прерывания не аналогична команде возврата из подпрограммы с установкой разрешения прерываний, т.к. помимо установки флага она еще "приводит в чувство" блк контроллера прерываний. правда, есть одно но: у MCS51 система прерываний с приоритетами, а у AVR - без них, поэтому, возможно, "приведение в чувтсво" и не потребуется - но кто уверен в этом на 100%? я - нет.

Но везде в описании reti на AVR говорится, что она аналогична sei; ret; За исключением, конечно того, что между этими двумя командами не может влезть прерывание. Скорее всего, они как-то одновременно делаются..