Проверка наличия инструкции возврата перед табличным прыжком

Родэрик

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

И в какой-то момент вдруг подумал: А что если однажды, по причине неведомого доселе сбоя мы потеряем 34h, и он станет чем-то иным.

И тут я решаю - надо бы до brw проверить на месте ли целевой 34h. Подумаешь, несколько микросекунд потеряю, зато типа качественный подход обеспечу. В итоге вставляю кусок - вычисление требуемого адреса и стандартное чтение флэш через eecon. Ну а как ещё старший байт заполучить?

И вот тут начинается самое интересное - делаю проверку старшего байта на 34h и написав это понимаю, что теперь мне не нужен табличный прыжок, ведь в младшем (eedat) уже лежит искомое. Но если мне не нужно табличное чтение, то тогда зачем мне проверка на 34h ?

Вопрос в следующем: Кто что думает об этой ситуации? Можно ли считать случившееся причиной для досрочного выхода на пенсию?

И кстати, всем привет!

Реклама

BOB51

От поражения ячеек конечно абсолютной страховки нету...
Но где гарантия, что такое не случится допустим в области программного кода или в самом начале ПЗУ?
ЁЖли уж охота "перестрахерится" -
просто перед началом выполнения программы делаем расчет CRC для всей области ПЗУ.
Сравниваем с ранее созданным эталоном...
Ёжли данные теста не совпали - аварийный останов.

Реклама

КРАМ

[uquote="Родэрик",url="/forum/viewtopic.php?p=3793944#p3793944"]Можно ли считать случившееся причиной для досрочного выхода на пенсию?[/uquote]
Да, можно.
А чтобы не выходить, нужно взять ДЕЙСТВИТЕЛЬНО новый чип, у которого пространство младших байтов флеша отображено в пространство ОЗУ, начиная с адреса 0x8000.
Смотрим раздел 4.6.3: http://ww1.microchip.com/downloads/en/D ... 01897B.pdf
Что касается надежности чтения флеша, то ее можно проконтролировать только внутри самого МК аппаратным образом. Такие МК, кстати, тоже есть. Они имеют ЕСС-память.
Проверять память рекурсивно, то есть саму себя - бессмысленно.

Родэрик

[uquote="КРАМ",url="/forum/viewtopic.php?p=3793999#p3793999"]....
А чтобы не выходить, нужно взять ДЕЙСТВИТЕЛЬНО новый чип, у которого пространство младших байтов флеша отображено в пространство ОЗУ, начиная с адреса 0x8000.[/uquote]

Имеется ввиду косвенное чтение через Fsr? Если да, то я так то в курсе (сам факт упоминания brw об этом свидетельствует ), и это конечно же доступно в чипе о котором я писал (12f1840).

Речь шла о парадоксальности ситуации, не более. Вопрос больше философский. То есть я решил привнести проверку (чего раньше никогда не делал), что само по себе в итоге исключило необходимость такой проверки. Такое ощущение что эта ситуация как бы на что-то намекает, но на что?

Ну вот представим, что человеку дали задачу в уже написанный код привнести проверку всех старших байт таблицы на 34h. Вроде ничего особенного в этой задаче нет. Как решить её? Только чтением через eecon, ведь так? Но приступая к выполнению данной задачи, начинаешь понимать, что смысл самого табличного чтения исчезает при реализации этой задачи и ты сразу убираешь brw. А как только его убрал, то сразу понимаешь, что и 34h (retlw) тоже уже не нужны, а значит и та проверка которая привела ко всему этому тоже не нужна.
Я не могу осознать смысл этого парадокса.

Добавлено after 12 minutes 39 seconds:
[uquote="BOB51",url="/forum/viewtopic.php?p=3793958#p3793958"]От поражения ячеек конечно абсолютной страховки нету...
Но где гарантия, что такое не случится допустим в области программного кода или в самом начале ПЗУ?......[/uquote]

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

Реклама

BOB51

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

Реклама

КРАМ

[uquote="Родэрик",url="/forum/viewtopic.php?p=3794070#p3794070"]Имеется ввиду косвенное чтение через Fsr? Если да, то я так то в курсе (сам факт упоминания brw об этом свидетельствует ), и это конечно же доступно в чипе о котором я писал (12f1840).[/uquote]
Тогда зачем читать через retlw или табличное чтение?

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

[uquote="Родэрик",url="/forum/viewtopic.php?p=3794070#p3794070"]Речь шла о парадоксальности ситуации, не более. Вопрос больше философский.[/uquote]
Первоначально Вы не обозначили, что речь идет о проверке только перезаписываемого участка флеша.
Но тогда проблема совсем не в том, что основной код не проверяет таблицы, а в том, что проверка не производится при перезаписи этих таблиц.
А это ващето обязательная процедура - верификация после записи.
Более надежным выглядит метод двойных полей данных. То есть имеется текущее поле используемое кодом и перезаписываемое.
После верификации В ОТДЕЛЬНОЙ ПЕРЕМЕННОЙ EEPROM переводится указатель на верифицированное поле данных, делая его актуальным, а прежнее становится готовым к новой перезаписи.
Таким образом, риск интервала порчи сводится менее, чем к 1 мс при изменении указателя. Если все это поддержать самоконтролем питания и электролитом на блокировке, то риск станет равным нулю.

Реклама

Родэрик

[uquote="КРАМ",url="/forum/viewtopic.php?p=3794141#p3794141"]....
Тогда зачем читать через retlw или табличное чтение?

[/uquote]

Хороший вопрос кстати. Почему-то fsr я и в мыслях не держал....... Надо будет этот вопрос детальней исследовать. Какой способ в какой ситуации быстрее/удобнее....

К примеру нам нужно значение 5-й строки таблицы. Загружаем 5 в W, исполняем BRW, и вот уже в следующем цикле у нас в W результат. Причём, тут стоит отметить, что у нас напрочь отсутствуют проблемы с переполнением pcl.

Теперь для fsr. Допустим имеем массив (без retlw). Загружаем младший и старший байты метки массива в fsr0 и fsr0h соответственно. Загружаем 5 в W. Прибавляем к fsr0 W. Смотрим перенос и если что добавляем единичку в fsr0h. Читаем indf0. (moviw fsr0)

По-моему, через brw всё-же быстрее выходит.

КРАМ

[uquote="Родэрик",url="/forum/viewtopic.php?p=3794201#p3794201"]К примеру нам нужно значение 5-й строки таблицы. Загружаем 5 в W, исполняем BRW, и вот уже в следующем цикле у нас в W результат. Причём, тут стоит отметить, что у нас напрочь отсутствуют проблемы с переполнением pcl.[/uquote]
Однако вспомним, что из-за необходимости сброса конвейера все команды ветвления выполняются за ДВА машинных цикла, а этих команд в цепочке чтения таблицы - ТРИ:

Код: Выделить всё

     call   Tab
.................
Tab:
     brw
.................
     retlw   0x34xx

Итого, ШЕСТЬ машинных циклов. Причем каждое чтение. То есть для чтения строки-вектора (например при размерности элементов таблицы более, чем 1 байт) придется умножить число байт на 6.
С FSR-INDF все не так, ибо есть автоинкрементное, автодекрементное и индексное чтение moviw.
Что касается "переполнения PCL", то и тут не все так просто. Единственный выигрыш с retlw мы получаем для произвольного размещения начала таблицы, но если таблица длиннее 256 элементов, то считать адрес из двух байт нужно по-любому. И все становится очень плохо с этими retlw. Прибить же таблицу "гвоздями" к началу страницы флеша никакой проблемы не представляет, а наличие двух FSR позволит загрузить старший байт однократно при инициализации, если канешна таблицы не вылазят за одну страницу...
Ну и бонусом для косвенного чтения идет та самая "безопасность". Риск ухода исполнения с заданной траектории равен нулю даже без всяких проверок. Будет просто считан ошибочный байт.
Еще одно удобство - заполнение самой таблицы в коде. Скажем, таблица из 256 элементов будет всего 16 строк из 16 байтных dw.

Код: Выделить всё

    org   0x500
Tab:
 dw   .12, .106, .99, .......
 dw   .20, ......
..

BOB51

Чет не понял...
Простое чтение данных из таблицы или переход по вектору, расположенному в таблице по заданному (или вычисляемому) смещению относительно адреса начала таблицы векторов затевается?

brw это удобно при вычисляемом переходе, а для фиксированного прыжка и bra сойдет...
Но при всем том - начало таблицы векторов фиксировано.
А для большего удобства - стандартно PCLATH:PCL.
Только вот у "улучшенной" в данном случае еще имеется CALLW... там сразу можно исполняемый код подставить...
И начало таблички/набора прикладных подпрограмм в PCLATH также изменяемое.

КРАМ

Речь идет об организации таблиц констант. Есть всего ТРИ способа их реализации в новых и относительно новых чипах 12/16 семейства.
1. Стандартный, с таблицей в виде retlw. При этом и используется инструкция brw.
2. Табличное чтение программного флеша через регистр-защелку EEDAT.
3. Линейный доступ к младшим байтам программного флеша в адресном пространстве ОЗУ (адрес 0x8000 и далее).

Родэрик

[uquote="КРАМ",url="/forum/viewtopic.php?p=3794272#p3794272"].......Еще одно удобство - заполнение самой таблицы в коде. Скажем, таблица из 256 элементов будет всего 16 строк из 16 байтных dw.

Код: Выделить всё

    org   0x500
Tab:
 dw   .12, .106, .99, .......
 dw   .20, ......
..

[/uquote]

Всё так, полностью согласен.
Но удобное заполнение таблицы через dw не является преимуществом (в рамках данного сравнения), поскольку в первом случае (для brw) всё делается точно также, только через dt.

КРАМ

Наверное так, я не слишком много пишу под 12/16-ые.
Остальные доводы я привел.
Причем если бы Вы работали одновременно с 16-разрядными ПИКами, то быстро бы отказались от retlw, поскольку МЕТОДЫ написания кода в 24/33-их как раз соответствуют линейному доступу к флешу. Там даже начальный адрес совпадает - 0x8000. )))
Это называется PSV-доступ - ПрограмСпэйсВизибилити.
Макрос начального адреса в коде будет #psvoffset(Tab), инструкция возвращающая адрес для перехода по указателю на функцию handle(Func) - для таблиц функций. Очень удобно при организации машины состояний.

Родэрик

[uquote="BOB51",url="/forum/viewtopic.php?p=3794388#p3794388"].....brw это удобно при вычисляемом переходе, а для фиксированного прыжка и bra сойдет...[/uquote]
Ещё со времен появления этого bra всё думал - а где его можно использовать? Что это за задача такая должна быть? До сих пор ни разу не применял.
Тоже самое кстати и с callw.

КРАМ

callw
Основное назначение - реализация указателей на функции.
bra - это основная инструкция для реализации безусловных ветвлений, патамушта goto - это длинная инструкция (два слова) позволяющая метаться по всему флешу, что в большинстве случаев совершенно не нужно.
Только нужно понимать, что время ее исполнения все равно будет 2 маш.цикла.

BOB51

В принципе - "все удобно, что в наличии имеется".
С "улучшенной" среднемладшей таки некоторые ограничения ассортимента при использовании
старого-доброго mplab 8.92.
Ежли есть на чем тренироваться - тогда все употребимо!

BRA и BRW удобны тем, что при их исполнении НЕ ЗАДЕЙСТВУЕТСЯ PCLATH.
В остальном ... особо от разновидности команд, использующих PCL в качестве приемника результата, по области применения не отличаются.