const

Не очень мне нравится, но остановился на таком варианте: -J2,sum,1,,CODE,,,,,=0-3FF,{CODE} // при этом не считаются последние сегменты во флеш (<FAR_F> 1, INITTAB, NEAR_ID), что то 80 байт В коде extern void (__exit)(int); // как переменная не хотело объявляться extern uint16_t __flash __checksum; // хранится не в конце прошивки, а в начале uint16_t sz = ((uint16_t)__exit + 1) * 2; Разве, что способ подсчета КС поменяю.

Что бы не лить через загрузчик по CAN лишние кбайты. И что бы одна и та же прошивка для разных МК имела одну и туже КС (имею ввиду ATmeg-и, у них есть модели с объемом 32/64/128).

Вскрыл тему. Не дает покоя. Может ли в предложении «To sustain a voltage higher than Vdd +0.3, the internal pull-up and pull-down resistors must be disabled.», слово «sustain» переводиться как поддерживать, а невыдерживать. То есть, производитель предупреждает, что при таком варианте, напряжение на "пине" не будет равно 5В, так как образуется делитель (последовательный резистор к 5В - вход - резистор подтяжки к 3,3В) и итоговое напряжение будет меньше? Что бы понять о чем я - тему следует перечитать. Или все же это ТАБУ?

Для подытожить. Почитав ответы, идею "мягкого сброса" забросил. Потратил день для изучения участков «чужого» ПО и написал некие заглушки. Вышло неидеально, но для проверки сойдет 🤪 Далее новое ПО.

В IAR ARM тоже использую КС, настройки и функции для подсчета CRC32 брал с этого форума (тыц). Все ок. Но там я прописываю диапазон адресов для подсчета (с запасом). Хотя хотелось бы и там считать КС только для используемой памяти. Но надо было «прямо сейчас» поэтому не заморачивался. В IAR AVR читал такой раздел (файл прикрепляю) «Checksum calculation» - page 34 и «Descriptions of XLINK options» «-J» - page 50. Но все что смог «родить» (с некоторыми опциями): -J2,sum,1,,CODE,,,,, Если решения не найду, наверное, пойду таким путем. Строчку «-J2,sum,1,,CODE,,,,,» заменю на «-J2,sum,1,,CODE,,,,,={CODE}», тогда из подсчета КС выпадут пару областей (дома не установлен ИАР, могут быть неточности): таблица векторов, область «FILL» в начале, и еще пару областей в конце прошивки (таблицы инициализации и еще чот, там немного). Тогда конец подсчета КС будет совпадать с меткой __exit + 1. А области в начале прошивки можно исключить с помощью __section_size(название областей), по моему, в ИАР АВР как и в ИАР АРМ есть такой макрос (haker_fox подсказал в смежной теме). Если не так, там, вроде, есть еще какая-то метка, пропускающая первые области. Или добавить эти области в подсчет: "-J2,sum,1,,CODE,,,,,=0-FF,{CODE}" (FF - как пример, главное больше начальных областей, см. стр. 53 прикрепленного файла). Но хотелось бы узнать как в ПО получить адрес = «размер прошивки» - 1. Пока писал сообщение пришла еще идея, так как количество и название областей неизменно, можно с помощью __section_size добавить смещения до конца файла. Хотя вспоминаю, там есть «упакованные» области (название со спец символами) и их добавлять не получалось - выдавало ошибку. Еще надо попробовать. З.Ы. "-J2,sum,1,,CODE,,,,," - приведено как пример, для удобства проверки, после экспериментов будет использована другая КС. Забыл. to haker_fox. __checksum_begin и __checksum_end нету, есть какие-то CHECKSUM_START и CHECKSUM_END (стр. 52), но их ПО не видит( xlink.ENU.pdf

Привет Никак не могу найти в документации на ИАР как узнать адрес конца ПО откомпилированного. Например, контрольная сумма обозначается __checksum, начало ПО __program_start. Есть еще дата и время компиляции __DATA__, __TIME__. А как будет обозначаться конец ПО? Команда линкеру: -J2,sum,1,,CODE,,,,, Symbol Checksum Memory Start End Initial value ------ -------- ------ ----- --- ------------- __checksum 0xd551 CODE 00000000 - 000000E5 0x0000 (#0x0000) CODE 000000E8 - 00001E21 мне надо посчитать КС до адреса 1Е21 (при изменении ПО будет меняться), где его взять в ПО?

ОСи нет. Про стек я уже писал, кроме этого еще что то надо? И как проинициализировать стек, писать сразу в регисты или по адресу этих регистров? Решение временное, ПО будет переписываться. А пока оно тормозит проверку системы в целом. Наступание на "грабли" при проверки легко локализуется. Рассказывать про стеки вы будете или кому-то другому советуете?

Мне важно содержание регистров портов - их настройка и текущее состояние, оно не должно меняться при "мягком сбросе".

Еще появился вопрос. Можно ли "перезапустить" МК без дерганья RESET (в т.ч. NVIC_SystemReset()), что бы проинициализированные регистры не сбрасывать? Как бы начать программу с Reset_Handler без сброса. Только, как понимаю, придётся еще проинициализировать СТЕК.

Своему ничего не говорил. Не было необходимости. Пользуюсь тем, что было с IAR-ом. Так что размещает он по указу мне незнакомых людей. Да и ладно 🙂 Спасибо, разобрался.

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

вредные я и не слушаю. Кнопку, вроде, нашел.

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

не понял для чего макет. То есть, вы, считаете что если соеденить, например, 3.3В через резистор 1К с 12В, то напряжение 3.3В поднимится до 12В, а не через резистор потечет ток (12-3.3) мА, а напряжения останутся "при своих". Я так, уточнить, наверное мы о разных схемных решениях. З.Ы. Устройств уже около 200 и все они работают одинаково - 3.3В не растет, ток через защитные диоды течет. Все же думаю мы о разном, не можете вы так ошибаться.

не знаю работу какой схемы вы описываете, но если брать за основу мою, то в ней стоит не только диод но и резистор, который ограничивает ток. И если напряжение на таком входе будет выше чем 3.3В, то через этот резистор будет течь ток равный (3.3+Uдиод-Uвх)/R. И если устройство потребляет больше этого - никакого привышения не будет. Если же рассматривать вариант без резистора, а нечего его и рассматривать, смысла в такой схеме нет, разве что от статики, незнаю, без резистора никогда и не применял защитные диоды.