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

ЗЫ: На работе есть несколько приборов, сделанных на 2313 тиньке. В интерфейсе куча настроек (over 300), при этом присутствует сложная логика работы устройства и при этом очень шустро работает. Как-то поинтересовался у разработчиков с центрального офиса, мол как они ухитрились так быстро проверять столько конфигов, и как они засунули всё это туда? Ответ - полиморфизм в программе.
Да я и не удивился ответу, там такие спецы сидят, что HEX или BIN файл вручную набить смогут.

думаю, слово "полиморфизм" - это типа тумана самопрограммирование в плане самомодификации программы МК AVR - это из области фантастики даже для больших мег с памятью 64 и более килобайт, а про тини и говорить нечего. дело в том, что невозможно ЗАПИСЫВАТЬ в область кода и одновременно ИСПОЛНЯТЬ код из записываемой области. именно поэтому область ЗАГРУЗЧИКА отделена от области ПРОГРАММЫ - читайте даташиты. таким образом, код из области загрузчика может изменять код программы, но сам себя не может ни тот, ни другой. значит, для "полиморфизма" программа должна иметь несколько кодов загрузчика в разных областях памяти и умело переключаться между ними - стоит произойти одному-единственному сбою, и вся память окажется похереной полностью.

к тому же в тини довольно мало памяти для того, что бы реализовать этот самый алгоритм полиморфизма - тут на ПК для этих целей приходится страшные извраты делать, а уж в МК и подавно. поэтому разработчики вашего девайса, скорее всего, все эти 300 настроек (даже не представляю, какие именно это могут быть настройки - не компьютер же с Windows на тини2313 они сделали!) на ПК компилируются в новую прошивку (вот вам и полиморфизм), которая затем грузится в МК при помощи тривиального bootloader-а.

это мое скромное мнение

Нет, это не ПК на тиньке, а диагностический прибор с семисегментным индикатором и 16 кнопками. Меню конфигурации там огромное - 20 пунктов, по 8 настроек в каждом пункте. 300 - это я конечно преувеличил. Несложно конфигуратор засунуть в область бутлоадера. Тем более там, чтобы войти в настройки, надо нажать на отдельную кнопку и удерживая её включить питание. К ПК ничего не подключается. Это полностью автономный прибор для теста акустических охранных датчиков.
Полностью менять весь код тоже нет смысла. Достаточно хотя-бы менять адреса меток в условиях, заранее наготовив шаблонов. Тем более тинька это позволяет в альтернативном режиме. То есть можно считать определённую область, сделать изменения, затереть старое и записать изменённое. При осмотре схемы я заметил, что вывод в индикатор работает через SPI и опрос кнопок происходит через дешифратор. Генерация звука скорее всего реализована таймером в PWM режиме. Фиг знает, как они сделали, но мне сказали, что конфигурация сделана методом полиформизма.

Здравствуйте, возникла проблема с подавлением дребезга контактов. Программа по таймеру выводит бегущую единицу в порт А, при нажатии на кнопку на 0 пине порта В, сбрасывается или устанавливается (в зав. от предыдущего состояния) бит разрешающий прерывание таймера. Код сброса/установки работает нормально, а вот обработка нажатия косячит. Иногда после сброса горит несколько светодиодов, иногда МК реагирует со второго нажатия. Пробовал разные интервалы задержки но не помогло. В чем может быть проблема?

.. опрос контактов ведут в прерывании и задержку делают там-же путем введения счетчика.

А без таймера разве не обойтись? Там же только одна кнопка.

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

... можно, только зачем??? ... если хотите занять все время МК опросом - можете делать это в основном цикле, но как ИМХО сделать лучше - написал выше...

то есть, каждую секунду по прерыванию таймера проверять состояние порта? я правильно понял? А насчет первого способа, где может быть ошибка то?

Доброго времени суток!
Просмотрел всю тему, но ответа на возникший вопрос не нашел. Поэтому сам вопрос:
Имеется ли в ассемблере AVRStudio возможность условного компилирования.

Почитал про директивы ассемблера в Евстифееве и Ревиче, но особо полезного для решения данного вопроса там ничего не обнаружил...
Думаю это должно как-то решаться, но с необходимыми для этого директивами асма, если таковые существуют, пока не встречался.
Может кто-нить что подскажет?

... ИМХО такие ответы лучше искать в help_e к компилятору.
сделать можно так:

для того чтобы не было заметно мерцание таймер настроим например на 1КГц. Внутри прерывания переменная-счетчик count увеличивает свое значение на 1 при обнаружении факта нажатия и обнуляется при отпускании. При достижении count заданного значения (например 250) - сбрасываем count в 0 и считаем что нажатие было.... (факт нажатия в данном случае регистрируется при удержании кнопки 250/1000=1/4 сек)

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

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

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

Думаю это избавит от необходимости держать кучу inc файлов...

... протеусом не пользуюсь - нет необходимости. Думаю "косячит" из-за того, что модели индикатора с 4 цифрами и отдельных индикаторов отличаются - не стоит забывать, что это всего-лишь модель....

Протеус не показывает все в реальном времени. Поэтому не стоит смотреть на то есть там мерцание или нет. Из опыта, мерцание не наблюдается если соблюдать следующее:
- засветка по очереди всех знаков должна происходить за время не более 20 мс (период сканирования <=20мс)
- При сканировании сначала гасим все знаки (0 на общие аноды или 1 - на общие катоды), затем выставляем нужные сегменты, после чего засвечиваем нужный разряд.

В реале делал максимум до 10 знаков (больше не было необходимости) Работает без мерцаний.
Кстати, в протеусе можно уменьшить тактовую частоту контроллера, например, раз в 50-100 по сравнению с реальной. и тогда ты увидишь, где идет неправильное переключение сегментов или разрядов, которое и вызывает мерцание

Всем спасибо, помогло

Кто нить может дать работающих код по самопрограммированию меги ?
интересует мега64...
нужно организовать хранение некоторых переменных в памяти программ..

p.s. по примерам что находил не совсем понятно в частности как зоны RWW и NRWW задаются и где лучше что размещать...

Еще один вопрос а можно ли организовать чтение из программной памяти при помощи индексной индексации ?
LDD r16 , X + 10 - походу дела читает из RAM, а мне нужно из FLASH.. причем чтобы значение X после выполения чтения не терялось...

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