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

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

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

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

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

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

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

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

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

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

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

Добавлено after 12 minutes 39 seconds:


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

Открыт интернет-магазин MEAN WELL.Market – весь ассортимент MEAN WELL, выгодные цены

Открыта удобная площадка с выгодными ценами, поставляющая весь ассортимент продукции, производимой компанией MEAN WELL – от завоевавших популярность и известных на рынке изделий до новинок. MEAN WELL.Market предоставляет гарантийную и сервисную поддержку, удобный подбор продукции, оперативную доставку по России. На сайте интернет-магазина посетители смогут найти обзоры, интересные статьи о применении, максимальный объем технических сведений.

Подробнее>>

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

LED-драйверы MOSO - надежные решения для индустриальных приложений

Продукция MOSO предназначена в основном для индустриальных приложений, использует инновационные решения на основе более 200 собственных патентов для силовой электроники и соответствует международным стандартам. LED-драйверы MOSO применяются в системах наружного освещения разных отраслей, включая промышленность, сельское хозяйство, транспорт и железную дорогу. В ряде серий реализована возможность дистанционного контроля и программирования работы по заданному сценарию. Разберем решения MOSO подробнее>>

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


Первоначально Вы не обозначили, что речь идет о проверке только перезаписываемого участка флеша.
Но тогда проблема совсем не в том, что основной код не проверяет таблицы, а в том, что проверка не производится при перезаписи этих таблиц.
А это ващето обязательная процедура - верификация после записи.
Более надежным выглядит метод двойных полей данных. То есть имеется текущее поле используемое кодом и перезаписываемое.
После верификации В ОТДЕЛЬНОЙ ПЕРЕМЕННОЙ EEPROM переводится указатель на верифицированное поле данных, делая его актуальным, а прежнее становится готовым к новой перезаписи.
Таким образом, риск интервала порчи сводится менее, чем к 1 мс при изменении указателя. Если все это поддержать самоконтролем питания и электролитом на блокировке, то риск станет равным нулю.

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

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

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

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

Однако вспомним, что из-за необходимости сброса конвейера все команды ветвления выполняются за ДВА машинных цикла, а этих команд в цепочке чтения таблицы - ТРИ:



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

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

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

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

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

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

Ещё со времен появления этого bra всё думал - а где его можно использовать? Что это за задача такая должна быть? До сих пор ни разу не применял.
Тоже самое кстати и с callw.

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

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


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