Alexeyslav писал(а):...Изменять память программ из самой программы тоже не выйдет - доступ к памяти программ на запись возможна только с адресов бутлоадера
Слишком категорично. В ATtiny13 бутлоадера нет, а возможность записи FLASH есть.
16. Self-Programming the Flash
The device provides a Self-Programming mechanism for downloading and uploading program code by the MCU itself. The Self-Programming can use any available data interface and associated protocol to read code and write (program) that code into the Program memory. The SPM instruction is disabled by default but it can be enabled by programming the SELFPRGEN fuse (to “0”).
Сам активно использую возможность записи калибровок во FLASH ATtiny2313, кстати тоже не имеющего бутлоадера.
Так бутлоадер - всего лишь программная "надстройка" для использования протокола самопрограммирования, отличного от исходного аппаратного, созданная изготовителем устройства.
А базируется всегда на аппаратном протоколе самопрограммирования (у АВРок вариации команды SPM).
Кроме того, обычный код 0xFFFF/0xFF при аппаратном "переборе" также равноценен NOPам - заполнение памяти программ чем-то иным используется в основном для табличных селекторов и/или сверхбыстрых кодеров/декодеров.
Чтоб МК с внутренним ПЗУ от внешних факторов "сбрендил" при исполнении программы...
Другое дело ежли внешние сигналы на лапках "за 50" перевалили. Или программные "извраты" слишком мудреные и на грани разумной нагрузки на МК - но на то тест-испытания имеются.
Насчёт "соломки" - смотри правила у микрощипа уж там перестрахерились "с запасом" - но более не от залета по кодам команд, а по возможности отказа системного генератора (ибо уж слишком пикачу микромощный) и по неконтролируемым "иглам" по питанию - в обеих случаях светит глухой "ступор" - полный останов МК в произвольном месте программы.
Следующим фактором сбоев может быть некорректный переход в несоответствующую ячейку ПЗУ,но такая проблема актуальна лишь для МК с произвольной длиной кода команды. У АВР, ПИКов и АРМ - фиксированная длина кода каманды, выполнение "бредятины" там просто невозможно ( в отличии от I8080, Z80, I8086, mcs51).
Основной формат команд АВР - двухбайтовое слово.
Дополнительно возможен формат с адресным полем опять же размером в слово. Однобайтовых кодов просто не существует (но производная проблема - вечная путаница в вопросах с размещением таблиц данных и строк данных).
У ПИКов также соблюдается подобная форма (но полностью двухбайтовые только у 18-й и выше -у среднемладших 12-14 битовый формат ).
I8080, Z80, mcs51, I8086 имеют произвольный формат, включающий в себя различные компоненты (адрес, данные, различные префиксы), кроме того для команд счетчик там идет ПОБАЙТОВО (любой встретившийся первый байт - начало команды), тем самым возможно случайное попадание в середину команды и соответствующие последствия. Для АВР или ПИКа попасть во второй байт слова при выборке команды практически из области фантастики. Частично там есть еще один уровень защиты, распознающий подобную ситуацию с пропуском "фиктивной команды" (попадание на второе слово, содержащее адрес) - но как то организовано, честно-не вникал.
Насчет бывают "длинные команды" или нет...
Достаточно двухбайтовой команды с приращением счетчика команд в один байт и сбойного возврата не на начальный код, а на второй байт. (А может и похуже MOV add,ads mcs51 или INC (IX+rel), SET 5,(IY) в Z80).
BOB51 писал(а):Для АВР или ПИКа попасть во второй байт слова при выборке команды
Думаю, что Jack_A имел в виду команды состоящие из двух машинных слов (а не байт). Соответственно можно на второе слово "джампнуть" так или иначе. И можно утверждать с очень большой долей вероятности, что защиты против этого нет.
Когда уже ничего не помогает - прочтите, наконец, инструкцию.
Лучший оптимизатор находится у вас между ушей. (Майкл Абраш, программист Quake и QuakeII)
Избыток информации ведёт к оскудению души - Леонтьев А. (сказано в 1965 г.)
В принципе возможно, но гораздо меньше, чем в тех же системах с произвольной длиной кода команды.
А ежли о таблицах... так у компилятора достаточно средств для правильного определения смещения адреса метки... Другое дело когда вручную на листочке трансляцию делать приходилось...
Да и насчет "детектора фальшивой команды".... все ж гдей-то встречалось... ШКЛЕРОЗЬ...
Мне не нравится слово "произвольная". Бывают команды различной длины, но при этом - всегда детерминированной, а не произвольной.
Насчет трудностей ложного "перескока" . Давно, еще в прошлом веке , Атмел выпустила баг репорт о том, что если после команд типа SBRC идет двухсловная команда, то может произойти х.з.ч. Но начиная с ревизии Х мы, мол, эту багу пофиксили. А если будете писать, мол, на С, то вумный компилятор и сам не допустит ничего такого даже на старых ревизиях.
А перескочить "не туда" -- как 2 байта об асфальт : загоняешь в Z адрес перехода -- IJMP -- и вы уже в Хопре. И представить механизм, который может предотвратить это аппаратно -- совершенно невозможно, в отличие от вышеописанной ошибки. Разумеется, все вышесказанное относится к прогр. на АСМе.
Про "попасть во второй байт" команды я и не думал и не говорил. Ес-сно, речь шла о втором слове команды.
Но ведь в указателе Z перед тем компилятор поставит правильно заданный адрес метки.
(как и в случае подстановки адреса возврата через стек).
Зачем абсолютными значениями пользоваться, ежли в компиляторе метки имеются???
Возможность загнать туды чегось неудобоваримого возможна только при некорректности работ с вычисляемыми по ходу программы самим МК адресами - а то уж "баг программиста", а не железа
Насчёт SBRC Rr,b (и прочей группы "пропуск инструкции при совпадении")....
это ж какой глюккос-валериани споймать надо, чтоб за ней команду длинного перехода (двухсловник) впихнуть?
там же четко оговорено, что пропуск одной инструкции, а не двусловного монстра.
произростание от cjne a,#d,rel (да и остальных cjne в mcs51), заодно и "зеркальная" по смыслу CPSE Rd, Rr у АВРок пропуск одной ячейки для счетчика команд ( у АВРок = слову, у 51-х = байту, у пичков ячейка в соответствии разрядности).
Когда уже ничего не помогает - прочтите, наконец, инструкцию.
Лучший оптимизатор находится у вас между ушей. (Майкл Абраш, программист Quake и QuakeII)
Избыток информации ведёт к оскудению души - Леонтьев А. (сказано в 1965 г.)
Отдельные "исключения" не в счет - у АВРок куча всяческих нюансов в конкретных даташитах, но "исключение", не являющееся общим правилом обычно и приводит к проблемам.
Кстати... в основном документе так и стоит PC+2 (or 3) одначе 2 выполняется в любом случае, а насчет 3 это в конвеере предвыборки анализ проводится должен на предмет "а кто там у нас следующий?" - есть ли такой аппаратный обработчик а самом имеющимся в лапах экземпляре МК токмо пробный тест кода на данном МК покажет.
В новых поступлениях -- есть, Атмелы на старые грабли не наступают.
Кстати, была у меня единожды с ними заморочка. Гоняю прогу - бредятина выходит, переход не срабатывает. Голову сломал, анализируя код -- ничего. Последовательным приближением нашел проблемную команду -- флаг не устанавливается. Заменил абсолютно эквивалентной парой команд -- ОК. Прогнал в симуляторе исходный вариант -- так тоже нормально! Написал Атмелям -- пришли, говорят, прошивку. Не слать же им всю рабочую прогу -- там до проблемного места через два десятка ветвлений добираться. Уменьшил код, выщемив только интересующий участок. Ни хрена себе! Тут работает нормально!
Так и остался в неведении, прога пошла с эквивалентной парой.
И дело тут не в том, что эквивалент не полный -- сам натыкался на то, что INC и ADD, к прмеру, по разному устанавливают С. До атомов разобрал в симуляторе и на макете на разных режимах эту пару и подозрительную команду - абсолютная идентичность. Но вот в конкретном контексте с конкретным МК что происходит -- так и осталось покрытым мраком.
А вы говорите -- Си, где к возможным багам МК могут добавиться заскоки компилятора.
ммм....
о "длинных переходах"...
при общем объёме программной памяти для большинсьва "ходовых" МК в 4килобайта слов в большинстве случаев достаточно RJMPа чтоб перекрыть практически весь эффективный диапазон доступа в+/-2килобайта... Возможно посему и не приходилось пока с двухсловными переходами по условию сталкиваться.
ARV
с вопросом о "чудотворцах" вполне согласен - чем проще алгоритм - тем надежнее.
сам испытал ( http://radiokot.ru/forum/viewtopic.php? ... 0%BE%D0%B4 )
ARV писал(а):
может быть, все чудеса заключены в чудотворцах, а не в ядрах МК?
Скорее всего. Потому что "не бывает в электронике чудес". Возможно, та моя проблемная команда меняла не все флаги, и потому анализ всего флагового вектора мог зависить от контекста, от предыдущих команд. Времени детально анализировать не было, нужно было сдавать работу. Нашел обходной вариант - и ладно. Давно это было, еще в прошлом тысячелетии .
Доброго времени суток. Есть массив в eeprom из 70 символов, я хочу перенести их в озу но не через стэк. Подскажите - как переделать код, что бы данные из eeprom загружались в ОЗУ "с начала" а не с конца. Вариант вручную прописать ВСЕ адреса для каждой ячейки не подходит а сам придумать не могу :|
Ну так считать не от 0 до 70, а наоборот (кстати, помимо прочего для этого не нужна команда cpi = экономия). И из регистра сохранять не в стек, а в ОЗУ c помощью команд ST/STD через указатели адреса ОЗУ X/Y/Z.
[ Всё дело не столько в вашей глупости, сколько в моей гениальности ] [ Правильно заданный вопрос содержит в себе половину ответа ]
, Атмел выпустила баг репорт о том, что если после команд типа SBRC идет двухсловная команда, то может произойти х.з.ч. Но начиная с ревизии Х мы, мол, эту багу пофиксили. А если будете писать, мол, на С, то вумный компилятор и сам не допустит ничего такого даже на старых ревизиях. 
