ИГРЫ С ВЕКТОРАМИ (по мотивам viewtopic.php?p=4561359#p4561359) Весьма обычный прием... Допустим есть в начальном месте размеченное изготовителем поле для команд переходов... тут вектор сброса на своем месте по умолчанию: Код: ; ; "irq_pavr.txt" файл описания поля векторов прерываний ; .cseg .org 0x000 irq_res: rjmp init ; переход к началу программы инициализации системы ; - - - - - - - - - - - - - - - - - - - - - - - - - - - ; блок размещения векторов активных прерываний ; .org OC0Aaddr ; irq_t0: ; rjmp timers_bum ; steps ; - - - - - - - - - - - - - - - - - - - - - - - - - - -
Теперь где-то в удобном месте ставим второй вектор сброса. Полнейшая "творческая отсебятина" в вопросе где те вектора ставить. Допустим так: Код: .cseg .org 0x200 init: rjmp real_init
а далее собственно у нас или тот real_init будет выполняться или в той же ячейке расположенная новая команда перехода на иную точку входа в программу (перепрошитая "обманщиком" при помощи SPM (или еще попакостнее с использованием возможностей IJMPов ))... Даже если исходная таблица закрыта для перезаписи локами, то "самодельная вторичная" может располагаться как нам нравится (где удобнее). Собственно при прерывании (аппаратном сбросе) у нас срабатывает тандем из двух команд : первый переход по команде, размещенной в классической ячейке таблицы векторов rjmp init и затем уже второй - на нужную в данный момент программу (из нашей "полной отсебятинки"): rjmp real_init или IJMP ; по адресу, находящемуся в Z хотя... никто не запрещал ставить IJMP и в "стандартную" таблицу векторов... УПС... это я точно прозевал... (В MCS51 такой приятненькой команды к сожалению нету) Я брал пример на скору руку с шаблона асма тинек - но там в принципе любые команды переходов вместо rjmp name сгодятся. Что JMP по фиксированному адресу, что еще поизворотливее (у АВРок) IJMP по содержимому Z регистра. Понятно что это потеря быстродействия - лишняя команда - зато возможности достаточно заморочливые. Второе - сама SPM не знает где чего лежит - но автор такого приема прекрасно знает разметку памяти своего творения посему параметры то уж задаст и для бутлоадера (при начальной прошивке) и для прикладной программы.
я говорил о совсем другом. меня интересуют не те переходы, как
.org 0x200 init: rjmp real_init
а интересует, чтобы прерывание, например, по таймеру
.org OC0Aaddr rjmp irq_t0
работало в области загрузчика. а конкретно я говорил про приемо-передатчик, и соответственно, мне нужно, чтобы работал такой код
.org URXCaddr ; адрес прерывания USART, Rx Complete rjmp USART_Rx_Complete ; прием готов nop rjmp USART_Tx_Complete ; передача готова
в области загрузчика. и как я уже там сказал, по установленному биту IVSEL у меня не происходит перенос таблицы векторов в загрузочную область, а продолжает работать таблица на своем прежнем месте, начиная с нулевого адрема.
_________________ Мудрость приходит вместе с импотенцией... Когда на русском форуме переходят на Вы, в реальной жизни начинают бить морду.
А что мешает сделать простой переход в область адресов загрузчика из "стандартной"? Привязка к аппаратной поддержке совсем не обязательна. Просто делаем свой раздел в защищенной области к которому обращаются команды указателей адреса перехода из основного раздела " по умолчанию"... Исходная таблица "по умолчанию" будет обслуживать переходы на вновь созданную, но не средствами аппаратной поддержки, а средствами программной поддержки автором программы. Мы же вторичные (целевые) указатели можем размещать где угодно. Другое дело, что при написании целевой программы нужно учитывать параметры разметки бутлоадера - знать адреса размещения векторов по листингу бутлоадера и задавать их затем вручную при написании целевой программы. Но это уже стандартная специфика для комплекта базового бутлоадера с набором минимальных общих функций и целевой программы, которая может как пользоваться подпрограммами бутлоадера (прием/передача, типовые преобразования и т.п.) так и своими аналогами таких же подпрограмм. Это привычнее с оперативно подгружаемыми программами на самоделке с единой общей базой. Меняем модуль аппаратного расширения и загружаем соответствующую этому аппаратному модулю прикладную часть программы. А в самой "мамке" сидит только базовый загрузчик и утилиты управления аппаратным ядром устройства. Некоторая аналогия ПК - сначала запускается биос аппаратной части, затем программа пользователя, которая также использует и ресурсы биос и ресурсы собственные, которые можно модифицировать при необходимости. Отличие только в режиме модификации ячеек памяти программ - для ОЗУ мгновенная запись, по флеш ПЗУ требуется некоторое время и спецпроцедуры для перезаписи. По конкретике... Допустим я взял мегу8а... Оставил исходную таблицу векторов на своем месте... А прикладные вектора хочу разместить в области бутлоадера (на всякий случай беру бутлоадер максимального размера)... Т.е. у меня область бутлоадера от 0хС00 и далее... ставлю вот такой добавок в дефайне (m8adef.inc):
Спойлер
Код:
; ***** my INTERRUPT VECTORS ************************************************
; причем софтовая таблица может иметь и другие адреса начального размещения внутри области бутлоадера ; а не только самые первые (от FOURTHBOOTSTART)
; далее текст программы при необходимости ................................. ; теперь область бутлоадера:
.org FOURTHBOOTSTART ; или иная область внутри области ПЗУ бутлоадера - это софт, а не аппаратная разметка*** INT0addr_r: jmp my_INT0 ; External Interrupt Request 0 INT1addr_r: jmp my_INT1 ; External Interrupt Request 1 OC2addr_r: jmp my_OC2 ; Timer/Counter2 Compare Match OVF2addr_r: jmp my_OVF2 ; Timer/Counter2 Overflow ICP1addr_r: jmp my_ICP1 ; Timer/Counter1 Capture Event OC1Aaddr_r: jmp my_OC1A ; Timer/Counter1 Compare Match A OC1Baddr_r: jmp my_OC1B ; Timer/Counter1 Compare Match B OVF1addr_r: jmp my_OVF1 ; Timer/Counter1 Overflow OVF0addr_r: jmp my_OVF0 ; Timer/Counter0 Overflow SPIaddr_r: jmp my_SPI ; Serial Transfer Complete URXCaddr_r: jmp my_URXC ; USART, Rx Complete UDREaddr_r: jmp my_UDRE ; USART Data Register Empty UTXCaddr_r: jmp my_UTXC ; USART, Tx Complete ADCCaddr_r: jmp my_ADCC ; ; ADC Conversion Complete ERDYaddr_r: jmp my_ERDY ; ; EEPROM Ready ACIaddr_r: jmp my_ACI ; Analog Comparator TWIaddr_r: jmp my_TWI ; 2-wire Serial Interface SPMRaddr_r: jmp my_SPMR ; Store Program Memory Ready
; далее сам бутлоадер с соответствующими подпрограммами: .....................................
my_INT0: reti ; External Interrupt Request 0 my_INT1: reti ; External Interrupt Request 1 my_OC2: reti ; Timer/Counter2 Compare Match my_OVF2: reti ; Timer/Counter2 Overflow my_ICP1: reti ; Timer/Counter1 Capture Event my_OC1A: reti ; Timer/Counter1 Compare Match A my_OC1B: reti ; Timer/Counter1 Compare Match B my_OVF1: reti ; Timer/Counter1 Overflow my_OVF0: reti ; Timer/Counter0 Overflow my_SPI: reti ; Serial Transfer Complete my_URXC: reti ; USART, Rx Complete my_UDRE: reti ; USART Data Register Empty my_UTXC: reti ; USART, Tx Complete my_ADCC: reti ; ; ADC Conversion Complete my_ERDY: reti ; ; EEPROM Ready my_ACI: reti ; Analog Comparator my_TWI: reti ; 2-wire Serial Interface my_SPMR: reti ; Store Program Memory Ready
В принципе... если у меня есть несколько вариантов на один вектор обработки и несколько подпрограмм требующих быстрого переключения... Тогда где-нибудь храню адреса тех подпрограмм а по точке вектора ставлю:
при этом надо позаботиться о предварительной загрузке прикладных адресов в Z регистр, что обеспечит возможность запуска нескольких вариантов подпрограмм для каждого из прерываний.
для аппаратной поддержки возможны и "обратные" варианты - когда основная таблица в бутлоадере, а "софтовая" в любом месте прикладной программы.
а мне нужен, как раз, аппаратный перенос таблицы векторов. ну вот смотри. записываем в МК бутлоадер. вся остальная память, начиная с нулевого адреса, до бутлоадера чистая. а мне нужно, чтобы работали прерывания, когда с нулевого адреса таблица не заполнена. к примеру, я пишу:
nachalo: ldi R26, 1<<IVCE out GICR, R26 ldi R26, 1<<IVSEL out GICR, R26
таким образом, я прописываю нужные вектора со смещением на начало и делаю перенос таблицы в область бутлоадера. ранее, когда я это пробовал сделать, видимо, я допустил какую-то ошибку и у меня не происходил перенос таблицы векторов. вчера вечером сделал тестовый текст, и тоже допустил, видимо, эту же ошибку, и у меня перенос не работал. а сейчас с утра нашел ошибку и исправил. и теперь у меня прекрасно работают прием и передача по новым векторам в области загрузчика. проверил - связь с компом теперь работает замечательно. правда, мне уже это не надо, так как я уже в загрузчике обошелся без прерываний и сделал программный анализ флага RXC на приеме и анализ флага UDRE при передаче. получилось, что я сам был виноват и зря тебя напрягал с вопросами. но все равно спасибо за потраченное на меня время.
_________________ Мудрость приходит вместе с импотенцией... Когда на русском форуме переходят на Вы, в реальной жизни начинают бить морду.
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
К сожалению я на АВРках с бутом и самопрограммированием пока не практиковался... Посему еще один нюанс упустил...
Касается он бит BLB02:01 и BLB12:11... Судя по документации той же меги8А с их помощью проводится защита от исполнения подпрограмм обслуживания прерываний, расположенных в "чужой" относительно основной таблицы прерываний области. Таблица векторов в области памяти целевой программы. Защита от доступа к целевой программе со стороны подпрограмм обработчиков прерываний, расположенных в области бутлоадера выполняют BLB12:11 Если защита включена, то адрес перехода, размещенный в таблице векторов которая находится в области адресов целевой программы, и указывающий на область бутлоадера будет игнорироваться т. е. подпрограмма - обработчик, размещенная в области бутлоадера и рассчитанная на исполнение как часть вызова из целевой программы не запустится.
Аналогично действуют и биты BLB02:01 — только по отношению бутлоадера. Если основная таблица в области бутлоадера и в ней адресован обработчик из области целевой программы то такой обработчик будет блокирован.
Однако... предполагаю что... Аппаратные средства отслеживают только адрес в основной таблице векторов... и то при его явном указании в команде (требует проверки вариант с IJMP вместо JMP addr).
Теоретически если в той же области, где расположена основная таблица сделать дополнительную таблицу-обманку и уже из нее вызывать «чужеродный» обработчик вполне вероятен вариант исполнения. "Подставной вектор" то уже будет "в своей" для защит области... Однако это предположение надо практическим тестом проверить... Пока в планах у меня такая проверка не стоит, но интересненько...
я про все локи уже давно прочитал в даташите. все твои дополнительные таблицы не являются аппаратными. все равно переходы на обработчики прерываний будут делаться из основной аппаратной таблицы. я вот что подумал, что при переходе из загрузчика в приложение сначала перемещенную таблицу нужно вернуть на свое место с нулевого адреса, а уж потом сделать переход на нулевой адрес.
_________________ Мудрость приходит вместе с импотенцией... Когда на русском форуме переходят на Вы, в реальной жизни начинают бить морду.
Вопрос как опознается блокировка. Т. Е. Какой базовый принцип. Ведь запрета на обращение к простым подпрограммами из "чужой области" блокировка не ставит. Иначе были бы блокированы и подпрограммы с вызывающим CALL/JMP ADR а в даташитах про то ни слова. Посему запрет блокировки касается только фиксированных ячеек области векторов прерываний. В других ячейках контроль адреса не проводится. Предположим, что при установленной защите в ячейке с вектором стоит адрес передачи управления в свою же область адресного пространства. Для системы защиты это разрешенный переход (и начало обработки прерывания)... А уже там стоит вторая переадресация "в запретную зону". Вот такой вариант в принципе вполне возможен. Проверку и без бутлоадера можно попробовать сделать... Чисто из " спортивна интересу"...
Прикупил жирну адуринку... mega2560 pro... Вроде бы и неплохая базовая платка -относительно малогабаритная... Только вот пригляделся - а на всего этого монстра с количеством под 70 линий ВСЕГО ТРИ КОНТАКТА "ОБЩИЙ"(GND)!!! https://img.radiokot.ru/files/20529/3eugnlk41u.jpg Как-то уж совсем неудобственно, особо при заявленном выходном токе стабилизаторов до 800мА... Для сигналов и силовых обратный проводок один (максимум два) на всю платку... ПЕЧАЛЬКА однако...
Так не факт, что на платке общий слой... Силовые и сигнальные что от источника питания, что от нагрузок/источников сигнала и все в один контакть... хотя бы еще парочку поставили... Силовые то можно и через "общий +" затянуть. Мне больше интерес был для подключения параллельного ОЗУ (23я серия похоже таки из области фантастики по местным условиям). Ну да и на том... сойдет... Все равно пока "на отлежку" в кащеев сундук.
А вот посмотрите,какая шняга интересная. https://forum.cxem.net/index.php?/topic ... nt=3938993 Можно же перенести прошивку (дизассемблировать,т.к исходника не дал) на другой МК ? например мега8 ? их у меня полно,а тини44 нет.
При наличии документации на те RW1990 можно под любой МК программу сделать... Да и в сети полно всяких самоделок на разных АВРкахи адуринах... Кстати... Для программирования далласов можно использовать аппаратную начинку DS2480... "... Supports 12V EPROM Programming and Stiff 5V Pullup for Crypto iButton, Sensors and EEPROM ..."
Карма: 1
Рейтинг сообщений: 60
Зарегистрирован: Ср сен 30, 2020 16:51:47 Сообщений: 4433 Откуда: РФ
Рейтинг сообщения:0
Доброго времени суток.
Накропал вот такой код для Ардуины:
#include <EEPROM.h>
int address = 0; // Переменная для хранения адреса byte value1 = B00001111; // Переменная для хранения значения 1 byte value2 = B10101010; // Переменная для хранения значения 2
void setup() { Serial.begin(115200);
EEPROM.put(address, value1); // Записать значение value1 в ячейку с адресом 0
address += 1; // Корректируем адрес
EEPROM.put(address, value2); // Записать значение value2 в ячейку с адресом 1
Так что положили, то и получили. Значения переменных как были так и остались Относительно "пропавших лидирующих нулей" - это особенности вывода на печать (функции обработчика перекодировки опции BIN, HEX в print) - аналогия гашения старших незначащих нулей на разнообразных индикаторах. Для контроля можете выставить HEX - хотя и там "лидирующий нуль" может не воспроизводиться если формат отличается от 0xNN.
Относительно "пропавших лидирующих нулей" - это особенности вывода на печать
Так это что, это он всегда будет и справа и слева в байте нули обрезать как ему вздумается? Но тогда ещё вопрос. Реальный код будет чтение из массива и запись байт в порты (У Ардуины 2560 можно байты сразу целиком в порты выводить) Я собираюсь потом этот прочитанный байт 00001111 в порт выводить, он мне его в порт как выведет? Где окажется младший бит если нулей нет?
Откуда взялись значения 127 и 191? Я ни разу не программист, но дело и не в программировании вовсе, я просто не понимаю как он всё это интерпретирует при выводе данных.
При печать старшие биты, равные 0, не отображаются. СпойлерМожете организовать собственный "правильной" печать. Код немного длинный, но все для теста. Напр.:
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 27
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
))...
