esaulenka

Можно придумать, как по-феншую сделать трюк типа `upd_bit(MY_REG).set(SET_MSK).clr(CLR.MSK)`. А ваша задача в исходном звучании не решается, имхо. Надо эти set() / clr() в общую область видимости выносить. Можете обернуть всё это в `namespace HwRegsWrapper { ... };` и в своих драйверах дописать `using namespace HwRegWrapper;`, тогда в остальных местах эти имена не будут мешаться.

Оу. А где можно ознакомиться с этими исследованиями? Или они ещё более секретные, чем это дополнительное ядро?

Мне кажется, этот форум - не лучшее место, чтобы публично заявлять "я не читаю документацию". Это стандартное поведение алгоритма запуска, называется "программная нейтраль". В большинстве моделей автовключение программной нейтрали (при поднятии ручника, подозреваю) можно отключить в настройках.

Мы тут с @Toxa555 чуть-чуть продвинулись с этим вопросом. Как минимум, читать он этот процессор умеет. Следующий вопрос - писать. Так вот, коллеги, у кого-нибудь есть опыт добавления нового процессора в J-Flash ? В их вики всё подробно написано - надо написать XML-ку с описанием процессора (это называется Device Support Kit) и скомпилировать ram-loader (это называется Segger Flash Loader). Загвоздка в том, что в стандартном комплекте никаких примеров нет, и для получения этого саппорт кит они предлагают написать в поддержку. Я нашёл, правда, какие-то loader'ы в комплекте segger SDK (когда-то старая версия пробегала здесь на форуме). Но xml-ок всё равно нету...

Вам не нужен "идентичный самсунг". Надо применить голову и из этого списка https://www.segger.com/supported-devices/search/samsung найти процессор с внутренней флешкой (в понимании сеггера. Прочерк в таблице означает внешнюю флешку), ядром ARM7 и одинаковыми адресами регистров контроллера флеш (IFC_xxx в терминах даташита). Э-э... где я это пропустил? Я не очень внимательно читал. В частности, мне лень там регистрироваться, и картинки мне не показывают. Но я не могу сказать, что действия автора правильные. В частности, он зачем-то пытался засунуть штатный бутлоадер как ram-code прошивальщика. Они оба, конечно, программы для процессора, даже называются одинаково "loader", но больше никаких схожих частей не имеют. Ну и привычка излагать непонятные вещи своими словами, в процессе преиначивая половину, тоже не сильно способствует пониманию... Да, у вас есть дамп от максимально похожего блока? Я бы посмотрел...

и что поменялось? 'error determining flash info' явно не будет ввиду отсутсвия такового запроса. Что "то же самое" ? "просто arm7" ничего никуда записать не может. И я не говорил "arm7", я говорил "samsung", это принципиально важно. Попробую чуть-чуть навести порядок в вашей голове. Читать из флеш просто - выставляем нужный адрес, забираем данные. Точно так же работает чтение и запись в ОЗУ. А вот для записи во флеш нужны определённые магические действия: прошивальщик записью в определённые регистры должен запустить стирание, потом подождать (проверяя готовность чтением регистра статуса), потом инициировать запись, скопировать кусок данных, и снова подождать (опять с проверкой готовности). Стандартный подход - создание небольшой программы специально для этого, которую прошивальщик заливает в ОЗУ контроллера, и дальше только "кормит" её данными. Последовательность этих "магических действий" у каждого производителя своя (часто и между моделями есть отличия). Ну попробуйте J-Mem ещё. Простейшая утилита, которая умеет только читать память, зато - любую, какую попросить. Можете ей посмотреть содержимое ОЗУ или периферийных регистров, например. А вообще говоря, правильно начинать с документации. Я вот полистал даташит и убедился, что флеш и ОЗУ включены всегда (эх, здравствуй 2006 год, камень примитивный совсем..). Т.е. оно ДОЛЖНО отдавать какие-то данные.

Ох... Ну зачем же _фото_ ?! Есть прекрасная кнопка PrintScreen (или, на win10, ещё более прекрасная Win-Shift-S). Быстро, удобно, и гораздо более читаемо. Подозрения подтверждаются - в Сеггере считают, что память там внешняя. Походу, они что-то напутали в самсунговской номенклатуре. Варианты действий: - попробовать снять галку "Automatically detect flash memory". Записать ничего не получится, но, возможно, даст прочитать. - попробовать выбрать другие процессоры в настройках. Попутно очень желательно сравнивать даташиты, чтоб там алгоритм записи (и соотв. регистры) соответствовали вашему процессору. Возможно, какой-то другой самсунг подойдёт. - вдумчиво покурить сеггеровские доки и написать загрузчик самостоятельно. Я так не делал, но вроде б это не запредельно сложно. - если вы платили Сеггеру деньги (ну, вдруг?), самое время написать в техподдержку 🙂 PS ссылка на даташит, если кому-то ещё будет интересно: https://www.datasheetarchive.com/datasheet?id=2342587efb1d49c7ec3feaee40e48b07fad5d9&type=P&term=s3f4a0k

Наоборот. Reserved и DataFlash по умолчанию недоступны. Хм. 32k RAM + 1M Flash. Странная пропорция, но автопроизводителям виднее, не зря ж они такой проц выпустили... У меня два предположения: - если у вас по-прежнему вот такая картинка, то, возможно, вам нужно поискать, кто мешает отладчику - кажется, судя по слову CFI, J-Flash пытается искать внешнюю флешку. Либо это следствие "универсальности" джейфлеша, либо Сеггер ошиблись с моделью процессора и по факту он не поддерживается. У меня сейчас под рукой джей-флеша нет, как там настройки для этого проца выглядят?

Уже хорошо. У меня почему-то подозрение, что вы пытаетесь читать внешнюю флешку. Давайте подробности - что у вас на плате (проц + внешняя SDRAM ?), как сконфигурирован J-Flash, какие конкретно ошибки при чтении? Я вижу, что отключена только data flash. Остальное, если верить даташиту, должно быть доступно.

Мой хрустальный шар подсказывает, что это кнопки для "запоминания" магической последовательности, и пользователь их должен нажимать примерно один раз в жизни устройства - когда меняет пульт. Насколько это надёжно работает - я не знаю. Скорее всего, не очень.

А у меня два монитора и несколько проектов, в каждом из которых по полсотни исходных файлов. Вы уж определитесь - у вас всё хорошо, или "куча варнингов, проблемы, я не понимаю". "приравнивается к единице" записывается как "var = 1;", а тут, с высокой вероятностью, написана ерунда. В вашем коде ДВА вызова eeprom_write_block. Найдите оба и сравните адреса, которые вы туда передаёте. Сравнить два массива. Ну ок. Вы даже читать не пытаетесь. Вопросов больше не имею.

Потому что заголовочный файл может include'иться в несколько .c файлов одновременно. Ваш подход приведёт к образованию нескольких копий переменных, и благоприятный исход всего этого - линкер при компиляции выдаст ошибку (неблагоприятный - накомпилирует чёрт знает что). Размер массива в байтах, в документации вполне явно написано. Ну и это не с++, компилятор не сможет узнать размер одного элемента. У вас, кстати, с этими eeprom read/write ещё одна ошибка. Надо указывать адреса так, чтобы они не перекрывались. Сейчас massive_open состоит из одного байта, принятого при открытии и "хвоста" из massive_close. Ещё одно "темное" место: if (button_open) { flag_button_open; } ... if (flag_button_open) { ... Что такое flag_button_open ? если это переменная типа bool, то что происходит в начале? И ещё. Что за магия с memccpy ? Вы точно хотите использовать это вместо обычного memcpy ?

Несколько замечаний. Сам алгоритм не пытался понять, чисто визуально. 1) вы не приложили main.h, в котором, подозреваю, определены переменные. В заголовочных файлах в 99% случаев нужно делать только объявления (declaration) с префиксом extern, а не определения (definition). Ваш подход приведёт к "непонятным" проблемам, если проект разрастётся до нескольких .c файлов. 2) в обработчике прерывания таймера вы записываете значения (не очень понятно, какие, ну да ладно) в массив без проверки значения 'i'. Это может закончится порчей памяти и очень странными ошибками. 3) eeprom_read_block, eeprom_write_block, memcmp в качестве последнего аргумента используют размер в байтах. 'unsigned int massive[10]' в случае AVR имеет размер 20 байт.

либо, как вариант, https://www.segger.com/supported-devices/infineon/fm3

Так бывает разве? Там весь обмен защищён какой-то примитивной контрольной суммой - бит чётности, что-ли. Т.е. при настабильной работе (скорость высокая, провода - метровая лапша, и т.д.) отладчик просто отваливается. Но я с ST-Link не очень много работал, может они "забыли" это реализовать.

Похоже на собственную реализацию SWD (хотя... мне кажется, программный SWD слейв сделать довольно сложно, там интерфейс тактируется отладчиком, и устройство как-то должно за ним успевать). Попробуйте Connect under Reset, или как оно у куба называется. В этом случае вы точно будете общаться с "оригинальным" SWD. Но в любом случае, как-то фантастически это всё звучит...

находится в porttimer.c находится в mbrtu.c находится в portevent.c Ни один из этих файлов в проект не включен. Какие пути вы проверяли? PS да, обратите внимание в каталоге port есть комплект файлов с суффиксами `_m`. У меня подозрение, что это для modbus master (без таковых - будет slave). В проект надо включать только один комплект, иначе будут новые ещё более "непонятные" сообщения линкера.

Когда-то давным-давно я использовал вышеупомянутый код Алекса для прошивки NRF52. А он его под Atmel'овские кортексы писал. Так что да, SWD довольно стандартный. Проблема, правда, в том, что SWD ногодрыгом получается довольно медленный. Я в итоге сделал микро-загрузчик, который SWD пишет в RAM, а вся основная прошивка передаётся по UART. Какая магия используется в JLink / STLink, я не разбирался.

Я тут мимопроходил, но википедия говорит, что Возможно, в этом была ваша проблема. А сами по себе симлинки в NTFS давно есть. Симлинки на каталоги появились в win2000, на файлы - в winxp.

Давайте всё-таки определимся, что такое "размер файла" ? Количество данных, которые там содержатся? Ваша магия на awk'е, кажется, должна корректно это считать. Но я плохо понимаю, зачем это нужно, поскольку из-за потенциальных "дырок" арифметика вида стартовый адрес + кол-во данных = конечный адрес здесь не работает. Этот топик вы начинали с вопроса "хочу найти конечный адрес". С применением удобных инструментов это решается очень просто: #!/usr/bin/env python import sys from intelhex import IntelHex ih = IntelHex(sys.argv[1]) print('min addr = %X, max addr = %X' % (ih.minaddr(), ih.maxaddr()))

Не надо так делать. Во-первых, в HEX файле некоторые строки - служебные, и содержат, например, адрес, с которого эта программа должна стартовать. Или наоборот, в hex-файле допустимы "дырки" в данных. Т.е. посчитать-то можно, но "простенький" код при изменении входных данных может внезапно сломаться, и выдавать ПОЧТИ правильный ответ.

Ну очевидно же, что оригинальный вопрос надо читать как "определить размер данных (макс. адрес) внутри хекс-файла". Можно, конечно, разобраться в формате hex и парсить его самостоятельно длинными регекспами, но в жизни есть и более интересные занятия. @VaTiKaNeTs, у вас на выбор два варианта. Можно внимательно прочитать доку к srec_cat, оно так точно умеет, я делал. Другой вопрос, что при малейшем изменении придётся её читать заново и всё переписывать, синтаксис сложных команд там совершенно нечеловеческий. Второй варинат - взять прекрасный питоновый модуль IntelHex, и написать два десятка строчек (из них половина - расчёт CRC).

Первое утверждение (что append() - это новый абзац) - из документации на QTextEdit. Второе, действительно, касается QPlain..., но в первом же ответе упоминается, что в обоих случаях поведение одинаковое. Чем поможет ваша ссылка, я, если честно, не понял. Один вызов append() добавляет один абзац. Ну да, это логично. Для добавления нескольких можно побить добавляемый текст символами '\n'. Тоже логично. Только к обсуждаемой "проблеме" отношения примерно никакого.

Согласно документации, append() 'appends a new paragraph to the end of the text edit'. Тут надо либо делать промежуточный обработчик "протокола" и выводить уже готовые склееные строки, либо применять магию для вывода: https://stackoverflow.com/questions/13559990/how-to-append-text-to-qplaintextedit-without-adding-newline-and-keep-scroll-at (я не пробовал, просто спросил у гугла).

Можно, конечно. И более новые тоже можно - активно денег они хотят только за всякий embedded. Нет, это и было, и остаётся нарушением GPL. Ну, если только вы не готовы выдавать ВСЕ исходники всем желающим - тогда можно.