Всем привет! Может быть, это может быть перенесено в соответствующий раздел на форуме! Я только что познакомился с BluePill, и сейчас я мигрирую все свои личные проекты (AVR 8-бит) на руку! Одной из моих первых потребностей был очень маленький загрузчик, который я могу использовать в своих проектах. Попробовал STM32Duino Bootloader (спасибо, Роджер, за отличную работу над ним!), но мне нужно было что -то более простое, меньшее, без водителя и совместимо с последними инструментами GCC. Итак, я придумал этот маленький загрузчик: https: // github.com/bootsector/stm32-gid-bootloader Может, это может быть полезно для некоторых из вас, ребята! Ваше здоровье, сапоги

Интересный Можете ли вы ссылаться на программу, используемую для загрузки на этот загрузчик E.глин. Что такое спрятанный Пса. Я видел аналогичные загрузчики, которые перечисляют в качестве USB -хранилища, но также нуждаются в специальном загрузке. Однако они были намного больше, чем 1 тыс. Размер. Кроме того, в не связанной заметке я заметил тенденцию для компаний, которые теперь используют RAW HID для своих продуктов, потому что Windows не нужен специальный драйвер. Что ж, загрузчик DFU на самом деле не нуждается в установке DLL драйвера, все, что делает установщик, связывает драйвер DFU, который поставляется с Windows, которые будут связаны с PID USB VID Bootloader Но подход Microsoft только что переместил предполагаемую проблему не позволить неизвестным устройствам подключаться, и теперь все устройства маскируются под хранение HID или массовое хранилище, даже если они являются совершенно другим типом устройства

Источники Hid-Flash также включены в репо: https: // github.com/bootsector/stm32-hid ... Мастер/CLI Условие триггера для загрузчика USB HID вытягивает A8 Low во время запуска. Ваше здоровье, сапоги

И векторная таблица перенаправлена ​​на 0x8001000, как я вижу...

[Сжимать - Солнце 15 апреля 2018 г. 14:46] - И векторная таблица перенаправлена ​​на 0x8001000, как я вижу...

Правильный! Вот куда должна идти пользовательская программа, поэтому обязательно настройте свою векторную таблицу при использовании этого загрузчика. Bootloader берет первые три 1K Flash Pages. Еще одна 1K Flash -страница зарезервирована для данных конфигурации пользователя, при желании.

Таким образом, общий размер - 4K ? Но должно быть возможно изменить это, чтобы перейти к адресу существующего, используемый Libmaple, поскольку его начальный адрес Проверяет ли это, существует ли эскиз уже, и вспыхивать светодиод и т. Д., А затем прыгайте на эскиз через несколько секунд ? Поддерживает ли он блокировку в режиме загрузки HID с использованием резервных операций с аккумулятором ? Это просто позор в Windows, что серийный драйвер еще должен быть установлен

[Rogerclark - Солнце 15 апреля 2018 г. 9:24 вечера] - Таким образом, общий размер - 4K ?

Это правильно, я зарезервирую первый 4K для самого загрузчика, а также некоторое место для дополнительных данных конфигурации программы пользователя Но должно быть возможно изменить это, чтобы перейти к адресу существующего, используемый Libmaple, поскольку его начальный адрес Правильно, загрузчик может быть настроен на то, чтобы перейти на любой адрес флэш -адреса, который вы хотите! Проверяет ли это, существует ли эскиз уже, и вспыхивать светодиод и т. Д., А затем прыгайте на эскиз через несколько секунд ? Он просто переходит к определенному адресу программы пользователя, не проверяя ничего, если A8 не низкий, когда загрузчик работает. Поддерживает ли он блокировку в режиме загрузки HID с использованием резервных операций с аккумулятором ? Если загрузчик активируется путем управления A8 LILE во время запуска, прошивка будет в режиме HID USB, пока вручную не перезапущено или отключено. Это просто позор в Windows, что серийный драйвер еще должен быть установлен Я не уверен, что ты здесь имеешь в виду. Водители не должны быть установлены даже в Windows. Просто для ясности, это очень простой и простой загрузчик. Это очень хорошо подходит для моих вариантов использования, но это может быть бесполезно для других вариантов использования, хотя.

[Rogerclark - Солнце 15 апреля 2018 г. 9:24 вечера] - Это просто позор в Windows, что серийный драйвер еще должен быть установлен

Я думаю, что Роджер означает общую серийную функциональность USB. Только для загрузки кода этот загрузчик должен работать без драйверов. Я думаю, что никто на этом форуме не будет использовать/программа/отладка без сериала, но создание вещей для третьих лиц. Этот загрузчик будет от интереса.

[Мадиас - Солнце 15 апреля 2018 г. 22:09] -

[Rogerclark - Солнце 15 апреля 2018 г. 9:24 вечера] - Это просто позор в Windows, что серийный драйвер еще должен быть установлен

Я думаю, что Роджер означает общую серийную функциональность USB. Только для загрузки кода этот загрузчик должен работать без драйверов. Я думаю, что никто на этом форуме не будет использовать/программа/отладка без сериала, но создание вещей для третьих лиц. Этот загрузчик будет от интереса.

Gotcha! Да, серийная функциональность должна быть внутри пользовательской программы, и для этого потребуется драйвер Windows, конечно!

Мне очень нравится идея установки загрузчика без водителя, и это всего лишь 4K. Использование специальной программы для загрузки также в порядке, так как в настоящее время нам нужно использовать DFU-UTIL и вам нужны версии для каждой платформы. Я думаю, что должно быть легко взять код из загрузчика STM32Dunno, который проверяет, является ли вектор запуска программы, который вектор ОЗУ содержит реальные данные, а затем прыгайте после предопределенной задержки И провернуть светодиод в ожидании, а также сделать сброс USB -автобуса.. И все еще быть ниже 4K Также.. Как вы думаете, можно было бы собрать это для серии F4 Поскольку нам отчаянно нужен загрузчик или F4

Да, проверка действительного кода перед прыжком должна быть очень простой для реализации. Также могут быть реализованы дополнительные пользовательские команды, включая USB -сброс. Какая дешевая доска F4 вы рекомендуете? Я могу купить один и попытаться перенести загрузчик на него.

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

На этом форуме строится F4 Board: F4-Bluepill строится. Я заказал это (хорошо поддерживается здесь): https: // www.aliexpress.com/item/free-sh ... 84907.HTML

[Мадиас - Солнце 15 апреля 2018 г. 22:23] - На этом форуме строится F4 Board: F4-Bluepill строится. Я заказал это (хорошо поддерживается здесь): https: // www.aliexpress.com/item/free-sh ... 84907.HTML

Потрясающий! Спасибо! Я закажу один из тех. Это может потребоваться пару месяцев, чтобы приехать сюда в Бразилии, хотя...

Можете ли вы ссылаться на файлы f4 cmsis ?? Я клонирую репо и добавлю их и т. Д

[Rogerclark - Солнце 15 апреля 2018 г. 22:47] - Можете ли вы ссылаться на файлы f4 cmsis ?? Я клонирую репо и добавлю их и т. Д

Все должно быть в этом большом пакете ZIP: http: // www.ул.com/en/encedded-software/stm32cubef4.HTML (Прокрутите вниз до конца, пока вы не увидите синюю кнопку «Получить программное обеспечение»). РЕДАКТИРОВАТЬ: Глядя на справочное руководство, плата F4 использует совершенно другое периферийное устройство USB по сравнению с F1. Так что это должно быть скорее полностью переписываемое, чем прямой порт...

Ах. ХОРОШО. Это стыдно из-за того, что F4 нуждается в полном повторном записи. У нас такая же проблема на загрузчике STM32Duino, поскольку он даже не использует CMSIS, он просто управляет портами напрямую напрямую. Таким образом, изменение его на работу на F4 потребует много изменений. Вы рассмотрели использование libopencm3 ? Я думаю, возможно, результирующий бинар был намного больше

[сапоги - Солнце 15 апреля 2018 г., 21:51] - Это правильно, я зарезервирую первый 4K для самого загрузчика, а также некоторое место для дополнительных данных конфигурации программы пользователя

Вау, это один компактный загрузчик. Я видел еще одного загрузчика, который весил около 4 киб, но он широко использовал рукописную сборку везде, особенно для USB-стека. Я впечатлен. Как дружелюбное совет, я заметил, что вы используете USB-поставщик идентификатор поставщика F055, который, похоже, не назначается USB-IF. Не должно быть никаких проблем для личного использования, но в случае, если ваш проект станет значительным успехом и начинает противоречить какой -то будущей компании, которая использует это видео, вы можете получить специальную пару USB VID/PID PARE. А пид.коды Проект и OpenMoko Оба поддерживают бесплатные программы распределения PID USB для проектов оборудования/программного обеспечения/программного обеспечения с открытым исходным кодом. Я использовал пид.Коды ранее - это очень простой процесс для назначения PID.

[Мадиас - Солнце 15 апреля 2018 г. 22:21] - Беспорядка без водителя сделает еще одну вещь: Сценарий может быть на открытом воздухе или труднодоступным для внутреннего устройства, поэтому вы можете запрограммировать его на смартфон Android, способный OTG (я думаю, что все они - USB OTG) - это простой путь, не уравновешивая ноутбук на последнем этапе лестницы.

Не для того, чтобы не смягчить это обсуждение слишком много, но это на самом деле возможно, сегодня, используя Webusb. Если вы поместите обычный загрузчик STM32Duino в режим постоянного загрузчика, вы можете использовать мой демо загрузить а .Файл корзины через интерфейс DFU.

[Rogerclark - Солнце 15 апреля 2018 11:15] - Ах. ХОРОШО. Это стыдно из-за того, что F4 нуждается в полном повторном записи. У нас такая же проблема на загрузчике STM32Duino, поскольку он даже не использует CMSIS, он просто управляет портами напрямую напрямую. Таким образом, изменение его на работу на F4 потребует много изменений. Вы рассмотрели использование libopencm3 ? Я думаю, возможно, результирующий бинар был намного больше

Я не рассматривал возможность использовать какую -либо стороннюю библиотеку, так как я хотел изучить и использовать синюю таблетку, доступную периферийные устройства до уровня регистра, только используя CMSIS. F4 Регистрационные ссылки и константы, связанные с прерыванием, должны быть доступны в заголовке CMSIS, поэтому, если однажды я приду для загрузки для него, я также буду использовать только CMSIS.

[Деван - Солнце 15 апреля 2018 11:43] - Как дружелюбное совет, я заметил, что вы используете USB-поставщик идентификатор поставщика F055, который, похоже, не назначается USB-IF. Не должно быть никаких проблем для личного использования, но в случае, если ваш проект станет значительным успехом и начинает противоречить какой -то будущей компании, которая использует это видео, вы можете получить специальную пару USB VID/PID PARE.

Спасибо за совет! Я обязательно зарегистрируюсь на пид! 0xf055 была неудачной попыткой сделать доступным видео для проектов с открытым исходным кодом в прошлом. Похоже, есть люди, пытающиеся оживить его здесь https: // f055.io/ РЕДАКТИРОВАТЬ: только что создал PR: https: // github.com/pidcodes/pidcodes.глин ... м/тяга/320

Я просто разделил ваш репо и попытался скомпилироваться, но похоже, что он может работать только с более новыми версиями GCC Можете ли вы сказать мне, какую версию вы используете, поскольку я получаю проблемы с компиляцией с ошибками C99, которые я решил, но теперь она не распознает ASM как команду.

[Rogerclark - Пн, 16 апреля 2018 г. 10:17] - Я просто разделил ваш репо и попытался скомпилироваться, но похоже, что он может работать только с более новыми версиями GCC Можете ли вы сказать мне, какую версию вы используете, поскольку я получаю проблемы с компиляцией с ошибками C99, которые я решил, но теперь она не распознает ASM как команду.

Я использую GCC-ARM-None-EABI-7-2017-Q4-MAJOR-MAC.смол.BZ2 Я на самом деле не тестировал со старыми инструментами. Я сделаю это и сделаю необходимые корректировки, чтобы они работали со старыми инструментами, когда у меня есть шанс.

ХОРОШО Не беспокойся Я попробовал с 4.8 Я думаю, что у меня установлены другие новые версии, но не на моем пути Не уверен, почему он не принимает команды ASM, возможно, чего -то не хватает в CFLAGS Я проверю

Я сделал несколько изменений и получил его для компиляции с GCC 4.8 Мне нужно было заменить ASM __asm__ А также команда линкера -WL,-печатная память не поддерживалась, поэтому я прокомментировал это Размер файла бина составляет 2988 байтов Насколько велик ваш корзин (PS еще не попробовал, вероятно, не будет времени сегодня вечером, чтобы проверить его) КСТАТИ. Я должен был добавить Cflags += -std = c99 Также, чтобы заставить его компилировать с GCC 4.8

КСТАТИ. Одна вещь, которую я заметил в вашем коде, - это прыжок в пользовательскую программу Я помню, что у этого были проблемы в загрузчике STM32Duino в некоторых версиях GCC Очевидно, что это сработало для вас, но я вспоминаю что -то гораздо более сложное, необходимое для других версий компилятора (хотя я не могу вспомнить точные детали)

Потрясающий! Я проверю сгенерированный размер кода, но я помню, что он также стал ниже 3000 байтов. Если возможно, попробуйте добавить -Std = gnu99 вместо простого C99, поскольку расширение GNU имеет некоторые дополнительные функции. Из того, что я прочитал о прыжке пользовательской программы, вам нужно убедиться, что ассемблер не генерируется поп. Чтобы проверить это, вы можете выпустить Make Main.s и увидеть сгенерированный код ассемблера.

Кроме того, убедитесь, что петля NOP генерируется внутри основного.S, в противном случае внутренний подтягивание может не быть поднято к тому времени, когда мы проверяем A8 на низкий уровень, прежде чем вступить в HID USB -режим.

Спасибо Я проверю завтра Пса. Вы можете добавить двоичные файлы Windows и т. Д. на GitHub, часто люди просто хотят установить и использовать загрузчик, но не скомпилируйте его. Так что поместите корзину загрузчика в GitHub

И, пожалуйста, поделитесь на GTIHUB, а также инструменты (HID-Flash) также.

Coolio! Сегодня вечером я опубликую релиз двоичных файлов на GitHub!

Это статистика компиляции загрузчика с использованием GCC-Arm-None-EAB-7-2017-Q4-Major Toolchain: Memory region Used Size Region Size %age Used RAM: 2760 B 20 KB 13.48% FLASH: 2920 B 64 KB 4.46%

Это очень мило!! Я думаю, что это показывает хороший потенциал, который будет использоваться в качестве компактного загрузчика общего назначения. Я только что провел свой обеденный час, проверяя его на Linux, и мой заблокированный Win7 Work PC. Я смог загрузить проста, контролируемый таймером, без необходимости без необходимости особых разрешений или водителей. Пара комментариев, хотя

1. Когда PA8 высокий, устройство все еще появляется в виде USB -устройства (неизвестно в Windows) и генерирует ошибки на Linux (невозможно перечислить USB -устройство). Я думаю, было бы лучше не выглядеть как устройство.
2. Я думаю, что в дескрипторе отсутствует строковое поле. На Linux I Get (строка дескриптор 0 Ошибка чтения: -22) Когда PA8 низкий

Я не могу комментировать скорость, так как я загружал только двоичный бинар 1100 байтов. Когда у меня появится шанс, я, конечно, хочу взглянуть на код, чтобы увидеть, как вы его реализовали. Эрик

[Эггсила - Пн, 16 апреля 2018 г., 19:16] - [*] Когда PA8 высокий, устройство все еще появляется в виде USB -устройства (неизвестно в Windows) и генерирует ошибки на Linux (невозможно перечислить USB -устройство). Я думаю, было бы лучше не выглядеть как устройство.

Если вы используете синюю таблетку, убедитесь, что ваша пользовательская программа вызывает usb_shutdown () (из USB.c) Как первое, иначе Windows попытается перечислять доску, поскольку у нее есть подтягивающий резистор на A12. Это необходимо, если ваша пользовательская программа не реализует USB -устройство. [*] Я думаю, что в дескрипторе отсутствует строковое поле. На Linux I Get (строка дескриптор 0 Ошибка чтения: -22) Когда PA8 низкий Я посмотрю на это. Вы прошивали прошивку под Linux? РЕДАКТИРОВАТЬ: Вам не обязательно вызовать usb_shutdown (), чтобы деактивировать USB в своей программе, если вы не используете его. Вы можете просто настроить A12 как выход и привести к нему низко. Это не связано не с загрузчиком, а с чертежом, который всегда включен USB с помощью физического резистора подтягивания.

Я думаю, было бы лучше, если бы вам не нужно было использовать внешний вывод, чтобы заставить в режим загрузчика в режиме загрузчика. Тайм -аут лучше. Также используйте регистр ОЗУ с аккумулятором, чтобы заблокировать загрузчик в режиме загрузки после составления сброса из прикладной программы, будет хорошим.

[Rogerclark - Пн, 16 апреля 2018 г., 21:04] - Я думаю, было бы лучше, если бы вам не нужно было использовать внешний вывод, чтобы заставить в режим загрузчика в режиме загрузчика. Тайм -аут лучше. Также используйте регистр ОЗУ с аккумулятором, чтобы заблокировать загрузчик в режиме загрузки после составления сброса из прикладной программы, будет хорошим.

Тайм -аут мешает мои варианты использования, и внешний булавка работает лучше всего для меня. Я мог бы работать в настраиваемой опции внутри Makefile, чтобы позволить пользователю выбрать, как перейти в режим HID USB в будущем. Я выпустил бинарную версию: https: // github.com/bootsector/stm32-hid ... R/выпуски @eggsylah Я обновил прошивку, поэтому теперь она должна правильно вернуть дескриптор строки 0 (LANG ID) в вашем поле Linux. Дайте мне знать, если иначе. Ваше здоровье, сапоги

Спасибо Я обновил вашу последнюю версию, и ошибка строки исчезла. Я также последовал вашему совету о PA12, и это остановило USB -ошибки, которые я видел в Linux и неизвестном устройстве в Windows. Так что это хорошо выглядит на моей стороне. Да, я использовал Linux и обычную плату Bluepill.Роджер, Я думаю, что идея состоит в том, чтобы увидеть, стоит ли этот подход, а затем попытаться подражать, как работает текущий загрузчик (например, тайм -аут и все другие функции). Я хотел бы посмотреть, смогу ли я заставить это работать на моей плате L462 Blue Pills Эрик

ХОРОШО Я вытащу последние изменения, а затем исследую добавление тайм -аута, а не использую внешний PIN -код. Я также изменил источник, чтобы он собирал и ссылается на более старые версии GCC E.G версия, используемая Arduino IDE Несмотря на то, что отходы Flash, я изначально установите адрес начала приложения в местоположение 8K, чтобы соответствовать лучшему загрузчику на основе Libmaple (STM32Duino)

Я выпустил новую версию, которая в стороне от проверки на A8 как низкая, альтернативно, она также проверит на Jumper Boot1 как 1. Таким образом, поддержание Boot0 как 0 (по умолчанию) и Jumper Boot1 As 1, USB HID Bootloader будет начнется. Я думаю, что это хорошее дополнение для синей таблетки, так как перемычка уже есть, чтобы использовать! https: // github.com/bootsector/stm32-hid ... S/Tag/v1.1

@bootsector Отличная работа ! Отличная работа. Я немного изменил ваш исходный код, чтобы работать с Arduino IDE Метод загрузки: загрузчик STM32Duino на Bluepill STM32F103C8 Для тех, кто хочет попробовать этот загрузчик HID:

1. Сжечь чертеж с помощью прикрепленного загрузчика HID (Hidbootloader.бин файл).
2. Выберите Метод загрузки: загрузчик STM32Duino от Arduino IDE
3. Скомпилируйте свой эскиз
4. Найдите, где ваш составлен .Файл корзины существует (например: мигание.Ино.корзин) и скопируйте его в ту же папку, где спрятанный.Exe существует
5. Подключите PA8 к GND и перезагрузите чертеж.
6. Выполнить следующую команду CLI hid-flash.exe blank-config.bin Blink.ino.bin

Я нахожу это действительно возможным, только если мне не нужно связываться с дополнительной настройкой PIN (PA8 в GND, а затем выпустите). Так что для меня это должно быть в состоянии автоматически: - Получите «волшебную последовательность» для перезагрузки в загрузчике (или дождитесь ее некоторое время после сброса) - прошить новое программное обеспечение и - запустить недавно вспыхнутую SW как текущий загрузчик STM32Duino Bootloader. С нетерпением жду возможности протестировать такую ​​версию. РЕДАКТИРОВАТЬ Я думаю, что нам нужна дополнительная запись под «загрузчиками и ядрами», чтобы переместить эту тему.

[Стивестронг - Вт 17 апреля 2018 г. 8:31] - Я нахожу это действительно возможным, только если мне не нужно связываться с дополнительной настройкой PIN (PA8 в GND, а затем выпустите). Так что для меня это должно быть в состоянии автоматически: - Получите «волшебную последовательность» для перезагрузки в загрузчике (или дождитесь ее некоторое время после сброса) - прошить новое программное обеспечение и - запустить недавно вспыхнутую SW как текущий загрузчик STM32Duino Bootloader. С нетерпением жду возможности протестировать такую ​​версию.

Стив Я уже опубликовал то же требование Кроме того

Я думаю, что нам нужна дополнительная запись под «загрузчиками и ядрами», чтобы переместить эту тему.

[Стивестронг - Вт 17 апреля 2018 г. 8:31] - Я нахожу это действительно возможным, только если мне не нужно связываться с дополнительной настройкой PIN (PA8 в GND, а затем выпустите). Так что для меня это должно быть в состоянии автоматически: - Получите «волшебную последовательность» для перезагрузки в загрузчике (или дождитесь ее некоторое время после сброса) - прошить новое программное обеспечение и - запустить недавно вспыхнутую SW как текущий загрузчик STM32Duino Bootloader. С нетерпением жду возможности протестировать такую ​​версию. РЕДАКТИРОВАТЬ Я думаю, что нам нужна дополнительная запись под «загрузчиками и ядрами», чтобы переместить эту тему.

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

Ниже должны быть необходимые шаги, чтобы получить автоматическую функцию прыжка с кода пользователя: - Добавьте флаг, который сообщает Bootloader, чтобы прыгнуть в код пользователя (первоначально устанавливается как False) - Установите таймер ISR, который установит флаг прыжка с кода пользователя как TRUE через X секунды, и не получила пользовательскую команду USB (для этого требуется другой флаг) - Активировать USB Hid - Добавить новую пользовательскую команду (я.эн., {'B', 't', 'l', 'd', 'c', 'm', 'd', 0x01}), который установит флаг прыжка кода пользователя как истинное - Изменить hidusb_handledata (), поэтому он обновляет пользовательский флаг полученного команды, используемый Timer Interrupt ISR - Основной цикл должен опросить на флаг прыжка кода пользователя - Прежде чем прыгнуть в код пользователя, позвоните USB_SHUTDOWN () из USB.C и выключить таймер На стороне CLI: - Отправить новую пользовательскую команду после завершения мигания Я уйду в сообщество, чтобы попробовать. Если это займет слишком много времени, и никто ничего не придумает, я буду реализовать это.

[Стивестронг - Вт 17 апреля 2018 г. 8:31] - Я нахожу это действительно возможным, только если мне не нужно связываться с дополнительной настройкой PIN (PA8 в GND, а затем выпустите). Так что для меня это должно быть в состоянии автоматически: - Получите «волшебную последовательность» для перезагрузки в загрузчике (или дождитесь ее некоторое время после сброса) - прошить новое программное обеспечение и - запустить недавно вспыхнутую SW как текущий загрузчик STM32Duino Bootloader. С нетерпением жду возможности протестировать такую ​​версию. РЕДАКТИРОВАТЬ Я думаю, что нам нужна дополнительная запись под «загрузчиками и ядрами», чтобы переместить эту тему.

Bootsector уже добавил поддержку для проверки PIN -кода Boot1 вместо A8, я думаю, что это охватывает первую точку в списке, по крайней мере для плат с прыгунами, и основная функция, которая перезагружается с последовательности DTR и 1EAF, все еще должны работать с этим Bootloder. Я думаю, что добавление опции остаться в загрузчике на неопределенный срок, если а) нет эскиза, или б) в регистре резервного копирования есть волшебное слово. Изменение кнопки на любой другой штифт должен быть прямым изменением. Первоначально клено загрузчик включал только код для исходной кнопки, а Роджер добавил поддержку для других с макросами во время компиляции. Скорее всего, то же самое можно сделать здесь без увеличения размера эскизов. Мигает светодиод, как предложил Роджер, станет хорошим визуальным сигналом о том, что делает загрузчик. Интересно, если все это останется ниже 3 кб. Еще одна вещь, которая была бы хорошей, - это добавление поддержки для других размеров страниц, поэтому ее можно использовать со всеми MCU F1, и, возможно, позже с F4, которые включают в себя несколько размеров страниц в одном и том же устройстве. Кстати, очень интересный проект и спасибо Bootsector за то, что он поделился им.

Правильно, «волшебная последовательность» для перезагрузки реализована во время выполнения с Libmaple, Bootloader не имеет к этому никакого отношения. Возможно, «волшебная последовательность» написать что -то в флаге памяти, указывающий, что загрузчик будет активирован после сброса. Таким образом, активация загрузчика может быть сделана одним из этих условий: 1. Применение сигнала в загрузке 1 или любой другой вывод, 2. флагом памяти 3. В случае пустой вспышки или плохой CRC программы. С помощью этой операции можно программировать и авторерезировать плату, с или без дополнительного провода или кнопки.В конце концов, если размер загрузчика остается ниже предела 4K, можно дать 4K больше места в программе, перемещая векторы сброса в 0x8001000

Я думаю, что в ядре уже есть какой -то код, чтобы написать «волшебную последовательность» где -то, я помню, как я видел обсуждения на форуме об этом, поэтому нам просто нужен загрузчик, чтобы проверить это. Я думаю, что большинство запрашиваемых изменений могут быть перенесены прямо из нашего загрузчика (проверяя волшебное слово, проверяя, загружается ли что -то, напоминающее эскиз, и мигает штифт)

Я не вижу ничего для написания в последовательности сброса в USB_SERIAL.C код (функция rxhook, imo, не очень хороший кусок кода) Я уверен, что @rogerclark может ответить на это.

Я работаю над этим загрузчиком HID для добавления «волшебной последовательности» и сигнала DTR. Я почти сделал это.

Обнаружение магической последовательности определенно в ядре, но я не могу вспомнить, где оно. Однако в настоящее время ядро ​​не устанавливает магическое число в DR10.Maple Bootloader (STM32BootLoader) уже проверяет на DR10 и будет удерживать загрузчик, если номер магии найден. Я хотел добавить магическое число в DR10 в ядро, но я помню, как некоторые люди возражали против этого, но я не могу вспомнить, почему. IMHO это сделало бы вещи намного лучше, так как мы могли бы почти покончить со временем ожидания загрузчика. Я также предложил, что использование Boot1 - булавка кнопки для BluePill, как это было реализовано на этом загрузчике, но опять же, была множество возражений (опять же, я не могу вспомнить, почему) Возможно, должно быть меньше потворствовать небольшим меньшинствам и просто внедрить оба изменения.

[Вассилис - Вт 17 апреля 2018 г., 17:13] - Я работаю над этим загрузчиком HID для добавления «волшебной последовательности» и сигнала DTR. Я почти сделал это.

Это не проверено: /* * STM32 HID Bootloader - USB HID bootloader for STM32F10X * Copyright (c) 2018 Bruno Freitas - * * This program is free software: you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation, either version 3 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program. If not, see . */ #include #include "usb.h" #include "hid.h" #include "bitwise.h" // HID Bootloader takes 3K. 1K of config flash follows it. #define USER_PROGRAM 0x08001000 typedef void (*funct_ptr)(void); uint16_t get_and_clear_magic_word() { bit_set(RCC->APB1ENR, RCC_APB1ENR_BKPEN | RCC_APB1ENR_PWREN); uint16_t value = BKP->DR10; if(value) { bit_set(PWR->CR, PWR_CR_DBP); BKP->DR10 = 0x0000; bit_clear(PWR->CR, PWR_CR_DBP); } bit_clear(RCC->APB1ENR, RCC_APB1ENR_BKPEN | RCC_APB1ENR_PWREN); return value; } int main() { uint32_t userProgramAddress = *(volatile uint32_t *)(USER_PROGRAM + 0x04); funct_ptr userProgram = (funct_ptr) userProgramAddress; // Turn GPIOA clock on bit_set(RCC->APB2ENR, RCC_APB2ENR_IOPAEN); // Set A8 as Input Mode with Pull-ups bit_clear(GPIOA->CRH, GPIO_CRH_MODE8); bit_clear(GPIOA->CRH, GPIO_CRH_CNF8_0); bit_set(GPIOA->CRH, GPIO_CRH_CNF8_1); bit_set(GPIOA->ODR, GPIO_ODR_ODR8); // Turn GPIOB clock on bit_set(RCC->APB2ENR, RCC_APB2ENR_IOPBEN); // Set B2 as Input Mode Floating bit_clear(GPIOB->CRL, GPIO_CRL_MODE2); bit_set(GPIOB->CRL, GPIO_CRL_CNF2_0); bit_clear(GPIOB->CRL, GPIO_CRL_CNF2_1); // Wait 1uS so the pull-up settles... for(int i = 0; i < 72; i++) { asm volatile ("nop\n"); } // If A8 is LOW or B2 is HIGH enter HID bootloader... if((!(GPIOA->IDR & GPIO_IDR_IDR8)) || (GPIOB->IDR & GPIO_IDR_IDR2) || (get_and_clear_magic_word() == 0x424C)) { USB_Init(HIDUSB_EPHandler, HIDUSB_Reset); for(;;); } // Set A8 to input floating bit_clear(GPIOA->CRH, GPIO_CRH_MODE8); bit_set(GPIOA->CRH, GPIO_CRH_CNF8_0); bit_clear(GPIOA->CRH, GPIO_CRH_CNF8_1); bit_clear(GPIOA->ODR, GPIO_ODR_ODR8); // Turn GPIOA clock off bit_clear(RCC->APB2ENR, RCC_APB2ENR_IOPAEN); // Turn GPIOB clock off bit_clear(RCC->APB2ENR, RCC_APB2ENR_IOPBEN); SCB->VTOR = USER_PROGRAM; asm volatile("msr msp, %0"::"g"(*(volatile u32 *) USER_PROGRAM)); userProgram(); for(;;); }

Спасибо... Я думаю, что мое время, которое добавлено и время ожидания, будет добавлено, 4K будет реалистичным размером. Который по -прежнему вдвое меньше загрузчика DFU.

Можем ли мы оставить очистку волшебного слова до сердечника, а не загрузчика? Этот раздел if(value) { bit_set(PWR->CR, PWR_CR_DBP); BKP->DR10 = 0x0000; bit_clear(PWR->CR, PWR_CR_DBP); }

Я согласен, что мы не должны очищать волшебное (наполовину) слово изнутри загрузчика. Так что функция получит как: uint16_t get_magic_word() { bit_set(RCC->APB1ENR, RCC_APB1ENR_BKPEN | RCC_APB1ENR_PWREN); uint16_t value = BKP->DR10; bit_clear(RCC->APB1ENR, RCC_APB1ENR_BKPEN | RCC_APB1ENR_PWREN); return value; }

Да. Реестр используется только потому, что он переживает мягкий сброс Если питание удаляется, регистр стерт

Это был я (по крайней мере, один из тех), которым не нравится проверка булавки в загрузчике. Причина проста: у BP не так много контактов, приложение может использовать все доступные выводы, чтобы PA8 (или PB2 AKA Boot1) может быть жестко. Потягивающий резистор на этих булавках введет в заблуждение загрузчика. Я думаю, что в их приложении будет много пользователей, из -за того, что наброски не работают, аналогично выводам отладки...

Стив Я понимаю ваши проблемы, но я не уверен, сколько людей будет использовать булавку Boot1 на синей таблетке. Все булавки на стороне АД и, возможно, булавки СВД, но я был бы удивлен, если многие люди используют Boot1 Я думаю, что Maple Mini использует Boot1 для своей кнопки, так что он также был бы совместимы с этим и с этим.

Я использую PB2 для ЖК -проектов (16 -битный параллель), чтобы я мог привлечь туда-вверх вниз, чтобы избежать какой -либо проблемы. Если можно согласиться с Boot1, то PA8 можно оставить, сохранив пару байтов в Flash.

Я думаю, что нет необходимости иметь кнопку вообще, если используется тайм -аут. Но проблема в одной системе e.глин. MAC Тайм-аут должен быть очень долго, чтобы гарантировать загрузку, так как USB, похоже, занимает много времени для повторного выхода

[Стивестронг - Ср 18 апреля 2018 г., 5:33 утра] - Я использую PB2 для ЖК -проектов (16 -битный параллель), чтобы я мог привлечь туда-вверх вниз, чтобы избежать какой -либо проблемы. Если можно согласиться с Boot1, то PA8 можно оставить, сохранив пару байтов в Flash.

Я думаю, что разумно держать только проверку выводов B2 (Boot1) (High) на данный момент. Я удаляю проверку PIN -кода A8.

HID Bootloader прогрессирует до сих пор:

• Добавил дополнительное меню в Arduino IDE (STM32F103C8 вариант): Метод загрузки: HID Bootloader [Сделанный]
• Внесли все модификации в доски.текст и платформа.текст Файлы для использования нового загрузчика HID [выполнен].
• Arduino IDE отправляет DTR, сигналы RTS и магическую последовательность 1EAF на STM32 [DOD]
• Если последовательность верна, STM32 перезагружается в Bootloader [DOD]
• Он остается там на некоторое время. Если загрузка завершена или происходит тайм -аут, STM32 прыгает на код пользователя [выполнено]
• Также внесли необходимые изменения в файл CLI (hid_flash.в)

Я также использовал, резюме с аккумулятором для более быстрого включения в Bluepill. Мне нужно сделать еще несколько тестов, а затем я отправлю запрос

Круто, Вассилис, с нетерпением жду возможности проверить это.

Очень круто... Я кратко рассмотрел код, чтобы увидеть, насколько легко он будет изменен, но CMSIS едва ли выше доступа к уровню аппаратного обеспечения и нуждается в подробном понимании битов в каждом регистре управления Интересно, как тяжело было бы портить на F4. Но я суспензирую, это не так просто.

[Rogerclark - Ср 18 апреля 2018 г., 21:28] - Очень круто... Я кратко рассмотрел код, чтобы увидеть, насколько легко он будет изменен, но CMSIS едва ли выше доступа к уровню аппаратного обеспечения и нуждается в подробном понимании битов в каждом регистре управления Интересно, как тяжело было бы портить на F4. Но я суспензирую, это не так просто.

CMSIS довольно прост, если вы следовали программам/справочным руководствам и, лично, я думаю, что это работает лучше, чем использование библиотеки более высокого уровня. Я приехал из мира Arduino/Libraries, а затем запрограммировал немного голого металла AVR, и теперь я действительно хорошо провожу время и получаю удовольствие, написав свои собственные библиотеки устройств на STM32, используя CMSI и имея ST технические документы в качестве ссылки. Как только мы выясним интерфейс аппаратного обеспечения USB F4, все остальное должно быть довольно простым.

Я понимаю, как программировать регистры напрямую. Я просто не знаком с определениями, используемыми CMSIS. Поэтому я продолжаю ссылаться на значения шестигранника в определении, а затем преобразовывать их в двоичный файл, а затем смотреть на руководство по программированию, чтобы определить, что это будет делать. Это еще один API, чтобы узнать.

Только что купил эту доску на основе F4: https: // www.eBay.com/itm/311702413371 Надеюсь, он начнется менее чем за 3 месяца! Не могу дождаться, чтобы поиграть со своим интерфейсом USB/OTG на основе FIFO!

[сапоги - Ср 18 апреля 2018 г., 23:29] - Только что купил эту доску на основе F4: https: // www.eBay.com/itm/311702413371 Надеюсь, он начнется менее чем за 3 месяца! Не могу дождаться, чтобы поиграть со своим интерфейсом USB/OTG на основе FIFO!

прохладный

Модифицированный загрузчик в настоящее время составляет 3176 байтов. Я вижу, что намерение состоит в том, чтобы поддерживать загрузчик до 3 КБ и раздел пользователя Flash до 1KB. Новый загрузчик, вероятно, может быть оптимизирован, но и тогда он будет близок к 3KB. Итак, я хотел бы спросить: - Действительно ли нам нужен 1 КБ в разделе пользовательской вспышки (я полагаю, что @bootsector По какой -то причине используйте раздел пользовательской вспышки) ? Было бы лучше, если бы мы могли бы использовать весь 4 КБ только для прошивки загрузчика (и его будущие обновления). Конечно, мы могли бы использовать первые 4 кб для загрузчика и следующее 1 кб для раздела пользователя Flash, если это необходимо. Я говорю это теоретически.Другая проблема заключается в том, что пустой конфиг.бин Файл перезаписывается каждый раз, когда мы пропускаем STM32 с новой прошивкой (эскиз). Как вы думаете об этих вопросах ?

IMHO область конфигурации имеет не слишком большой смысл, я могу жить без нее.

[Вассилис - Чт 19 апреля 2018 г. 18:06] - Модифицированный загрузчик в настоящее время составляет 3176 байтов. Я вижу, что намерение состоит в том, чтобы поддерживать загрузчик до 3 КБ и раздел пользователя Flash до 1KB. Новый загрузчик, вероятно, может быть оптимизирован, но и тогда он будет близок к 3KB. Итак, я хотел бы спросить: - Действительно ли нам нужен 1 КБ в разделе пользовательской вспышки (я полагаю, что @bootsector По какой -то причине используйте раздел пользовательской вспышки) ? Было бы лучше, если бы мы могли бы использовать весь 4 КБ только для прошивки загрузчика (и его будущие обновления). Конечно, мы могли бы использовать первые 4 кб для загрузчика и следующее 1 кб для раздела пользователя Flash, если это необходимо. Я говорю это теоретически. Другая проблема заключается в том, что пустой конфиг.бин Файл перезаписывается каждый раз, когда мы пропускаем STM32 с новой прошивкой (эскиз). Как вы думаете об этих вопросах ?

Область конфигурации используется в одном из моих проектов. Я думаю, что это будет иметь смысл, что он удален из широкой общедоступной прошивки, которую я выпустил. Я тоже удалю это из этого. Ваше здоровье.

ОК. Тогда. Я удалю область конфигурации.

Немного не по теме, но я только что изменил загрузчик Blue Pill Bootloader, чтобы использовать PIN -код Boot1 для блокировки в режиме DFU. Мне нужно было изменить несколько вещей, так как резисторы с подтягиванием на перепрыгивающих ссылках слабее, чем внутреннее притяжение, которое было включено по умолчанию в загрузчике STM32Duino, но я добавил еще один #Define, чтобы каждый вариант мог указать, какой режим ввода он хочет.глин. (Обычно вытягивает или нормальный вход) Я сделаю сообщение об генерале / объявлениях

@Роджер Я отправил вам запрос на привлечение HID Bootloader (https: // github.com/rogerclarkmelbourne/ ... 2/pull/504) Единственный основной файл, который я изменил, - это usb_serial.CPP. Я добавил 4 строки кода ... #ifdef SERIAL_USB // Got the magic sequence -> reset, presumably into the bootloader. // Return address is wait_reset, but we must set the thumb bit. bkp_init(); <------------------------ (1) bkp_enable_writes(); <------------------------ (2) bkp_write(10, 0x424C); <------------------------ (3) bkp_disable_writes(); <------------------------ (4) uintptr_t target = (uintptr_t)wait_reset | 0x1; asm volatile("mov r0, %[stack_top] \n\t" // Reset stack "mov sp, r0 \n\t" "mov r0, #1 \n\t" "mov r1, %[target_addr] \n\t" "mov r2, %[cpsr] \n\t" "push {r2} \n\t" // Fake xPSR "push {r1} \n\t" // PC target addr "push {r0} \n\t" // Fake LR ...

[Rogerclark - Пт 20 апреля 2018 г. 11:08] - Немного не по теме, но я только что изменил загрузчик Blue Pill Bootloader, чтобы использовать PIN -код Boot1 для блокировки в режиме DFU. Мне нужно было изменить несколько вещей, так как резисторы с подтягиванием на перепрыгивающих ссылках слабее, чем внутреннее притяжение, которое было включено по умолчанию в загрузчике STM32Duino, но я добавил еще один #Define, чтобы каждый вариант мог указать, какой режим ввода он хочет.глин. (Обычно вытягивает или нормальный вход) Я сделаю сообщение об генерале / объявлениях

Я согласен с этим, и я тоже буду изменять на прошивке HID. Невозможно узнать точное значение внутренних резисторов, хотя они могут подняться до 50 тысяч, я считаю. Если это так, внутреннее вытягивание на 50 тыс. На Boot1 будет представлять разделитель напряжения с вытягиванием 100 тыс. Так что это действительно безопаснее деактивировать внутреннюю вырубку.

Когда я первоначально проверил новый код, он не сработал. Я дважды проверил штифт и т. Д., И понял, что проблема заключалась в внутреннем выпуске. Я думаю, что в листе данных для STM32 говорится, что значение внутреннего вытяжения может быть между 30К до 50K. После того, как я сменил код, чтобы не использовать стягивание, все работало нормально. Примечание. Я думаю, что некоторые платы Blackpill не имеют ссылки на boot1jumo, у них только Boot0, но Boot1 должен быть навсегда натягнут на этих платах, иначе никто не мог использовать внутренний загрузчик для установки в Flash. Однако большинство плат STM32 имеют обе ссылки, поэтому я думаю, что использование Boot1 является лучшим вариантом, если на плате нет кнопки «пользователя»

@bootsector Я развел твою репо, и Вассилис прислал мне пиар, чтобы добавить ваш загрузчик в ядро ​​Libmaple. Но я не думаю, что добавление источников загрузчика в Arduino «Core» источники были бы хорошей идеей.. Я изменил свою вилку твоего репо, а затем объединил файлы из Вассилиса Видеть https: // github.com/rogerclarkmelbourne/ ... загрузчик Он также немного изменил Heirarchy, поместив прошивку в свою собственную папку, что, я думаю, является хорошей идеей Я мог бы сделать пиар для изменений, чтобы вернуть их обратно в вашу версию, однако я подозреваю, что вы не захотите большинство из них, так как у вас есть разные требования к загрузчику большинству людей на этом форуме КСТАТИ. Я не уверен, почему ты .о .размер .Карта и т. Д. Файл не в вашем репо, потому что ваш .Файл gitignore не исключает их, поэтому я обновил Gitignore, чтобы эти типы файлов не отслеживались.

Привет, Кларк, Как я уже болтал с Vassilis, я думаю, что я буду держать оригинальные источники прошивки максимально простыми, чтобы людям было легче добавить к ней функции в своих производных работах. Я согласен с тем, что прошивка в его нынешнем виде не очень полезна для большинства людей на этом форуме, и я рад, что вы, ребята, проделали отличную работу по созданию ее версии, которая плавно интегрируется с экосистемой STM32Duino. Надо, мне очень нравится идея иметь прошивку в отдельной папке и более полной .gitignore file

ХОРОШО Vassilis сделает новую репо с текущей версией модифицированных источников, потому что он внесет больше изменений, и вы не хотите PR Я, вероятно, добавлю исходный код хоста в Arduino STM32 -репо в папке инструментов, потому что источники для других инструментов находятся в этом репозиции Я добавлю readme, чтобы почесть вас и ссылаться на ваш репо

Загрузчик HID загружается на GitHub (https: // github.com/serasidis/stm32_hid_bootloader) Я загрузил файл Zip Patch для Arduinostm32 для тех, кто хочет попробовать новый загрузчик HID. Пожалуйста, не забудьте получить резервную копию перед нанесением патча. Пока что он работает очень хорошо на Windows 10 (64-битный) с Bluepill доска.Поддержка Linux скоро появится. П.С. Роджер хочет сделать некоторые тесты в загрузчик HID, прежде чем добавить его в репо arduino_stm32.

Хорошо выглядит, @Vassilis! Продолжайте в том же духе!

Я только что попробовал это. Я использовал демонстратор Flash Loader для загрузки HID_BOUTLOADER.HEX -файл на адрес 8000000. Их я могу использовать Arduino для прошивки платы в режиме HID Bootloader, и загружает мою программу. После этого снова переворачивает загрузчик Boot1 в High Start Hid.Я принял ваши изменения и внедрил их в STMCORE. Теперь я могу скомпилировать и вспыхивать свой чертежи с Arduino, но моя основная программа не выполняет. Я изменил сценарий линкера, чтобы отразить новую память происхождения при происхождении = 0x8001000. Я не уверен, есть ли что -нибудь еще заняться на данный момент...

Джамперы устанавливаются так же, как на картинке ?

Вассилис КСТАТИ. Я просто разбил твою репо https: // github.com/rogerclarkmelbourne/ ... Загрузчик Я не думаю, что внесу какие -либо изменения, но если я это сделаю, я смогу отправить пиар Я, наверное, проверю сегодня

ОК, спасибо

Хорошо, я также пропустил новый Hid-Bootloader через инструменты ST-Link, и он работал только один раз, После загрузки чего -то вроде «серийного примера» он больше не попадет в режим загрузчика +----------------------------------------------------------------------+ | HID-Flash v1.4 - STM32 HID Bootloader Flash Tool | | (c) 04/2018 - Bruno Freitas - http://www.brunofreitas.com/ | | (c) 20/2018 - Vassilis Serasidis - http://www.serasidis.gr/ | | Customized for STM32duino ecosystem - http://www.stm32duino.com/ | +----------------------------------------------------------------------+ Sending Magic sequence "1EAF" Unable to open device.

Это странно... Я проверю это позже

Я изменил свой пост, я думаю, речь идет о не работающем автоматическом сбросе. Я также вспыхнул нормальный 2.0bootloader снова, чтобы «пересечь» подтвердите это. 2.0 работает без проблем.

[Вассилис - Вт 17 апреля 2018 г., 7:44 утра] - @bootsector Отличная работа ! Отличная работа. Я немного изменил ваш исходный код, чтобы работать с Arduino IDE Метод загрузки: загрузчик STM32Duino на Bluepill STM32F103C8 Для тех, кто хочет попробовать этот загрузчик HID:

1. Сжечь чертеж с помощью прикрепленного загрузчика HID (Hidbootloader.бин файл).
2. Выберите Метод загрузки: загрузчик STM32Duino от Arduino IDE
3. Скомпилируйте свой эскиз
4. Найдите, где ваш составлен .Файл корзины существует (например: мигание.Ино.корзин) и скопируйте его в ту же папку, где спрятанный.Exe существует
5. Подключите PA8 к GND и перезагрузите чертеж.
6. Выполнить следующую команду CLI hid-flash.exe blank-config.bin Blink.ino.bin

Кажется, я забыл добавить один измененный файл Core в файл Zip Patch (usb_serial.CPP). Вот почему автоматический сброс не работал. Пожалуйста, скопируйте usb_serial.CPP файл в ... Arduino_STM32\STM32F1\cores\maple

[Вассилис - Пт 27 апреля 2018 г., 17:43] - Кажется, я забыл добавить один измененный файл Core в файл Zip Patch (usb_serial.CPP). Вот почему автоматический сброс не работал. Пожалуйста, скопируйте usb_serial.CPP файл в ... Arduino_STM32\STM32F1\cores\maple

После установки нового загрузчика я попробую новый компьютер и не могу правильно установить драйвер Это вина моих окон?

В Windows вам все еще нужна установка последовательного драйвера, вы сделали это на новой машине? ---> https: // github.com/rogerclarkmelbourne/ ... занижаем Если вам не нужен серийный драйвер (»серийный.Печать " --> USB) Вы можете попробовать это: Снимите перемычку для Boot1 (рядом с «сбросом») и отключите (!) устройство и воссоедините его.

Я уже сделал это, теперь после того, как все будет сделано (вспыхнуте загрузчик HID, составьте пользовательский код, используя параметры загрузчика STM32DUIN.Exe Dod, без проблем) плата продолжает показывать устройство HID и светодиодную светодиодную модель PC13, мой код - быстрого кода (содержит последовательный.печать) Почему порт COM не появился? Я уже установил драйвер Maple (много раз удаляет и переустановил)

Я пробую загрузку, используя Arduino IDE (параметры HID) с тем же эскизом и сработавшим эскизом, установка последовательного устройства поднята и после пары с секунды показал «Mapple......Не удалось "так что это проблема моего компьютера, но почему использование Hid-Flash.Exe не загружал эскиз? Даже командные строки были успехом? Спасибо Обновление, я попытался использовать другой компьютер, и он установил драйвер для сериала Maple просто отлично, я не знаю, почему Windows так ужасны в управлении драйверами

@madias Вы используете старый инструмент HID-Flash (1.0) Последний - v1.4

@Vassilis: Хорошо, я смешал ваш с репо от Роджера (все еще включайте старую версию)...Теперь все работает снова - даже с сбросом (лишь строка ошибок тайм -аута о ком -портом, которую я могу игнорировать) Offtopic: это самый простой способ сделать Makefile под окнами без вздутия загрузки?

[Мадиас - Сб 28 апреля 2018 г., 7:43]] - @Vassilis: Хорошо, я смешал ваш с репо от Роджера (все еще включайте старую версию)...Теперь все работает снова - даже с сбросом (лишь строка ошибок тайм -аута о ком -портом, которую я могу игнорировать)

Offtopic: это самый простой способ сделать Makefile под окнами без вздутия загрузки? Gnuwin всего 32 бит, а Gnuwin64 мертв...

[Мадиас - Сб 28 апреля 2018 г., 7:55]] -

[Мадиас - Сб 28 апреля 2018 г., 7:43]] - @Vassilis: Хорошо, я смешал ваш с репо от Роджера (все еще включайте старую версию)...Теперь все работает снова - даже с сбросом (лишь строка ошибок тайм -аута о ком -портом, которую я могу игнорировать)

Offtopic: это самый простой способ сделать Makefile под окнами без вздутия загрузки? Gnuwin всего 32 бит, а Gnuwin64 мертв...

Ну, инструменты, которые я использую: 1. GCC-ARM-None-EABI-7-2017-Q4-MAJOR-WIN32.Exe 2. Mingw 3. Блокнот++ Для редактирования Makefiles Вы всегда можете найти последние Hid_bootloader здесь

Использование Mingw для Make - это немного излишнее. Я думаю, что использую GNU Make. Я дважды проверю... Я также думаю, что использую версию GCC, которая установлена ​​Arduino IDE, хотя мне пришлось внести небольшие изменения в Makefile и т. Д

ОК, спасибо за эту информацию -c: \ bootloader \ cli>Mingw32-Make.Exe сделал эту работу, в прошлом я составлял только с OSX

Я дважды проверил, и я заставил GNU сделать 3.81 установлен Я не уверен, откуда я его получил...

Небольшая модификация в Makefile для CLI необходима для сборки Linux/Mac, вы должны добавить RS232.С источниками для всех платформ.

Добавлена ​​поддержка Maple Mini Poard https: // github.com/serasidis/stm32_hid_bootloader Есть двоичные файлы загрузчика для загрузки Maple Mini и generic_pc13 (Bluepill) Доски. Я не использовал диск на Maple Mini. Я использовал штифт PA12 в GND для перечисления USB. Он тестируется на 3 компьютерах Windows и работает ОК.

[Сжимать - Солнце 29 апреля 2018 г. 8:25] - Небольшая модификация в Makefile для CLI необходима для сборки Linux/Mac, вы должны добавить RS232.С источниками для всех платформ.

Привет, Сламмер, это в моих будущих планах поддержать операционные системы Linux/Mac.

Привет, Вассилис! Я еще не проверял модифицированное ядро ​​(особенно в Windows невозможно, так как у меня нет машины Windows) Я собрал CLI для Linux и самого загрузчика. Кажется, работает под Linux. Я хочу увидеть последовательность AutoReset, потому что текущая процедура немного нестабильна на Linux. Примечание: серийный порт «Волшебная последовательность» для AutoReset должна быть необязательным в CLI. Если нет аргумента о последовательном порте, программа должна пропустить серийные команды.

Хотя HID Bootloader Работает идеально на окнах, я не могу сказать то же самое для Ubuntu 17.4 (64-битный). У меня такая же проблема на STM32duino Bootloader слишком. Bluepill распознается как устройство TTYACM0 (PID 0004), но он не вычисляется, чтобы появиться в виде устройства DFU (PID 0003) . Это кажется проблемой Linux, потому что я читал, что у многих людей проблемы с USB -перечислением на Linux Я пробовал много возможных решений, найденных на форуме STM32Duino, но ни один из них не решил проблему.

Дайте мне знать, если у вас, ребята, есть какие -либо проблемы между операционными системами (Linux, Mac и Windows) для функциональности мигания HID (не связанный с виртуальным последовательным портом).

Я уверен, что проблема с Autoreset в Linux заключается в Core/Libmaple или в программе, которая посылает последовательность сброса. Много раз после отправки последовательности сброса, чертеж замораживает, на самом деле не происходит сброса, чтобы снова перечислить. Всегда правильно перечисляет сброс устройства DFU. Я думаю, что в Linux время последовательности намного быстрее, чем Windows, и это создает что -то странное в рутине AutoReset, не является проблемой перечисления, является проблемой сброса сброса.Прочитайте эту тему об AutoReset в Linux и о моих усилиях по улучшению некоторых проблем ViewTopic.PHP?F = 22&t = 3448&P = 43584#P43573

Хороший маленький загрузчик. Это потребовалось немного массажирования, но здесь работает. Предварительно скомпилированные двоичные файлы сапог-репозиции не работают для меня, но я все построил. Некоторая информация для разработчиков (пусть это будет помогать): на Mac OS X Sierra, версия Maple-Mini-Mini Vassilis, построенная на клоне Baite. Он был проклят модифицированным последовательным инструментом и сценарием PY из этого проекта. Я еще не пробовал Debian или Win7. $ lsusb Bus 250 Устройство 007: ID F055: 0001 F055 STM32F HID Bootloader Устройство не отображалось под /dev /(и, следовательно, Arduino IDE), пока я не загрузил эскиз через командную строку, но теперь оно разобралось и появляется под /dev /cu.usbmodemfa411, как обычно, и в IDE. Инструмент Hid-Flash из того же репозитория (с файлами RS232) не будет построен, но инструмент Bootsector CLI построил прекрасно и прошел тест: я построил пример Blink STM32 и загрузил Blink.Ино.Bin от / var / wia Hid-Flash, и она загружена как чемпион после перезагрузки, и в настоящее время мигает. Дополнительная информация: Для инструмента Vassilis 'CLI я изначально получил, «Фактальная ошибка:» Windows.H 'файл не найден », поэтому я попытался прокомментировать компоненты Windows, чтобы увидеть, насколько он построит, и получил: GCC Main.o Hid-Mac.o -framework iokit -framework corefoundation -o Hid -Flash Неопределенные символы для архитектуры x86_64: "_Rs232_Closecomport", ссылается из: _serial_init в основном.о "_Rs232_opencomport", ссылается из: _serial_init в основном.о "_Rs232_sendbuf", ссылается из: _serial_init в основном.о "_Rs232_disabledtr", ссылается из: _serial_init в основном.о «_Rs232_disablerts», ссылается из: _serial_init в основном.о "_Rs232_enabledtr", ссылается из: _serial_init в основном.о "_Rs232_enablerts", ссылается из: _serial_init в основном.о LD: Символ (ы) не найден для архитектуры x86_64 Я проверил Makefile и попытался массировать код, но я отказался от него, так как инструмент Bootsector построил отличный. Спасибо!

После нескольких дней проверки исходного кода я обнаружил, как решить проблему загрузки на Linux. Теперь успех загрузки на Linux и Windows составляет 100% (по крайней мере, на моих 4 машинах). Рабочие доски до сих пор: Bluepill и Maple Mini _

Arduino_stm32_patch_180507_01.молния

(63.21 киб) скачано 21 раз

@Vassilis Вы изменили программу Hid-Flash?

[Сжимать - Пн, 7 мая 2018 г., 11:38] - @Vassilis Вы изменили программу Hid-Flash?

Да, я сделал с ...\ cli \ main.в файл

Кли.молния

(75.64 киб) скачано 20 раз

Я подтверждаю, что последовательность AutoReset работает очень хорошо в Linux (намного лучше, чем старый загрузчик/Autoreset). Я протестировал несколько эскизов с тяжелым серийным трафиком (где у оригинального загрузчика есть некоторые проблемы), а сброс/загрузка работает. У меня есть ошибки, но, наконец, сброс/загрузка в порядке. Я скачал более 20 эскизов, более 2-3 раза каждый, и это был на 100% успех. Sending Magic sequence "1EAF" unable to set portstatus: Broken pipe unable to get portstatus: Input/output error unable to set portstatus: Input/output error unable to get portstatus: Input/output error unable to set portstatus: Input/output error Sending command... Flashing firmware... ....................................................................... ......................................................... Done! Sending command...

Ребята Я смотрю на то, как ядро ​​сбрасывается для загрузки, а не только для загрузчика HID, и в коде есть несколько странных вещей, которые я попытаюсь исправить Похоже, есть какой -то избыточный код, требующий установки терминала на 1200 бод. На ПК этот код, кажется, вообще не требуется, и, глядя на существующую утилиту upload_reset, он также не устанавливает терминал на 1200 (однако, возможно, файл PC Jar делает это.) У нас никогда не было источников для банки для ПК, но я думаю, что она была декомпилирована в прошлом, поэтому мне нужно снова декомпилировать, чтобы увидеть, устанавливает ли он терминальный скорость бода на 1200 или нет. Я не думаю, что это должно быть необходимо, так как я думаю, что просто переключать линию DTR, а затем отправка волшебной последовательности должна быть всем, что нужно для сброса ЦП. КСТАТИ. Я также думаю, что есть потенциальная проблема, потому что этот код не очищает if (reset_state == DTR_NEGEDGE) { reset_state = DTR_LOW; if (usb_cdcacm_data_available() >= 4) { uint8 chkBuf[4]; // Peek at the waiting bytes, looking for reset sequence, // bailing on mismatch. usb_cdcacm_peek_ex(chkBuf, usb_cdcacm_data_available() - 4, 4); for (unsigned i = 0; i < sizeof(magic); i++) { if (chkBuf[i] != magic[i]) { return; } }

Роджер, я нашел команду, чтобы установить Baudrate на upload_reset. Я протестировал новую скомпилированную upload_reset на Ubuntu, и это сработало. Я выложу код, когда пойду домой.

Роджер, кажется, что всегда 4 байта отправляются вместе как один пакет, и по этой причине нет проблем. Потенциально существует риск получить 4 байта в двух кадрах. Другая проблема - обнаружение DTR Oftion Egde, гораздо проще и чище, чтобы обнаружить его путем хранения предыдущего состояния DTR и сравнить ток с предыдущим, а не используемым Стейммахином. Я имею в виду что-то подобное (в псевдокоде): Current = getDTRState() nDTREgde = ( !Current ) && Previous Previous = Current;

[Сжимать - Вторник 8 мая 2018 г. 1:04 утра] - Роджер, кажется, что всегда 4 байта отправляются вместе как один пакет, и по этой причине нет проблем. Потенциально существует риск получить 4 байта в двух кадрах. Другая проблема - обнаружение DTR Oftion Egde, гораздо проще и чище, чтобы обнаружить его путем хранения предыдущего состояния DTR и сравнить ток с предыдущим, а не используемым Стейммахином. Я имею в виду что-то подобное (в псевдокоде): Current = getDTRState() nDTREgde = ( !Current ) && Previous Previous = Current;

[Сжимать - Вторник 8 мая 2018 г. 1:04 утра] - Роджер, кажется, что всегда 4 байта отправляются вместе как один пакет, и по этой причине нет проблем. Потенциально существует риск получить 4 байта в двух кадрах. Другая проблема - обнаружение DTR Oftion Egde, гораздо проще и чище, чтобы обнаружить его путем хранения предыдущего состояния DTR и сравнить ток с предыдущим, а не используемым Стейммахином. Я имею в виду что-то подобное (в псевдокоде): Current = getDTRState() nDTREgde = ( !Current ) && Previous Previous = Current;

[Вассилис - Вторник 8 мая 2018 г. 1:00] - Роджер, я нашел команду, чтобы установить Baudrate на upload_reset. Я протестировал новую скомпилированную upload_reset на Ubuntu, и это сработало. Я выложу код, когда пойду домой.

Я не думаю, что изменение скорости бод. Я пытаюсь удалить его из ядра.

[Rogerclark - Вторник 8 мая 2018 г., 3:01 утра] - Где используется RTS. Я не вижу этого в usb_serial.CPP

В строке 267, роботис (что это?) «Волшебная последовательность» инициирует, когда rts = 1 и dtr = 0... #if defined(BOOTLOADER_robotis) uint8 dtr = usb_cdcacm_get_dtr(); uint8 rts = usb_cdcacm_get_rts(); if (rts && !dtr) { reset_state = DTR_NEGEDGE; } #endif

РЖУ НЕ МОГУ ХОРОШО. Я уже удалил весь код #ifdef robotis из моей локальной копии. Вот почему я не мог его найти

[Rogerclark - Вторник 8 мая 2018 г. 3:02 утра] -

[Вассилис - Вторник 8 мая 2018 г. 1:00] - Роджер, я нашел команду, чтобы установить Baudrate на upload_reset. Я протестировал новую скомпилированную upload_reset на Ubuntu, и это сработало. Я выложу код, когда пойду домой.

Я не думаю, что изменение скорости бод. Я пытаюсь удалить его из ядра.

@Роджер Хорошо. Если вы хотите его использовать: int openserial(char *devicename) { struct termios attr; if ((fd = open(devicename, O_RDWR)) == -1) return 0; /* Error */ atexit(closeserial); if (tcgetattr(fd, &oldterminfo) == -1) return 0; /* Error */ attr = oldterminfo; attr.c_cflag |= CRTSCTS | CLOCAL; attr.c_oflag = 0; cfsetospeed(&attr,B1200); <------------------------------------------------[ Sets the Baudrate to 1200 bps ] if (tcflush(fd, TCIOFLUSH) == -1) return 0; /* Error */ if (tcsetattr(fd, TCSANOW, &attr) == -1) return 0; /* Error */ /* Set the lines to a known state, and */ /* finally return non-zero is successful. */ return setRTS(0) && setDTR(0); }

[Сжимать - Пн, 7 мая 2018 г., 23:35] - Я подтверждаю, что последовательность AutoReset работает очень хорошо в Linux (намного лучше, чем старый загрузчик/Autoreset). Я протестировал несколько эскизов с тяжелым серийным трафиком (где у оригинального загрузчика есть некоторые проблемы), а сброс/загрузка работает. У меня есть ошибки, но, наконец, сброс/загрузка в порядке. Я скачал более 20 эскизов, более 2-3 раза каждый, и это был на 100% успех. Sending Magic sequence "1EAF" unable to set portstatus: Broken pipe unable to get portstatus: Input/output error unable to set portstatus: Input/output error unable to get portstatus: Input/output error unable to set portstatus: Input/output error Sending command... Flashing firmware... ....................................................................... ......................................................... Done! Sending command...

Вассилис, переключение RTS не требуется... Вы можете удалить соответствующие команды

Я уже сделал это. Проверьте последние HID Bootloader GitHub Pr. Роджер удалит функцию, которая перезагружает MCU под DTR Toggle + 1200 BPS. Итак, я жду, чтобы увидеть окончательный файл исходного кода серийного USB, прежде чем я сделаю какое -либо изменение в загрузчик HID.

RS232 LIB, похоже, нуждается в некоторых изменениях, чтобы построить инструмент CLI на OSX. Добавление списка определений для определения скорости передачи данных, которые отсутствуют в заголовке Sys/Termios от OSX, и добавление определения (__ Apple__) к концу переключенной ОС Linux, казалось, делало свое дело и заставило его построить здесь, но я могу ' T-тест Hid-Flash Utility на данный момент (извините, я постараюсь проверить его позже), чтобы увидеть что-нибудь еще в изменении нуждающихся либеров RS232... Надеюсь, не слишком много, так как я совершенно не знаком с серийными вещами (если более серийный маки-пользователь, чем я хочу сначала взломать, пожалуйста). Добавлено в верхней части 232 рупий.H: #if defined(__APPLE__) #define B460800 460800 #define B500000 500000 #define B576000 576000 #define B921600 921600 #define B1000000 1000000 #define B1152000 1152000 #define B1500000 1500000 #define B2000000 2000000 #define B2500000 2500000 #define B3000000 3000000 #define B3500000 3500000 #define B4000000 4000000 #endif

@Aletheianalex Спасибо! Кажется, что вы единственный тестер на Mac . Я думаю, что у Мадиаса есть книга Mac. Может он тоже может помочь.

У меня есть старый MacBook и Hackintosh, так что я могу его проверить

Вассилис Я не могу заставить загрузчик работать сейчас Спрятанный.Exe в основном висит и не загружается. Мне пришлось зайти в менеджер задач Windows, чтобы убить задачу. Я думал, что попробую собрать EXE с помощью кода :: блоки, но он выглядит как только компилируется с помощью Cygwin или чего -то в этом роде Одна проблема также заключается в том, что при первоначальном установке загрузчика нет порта для его подключения, чтобы сделать сброс. Таким образом, код должен попытаться открыть порт COMM, но если он не удается или нет порта COMM, он должен попытаться загрузить через HID независимо. Он также должен иметь какой -то тайм -аут, а не просто висеть, если у него есть проблема с подключением к USB -устройству. Мне нужно решить, как скомпилировать EXE, потому что мне нужно добавить гораздо больше текста отладки Использование Code :: Blocks будет лучшим вариантом для меня, так как он установлен, и он использует GCC. Однако у него есть несколько проблем со всеми Unix, включают E.глин #включать <Sys/ioctl.час> #включать <Sys/utsname.час> и #включать <Либусб.час> и #включать <ICONV.час> Похоже, он основан на https: // github.com/signal11/hidapi, который использует Visual Studio для его сборки Windows, поэтому я попробую загрузить это

Только что пришел к строительству и попробованию инструмента CLI с изменениями OSX, и, похоже, он работает: загруженная мигание успешно, перезагружен и загружен. Я не мог выяснить отображение портов, и оно не будет загружаться без аргумента, поэтому я вошел в пайд VID от LSUSB, чтобы увидеть и получить ошибки, но загрузка все еще прошла: $ hid-flash Usage: hid-flash $ hid-flash Blink.ino.bin f055:0001 Illegal comport number Can not open comport Sending command... Flashing firmware.................... ............................... Done! Sending command...

Я собирался предположить, что аргументы USB VID и PID являются наследием, но на самом деле этот загрузчик должен получить настоящий PID PID, прежде чем он будет готов к основному использованию. Ток, видео, кажется, 0xf055. Если утилита использует PID VID, переданный ему, то мы можем изменить PID PID с досок.TXT, когда это необходимо, без необходимости восстанавливать утилиту для каждой платформы

[Aletheianalex - Вторник 8 мая 2018 г., 23:41] - Только что пришел к строительству и попробованию инструмента CLI с изменениями OSX, и, похоже, он работает: загруженная мигание успешно, перезагружен и загружен. Я не мог выяснить отображение портов, и оно не будет загружаться без аргумента, поэтому я вошел в пайд VID от LSUSB, чтобы увидеть и получить ошибки, но загрузка все еще прошла: $ hid-flash Usage: hid-flash $ hid-flash Blink.ino.bin f055:0001 Illegal comport number Can not open comport Sending command... Flashing firmware.................... ............................... Done! Sending command...

Доска - это клон Baite Maple Mini, подключенный к USB2.0 [Электронная почта защищена]'. Я только что восстановил из новейших источников и повторно сошел, а затем установил бинар Blink с помощью инструмента CLI. Вот выходы LS/DEV, LSUSB и усеченного IOREG (так как нет/SYS/BUS/USB/ON OS X), как для режима загрузчика, так и для режима запуска пользовательской программы: HID Bootloader Mode -> Удерживать кнопку «», подключите кнопку, нажмите сброс: $ ls /dev/{tty,cu}.* /dev/cu.Bluetooth-Incoming-Port /dev/tty.Bluetooth-Incoming-Port

Maple Mini opeare на Arduino Ide как "Порт: /dev /cu.usbmodemfa411 (клен) " ?Я успешно скомпилировал хит-шлюх для OSX 10.12. Сейчас работает нормально. Он успешно перезагружает и обновляет прошивку на MCU. RS232.c, кстати, нуждается в некоторой переделке.

[Вассилис - Ср 09 мая 2018 г., 15:28] - Maple Mini opeare на Arduino Ide как "Порт: /dev /cu.usbmodemfa411 (клен) " ?

Вот скриншот меню Arduino IDE и история портов в сетевой утилите:

IDE

Ардуино.PNG (56.33 киб) просмотрено 568 раз

ОК, спасибо! Это очень помогает

Теперь HID Bootloader Кажется, идеально подходит на Окна, Linux и Macosx Я надеюсь, что завтра я загрузил патч и исходный код в репозиторие GitHub.

КСТАТИ. Я установил Mingw, чтобы я мог скомпилировать Hid-Flash.exe, но у меня еще не было времени, чтобы попробовать его собрать

@Роджер Я читал, что вы отправили пиар с некоторыми изменениями в репо arduino_stm32. Я скачаю последнюю версию, чтобы увидеть, работает ли загрузчик HID правильно.

Я наставил некоторые изменения, чтобы удалить код для загрузчика "robotis" (кажется, никто не знает, что это за загрузчик. Я также удалил код, который сбрасывается, когда терминал установлен на 1200 бод, так как это также предназначено для загрузчика Robotis. @victor_pv рекомендует некоторые другие изменения, чтобы сделать код чище, но я еще не сделал их.

Roger, я загрузил последнюю Arduino_stm32 Repo и преобразовал загрузчик HID для работы с тем же методом, что и Bootloader 2.0 Работа (Magic Pack + DTR + RTS -последовательность). Под окнами он работает очень хорошо. Под Linux он не работает ни загрузчиком HID, ни загрузчиком 2.0 (Maple DFU). Светодиод очень быстро мигает.

Вассилис Когда вы говорите, что светодиод быстро мигает.. Как вы думаете, код сбивается в ядре и не прыгает в загрузчик ?? Лучшее, что нужно сделать, это получить ядро, чтобы установить штифт GPIO на высокий непосредственно перед тем, как оно прыгнет к загрузчику, и отслеживать этот GPIO с помощью логического анализатора Если штифт GPIO высокий, но ядро ​​не прыгает в загрузчик, должна быть некоторая разница в GCC на Linux Возможно, что сброс на Linux происходил только из -за WDT, но это просто означает, что код сброса должен быть исправлен ошибкой

Я действительно не знаю, где сбивается код Я попробую светодиодный трюк, который вы упомянули ранее.

Просто некоторые дополнительные данные, если это помогает. Bootloader прыгает на эскиз пользователя на Maple Mini Fine сразу после загрузки, если он маленький (например, Blink), но не на более крупных эскизах (которые, как я подтвердил не может загружать эскиз (обычно нет, кажется случайным).

Это напоминает мне. Проблема, которую я столкнулся с загрузчиком DFU под Linux. В первый раз после жесткого сброса или включения все, что работает, как и ожидалось, но после этого иногда программа висит сразу после отправки «волшебной последовательности». Я не знаю, актуально ли размер или серийная деятельность, это кажется случайным, но это случается очень часто.

Хорошо. Я взял этот вызов загрузчика, личный (Потому что мне нравится решать головоломки) и, наконец, я сделал это. После того, как Роджер внес некоторые изменения в usb_serial.CPP Файл (и некоторые другие файлы тоже), я работал в течение нескольких дней, и, наконец, я сделал HID Bootloader отлично работайте на 3 платформах (Окна, Linux и MacOS. Итак, HID Bootloader отлично работает сейчас! Сейчас работает с известной последовательности 1EAF + DTR + RTS Я не остановился на этом. Я сделал загрузчик2.0, чтобы работать хорошо на 3 платформах тоже ! Несколько изменений внесли, в основном в пакетных файлах. Итак, теперь эти два загрузчика отлично работают на 3 -х платформах ОС Мне нужно время, чтобы повторно упаковать все файлы и загрузить их в GitHub.

Приятно слышать! Я связывался с этим прошлой ночью, но не мог понять это. Я скрещивал пальцы, потому что была бы неплохо.

Я не могу дождаться, чтобы увидеть изменения....

Отличный

Новый HID Bootloader Версия загружена. Включает в себя исправления DFU в Linux и MacOS (DFU Bootloader 2.0).

Спасибо за пиар, я постараюсь проверить его и объединить сегодня

Хорошо, кажется, работает, по крайней мере, в моей машине Linux, Autoreset работает всегда (20-20 успех). Наконец мне нравится функция AutoReset в моей машине!!! Я вижу разницу в usb_serial.c, в функции rxhook в поисках "Magic 1eaf". Теперь вы буферируете локально весь буфер RX и проверяете последние 4 байта на «1EAF», хорошо, это стоит несколько байтов, но кажется более безопасным... Я лично предпочитаю более безопасный способ сигнализации последовательности сброса без «магических байтов» и буферного поиска в подпрограмме приема, которая стоит времени и памяти, например, конкретная последовательность DTR/RTS - лучший способ, но в любом случае Leaflabs решил таким образом, так... Я также проверяю его без поддержки USB-CDC в ядре или с помощью Boot1 = 1 (оставаясь в загрузчике), но спрятана спрятана, так как не было никакого последовательного порта. Trying to open the comport... error, counldn't open comport /dev/ttyACM0 Sending command... Error while sending command. Error while sending command.

[Сжимать - Ср 23 мая 2018 г. 12:46] - Я также проверяю его без поддержки USB-CDC в ядре или с помощью Boot1 = 1 (оставаясь в загрузчике), но спрятана спрятана, так как не было никакого последовательного порта. Trying to open the comport... error, counldn't open comport /dev/ttyACM0 Sending command... Error while sending command. Error while sending command.

Вассилис Я только что попробовал оригинальную версию загрузчика, которую написал @bootsector, https: // github.com/bootsector/stm32-hid ... R/выпуски И это действительно отображается на моей машине Windows 7 Так что либо то, что вы изменили в коде, либо, возможно, версия компилятора, которую вы используете, означают, что она не отображается на моих разных машинах Я сомневаюсь, что я буду единственным человеком, где загрузчик не работает на своей машине. Многие люди все еще используют Windows 7 и Windows 8 и т. Д

Я попытался интегрировать загрузчик HID USB с помощью arduino_core_stm32. Я могу скомпилировать и вспыхивать, перемещая перемычку Boot1 с библиотекой STM32Druino и arduino_core_stm32 С arduino_core_stm32, после того, как она вспыхнула, моя программа не будет выполнена (я также попробовал с приложением Blink и ничего). Я уверен, что это связано со сценарием линкера. Единственное изменение, которое я сделал, это: Flash (Rx): Origin = 0x08001000, длина = 60K Есть ли что -то еще, что я должен сделать? Я не использовал hid_bootloader.LD файл. Вы можете проверить мой коммит здесь: https: // github.com/supzze/stm32corehid ... 2FE9B74428

В другой потоке я предложил включить внутренний вывод на PB2-штифт (Boot-1). Это поможет в случае, если кто -то захочет заставить чертеж остаться в загрузке. Есть небольшая проблема в этом. Установка PB2 для раскрытия PCB Bluepill имеет резистор 100K (R4) между Jumper-1 и PB2 Pin. Это означает, что когда я устанавливаю эту штифт вниз, а перемычка выходит из разъема, у PB2 есть 0 В. Это нормально. Когда я подключаю перемычку для Boot-1 к 3.3V, PB2 имеет только 0.95V. Это происходит потому, что R4 и внутренний выпадающий резистор действуют как разделитель напряжения. Конечно, 0.94 В недостаточно, чтобы установить PB2 на логике '1'. Настройка PB2 для подтягивания Когда я установил этот штифт на подтягивание, а перемычка выходит из разъема, у PB2 есть 3.3В. Это нормально. Когда я подключаю перемычку для Boot-1 к 0 В, у PB2 есть 2.18v, который слишком высок, чтобы рассматриваться как логика '0' Blackpill, кажется, не имеет этой проблемы, потому что он использует резистор 10 тыс. Есть некоторые возможные решения

1. Замените R4 (или добавьте параллельно дополнительный резистор) на резистор меньшего значения (10 - 20K). [Это нужны навыки пайки]
2. Короткометражную цифру R4 с помощью небольшого провода. [Это тоже нужны навыки пайки...]
3. Пусть PB2 как есть. Теперь это в плавающем режиме [это было бы проблемой с другими платами, такими как Maplemini, PB2 не подключен к +3.3 В или 0 В]. Одним из прикосновений к этому пальца этого штифта может заставить MCU войти в загрузчик во время перезагрузки.
4. Настройка BluePill может быть оставлена ​​в плавающем режиме, но это потребует, чтобы перемычка для Boot-1 была либо в 3.3 В или при 0 В. Внутреннее выпадение может быть включено на другие доски, такие как Maplemini.

Вариант 4 кажется мне более логичным

Вассилис, я вижу твою точку зрения с раскрыванием. Я также согласился с NR. 4. Я проверю магический обходной путь "пальцем".

Я искал, искал и ничего не нашел. Я могу прошить свою плату с помощью загрузчика HID, но если программа составлена ​​с модифицированным сценарием линкера (с правильным адресом), она не выполняет. Если я поместим Jumper Boot1, я смогу снова запустить загрузчик HID и снова вспыхивать. Не уверен, что еще проверить. Я смотрю на файлы LinkerScript и не вижу ничего другого, что повлияет на это...

[Suprazz - Солнце 03 июня 2018 2:17] - Я попытался интегрировать загрузчик HID USB с помощью arduino_core_stm32. Я могу скомпилировать и вспыхивать, перемещая перемычку Boot1 с библиотекой STM32Druino и arduino_core_stm32 С arduino_core_stm32, после того, как она вспыхнула, моя программа не будет выполнена (я также попробовал с приложением Blink и ничего). Я уверен, что это связано со сценарием линкера. Единственное изменение, которое я сделал, это: Flash (Rx): Origin = 0x08001000, длина = 60K Есть ли что -то еще, что я должен сделать? Я не использовал hid_bootloader.LD файл. Вы можете проверить мой коммит здесь: https: // github.com/supzze/stm32corehid ... 2FE9B74428

[Suprazz - Ср. 06, 2018 12:02] - Я искал, искал и ничего не нашел. Я могу прошить свою плату с помощью загрузчика HID, но если программа составлена ​​с модифицированным сценарием линкера (с правильным адресом), она не выполняет. Если я поместим Jumper Boot1, я смогу снова запустить загрузчик HID и снова вспыхивать. Не уверен, что еще проверить. Я смотрю на файлы LinkerScript и не вижу ничего другого, что повлияет на это...

[Suprazz - Солнце 03 июня 2018 2:17] - Я попытался интегрировать загрузчик HID USB с помощью arduino_core_stm32. Я могу скомпилировать и вспыхивать, перемещая перемычку Boot1 с библиотекой STM32Druino и arduino_core_stm32 С arduino_core_stm32, после того, как она вспыхнула, моя программа не будет выполнена (я также попробовал с приложением Blink и ничего). Я уверен, что это связано со сценарием линкера. Единственное изменение, которое я сделал, это: Flash (Rx): Origin = 0x08001000, длина = 60K Есть ли что -то еще, что я должен сделать? Я не использовал hid_bootloader.LD файл. Вы можете проверить мой коммит здесь: https: // github.com/supzze/stm32corehid ... 2FE9B74428

Поддерживает ли этот репо serialusb ?

[Suprazz - Ср. 06, 2018 12:02] - Я искал, искал и ничего не нашел. Я могу прошить свою плату с помощью загрузчика HID, но если программа составлена ​​с модифицированным сценарием линкера (с правильным адресом), она не выполняет. Если я поместим Jumper Boot1, я смогу снова запустить загрузчик HID и снова вспыхивать. Не уверен, что еще проверить. Я смотрю на файлы LinkerScript и не вижу ничего другого, что повлияет на это...

Минимальные модификации, которые вы должны сделать, чтобы включить Hid-Bl: Заменить в платформа.текст файл OLD: compiler.c.flags={compiler.extra_flags} -c {build.flags.optimize} {compiler.warning_flags} -std=gnu11 -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -Dprintf=iprintf -MMD {compiler.stm.extra_include} NEW: compiler.c.flags={compiler.extra_flags} -c {build.flags.optimize} {compiler.warning_flags} -std=gnu11 -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -Dprintf=iprintf -MMD {compiler.stm.extra_include} -D{build.vect}

Я надеялся использовать этот загрузчик, потому что у меня есть проблемы с перечислением последовательного устройства /dev /ttyacm0, и я могу программировать только в том случае, если я нажму кнопку сброса в нужное время. Я вспыхнул на свою синюю таблетку с Hidbootloader.корзин, оба из выпуска на GitHub, и я тоже его собрал. Я не получаю USB. Только USB чтения ошибок дескриптора. Когда я вспыхиваю назад generic_boot20_pc13.Bin, я получаю USB -устройство, но его очень сложно использовать, потому что оно не перечисляет /dev /ttyacm0, пока не мигает в первый раз, и что пересекается в нужное время.

Hid Bootloader почти готов к STM32F407 Магистр. Еще несколько тестов, и я опубликую файлы.

Ух ты! Это будет потрясающе! +100!

@Vassilis, пожалуйста, дайте мне знать, если вам нужна помощь, я добровольно получаю тестирование загрузчика HID на моей черной плате F4VET6 и Mini F4VET6. Кстати, последняя утилита HID-Flash для F1 снова ждет несколько (более чем необходимо) секунды, чтобы обнаружить устройство HID после сброса. Это было быстрее по предыдущей версии. Могло бы снова уменьшить это время обнаружения? Я скучаю по этим персонажам отсюда. ViewTopic.PHP?F = 32&t = 3661&начало = 80#P46036

[Стивестронг - Чт 21 июня 2018 г. 13:21] - @Vassilis, пожалуйста, дайте мне знать, если вам нужна помощь, я добровольно получаю тестирование загрузчика HID на моей черной плате F4VET6 и Mini F4VET6.

ОК, спасибо

[Стивестронг - Чт 21 июня 2018 г. 13:21] - Кстати, последняя утилита HID-Flash для F1 снова ждет несколько (более чем необходимо) второй для обнаружения устройства HID после сброса. Это было быстрее по предыдущей версии. Могло бы снова уменьшить это время обнаружения? Я скучаю по этим персонажам отсюда. ViewTopic.PHP?F = 32&t = 3661&начало = 80#P46036

Я проверю это.

Привет, Вассилис, У вас есть первоначальная версия для F4 для тестирования? Любой источник на git? Не могли бы вы улучшить скорость спрятанного флаша, чтобы распознать устройство?

[Стивестронг - Пт, 6 июля 2018 г. 10:04] - Привет, Вассилис, У вас есть первоначальная версия для F4 для тестирования? Любой источник на git? Не могли бы вы улучшить скорость спрятанного флаша, чтобы распознать устройство?

Я написал с нуля, F4 Hid Bootloader (Hid-Bl) с помощью CubeMX. Произведено .Файл корзины составляет почти 12 т.п.н., но это не проблема, потому что STM32F407 имеет как минимум, размер страницы флэш -памяти 16 КБ (STM32F103 имеет размер страницы 1 кБ). Я также написал F1 Hid BL, используя Cubemx, но .Файл корзины почти 10 кб. Слишком большой для 64 -километрового MCU. Я пытаюсь уменьшить размер, но Cubemx известно, что производит большой .Файлы корзины (раздутый код). Я адаптировал файл Hid-Flash для работы как на загрузчиках F1, так и F4, но на новых двоичных файлах Cubemx. Текущий файл Hid-Flash имеет небольшую проблему. Программное обеспечение отправляет страницу Flash, а затем задерживает несколько микроспускон. Время задержки оценивается и вызывает большую задержку с процессом вспышки. Что я сделал, так это отправить страницу Flash с компьютера на MCU, MCU сжигает страницу Flash и отвечает командой «Запись успех». Когда с Hid-Flash получает этот ответ, отправляет следующую флэш-страницу. Это минимизирует общее время процесса вспышки. Мне жаль эту задержку, но у меня не слишком много свободного времени, чтобы работать над Hid-Bl, потому что моя работа очень требовательна. Когда у меня появятся какие -либо дополнительные новости, я сообщу вам.

Сегодня я загрузил HID Bootloader v2.0 к моей учетной записи GitHub Новая прошивка поддерживает Bluepill и Черный 407VE доски. Новый спрятанный Инструмент работает только на новейшей прошивке Hid-Bl и только на Окна. Linux и MacOS Версии будут доступны на следующей неделе (может быть, раньше). А Hid-Bl появляется как "Hid Bootloader 2.0 "На исходном коде Arduino Ide Menuthe для 407 домов еще не загружено. Только 2 двоичных файла с светодиодами на выводах PB3 или PE0. [Редактировать] Чтобы поместить плату 407 в режим принудительного загрузчика HID, положите PD15 Pin Low. Обычно PD15 должен находиться в высоком состоянии (через резистор от 1 до 10 тысяч во время перезагрузки MCU. Я сделал это, потому что Archmax v1.1 плата не имеет PIN-1 Boot-1, доступной для заголовка PIN-кода. Он отлично работает на Archmax v1.1 и Diymore STM32F407 Правление [/редактировать] Hid-Bl доступен на Arduino_stm32 и STM32Generic Репозитории. Я отправил оба запроса на притяжение.

Отличная работа! Просто чтобы подтвердить, какой необходимый шаг, чтобы заставить это работать над BluePill ? Вот что я сделал: - Провернул hid_generic_pc13.корзина со св. - Скачал последний arduino_stm32 - Применил этот патч: arduino_stm32_patch_180610_02.молния Поэтому, когда я прошиваю, я сейчас получаю эту ошибку: > Trying to open the comport... > Toggling DTR... > Searching for 1209:BEBA HID device... > 1209:BEBA device is found ! > Sending command... > Error while sending command. > Error while sending command.

Майкл, патч 180610_02 содержит старую скрытую панцирь.Exe Tool. Заменить старую скрытую шлюпку.Exe с новым (v2.0) из здесь Я сделаю новый патч для Hid-Bl v2.0 и выше.

Протестировано v2.0 на черной таблетке (Hid-Generic-PB12), Mint Linux 17.3. Вам не хватает места в тексту баннера (Main.c, строка 76). +----------------------------------------------------------------------+ | HID-Flash v2.0 - STM32 HID Bootloader Flash Tool | | (c) 04/2018 - Bruno Freitas - http://www.brunofreitas.com/ | | (c) 04/2018 - Vassilis Serasidis - http://www.serasidis.gr/ | | Customized for STM32duino ecosystem - http://www.stm32duino.com/ | +----------------------------------------------------------------------+ > Trying to open the comport... > Searching for 1209:BEBA HID device... # > 1209:BEBA device is found ! > Sending command... > Flashing firmware... . 1024 Bytes . 2048 Bytes . 3072 Bytes . 4096 Bytes . 5120 Bytes . 6144 Bytes . 7168 Bytes . 8192 Bytes . 9216 Bytes . 10240 Bytes . 11264 Bytes . 12288 Bytes . 13312 Bytes . 14336 Bytes . 15360 Bytes > Done! > Sending command...

@fredbox Хорошо. Спасибо за тестирование новой версии

[Вассилис - Четверг 09 августа 2018 14:01] - Майкл, патч 180610_02 содержит старую скрытую панцирь.Exe Tool. Заменить старую скрытую шлюпку.Exe с новым (v2.0) из здесь Я сделаю новый патч для Hid-Bl v2.0 и выше.

Да, спасибо. 2.0 версия работает с моим чертежом. > Trying to open the comport... > Toggling DTR... > Searching for 1209:BEBA HID device... ## > 1209:BEBA device is found ! > Sending command... > Flashing firmware... . 1024 Bytes . 2048 Bytes . 3072 Bytes . 4096 Bytes . 5120 Bytes . 6144 Bytes . 7168 Bytes . 8192 Bytes . 9216 Bytes . 10240 Bytes . 11264 Bytes . 12288 Bytes . 13312 Bytes . 14336 Bytes . 15360 Bytes . 16384 Bytes . 17408 Bytes > Done! > Sending command...

Hid Bootloader v2.0 исходный код для STM32F407 был выпущен https: // github.com/serasidis/stm32_hid_ ... tloader_f4

Маленький USB HID -загрузчик становится еще меньше! В то время как версия USB HID Bootloader для STM32F4 с использованием вздутого LL+HAL от STM практически не вписывается в 16 КБ (менее важно, поскольку на устройствах STM32F4XX, размер Flash Page в любом случае составляет 16 КБ), @BootSector и @Vassilis были в состоянии генерировать STM32F1XX), @BootSector и @Vassilis были в состоянии генерировать STM32F1XX) @BootSector и @Vassilis. версия, которая работает внутри Только 4 кб, Таким образом, оставляя 60 кб / 124 кб для пользовательского приложения, благодаря реализации драйвера USB на основе Lean Bare-Metal / CMSIS / CMSIS. Теперь, применяя достаточное количество методов оптимизации (все еще используя C GNU99, без сборки), я смог уменьшить размер загрузчика с 4 кб до до до тех пор до 2 кб Мои запросы на притяжение GitHub были приняты @Vassilis, поэтому новая версия легко доступна в предыдущем хранилище HID Bootloctorer: https: // github.com/serasidis/stm32_hid_bootloader Использование этого нового USB HID Bootloader версии 3.0, пользовательский приложение теперь комфортно имеет 62 КБ / 126 КБ, оставшуюся в флэш -памяти на STM32F1XX, в то же время поддерживая те же функции загрузчика:

• Введите загрузчик, заставив PIN -контакт Boot1 (PB2)
• Обнаружение волшебного слова ARDUINO API в резервном копировании памяти / DTR, чтобы заставить USB-повторное увеличение от USB CDC и войти в загрузчик после перезагрузки (это избегает необходимости перемещать перемычку, если работает приложение для загрузчика)
• Неверное обнаружение приложений пользователя (без начального указателя стека), чтобы оставаться в загрузке
• «Нервный» световой мигал, чтобы отличить его от стандартного наброска мигания

Вот мотивация для этой работы: я уже знал как программирование USB-протокола, так и программирование ARM Bare-Metal Cortex M3 на других MCU (EFM32 и LPC11/LPC13...), но до сих пор я использовал только STM32, используя API ARDUINO, и я хотел исследовать программирование с голой-металлом на STM32 и понять реализацию USB на уровне регистрации. Теперь я могу сказать, что эти цели были достигнуты. Несмотря на то, что сам по себе результат интересен для конечных пользователей, путешествие, по крайней мере, так же интересно: различные коммиты показывают различные методы оптимизации, которые использовались для достижения этого результата, в том числе в любом конкретном порядке:

• Оптимизированная обработка таблицы векторов процессора с начальной (минимальной) таблицей во время ранней загрузки, промежуточной таблицы для загрузчика USB и окончательной таблицы из пользовательского приложения
• Удалили из всех избыточных кодов, обеспечивающих принудительные аппаратные регистрации начальные значения загрузки, так как, эй, мы уже являемся основным загрузчиком, поэтому мы можем рассчитывать на это! По сути, это избавится от большей части функций SystemInit () и setSySclock () в «Bootloader_f1/cmsis/device/stm32f10x/source/templates/system_stm32f10x.c "
• Заменена встроенная сборка соответствующими макросами CMSIS
• Используется STM CMSIS clear_bit (), set_bit (), read_reg (), macros write_reg () для доступа к периферийным регистрам везде
• Оптимизация логики кода
• Удалили все инициализированные данные: поверните их либо в Const, либо ненициализированные данные; Явно инициализируйте данные в коде, когда это необходимо, поэтому нет необходимости инициализировать тоже .Раздел данных от начальных значений во флэш - .Раздел BSS для нуля в раннем загрузке в Resethandler () из "bootloader_f1/cmsis/device/stm32f10x/source/templates/gcc/startup_stm32f10x_md.s "
• Удаленная зависимость от стандартных библиотек, поэтому C ++ Исключение и статические конструкторы / деструкторы раздуваются в rethandler () не тянутся в
• Используют оптимальные макросы для доступа к периферическим регистрам USB, включая Toggle_REG () для регистров, использующих функцию Brainf *** «Toggle Bits»
• Повернули все возможные функции переменных в локальную область (E.глин. «Статический»), когда это возможно, поэтому компилятор может дополнительно оптимизировать код, например, размещение встроенного функции
• Выключенная функция компилятора для размещения каждой переменной / функции в отдельный раздел: даже если она обычно помогает избавиться от неиспользованных данных / кода при использовании соответствующего сечения мусора в соответствии с соответствующим линкером, это фактически мешает компилятору выполнять уровень секции оптимизация, такая как обмен постоянными пулами и избегание ненужных отверстий выравнивания
• Заменили объявления и функции GPIO и GPIO оптимизированными макросами: нет необходимости получать накладные расходы на функцию вызова, чтобы немного переключиться
• Не повторяйте один и тот же вызов функции с разными аргументами в операторе коммутатора: заменил их на установление правильных аргументов в каждом случае и вызовите функцию только один раз в конце

Если спросить, я могу дополнительно объяснить оптимизацию, раннюю последовательность кода загрузки или периферийный доступ USB.

прохладный! +1

Отличная работа! Если вы чувствуете себя другим проектом, пиар для ядра STM тоже был бы отличным

[Беннебой - Солнце 20 января 2019 г. 11:15] - Отличная работа! Если вы чувствуете себя другим проектом, пиар для ядра STM тоже был бы отличным

LL+HAL - это такое раздувание, мне интересно, не лучше ли начать с нуля? Если бы это не было лицензией, LiboPencm3 был бы хорошим началом.

Может быть, это вздутие, но на F4 я не думаю, что это важно. Сегодня днем ​​у меня появится популярность, глядя на пиар STM32GENERIER, он не будет выглядеть так, как будто будет слишком сложно - особенно теперь, когда Фредерик добавил предварительную обработку сценариев линкера.

[Squonk42 - Солнце 20 января 2019 г. 10:44] - Маленький USB HID -загрузчик становится еще меньше!

Хорошая работа Squonk42! В то время как я не большой поклонник написанных пользователей загрузчиков, этот хороший и маленький, и из -за HID даже не нужно мучить с драйверами. Мне нравится подход просто использовать заголовок устройства STM, а затем напрямую манипулировать регистрами. Я использовал это в некоторых из моего кода, и он производит хороший маленький код. Интересно, что GCC делает буквальное объединение, узнайте что -то новое каждый день. Я видел, как некоторые люди оставляли функцию вызовов мусора сбором и выключали раздел данных GC. Я думаю, буквальный бассейн - почему. Я делал загрузчик для MSP430 в прошлом. Одна вещь, которую я сделал, чтобы облегчить его для пользователей, код загрузчика молча переписал свой векторный адрес сброса и заменил его на адрес загрузки. Это означало, что им не пришлось мучиться со сценариями линкера, чтобы переместить свой код после загрузчика. Я бы уберелся с реальным векторным адресом сброса пользователя, и это то, что загрузитель прыгнул к. Для этого загрузчика HID-загрузчика кажется, что код HID-Flash может переписать адрес 0x08000004, а затем отправить новую пользовательскую команду USB HID, которая сообщает The Bootloader, где реальный адрес, поэтому он может сохранить его в Flash. Наверное больше хлопот, чем стоит. Однако тогда я мог бы просто взять обычный бинар и загрузить его, не перекомпилируя его. Конечно, чтобы все это работало, загрузчик должен был быть перенесен в верхнюю часть флэш -памяти. Отличная работа, мне кажется, что это путь к будущему. Этот подход будет хорошо вписаться в новое ядро ​​с минимальной суетой. Спасибо!

Спасибо, Рик! Поскольку он был в то же время мой инструмент обучения, я старался укоренить источники столько, сколько мог, читая их, так что я думаю, что их также будет легче читать, чем раньше, чем они раньше были. Что касается буквального объединения, GCC пытается избежать абсолютных инструкций по перемещению и заменить их на LDR по сравнению с ПК, используя буквальные бассейны, размещенные в конце каждой функции. При использовании статических функций и избегания их расщепления на разные разделы, GCC может внедрять их и удалять еще больше дубликатов в комбинированном буквальном пуле, если вы не используете варианты «-функциональные сечения» и «-фдата-сечения». Вы можете оставить опцию линкера "-WL,-GC-сечения", так как он все равно будет исключать целые разделы данных или кода, которые вообще не используются. Кроме того, не используя опции «-функциональных сечений», а «-фдата-сечения» имеет преимущество, позволяя компилятору упаковать функции без принудительного перестройки между каждым атомным разделом, сохраняя несколько байтов здесь и там. Что касается тихо переписывая адрес вектора сброса пользователя, я должен сказать, что я подумал об этом, оставив приложение пользователя в начале региона Flash и размещение крошечного загрузчика в конце, изменяя вектор сброса пользователя, чтобы указывать на загрузчик , это должно было бы хранить где -то оригинальный пользовательский векторный адрес, чтобы вызвать его обратно после выхода загрузчика. Мои самостоятельные действия были:

• Если приложение пользователя изменено, оно не может быть подписано
• Оригинальный вектор сброса пользователя должен храниться где -то, чтобы вернуться к приложению пользователя: я думал об использовании байтов опции, но их только 2 из них. Поскольку адреса кода пальца рук всегда нечетные, мы могли бы сместить исходный адрес справа на один бит при хранении его и обратно влево при прыжке к нему, чтобы мы могли охватить диапазон вспышки 128 КБ. Но это не очень хорошо масштабируется для больших размеров вспышки
• Вместо того, чтобы хранить исходный вектор сброса пользователя в байтах опций, мы могли бы создать небольшую заглушку в конце кода пользователя, куда прыгает модифицированный загрузочный вектор, вызовут загрузчик оттуда и перейти к исходному вектору пользовательского сброса на Выход загрузчика: прямо сейчас это должно быть сделано с помощью кода 48 байтов, который у меня остался

Приглашается любая идея! Я все еще работаю над этим загрузчиком, чтобы улучшить его дальше. Моя текущая задача состоит в том, чтобы заменить неловкую конфигурацию PIN-кода на что-то вроде «#Define LED1 PC13» и вычислить все необходимые регистры и значения, используя предварительные макросы; Если возможно, объединение нескольких определений GPIO в одних и тех же регистрах конфигурации. Этот первый не должен быть слишком сложным, но второй - более вовлечен, поскольку он касается общей структуры загрузчика. Прямо сейчас основной процесс вызывает функции USB init () и USB_SHUTDOWN () в общем уровне USB -драйвера из «USB.C "(раньше использовалось динамическое связывание с указателями функций, которые были не очень полезны). Этот универсальный драйвер затем вызывает, в свою очередь, слой HID из "HID.C «Использование функций USB_RESET () и USB_EPHANDLER () для инициализации устройства и обработки входящих данных« Out », поступающих с хоста, выхода» в «Данных, обрабатываемых USB_SENDDATA () в общем уровне. Тем не менее, нет чистого разделения между слоем HID и слоем загрузчика, который в конечном итоге вызывает функцию мигания Flash_WritePage ()... На самом деле, функция hidusb_handledata () должна быть где -то вне "HID.C "(в новом" загрузке.c "?), и часть функции usb_ephandler (), которая занимается настройкой пакетов, должна вернуться в «USB.c ", а также функция generic hidusb_getdescriptor (). Тогда то, что осталось в "Скрытом.C " - это в основном дескрипторы, специфичные для HID, и конкретная конечная точка HID в USB_RESET (). И весь дизайн вроде как ногл с ног на голову: основной процесс должен вызвать загрузчик, который должен вызвать слой HID, который, в свою очередь, должен вызвать общий USB-слой нисходящим образом. Чистое расщепление основного петля, погрузчика, HID и USB -слоев, тогда станет легко заменить данную реализацию новой, E.глин. Замените HID на DFU, CDC или MSC (погрузчик тоже будет отличаться, так как команды не совместимы) или сделать что -то еще, кроме загрузчика на основе HID (Mouse + клавиатура...). Наконец, я хотел заменить встроенный устаревший CMIS динамическим подмодулем GIT на последнее определение CMSIS STM, автоматически извлеченное из современных заголовков устройств CMSIS из STM с использованием процесса Travis CI: https: // github.com/modm-io/cmsis-header-stm32

[Squonk42 - Солнце 20 января 2019 г., 16:07] - Что касается тихо переписывая адрес вектора сброса пользователя, я должен сказать, что я подумал об этом, оставив приложение пользователя в начале региона Flash и размещение крошечного загрузчика в конце, изменяя вектор сброса пользователя, чтобы указывать на загрузчик , это должно было бы хранить где -то оригинальный пользовательский векторный адрес, чтобы вызвать его обратно после выхода загрузчика. Мои самостоятельные действия были:

• Если приложение пользователя изменено, оно не может быть подписано
• Оригинальный вектор сброса пользователя должен храниться где -то, чтобы вернуться к приложению пользователя: я думал об использовании байтов опции, но их только 2 из них. Поскольку адреса кода пальца рук всегда нечетные, мы могли бы сместить исходный адрес справа на один бит при хранении его и обратно влево при прыжке к нему, чтобы мы могли охватить диапазон вспышки 128 КБ. Но это не очень хорошо масштабируется для больших размеров вспышки
• Вместо того, чтобы хранить исходный вектор сброса пользователя в байтах опций, мы могли бы создать небольшую заглушку в конце кода пользователя, куда прыгает модифицированный загрузочный вектор, вызовут загрузчик оттуда и перейти к исходному вектору пользовательского сброса на Выход загрузчика: прямо сейчас это должно быть сделано с помощью кода 48 байтов, который у меня остался

Приглашается любая идея! Я все еще работаю над этим загрузчиком, чтобы улучшить его дальше.

Мой подход (вдохновленный этим Оригинальный пост форума) заключается в использовании некоторых зарезервированных слотов в векторной таблице из смещения 0x1c-0x2b. Из моего тестирования на BluePill, нет никаких странных побочных эффектов до набивания 8 байтов при смещении 0x1c для адреса вектора сброса пользователя и первоначального указателя стека. Это не решает проблему подписания, но это позволяет избежать использования дополнительной флэш -страницы.

[Squonk42 - Солнце 20 января 2019 г., 16:07] - [*] Вместо того, чтобы хранить исходный вектор сброса пользователя в байтах опций, мы могли бы создать небольшую заглушку в конце кода пользователя, где прыгает модифицированный загрузочный вектор, вызовите загрузчик оттуда и перейти к исходному сбросу пользователя векторный адрес при выходе из загрузчика: прямо сейчас это должно быть сделано с помощью кода 48 байтов, который у меня остался

Возможно, вы захотите перейти на более новый ARM-None-Eabi-GCC для меньшего размера. Я использую 7.3.1 и в конечном итоге становятся 1984 г. Текст + 8 байтов данных. Это даже после того, как я добавил _dmb () и _dsb () вызовы вокруг изменений VTO. 56 байтов вместо 48

[Деван - Солнце 20 января 2019 г., 17:38] - Мой подход (вдохновленный этим Оригинальный пост форума) заключается в использовании некоторых зарезервированных слотов в векторной таблице из смещения 0x1c-0x2b. Из моего тестирования на BluePill, нет никаких странных побочных эффектов до набивания 8 байтов при смещении 0x1c для адреса вектора сброса пользователя и первоначального указателя стека. Это не решает проблему подписания, но это позволяет избежать использования дополнительной флэш -страницы.

Да, я был боялся использовать любой из этих «зарезервированных», но это может быть решением. Я не думаю, что нам нужно сохранить первоначальный указатель стека, нам просто нужно настроить нашу в временной таблице векторов USB Timary HID перед использованием стека, разве мы не мы?

[Рик Кимбалл - Солнце 20 января 2019 г., 17:52] -

[Squonk42 - Солнце 20 января 2019 г., 16:07] - [*] Вместо того, чтобы хранить исходный вектор сброса пользователя в байтах опций, мы могли бы создать небольшую заглушку в конце кода пользователя, где прыгает модифицированный загрузочный вектор, вызовите загрузчик оттуда и перейти к исходному сбросу пользователя векторный адрес при выходе из загрузчика: прямо сейчас это должно быть сделано с помощью кода 48 байтов, который у меня остался

Возможно, вы захотите перейти на более новый ARM-None-Eabi-GCC для меньшего размера. Я использую 7.3.1 и в конечном итоге становятся 1984 г. Текст + 8 байтов данных. Это даже после того, как я добавил _dmb () и _dsb () вызовы вокруг изменений VTO. 56 байтов вместо 48

Я придерживался 4.9.3 Поскольку это тот, который упакован в мою старую Ubuntu 16.04 LTS, так как это уже лучше, чем тот, который из пакета Arduino Samd, но я могу следовать вашему пути здесь... Может быть, мы должны согласиться с общей «официальной» версией? Какой из них вы получили и откуда? Что касается _dmb () _dsb (), то есть в процессорах Cortex-M3, Cortex-M4 и Cortex-M0+, после обновления VTOR не потребовалось барьера памяти: http: // Infocenter.рука.com/help/index.младший ... HDGBC.HTML Я полагаю, что все отправляют PR в репо @Vassilis, чтобы сохранить синхронизацию! Я просто смотрю ваш загрузчик MSP430 GDB, хороший

Я строил для F4, используя в комплекте с ядром STM.

[Squonk42 - Солнце 20 января 2019 г. 18:06] - Да, я был боялся использовать любой из этих «зарезервированных», но это может быть решением. Я не думаю, что нам нужно сохранить первоначальный указатель стека, нам просто нужно настроить нашу в временной таблице векторов USB Timary HID перед использованием стека, разве мы не мы?

Да, я думаю, это правда - в обмен на небольшую работу, чтобы исправить указатель стека в коде, вы можете избежать перезаписи первоначального указателя стека приложения во Flash. Тогда вам нужно освободить место для четырех байтов.

[Рик Кимбалл - Солнце 20 января 2019 г., 17:52] - [...] Я [...] Сделал «uint32_t i» в задержке. 56 байтов вместо 48

Я не уверен, что это требуется, так как NOP не позволит GCC оптимизировать цикл: вот что я получаю без летучих: 08000008 : 8000008: 2300 movs r3, #0 800000a: 4283 cmp r3, r0 800000c: d002 beq.n 8000014 800000e: bf00 nop 8000010: 3301 adds r3, #1 8000012: e7fa b.n 800000a 8000014: 4770 bx lr

[Рик Кимбалл - Солнце 20 января 2019 г., 17:52] - Возможно, вы захотите перейти на более новый ARM-None-Eabi-GCC для меньшего размера. Я использую 7.3.1 и в конечном итоге становятся 1984 г. Текст + 8 байтов данных. Это даже после того, как я добавил _dmb () и _dsb () вызовы вокруг изменений VTO. 56 байтов вместо 48

... 1972 Текст + 8 байтов данных с использованием последних GCC отсюда: https: // Разработчик.рука.com/с открытым исходным кодом/g ... /Загрузки $ make generic-pc13 CLEAN arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 8-2018-q4-major) 8.2.1 20181213 (release) [gcc-8-branch revision 267074] Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. mkdir build CC Src/main.c CC Src/usb.c CC Src/hid.c CC Src/led.c CC Src/flash.c LD build/main.o Memory region Used Size Region Size %age Used RAM: 3024 B 20 KB 14.77% FLASH: 1980 B 64 KB 3.02% GENBIN build/hid_bootloader.bin COPY bootloader_only_binaries/hid_generic_pc13.bin INFO build/hid_bootloader.elf SIZE build/hid_bootloader.elf text data bss dec hex filename 1972 8 3024 5004 138c build/hid_bootloader.elf

[Squonk42 - Солнце 20 января 2019 г. 18:49] - SIZE build/hid_bootloader.elf text data bss dec hex filename 1972 8 3024 5004 138c build/hid_bootloader.elf

Не уверен, что я делаю не так. Пользовательский светодиод освещается, но без мигает...

Вы должны сменить доски.txt и hid_bootloader.сценарий LD, чтобы соответствовать

[Рик Кимбалл - Солнце 20 января 2019 г., 19:37] -

Я на Ubuntu, я использую это репо https: // launchpad.net/~ team-gcc-arm-emb ... Ubuntu/PPA После возвращения моих изменений, поэтому я синхронизируюсь с вашим репо, мой выходит меньше (1956+8) text data bss dec hex filename 1956 8 3024 4988 137c build/hid_bootloader.elf

Скажем, мы хотим использовать это с официальным St Core? Как вы собираетесь иметь дело с сбросом? Я не думаю, что драйвер USB CDC ищет любых волшебных персонажей.

Да, официальное ядро ​​придется реализовать тот же механизм, что и ядро ​​Роджера, чтобы обнаружить последовательность «перезагрузка в режиме загрузчика», i, i.эн.:

• отрицательный край на DTR до
• Получение последовательности сброса магии в диапазоне «1», «e», 'a', 'f'
• магазин 0x424c ("bl") в BKP->DR10
• На самом деле выполните сброс процессора

Вот код в ядре Роджера: https: // github.com/rogerclarkmelbourne/ ... л.CPP#L248 В противном случае пользователь должен будет перемещать перемычку Boot1 каждый раз, когда требуется запись загрузчика.

[Рик Кимбалл - Солнце 20 января 2019 г. 20:55] - Скажем, мы хотим использовать это с официальным St Core? Как вы собираетесь иметь дело с сбросом? Я не думаю, что драйвер USB CDC ищет любых волшебных персонажей.

Я написал пиар, который включает в себя его... Я могу загрузить, и плата сбрасывается в эскиз, но после сброса системы она возвращается к загрузчику навсегда, не уверен, что я испортил или возникает проблема с загрузчиком F4.... (Мои деньги на меня) Работать в моей вилке -> https: // github.com/bennehboy/arduino_co ... Загрузчик Вам также понадобится этот пиар для инструментов STM -> https: // github.com/stm32duino/arduino_tools/pull/33 (или просто бросьте hid_flash.exe в папку «Инструменты/победа») Я отправлю его, как только я тестировал F1 на ядро ​​STM, но мне нужно сначала настроить.

[Рик Кимбалл - Солнце 20 января 2019 г. 20:06] - Вы должны сменить доски.txt и hid_bootloader.сценарий LD, чтобы соответствовать

Хм, что нужно перевести вектор загрузки на 0x8000800?

Да, работа, отлично. Теперь обновить мой пиар

F1 протестирован и работает против ядра STM. Я проверю F4 против Роджера и посмотрю, получу ли я такую ​​же проблему.

Такое же поведение с ядром Роджера, мигает OK и сбрасывается в эскиз, но после дальнейшего сброса системы это вечная загрузчика. Если это не проблема с моим сборником BL, то я думаю, что это один для Vassilis. Я попробую пару различных ароматов GCC и посмотрю, есть ли разница в поведении. РЕДАКТИРОВАТЬ - ИСПОЛЬЗУЕТ ОДИН из поставляемых HEX и все еще одинакового поведения после сброса системы PS - если я тогда нажмите «Сбросить» на плате, он выполняет эскиз - это по дизайну?

PR для ядра STM -> https: // github.com/stm32duino/arduino_c ... 2/тяга/415

Хорошо, я манекен, был набор Boot0 - снят джемпер, и он загружается прямо к наброску.

Для нас хорошо использовать последнюю версию Hid-Bl, но новый релиз v3.0 на стороне Arduino IDE несовместимо с платами, которые уже снабжены Hid-Bl V2.0 Из -за различного адреса области области usercode (VECT_TAB_ADDR = 0x8000800 вместо VECT_TAB_ADDR = 0x8001000). Эта проблема может сбить с толку людей, которые попытаются использовать V2.0 досок с Arduino IDE, который поддерживает только V3.0. Нехорошо заполнить Arduino IDE слишком большим количеством версий Hid-Bl. Последний достаточно хорош. По этой причине я внес некоторые модификации как в прошивке, так и в программном обеспечении (HID-Upload) - Сторона прошивки - Я изменил пересмотр прошивки на Usb_devicedescriptor версии 3.00 static const uint8_t USB_DeviceDescriptor[] = { 0x12, // bLength 0x01, // bDescriptorType (Device) 0x10, 0x01, // bcdUSB 1.10 0x00, // bDeviceClass (Use class information in the Interface Descriptors) 0x00, // bDeviceSubClass 0x00, // bDeviceProtocol MAX_PACKET_SIZE, // bMaxPacketSize0 8 0x09, 0x12, // idVendor 0x1209 0xBA, 0xBE, // idProduct 0xBEBA 0x00, 0x03, // bcdDevice 3.00 <-----------------------------<< 0x01, // iManufacturer (String Index) 0x02, // iProduct (String Index) 0x00, // iSerialNumber (String Index) 0x01 // bNumConfigurations 1 };

Отличный материал. Есть ли Linux & MacOS HID_FLASH Executables в работах?

[Вассилис - Пн 21 января 2019 г., 19:13] - Для нас хорошо использовать последнюю версию Hid-Bl, но новый релиз v3.0 на стороне Arduino IDE несовместимо с платами, которые уже снабжены Hid-Bl V2.0 Из -за различного адреса области области usercode (VECT_TAB_ADDR = 0x8000800 вместо VECT_TAB_ADDR = 0x8001000). Эта проблема может сбить с толку людей, которые попытаются использовать V2.0 досок с Arduino IDE, который поддерживает только V3.0. Нехорошо заполнить Arduino IDE слишком большим количеством версий Hid-Bl. Последний достаточно хорош.

Еще одна причина подумать о загрузке загрузчика в высокой памяти, а не в начале Flash. У вас может быть загрузчик 10K или 250 байтов, если вы загрузите его в конце. Пользователь не имеет значения, если они загружают свой код по телефону 0x08000000.

[Рик Кимбалл - Пн 21 января 2019 г. 22:15] -

[Вассилис - Пн 21 января 2019 г., 19:13] - Для нас хорошо использовать последнюю версию Hid-Bl, но новый релиз v3.0 на стороне Arduino IDE несовместимо с платами, которые уже снабжены Hid-Bl V2.0 Из -за различного адреса области области usercode (VECT_TAB_ADDR = 0x8000800 вместо VECT_TAB_ADDR = 0x8001000). Эта проблема может сбить с толку людей, которые попытаются использовать V2.0 досок с Arduino IDE, который поддерживает только V3.0. Нехорошо заполнить Arduino IDE слишком большим количеством версий Hid-Bl. Последний достаточно хорош.

Еще одна причина подумать о загрузке загрузчика в высокой памяти, а не в начале Flash. У вас может быть загрузчик 10K или 250 байтов, если вы загрузите его в конце. Пользователь не имеет значения, если они загружают свой код по телефону 0x08000000.

+1 Я обязательно постараюсь поместить загрузчик в высокую память как можно скорее, это избежит умножения сценариев линкеров для различных загрузчиков.

Конечно, сценарий линкера должен был бы знать размер, а не пытаться использовать память загрузчика.

[Рик Кимбалл - Пн 21 января 2019 г., 23:03] - Конечно, сценарий линкера должен был бы знать размер, а не пытаться использовать память загрузчика.

Что ж, загрузчик может проверить, что он не самостоятельный во время мигания, так что об об об об об об этой ошибке может быть сообщено инструмент мигания, скорее, линкером, поэтому мы могли бы избежать прикосновения к сценарию линкера в целом... Я также воспользуюсь некоторыми вариантами определения максимального размера эскиза в плате.TXT или где -то еще в файлах Arduino? Это может быть хорошо, если бы это могло быть указано только для этого конкретного инструмента мигания.

Github Repo обновляется. Новый спрятанный исполняемый файл доступен для Windows, Linux и Mac@Rick Спасибо за идею. Я думаю, что этот подход сложный. Я постараюсь проверить это, хотя.

Один очень незначительный наблюдение Vassilis, я собрал прошивку F4 для работы на Black407zet6, Boot1, PB2, светодиод, PF9 (или 10). Светодиод не моргнет, у меня был нос через код, и заметил, что часы не были инициализированы для GPIOF, поэтому добавили, что и перекомпилировались и до сих пор не получили мигающий светодиод. Любые мысли о том, что это может быть? Пса Кажется, что исполняемые файлы Hid-Flash не в папке CLI? Нашел их в патче, опси

@Bennehboy Я постараюсь сменить светодиодную булавку на мою доску 407 и сообщить вам

[Беннебой - Вт 22 января 2019 г. 10:22] - Один очень незначительный наблюдение Vassilis, я собрал прошивку F4 для работы на Black407zet6, Boot1, PB2, светодиод, PF9 (или 10). Светодиод не моргнет, у меня был нос через код, и заметил, что часы не были инициализированы для GPIOF, поэтому добавили, что и перекомпилировались и до сих пор не получили мигающий светодиод. Любые мысли о том, что это может быть? Пса Кажется, что исполняемые файлы Hid-Flash не в папке CLI? Нашел их в патче, опси

1. Какую репо вы используете ? 2. Какой вариант вы используете ? 3. Является STM32 HID Bootloader появился в Windows Device Manager ? 4. У вас есть схема вашей доски ? 5. Вы подключили светодиод к PIN PF9 и не мигает во время загрузчика или после того, как вы загружаете эскиз в STM32F407ZET ?

1. STM Core - версия GitHub 2. Black407zet6 3. Да 4. http: // wiki.STM32duino.com/images/4/4f/ ... _SCH-1.PDF 5. PF9 & PF10 - это встроенные светодиоды, которые могут моргнуть оба светодиода, используя стандартное мигание.Ино из ядра (или с использованием Роджера). Светодиоды не мигает во время загрузчика. Отлично работает для Black407Vet6 или Diomrue Poard, но оба они имеют светодиоды на GPIO A до E.

Я перекомпилировал исходный код ВЕЛ -> PF9 Boot1 -> PD6 (внутреннее подтягивание включено) Скажи мне, работает ли это

Hid-bl_407zet_led-pf9_boot1-pd6.молния

(10.22 киб) скачано 7 раз

Почему PD6 для Boot1? Это на PB2 в соответствии с схемой...

У нас есть работающий светодиод - вы что -то изменили, или у меня, возможно, возникла проблема с инструментами?

Потому что PB2 на вашей плате подключил усадочный резистор. HID-загрузчик нуждается.

[Беннебой - Вторник 22 января 2019 г., 21:13] - У нас есть работающий светодиод - вы что -то изменили, или у меня, возможно, возникла проблема с инструментами?

Я не изменил ничего другого, кроме как добавить часы для GPIOF __HAL_RCC_GPIOF_CLK_ENABLE();

Хорошо, получил это, так что мы пожимая подтягиваем.

[Вассилис - Вторник 22 января 2019 г. 9:18 вечера] -

[Беннебой - Вторник 22 января 2019 г., 21:13] - У нас есть работающий светодиод - вы что -то изменили, или у меня, возможно, возникла проблема с инструментами?

Я не изменил ничего другого, кроме как добавить часы для GPIOF __HAL_RCC_GPIOF_CLK_ENABLE();

make -v GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for i386-pc-mingw32

https: // github.com/stm32duino/arduino_core_stm32 Во время установки он загружает инструменты отсюда -> https: // github.com/stm32duino/boardmanagerfiles make -v GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for i386-pc-mingw32

На первом шаге для перемещения загрузчика HID к высокой памяти я отправил Новый пр @vassilis. Я изменил стратегию, чтобы использовать USB -опрос вместо USB IRQ Да, я знаю, обычно это наоборот, но цель состояла в том, чтобы не создавать таблицу промежуточного вектора в оперативной памяти, чтобы добавить обработчик USB IRQ: таким Чтобы сдержать обработчик сброса (ПК) и первоначальный указатель стека (SP), даже если бы мы могли жить без этого последнего и установить его в первую очередь в самой процедуре сброса. Это экономит еще пару инструкций (вплоть до 1936 байтов ), но OTOH мы больше не можем использовать петли блокировки задержки для мигания светодиода. Вместо этого я использовал статический счетчик и переключил светодиод, используя немного маски, поэтому «нервное» мигание все еще здесь, однако, вероятно, немного другая частота. Предыдущий «USB_LP_CAN1_RX0_IRQHandler ()» «Обработчик USB IRQ стал" USB_POLL () ", и маршрутизация IRQ в CMSIS CORE" NVIC_ENABLEIRQ () "была удалена, но все остальное не облегчено. В целом, не создавать еще одну векторную таблицу - это хорошая вещь, и в итоге цель состоит не в том, чтобы создать его вообще, а для изменения пользователя, чтобы прыгнуть на загрузчик HID и обратно в приложение, так что SCB->Регистр ядра VTOR не будет использоваться, что позволит тому же загрузчику работать на MCU Cortex M0 (STM32F0XX), который тоже не включает в себя этот регистр. Я также вынудил цикл usb_shutdown ()/usb_init () для выполнения повторного использования USB во всех случаях, а не только при поиске волшебного слова в памяти резервного копирования: мне показалось более удобным, не приходится физически отключать/подключить кабель USB При использовании перемычки Boot1 или когда в памяти не было пользовательского приложения.

Я знаю, что заманчиво продолжать играть, но 2 кб недостаточно хорошо? И я думаю, что высокая память имеет столько же проблем связывания, сколько и низкое - т.е. предотвращение эскиза перезаписать BL... Например, для Bluepill будет 3 возможных сценария линкера, 64 КБ, 128 КБ, 32 КБ (поддельный чертеи), очевидно, только мои 2 цента.

Я не пытаюсь сделать загрузчик меньше, это просто следствие облегчения его Наличие загрузчика в высокой память... Сам BL! Нам просто нужно контролировать это во время мигания. И в любом случае, максимальный размер загрузки может быть намекнут в «плату».txt ", например: mapleMini.menu.bootloader_version.hid_bootloader.upload.maximum_size=129024

Хорошо, если вы сможете обеспечить его не перезаписать, это было бы здорово, версия F4, безусловно, не обеспечивает этого. РЕДАКТИРОВАТЬ - на самом деле не просмотрел код, это могло быть просто плохо связанные кодовые бомбы, и мне пришлось стирать, чтобы разрешить разрешение.

[Беннебой - Пн 28 января 2019 г., 21:21] - Например, для Bluepill будет 3 возможных сценария линкера, 64 КБ, 128 КБ, 32 КБ (поддельный чертеи), очевидно, только мои 2 цента.

Может быть, было бы проще добавить загрузчик, это подход, который вы видите на устройствах PSOC.

Лучший вариант использования, который я вижу для загрузчика MSD, - это то, где у вас есть 2 чертежа, один, который действует как диск, и используя встроенный ROM Serial Bootloader. Загружает код на второй.

Хорошо, у меня есть загрузчик HID, работающий в высокой памяти на Bluepill. На самом деле не имеет большого значения, я просто:

• Изменил сценарий линкера так, чтобы загрузчик был расположен на 2 кб ниже верхней части флэш -памяти (0x800f800 для устройства 64 КБ)
• Начал мигать в начале вспышки, а не оставлять 2 кб для загрузчика
• Перед прошивкой на странице 0, исправлено таблицу пользовательского вектора, чтобы сохранить свой обработчик сброса @ Адрес 0x4 на неиспользованный векторный адрес (0x1c) и вместо этого написать или собственный обработчик сброса
• Проверил, что мы не перезаписываем себя (не пишут страницы > 62 для устройства 64 КБ)
• Позднее получили обработчик сброса пользователя из нашего сохраненного местоположения, чтобы передать ЦП на прошивку приложения
• Больше не изменял реестр VTOR

Я только что протестировал с помощью рисового эскиза для серийного (ROM) загрузчика, и это работает нормально, за исключением того, что этот эскиз, кажется, не пишет волшебное слово в памяти резервного копирования, поэтому я должен ввести загрузчик, перемещая перемычку Boot1. Я не уверен, что патч DTR+ Leaf используется в этой конфигурации, я буду расследовать завтра. Текущий размер загрузчика HID составляет 1924 байт. Текст + 8 байт данных. РЕДАКТИРОВАТЬ: Я изменил доску.TXT и сценарий линкера, чтобы найти эскиз по телефону 0x08000000 (начало Flash) и перекомпилировать эскиз, все работает, как и ожидалось. Я обернусь и отправлю новый пиар.

Добавление сценария линкера предварительно обработает жизнь. Вот раздел от LDScript.LD используется для BluePill: /* Entry Point */ ENTRY(Reset_Handler) /* Highest address of the user mode stack */ _estack = 0x20000000 + LD_MAX_DATA_SIZE; /* end of RAM */ /* Generate a link error if heap and stack don't fit into RAM */ _Min_Heap_Size = 0x200; /* required amount of heap */ _Min_Stack_Size = 0x400; /* required amount of stack */ /* Specify the memory areas */ MEMORY { RAM (xrw) : ORIGIN = 0x20000000, LENGTH = LD_MAX_DATA_SIZE #ifdef HIDBL_F1 FLASH (rx) : ORIGIN = 0x8000800, LENGTH = LD_MAX_SIZE - 0x800 #elif DFUBL2_F1 FLASH (rx) : ORIGIN = 0x8002000, LENGTH = LD_MAX_SIZE - 0x2000 #else FLASH (rx) : ORIGIN = 0x8000000, LENGTH = LD_MAX_SIZE #endif }

Просто посмотрите, как вы обновляете сценарий LD для обработки размера загрузчика. Было бы проще определить переключатель с размером загрузчика, тогда это избежит дальнейшего обновления в случае поддержки новой загрузчика? FLASH (rx) : ORIGIN = 0x8000000 + BL_SIZE, LENGTH = LD_MAX_SIZE - BL_SIZE

Да, я просто думал о том же Фредерик. На этом примечании, могу ли я установить по умолчанию для всех досок 0? Чтобы избежать необходимости устанавливать его для каждого варианта/семьи. Apols для небольшого ОТ.

Я посмотрю, но теперь это на самом деле очень просто, так как пользовательское приложение находится в начале флэш -памяти (Origin = 0x8000000, Length = LD_MAX_SIZE - 0x800).

С загрузчиком в высокой памяти, что произойдет, если приложение сбой ? Я не вижу, как MCU может ввести загрузчик в этих условиях.

[Rogerclark - Пт. 01 февраля 2019 г. 20:56] - С загрузчиком в высокой памяти, что произойдет, если приложение сбой ? Я не вижу, как MCU может ввести загрузчик в этих условиях.

Что вы имеете в виду под "приложением сбоев"? Загрузчик загрузчика заменяет обработчик RHE сброса приложения самостоятельно после мигания, а процессор сначала переходит на загрузчик, после «Boot» и вызывает сохраненный обработчик сброса приложения при выходе. Если приложение вылетает после этого шага, оно не предпочитает входить в загрузчик. Конечно, магическое слово DTR + в памяти резервного копирования может не работать в этих условиях, но перемещение перемычки Boot1 будет. Единственный случай, если вы больше не сможете войти в загрузчик, - если вы перепрофилируете приложение другим средством (Jlink или последовательным), но этот случай не хуже, чем с другими загрузчиками в любом случае.

Загрузчик заменяет обработчик сброса приложения Ах. Вы имеете в виду, что загрузчик изменяет двоичный файл приложения, когда он получает его через HID, чтобы изменить местоположение обработчика сброса по умолчанию, так что, когда плата сбрасывается, код переходит на адрес загрузчика, я.E изменяет «векторный таблица» Таким образом, даже если приложение вылетает, оно не имеет никакого значения, если только приложение не повреждено векторной таблицей (что маловероятно) И загрузчик загружается не только в верхнюю часть флэш -памяти, он также должен содержать векторную таблицу - сброс вектор, чтобы первоначально прыгнуть на загрузчик. Следовательно, необработанный двоичный файл загрузчика должен быть 128K для STM32F103CB ? Или используйте формат файла прошивки, в котором может быть несколько разделов ? Когда должны быть разные загрузчики в зависимости от размера вспышки в MCU. (32K, 64K, 128K и т. Д.) На самом деле, это заставило меня задуматься о большом количестве вариантов загрузчика Maple, из -за различных светодиодных выводов и «Пользовательская кнопка». Теоретически, должно быть довольно просто написать какую -то программу конфигуратора, чтобы изменить светодиодный штифт и вывод кнопки путем изменения двоичного файла, а не поддерживать нагрузки разных двоичных файлов. Тем не менее, конфигуратор, вероятно, потребуется изменить, если какие -либо изменения, внесенные в код, поскольку конфигуратор может быть невозможным автоматически найти, какие части мусорного ведра изменится.

[Rogerclark - Сб 02 февраля 2019 г. 2:55 утра] - Загрузчик заменяет обработчик сброса приложенияВы имеете в виду, что загрузчик изменяет двоичный файл приложения, когда он получает его через HID, чтобы изменить местоположение обработчика сброса по умолчанию, так что когда плата сбросится, код переходит на адрес загрузчика, я.E изменяет «векторный таблица»

Да, точно! Оригинальный обработчик сброса пользователя резервируется в одном из «зарезервированных» векторов в смещении 0x1c, как указано выше в этом потоке.

[Rogerclark - Сб 02 февраля 2019 г. 2:55 утра] - и загрузчик загружается не только в верхнюю часть флэш -памяти, но и с тем, чтобы содержать векторную таблицу - сбросить вектор, изначально перепрыгнуть к загрузчику. Следовательно, необработанный двоичный файл загрузчика должен быть 128K для STM32F103CB ? Или используйте формат файла прошивки, в котором может быть несколько разделов ?

Да, загрузчик содержит 8 байтов (2 вектора) в низкой памяти для минимальной векторной таблицы по адресам 0x0-0x7, содержащей начальный указатель стека (MSP) и обработчик сброса загрузчика, а затем необработанный двоичный файл содержит все устройство. Вспышка. OTOH, если вы используете Hex Intel (.IHEX) Формат, также поддерживаемый утилитой ST-Flash, вы получаете несколько разделов, и флэш-сектора не содержатся в гораздо меньшем файле, хотя они все еще стерты и заполнены 0xff, если вы прочитали обратную память с одним и тем же инструментом.

[Rogerclark - Сб 02 февраля 2019 г., 2:55 утра] - Когда должны быть разные загрузчики в зависимости от размера вспышки в MCU. (32K, 64K, 128K и т. Д.) На самом деле, это заставило меня задуматься о большом количестве вариантов загрузчика Maple, из -за различных светодиодных выводов и «Пользовательская кнопка».

Да, в любом случае, уже есть много различных загрузчиков для различных конфигураций устройства и плат.

[Rogerclark - Сб 02 февраля 2019 г. 2:55 утра] - Теоретически, должно быть довольно просто написать какую -то программу конфигуратора, чтобы изменить светодиодный пин -код и кнопку, изменяя двоичный файл, а не поддерживать нагрузки разных двоичных файлов. Тем не менее, конфигуратор, вероятно, потребуется изменить, если какие -либо изменения, внесенные в код, поскольку конфигуратор может быть невозможным автоматически найти, какие части мусорного ведра изменится.

Очень хорошая идея! Если вы посмотрите на "bootloader_f1/inc/config.H ", на практике не так много разных вариантов, так как внешние ресурсы, требуемые загрузчиком, весьма ограничены:

• Входной штифт, чтобы заставить запись загрузчика (обычно Boot1/PB2), и если он требуется для использования внутреннего резистора подтягивания или нет, мы могли бы добавить полярность
• LED1 PIN -код и, вероятно, его полярность тоже
• в настоящее время неиспользованный PIN -код LED2
• Выходной штифт диска для привлечения внешней схемы USB отключения, опять же с полярностью

Все остальные константы, определенные здесь, могут быть получены из этих настроек. Если мы отказались от поддержки LED2, у нас останется определение только 3 контактов. Учитывая, что порты GPIO в теоре. Полярность потребует 1 дополнительного бита, а входной штифт-1-битный флаг подтягивания. Все это, вероятно, может быть эффективно сохранено примерно за 3 байта или меньше, если мы ограничим возможные порты GPIO. Мы могли бы использовать тот же трюк, что и при хранении обработчика сброса пользователя в «зарезервированной» записи векторной таблицы, или, возможно, использовать 2 доступных вариантов байта в блоке информации о флэш -памяти по адресам 0x1fff f800 - 0x1fff f80f, хотя обработка этих байтов требует значительный объем кода.

[Rogerclark - Сб 02 февраля 2019 г., 2:55 утра] - Когда должны быть разные загрузчики в зависимости от размера вспышки в MCU. (32K, 64K, 128K и т. Д.)

На самом деле я проверил сгенерированный код сборки, и весь код относится к ПК, за исключением записи таблицы вектора reset_handler. Это означает, что загрузчик HID на самом деле является PIC (независимый код положения) и теоретически может быть перемещен в любом месте флэш-памяти, при условии, что на него указывает векторные таблицы с низкой памяти (точка входа Reset_handler является первым местоположением в высокой памяти). Таким образом, мы могли бы генерировать один .Файл корзины, который не зависит от размера памяти флеш .Файлы корзины, которые будут размещены в низкой памяти, содержащей правильный reset_handler для этого устройства, и, возможно, байты конфигурации, которые я предложил в своем предыдущем посте. РЕДАКТИРОВАТЬ: Код является ориентированным на ПК, но есть некоторые абсолютные данные

Я внесли свой вклад в PR на @Serasidis с изменениями, чтобы поместить загрузчик HID в высокую память для STRM32F1XX: https: // github.com/serasidis/stm32_hid_ ... der/pull/7

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

[Squonk42 - Сб 02 февраля 2019 г. 23:10] - Я внесли свой вклад в PR на @Serasidis с изменениями, чтобы поместить загрузчик HID в высокую память для STRM32F1XX: https: // github.com/serasidis/stm32_hid_ ... der/pull/7

Будет ли ядро ​​будет обновлять ? Поскольку код приложения должен будет иметь свой начальный адрес (векторной таблицы), по адресу 0x800000 Или вы думаете, что ядра могут генерировать независимый код позиции ? (Я предполагаю, что код не гарантированно не будет независимым от позиции) КСТАТИ. Я помню, что @jcw aka jeelabs пишет серийный загрузчик, который проживал в высокой памяти, но я думаю, что он по какой -то причине отказался от него (но, возможно, он все еще использует его и развивает его). Вы могли бы написать ему, так как он был активным на форуме несколько лет назад

[Rogerclark - Солнце 03 февраля 2019 12:51] - Использование зарезервированных векторов - интересная идея. Мое единственное беспокойство заключается в том, что добавление кода для чтения данных в зарезервированном векторе может сделать загрузчик больше, помимо границы страницы вспышки. Но я полагаю, что с тех пор, как он сейчас находится в высокой памяти, тогда, вероятно, стоит увеличить гибкость.

Использование последних GCC 8.2.1 от Arm Ltd. (Версия 8-2018-Q4-Major Linux 64-бит), размер загрузчика в настоящее время составляет 1924 байта в высокой памяти, плюс 8 байт для начальной MSP и ПК в низкой памяти, поэтому в высоком уровне осталось 124 байта. Память перед достижением границы страницы 2 КБ (2048 байт), которая должна быть более чем достаточно.

[Rogerclark - Солнце 03 февраля 2019 12:59] - [Будет ли ядро ​​будет обновлять ? Поскольку код приложения должен будет иметь свой начальный адрес (векторной таблицы), по адресу 0x800000 Или вы думаете, что ядра могут генерировать независимый код позиции ? (Я предполагаю, что код не гарантированно не будет независимым от позиции)

HID Bootloader содержит zip -файл для исправления вашего ядра, и этот PR содержит новый обновленный, и @Bennehboy ​​отправляет пиар, чтобы интегрировать его в ядро ​​STM: https: // github.com/stm32duino/arduino_c ... 2/тяга/415 По сути, этот патч заменяет «доску.txt "," платформа.TXT «Чтобы добавить загрузчик HID, включает в себя" usb_serial.CPP "с Magic Word DTR + и добавляет сценарии линкера в соответствии с организацией памяти загрузчика. Было бы здорово обновить свое ядро, но, возможно, подождите немного больше, пока загрузчик HID не станет более стабильным? Я не думаю, что ядро ​​нужно будет сгенерировать PIC, но наличие другого файла для каждого загрузчика - это боль. Мы могли бы взять идею @bennehboy ​​и @fpistm и выполнить Скрипт сценария линкера на платформе «.txt "файл: # preprocess linker file preprocld.name=preproc.ld preprocld.filepath={build.path}/{preprocld.name} preprocld.flags=-DLD_MAX_SIZE={upload.maximum_size} -DLD_MAX_DATA_SIZE={upload.maximum_data_size} recipe.hooks.linking.prelink.1.pattern="{compiler.path}{compiler.c.cmd}" -x c -E -P {preprocld.flags} {compiler.c.flags} {build.info.flags} {compiler.c.extra_flags} {build.extra_flags} {compiler.arm.cmsis.c.flags} "{build.variant.path}/{build.ldscript}" -o "{preprocld.filepath}"

Могу ли я объединить этот пиар, прежде чем ваш пиар -загрузчик объединен? КСТАТИ. Я думаю, что мне может понадобиться слияние платформы вручную.TXT, как я только что изменил платформу.TXT, чтобы исправить ошибку с загрузкой Stlink. Редактировать. Я запутался, я думал, что пиар был для моего ядра, но когда я подробно посмотрел, я увидел, что это ядро ​​STM. Так что мне нужно найти zip -файл, на который вы ссылались, чтобы увидеть, что делает патч Редактировать. Где эта молния Вы можете опубликовать ссылку ? Редактировать Я нашел это https: // github.com/rogerclarkmelbourne/ ... 202_01.молния

Я добавил и обновил файлы в папке инструментов. Примечание. Двоинар Mac не был помечен как исполняемый файл, поэтому я изменил его на исполняемый файл на моей машине Linux. Но это не гарантирует, что разрешения будут работать на Mac. Мне нужно потянуть репо на мой Mac и подтвердить это, но, возможно, тот, кто регулярно использует Mac, может проверить это

Я только Linux, я спросил @serasidis, чтобы обновить инструменты и исправить проблему разрешения.

[Squonk42 - Пн, 04 февраля 2019 г. 5:42 утра] - Я только Linux, я спросил @serasidis, чтобы обновить инструменты и исправить проблему разрешения.

У меня есть машины Windows, Linux и OSX, но я вряд ли когда -либо использую OSX, у меня есть только OSX, чтобы сделать сборки для рабочих клиентов. Я вручную объединяю изменения в доски.TXT и платформа.TXT с использованием моего компьютера Windows (7) позже сегодня.

Глядя на репо github, все, кроме версии Maple_mini, кажется, ориентирована на 64 -килограммовую вспышку. На данный момент, я думаю, это означает, что те, у кого есть 32-километровые или 128-километровые флэш-устройства, должны быть способны редактировать/поставлять правильный сценарий линкера, изменять Makefile и повторно снять. Предварительно скомпилированные двоичные файлы для вышеизложенного на дорожной карте? Я просто думаю о том, как Noobies могут возникнуть в проблемы, которые вводит High Mem.

Maple Mini всегда должен иметь 128K, но, конечно, продавцы могут просто перебраться в C6 MCU как CB Еще одна вещь, которую вы уже рассмотрели с помощью загрузчика с высокой загрузкой памяти, - это конфликт с библиотекой EEPROM, которая также использует высокую память. #ifndef EEPROM_PAGE_SIZE #if defined (MCU_STM32F103RB) #define EEPROM_PAGE_SIZE (uint16)0x400 /* Page size = 1KByte */ #elif defined (MCU_STM32F103ZE) || defined (MCU_STM32F103RE) || defined (MCU_STM32F103RD) #define EEPROM_PAGE_SIZE (uint16)0x800 /* Page size = 2KByte */ #else #error "No MCU type specified. Add something like -DMCU_STM32F103RB to your compiler arguments (probably in a Makefile)." #endif #endif #ifndef EEPROM_START_ADDRESS #if defined (MCU_STM32F103RB) #define EEPROM_START_ADDRESS ((uint32)(0x8000000 + 128 * 1024 - 2 * EEPROM_PAGE_SIZE)) #elif defined (MCU_STM32F103ZE) || defined (MCU_STM32F103RE) #define EEPROM_START_ADDRESS ((uint32)(0x8000000 + 512 * 1024 - 2 * EEPROM_PAGE_SIZE)) #elif defined (MCU_STM32F103RD) #define EEPROM_START_ADDRESS ((uint32)(0x8000000 + 384 * 1024 - 2 * EEPROM_PAGE_SIZE)) #else #error "No MCU type specified. Add something like -DMCU_STM32F103RB to your compiler arguments (probably in a Makefile)." #endif #endif

https: // github.com/serasidis/stm32_hid_ ... der/pull/7 Я возвращаю предыдущую версию Hid-Bl на GitHub, потому что нам сначала нужно поговорить о том, что мы хотим от этого загрузчика Для всех устройств MCU что мы хотим поддерживать и как справиться с лучшей стратегией кода для этого. Например, устройства F40X и F41X имеют 128 КБ в последнем секторе. Это означает, что мы жертвуем много флеш -памяти для загрузчика.

[Rogerclark - Пн, 04 февраля 2019 г., 9:24 утра] - Maple Mini всегда должен иметь 128 тыс., Но, конечно, поставщики могут просто освоить C6 MCU как CB

Или C8, которые на самом деле являются CBS

[Rogerclark - Пн февраля 04, 2019, 9:24 утра] - Еще одна вещь, которую вы уже рассмотрели с высокой загрузкой памяти, - это конфликт с библиотекой EEPROM, которая также использует высокую память. #ifndef EEPROM_PAGE_SIZE #if defined (MCU_STM32F103RB) #define EEPROM_PAGE_SIZE (uint16)0x400 /* Page size = 1KByte */ #elif defined (MCU_STM32F103ZE) || defined (MCU_STM32F103RE) || defined (MCU_STM32F103RD) #define EEPROM_PAGE_SIZE (uint16)0x800 /* Page size = 2KByte */ #else #error "No MCU type specified. Add something like -DMCU_STM32F103RB to your compiler arguments (probably in a Makefile)." #endif #endif #ifndef EEPROM_START_ADDRESS #if defined (MCU_STM32F103RB) #define EEPROM_START_ADDRESS ((uint32)(0x8000000 + 128 * 1024 - 2 * EEPROM_PAGE_SIZE)) #elif defined (MCU_STM32F103ZE) || defined (MCU_STM32F103RE) #define EEPROM_START_ADDRESS ((uint32)(0x8000000 + 512 * 1024 - 2 * EEPROM_PAGE_SIZE)) #elif defined (MCU_STM32F103RD) #define EEPROM_START_ADDRESS ((uint32)(0x8000000 + 384 * 1024 - 2 * EEPROM_PAGE_SIZE)) #else #error "No MCU type specified. Add something like -DMCU_STM32F103RB to your compiler arguments (probably in a Makefile)." #endif #endif

Основная идея с загрузчиком с высокой памятью, по крайней мере, для F1, чтобы иметь возможность скомпилировать эскиз, который совместим с большинством загрузчиков (Serial, Stlink, BMP. DFU, вероятно, также можно преобразовать, но, конечно, не Maple DFU), основанный в нижней части памяти флэш -. В противном случае, если BL помещены в низкую память перед наброзом пользователя, вам нужно будет генерировать один двоичный файл при каждом различном смещении, в зависимости от размера загрузчика. Это меньше проблемы для F4, который имеет загрузчик DFU в ПЗУ, и для которого основное преимущество заключается в том, что загрузчик HID не требует драйвера на стороне хоста. Согласно моему PR, вы можете видеть, что теперь можно поставить F1 Hid Bl, где бы мы ни хотели, и, вероятно, довольно легко сделать то же самое для DFU One. Поэтому я думаю, что это больше вопроса, если мы хотим сохранить бинарную совместимость аппаратного обеспечения для эскизов между загрузчиками, или мы только гарантируем совместимость эскизов на уровне источника.

[Squonk42 - Пн, 04 февраля 2019 12:53] - Основная идея с загрузчиком с высокой памятью, по крайней мере, для F1, чтобы иметь возможность скомпилировать эскиз, который совместим с большинством загрузчиков (Serial, Stlink, BMP.

Это большое преимущество! Один общий файл бина, который можно использовать с серийным, ST-Link и Hid-Bl. Люди должны знать, что сжигание файла со ST-Link с устройством с установленным загрузчиком HID, поврежден загрузчик HID, даже если загрузчик хранится в конце вспышки.

[Squonk42 - Пн, 04 февраля 2019 12:53] - Поэтому я думаю, что это больше вопроса, если мы хотим сохранить бинарную совместимость аппаратного обеспечения для эскизов между загрузчиками, или мы только гарантируем совместимость эскизов на уровне источника.

На мой взгляд, бинарная совместимость аппаратного обеспечения важнее.

[Squonk42 - Пн, 04 февраля 2019 12:53] - ... Поэтому я думаю, что это больше вопроса, если мы хотим сохранить бинарную совместимость аппаратного обеспечения для эскизов между загрузчиками, или мы только гарантируем совместимость эскизов на уровне источника.

Время от времени я видел запросы на форуме по поводу загрузки бинарных каплей, на самом деле я написал сценарий Windows много лет назад, чтобы сделать то же самое: https: // www.хакерс.io/rayburne/avr-fi ... дубликатор Но мои подозрения в том, что > 99% пользователей просто используют IDE для компиляции, ссылки, загрузки. В темных веках компьютеров было время, где «связанные наложения» использовались из -за небольшого основного хранилища, но я не слышал, чтобы этот метод применялся к микроконтроллерам на основе архитектуры Гарварда. Я нахожу эту идею интересной, купи, я вообще не загружайчик, чувак. Луча

[Вассилис - Пн, 04 февраля 2019 г., 16:24] -

[Squonk42 - Пн, 04 февраля 2019 12:53] - Основная идея с загрузчиком с высокой памятью, по крайней мере, для F1, чтобы иметь возможность скомпилировать эскиз, который совместим с большинством загрузчиков (Serial, Stlink, BMP.

Это большое преимущество! Один общий файл бина, который можно использовать с серийным, ST-Link и Hid-Bl. Люди должны знать, что сжигание файла со ST-Link с устройством с установленным загрузчиком HID, поврежден загрузчик HID, даже если загрузчик хранится в конце вспышки.

[Squonk42 - Пн, 04 февраля 2019 12:53] - Поэтому я думаю, что это больше вопроса, если мы хотим сохранить бинарную совместимость аппаратного обеспечения для эскизов между загрузчиками, или мы только гарантируем совместимость эскизов на уровне источника.

На мой взгляд, бинарная совместимость аппаратного обеспечения важнее.

Итак, если я вас хорошо понимаю, вы имеете максимальную бинарную совместимость для эскизов .корзин среди различных загрузчиков? Как насчет F4, тогда?

В чем смысл бинарной совместимости? У каждого загрузчика есть другой размер, так что не будут проблемы с линкером? Обучите меня.

Я согласен с Рэем... Я тоже не вижу никакой потребности в совместимости с бинарной приложением. Обычно это необходимо только в ситуациях с замкнутым исходным кодом. Я не помню, чтобы видел какие -либо файлы приложений для прошивки Arduino с закрытым исходным кодом, или, в этом отношении, многие приложения Arduino с открытым исходным кодом, которые распространяются как двоичные файлы. И со ссылкой на Василис комментарий о том, что люди знают, что они эффективно сделают Hid Bootloader бесполезным, если они загружают через STLINK или сериал... Я думаю, что это сложная концепция, которую нужно объяснить большинству людей, и, скорее всего, будет не понят. Эта концепция напоминает мне о оригинальных платах PSOC Cyoress, которые содержали загрузчик в предварительно установившемся приложении, которое поставляется с платой. Но если пользователи не смогли добавить модуль загрузчика в свои приложения... Как только они загрузили свое первое заявление, доска была эффективно «кирпичкой», потому что больше не мог загружать его. Через некоторое время Cypress понял, что это была проблема, и изменило оборудование, чтобы включить встроенный интерфейс загрузки, похожий на Stlink

[Mrburnette - Пн, 04 февраля 2019 г., 16:29] - Но мои подозрения в том, что > 99% пользователей просто используют IDE для компиляции, ссылки, загрузки.

Вероятно, это верно для эскизов Arduino, где вы получаете источники и имеете бесплатные инструменты, но более спорные для других платформ, и в этом случае бинарная совместимость была бы обязательной.

[Mrburnette - Пн, февраль 04, 2019, 16:29] - в темных веках компьютеров было время, где «связанные наложения» использовались из -за небольшого основного хранилища, но я не слышал, чтобы этот метод был применен к микроконтроллерам на основе Гарвардской архитектуры.

Рэй, я не понимаю твою точку зрения здесь: не могли бы вы уточнить, пожалуйста? Много лет назад я использовал наложения, но я не понимаю ссылки с этим материалом для загрузчика: наложения использовались для загрузки в основную часть приложения для выполнения некоторых задач, тогда как BL - это просто для облегчения прошивки основного приложения. (Кстати, это было не так много лет назад: мне пришлось использовать наложения в проекте с участием запатентованного видео процессора с очень ограниченной емкостью памяти, где приложение было нарезано на различные задачи, загруженные как наложения при необходимости).

[Mrburnette - Пн, 04 февраля 2019 г., 16:29] - Я нахожу эту идею интересной, купи, я вообще не загружайчик, чувак.

Использование загрузчика, который делится обычной ссылкой с MCU (в данном случае, USB) - это хорошее удобство, вместо того, чтобы подключать дополнительные провода для Jlink или Serial (загрузчики тоже по -своему ) программирование.

[Беннебой - Пн, 04 февраля 2019 г. 20:26] - В чем смысл бинарной совместимости? У каждого загрузчика есть другой размер, так что не будут проблемы с линкером? Обучите меня.

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

[Rogerclark - Пн, 04 февраля 2019 г. 20:35] - Я тоже не вижу никакой потребности в совместимости с бинарной приложением. Обычно это необходимо только в ситуациях с замкнутым исходным кодом. Я не помню, чтобы видел какие -либо файлы приложений для прошивки Arduino с закрытым исходным кодом, или, в этом отношении, многие приложения Arduino с открытым исходным кодом, которые распространяются как двоичные файлы.

Несмотря на это название форума и девиз, здесь есть люди, которые не только используют Arduino Framework

[Rogerclark - Пн, 04 февраля 2019 г. 20:35] - и со ссылкой на Василис комментарий о людях, знающих, что они будут эффективно отображать HID -загрузчик бесполезным, если они загружают через Stlink или Serial...

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

[Беннебой - Пн, 04 февраля 2019 г. 20:26] - В чем смысл бинарной совместимости? У каждого загрузчика есть другой размер, так что не будут проблемы с линкером? Обучите меня.

Я не уверен, что кто -нибудь ответил на этот вопрос... Когда загрузчик High Memory Studloader прошивается на MCU, одна часть установлена ​​в основании Flash, а основной корпус загрузчика находится в верхней части Flash. Часть загрузчика, которая находится в основе вспышки, - это только векторная таблица (только такие вещи, как указатель стека, сброс вектор и т. Д., Вероятно, некоторые из ISR, необходимые для USB и, возможно, для Systick и т. Д.) Когда MCU сапится, он всегда читает базу Flash, чтобы получить SP и начальный адрес кода приложения. Таким образом, выполнение затем запускает основной корпус загрузчика, который находится в верхней части Flash Хитрость... При загрузке с HID -загрузчиком с высокой памятью загружается бинарный приложение, оно перезагружает SP и запускает векторы, со своим собственным SP и запуск вектора. Но если вы загрузите один и тот же двоичный, через серийный UART или ST-Link The SP. Векторы не будут обновлены, поэтому высокий загрузчик памяти будет сиротом, так как он больше никогда не будет запущен

[Squonk42 - Пн, 04 февраля 2019 г. 20:49] -

[Rogerclark - Пн, 04 февраля 2019 г. 20:35] - и со ссылкой на Василис комментарий о людях, знающих, что они будут эффективно отображать HID -загрузчик бесполезным, если они загружают через Stlink или Serial...

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

Разве это не концептуальная проблема. У любого, кто использует загрузчик HID-загрузчика, может не быть навыка, чтобы понять, что только потому, что они могут загружать тот же код приложения через последовательный или ST-Link, и он будет работать один раз... Они не могут затем переключиться обратно на загрузчик, не переустановите его

Спасибо, Роджер, очень хорошее и четкое объяснение! В конкретной реализации HID с высокой памяти, не требуется дополнительная ISR для USB (I использовал опрос) или Systick, поэтому требуется только начальный вектор сброса и сброса стека. И поскольку пользовательское приложение будет иметь указатель стека, инициализированное в действительное местоположение оперативной памяти, и мы можем использовать его до его запуска, а затем освободить его, когда BL уходит, нам просто нужно угнать вектор сброса Таким образом, исходный вектор сброса копируется в «зарезервированный» (неиспользованный) вектор ISR приложения (низко-память) пользователя и вместо этого установлена ​​точка входа BL (высокая память). После выхода BL только что сбросит указатель стека на исходный и прыгает к точке ввода пользователя (низкому) пользовательским приложением. Этот угон выполняется на лету BL при прошивении пользовательского приложения, но, конечно, если вы используете внешнее среднее (Stlink или серийный), это не произойдет, и загрузчик HID не будет вызван. Тем не менее, это всего лишь вопрос переустановки вектора сброса, чтобы указывать на точку входа BL.

[Rogerclark - Пн, 04 февраля 2019 г. 9:07 вечера] - разве это не концептуальная проблема. У любого, кто использует загрузчик HID-загрузчика, может не быть навыка, чтобы понять, что только потому, что они могут загружать тот же код приложения через последовательный или ST-Link, и он будет работать один раз... Они не могут затем переключиться обратно на загрузчик, не переустановите его

Я так не думаю: люди, которые установят HID BL, вероятно, будут использовать его удобство (просто прикрепите стандартный USB -кабель, не требуется драйвер) все время, когда он будет установлен STLINK/SERIAL и не переходите вперед и назад между загрузчиками. И если они это сделают, они смогут переустановить его, как они уже делали это, и иметь все инструменты, чтобы сделать это снова, они не будут кирпичить свое устройство.

Мне нравится концепция загрузчика с высокой загрузкой памяти. Но я не уверен, являются ли преимущества больше, чем недостатки Пожалуйста, обновите по мере необходимости... Преимущества

• Имеет ту же конфигурацию линкера и т. Д???

Недостатки

• В настоящее время будет противоречить библиотеке EEPROM

• Может запутать пользователей, думая, что они могут загружать через ST-Link или Serial и вернуться в работу загрузчика без перепрошивания загрузчика

Нет изменений

• По -прежнему требуется свои собственные линии конфигурации в обеих досках.TXT и платформа.текст

• Все еще нужны свои собственные инструменты загрузки

Преимущества

• Имеет ту же конфигурацию линкера и т. Д???

Да, но это также может быть достигнуто с помощью предварительной обработки сценария линкера, так что все настройки BL определяются в платах.TXT и платформа.TXT и общий набор сценариев линкеров используется для всех загрузчиков, или даже используется один монолитный сценарий линкера, как для официального ядра STM.

• Совместимость с бинарным пользователем, при условии, что оно вписывается в память

Недостатки

• В настоящее время будет противоречить библиотеке EEPROM (может быть исправлен с использованием DESICE () в сценариях линкера для определения области вспышки вместо жестких значений в источнике)

• Может запутать пользователей, думая, что они могут загружать через ST-Link или Serial и вернуться в работу загрузчика без перепрошивания загрузчика (Учитывая его преимущества, после того, как они вспыхнут HID BL, пользователи, вероятно, никогда не вернутся к миганию с помощью ST-Link или Serial)

Нет изменений

• По -прежнему требуется свои собственные линии конфигурации в обеих досках.TXT и платформа.текст

• Все еще нужны свои собственные инструменты загрузки

• Все еще не требует конкретного драйвера

Re: все еще не требует конкретного драйвера Я думал о преимуществах / недостатках перемещения на высокую память, а не использование загрузчика HID против DFU, поэтому я не думаю, что драйвер актуален

[Squonk42 - Пн, 04 февраля 2019 г. 22:20] -

• Может запутать пользователей, думая, что они могут загружать через ST-Link или Serial и вернуться в работу загрузчика без перепрошивания загрузчика (Учитывая его преимущества, после того, как они вспыхнут HID BL, пользователи, вероятно, никогда не вернутся к миганию с помощью ST-Link или Serial)

Кстати, это та же проблема с загрузчиками с низкой памяти: если вы прошиваете прошивку, используя либо ST-Link, либо последовательный с соответствующим макетом памяти, который не знает о них, они тоже будут удалены, поэтому загрузчик с низкой памяти VS с низкой памятью. Дебаты с высокой памятью не имеют отношения к этому моменту. Единственными действительными проблемами, по-видимому, является нелинейный размер страницы флэш-страницы для столкновения F4 и библиотеки EEPROM, которые будут лучше решены путем представления символов памяти сценария линкера, а не жесткого кодирования в библиотеку.

[Squonk42 - Пн, 04 февраля 2019 г. 20:25] -

[Вассилис - Пн, 04 февраля 2019 г., 16:24] - На мой взгляд, бинарная совместимость аппаратного обеспечения важнее.

Итак, если я вас хорошо понимаю, вы имеете максимальную бинарную совместимость для эскизов .корзин среди различных загрузчиков?

Сказав "Совместимость бинарного оборудования«Я имею в виду один двоичный файл (созданный эскизом), который можно вспыхнуть, используя различный тип аппаратного обеспечения для загрузки, как ST-Link, серийный адаптер и т. Д. Вы имели в виду что -то другое ?

Хорошо, отлично, теперь я думаю, что единственным недостатком является столкновение библиотеки EEPROM с высокой памятью.

Преимущества

• Прошивка Hid-Bl может быть легко обновлена ​​без влияния на доски.TXT или сценарий линкера

Обычно в обновлении прошивки загрузчика возможно превышать 2 кбаита флэш -памяти, которые мы выделили. Это изменит адрес начала загрузчика HID -загрузчика. Свободная флеш -память также будет уменьшена. А загрузить.maximum_size в доски.текст не имеет реального значения флэш -памяти. Таким образом, существует опасность для составления большого эскиза, и созданный файл будет больше от доступной бесплатной флэш -памяти. В результате часть загрузчика будет перезаписана. Я провел некоторое время, выяснив, как решить эту проблему. Я слегка изменил прошивку CLI и Hid-Bl (не волнуйтесь, он все еще менее 2 кбит ) и я сделал это!

1. CLI рассчитывает размер файла корзины.
2. Он запрашивает бесплатную флэш -память у загрузчика.
3. Загрузчик отвечает.
4. CLI проверяет, если доступная флэш -память больше, чем размер файла bin
5. Если это так, это продолжается с загрузкой корзины
6. Если это не так, он завершает процесс загрузки и печатает сообщение

Итак, как будут решены устройства флэш -памяти разного размера? Будет ли 32 КБ, 64 КБ, & Версии 128 КБ, отправленные для начала с? Или это будет оставлено пользователю? Я думаю, что в любом случае не вводит путаницу для тех, кто не так знаком с тем, что они делают, что, по -видимому, противоречит философии этого изменения - в конце Выберите, какую светодиодную прошивку для использования (и даже тогда она все равно будет работать, если (ы) он пойдет неправильно).

Звучит как кошмар для людей, потому что они сначала должны выяснить, сколько у них вспышка. Кроме того, что касается Vassilis Point о том, что не нужно изменять линкер, если произошло изменение в BL. Прошло много лет с тех пор, как мне пришлось изменить ядро ​​из -за изменений в загрузчику DFU. В настоящее время последний HID BL всего 2K, но с очень небольшим свободным пространством изменений. В долгосрочной перспективе было бы гораздо легче управлять, если бы спрятано было 4K, так как любой, кто так обеспокоен тем, что ему нужно еще 2 тыс. Приложений, вероятно, должен использовать другой MCU. И у нас все еще нет решения для библиотеки eEPROM, за исключением того, что мы ее перемещают, и потенциально тратить 2K для людей, не использующих этот загрузчик, если мы не добавим какой -то метод для библиотеки EEPROM, чтобы узнать, когда был выбран высокопоставленный загрузочный загрузчик памяти. И все эти изменения для неверной потребности в бинарной совместимости, которые, я не думаю.

[Rogerclark - Вторник 05 февраля 2019 г. 20:39] - В настоящее время последнее Hid BL - всего 2K, но с очень небольшим свободным пространством изменений.

В моем пиаре, который можно использовать либо в низком, либо с высоким уровнем, размер BL в настоящее время составляет 1924 байта, далеко (124 байта, ~ 6%) от предела страницы 2K (2048 байт). Прямо сейчас, помимо этой дилеммы с низким/высоким мем, не так много ожидаемых изменений в трубе.

[Rogerclark - Вторник 05 февраля 2019 г., 20:39] - и у нас все еще нет решения для библиотеки EEPROM, за исключением того, что они ее перемещают, и потенциально тратить 2K для людей, не использующих этот загрузчик, если мы не добавим какой -то метод для библиотеки EEPROM, чтобы узнать, когда Выбран загрузчика Hid Hid Hid Hid.

То, как библиотека EEPROM обрабатывает свое вспышка, является безобразным: в комментарии есть даже «хала -оповещение» чуть выше его определения в источниках. По сути, пользователь должен определить символ препроцессора в соответствии с правильным процессором Правильный способ обработки этого - экспортировать символы линкера в скрипте линкера, чтобы обеспечить правильный размер вспышки (возможно, включая BL) и использовать их для резервного правильного местоположения и размера для пространства EEPROM, не требуя, чтобы пользователь что -либо изменил по рука.

[Вассилис - Вторник 05 февраля 2019 г. 18:31] - [Итак, существует опасность для составления большого эскиза, и созданный файл будет больше от доступной бесплатной флэш -памяти. В результате часть загрузчика будет перезаписана.

Нет, в PR, который я отправил, загрузчик отказывается перезаписать себя. Эскиз пользователя не будет полностью написан, но нет шансов забрать устройство. Единственный способ уничтожить BL-это использовать либо ST-Link, либо последовательный BL, но это также относится к всем загрузчикам с низким уровнем MEM (включая DFU и Maple), если вы прошиваете прошивку, которая не знает о местоположении загрузчика и размер.

Недостатки

• Слишком много двоичных файлов загрузчика

При загрузчике HID с низкой памяти мы должны выбрать F103 в соответствии со светодиодным выводом из-за производителя платы. На загрузчике HID с высокой памятью, за исключением светодиодного штифта, мы должны выбрать размер вспышки, потому что есть F103 с 16, 32, 64, 128, 256, 512, 768, 1024 кбайт флэш-памяти. Загрузчик загружается за последние 2 кбаита. Так что это может быть небольшой проблемой не для конечного пользователя, а для тех, кто собирается переписать файлы Makefile и LD загрузчика и LD . Требуется много работы, чтобы сделать загрузочный загрузчик с высоким уровнем MEM, потому что для изучения слишком много переменных для.

Я подумываю изменить компиляцию F103 HID-BL, полученные на что-то подобное: make FLASH_SIZE=64 RAM_SIZE=20 LED_PIN=PC13 LED_ON=HIGH make FLASH_SIZE=64 RAM_SIZE=20 LED_PIN=PC13 LED_ON=HIGH DISC=PB9 DISC_EN=HIGH

Это определенно легче управлять, чем иметь несколько целей в файле Make Зачем необходим размер вспышки, это только для высокой версии памяти ? Вам нужны и Disc_en, и Disc_pin ? Эн.глин. Можете ли вы иметь диск без диска ? Также. Я думаю, что @Squonk42 работал над системой, чтобы настраивать большинство, если это изменить двоичный компилятор. Он собирался сохранить информацию конфигурации в неиспользованном месте в векторной таблице, и загрузчик прочитал эти данные и использует ее для управления, какой PIN -код является светодиодом и т. Д Таким образом, вам не нужно иметь конфигурации сборки для светодиодного штифта, и, возможно, не для некоторых других настроек

Да, управление всеми этими целями - это просто боль. Если мы удалим неиспользованный LED2, HID BL имеет больше всего 3 пина:

• загрузочный штифт, используемый для заставления входа в загрузчик. По умолчанию PB2/Boot1 на BP, который имеет перемычку для него, а также для Boot0, и комбинация Boot0 = High + Boot1 = LOW на самом деле не использовалась. Мы могли бы жестко кодировать номер PIN для этой функции, но это может быть полезно, чтобы он настраивался для пользовательских плат.
• светодиодная булавка. По умолчанию PC13 на BP
• Диск. Не нужно на BP, но используется для платы клена, которая имеет внешнюю схему отключения USB. По умолчанию для клена - PB9

Если мы определим «пин» как название порта или номер (теоретически от «A» до «g», но более реалистично от «A» до «C» или от 0 до 3) плюс бит (от 0 до 0 до 0 до 0 15), это может быть упаковано в 7 бит с зарезервированным портом (4) для неиспользованных булавок. Часто существует необходимость определить булавку как Active_low или Active_high, поэтому 8 -й бит можно использовать для этой цели. Затем некоторые контакты могут потребоваться быть установленными в конкретный режим/CNF в смысле таблицы конфигурации порта порта. Для STM32F103 это здесь: https: // www.ул.com/content/ccc/resource ... f#page = 161 Например, загрузочный штифт может потребовать внутреннего подтягивания для кленовой платы, тогда как он находится в режиме плавающего ввода для других плат, имеющих внешний резистор подтягивания. Светодиодный штифт, как правило, является выходом из толчка, но вывод диска-выходной сигнал с открытым дрендом. Эта конфигурация режима PIN требует 4 бита на вывод, а минимальный необходимый размер для хранения конфигурации PIN, таким образом, 3 * (8 + 4) = 36 бит = 4.5 байтов. Ram_size не требуется, и Flash_Size требуется только для высокопоставленной BL BL. Большинство STM32 имеют «зарезервированные» векторы в своей векторной таблице и адреса 0x0000001C - 0x0000002B (16 байт) и 0x00000034 - 0x00000037 (4 байта), кажется, одинаковы для большинства чипсов. В моем PR с высокой памятью я использовал адреса 0x0000001C - 0x0000001F (4 байта), чтобы сохранить оригинальный вектор сброса пользователя, чтобы прыгнуть после запуска BL, но я мог бы также использовать вторую область. Мы могли бы использовать 0x0000001C - 0x0000002B для хранения конфигурации PIN -кода и настройки их во время выполнения, а не исправлять их во время компиляции, как сегодня, это не потребует большого кода в BL. Но тогда есть необходимость в том, чтобы инструмент прошивал эту конфигурацию: он может быть с помощью ST-Link или Serial BL или использования конкретного наброска, но я не знаю, насколько это практично для пользователя, хотя и на этом Тема приветствуется! РЕДАКТИРОВАТЬ: Размер вспышки можно определить во время выполнения, используя регистр f_size (адрес 0x1ffff7e0 на STM32F103C8T6).

@Squonk42 Я предположил, что «конфигуратор» должен быть какой -то формой веб -приложения. Изначально я, возможно, PHP. Но снова думая, я думаю, что JavaScript, вероятно, может сделать это. Я знаю, что есть библиотеки JS для динамического генерации PDF, а затем заставлять браузер думать, что пользователь загрузил файл, поэтому я предполагаю, что для этого можно сделать что -то подобное. Пользовательский интерфейс может быть очень простым, просто несколько выпадающих меню, радиопроизводства и т. Д

Нашел это https: // eligrey.com/demos/filesaver.JS/ https: // github.com/eligrey/filesaver.младший Похоже, он может сохранить двоичные файлы

Я просто подумал об использовании текстового кодирования для булавок:

• Характер 1: Порт: «А» до «g», «x» для неиспользованных булавок
• Персонаж 2: Бит: в ASCI-кодированном шестигранном
• Символ 3: Активное состояние: «L» для активного низкого штифта, «h» для активного вывода, «x» для неиспользованных булавок
• Символ 4: режим GPIO/CNF: «P» для вывода нажимания, «O» для вывода с открытым дрэном, «P» для вывода напрокат альтернативной функции, «O» для альтернативной функции Open-Drain «A» для аналогового ввода, F »для плавающего входа,« D »для ввода с выпуском« U »для ввода с подтягиванием,« x »для неиспользованных выводов

Например, BP: "b2hfcdhpxxxx"

• B2HF => ПB2 является активным-ЧАСинициатор ФонОсвобождение входного штифта для загрузочного штифта
• CDHP => ПВ13 (13 декабря - шестигранник Дюймовый) является активным-ЧАСинициатор ПВывод USH-PULL для светодиодного штифта
• Xxxx => неиспользованный штифт для диска

Это может быть сгенерировано с помощью любого инструмента редактирования текста, включая веб-страницу, содержащую встроенный сценарий JS, который вычисляет это значение из выпущенных меню, как вы предлагаете. Что касается размера BL, мы могли бы использовать соглашение об именах в дескрипторе USB, чтобы вернуть описание памяти, очень похоже на расширение DFUSE STM на стандартный DFU: https: // github.com/dangerousprototypes/ ... G/проблемы/5 Например, АД со вспышкой 64 КБ, с HID BL 2 КБ в низкой памяти: @Internal Flash /0x08000000/2*001Ka,62*001Kg

[Rogerclark - Ср. 06 февраля 2019 г. 20:09] - Зачем необходим размер вспышки, это только для высокой версии памяти ?

Да, это для высокой памяти BL. В тестовом скрипте, который я написал, размер области кода пользователя рассчитывается на лету во время компилятора загрузчика в соответствии с атрибутом flash_size. Адрес начала загрузчика передается в качестве атрибута для STM32F103.LD файл. Обычно атрибут ram_size не требуется, но добавляется, потому что сценарий линкера также определяет размер ОЗУ. Серия F103 имеет от 6 до 96 кбайт ОЗУ

[Rogerclark - Ср. 06 февраля 2019 г. 20:09] - Вам нужны и Disc_en, и Disc_pin ? Эн.глин. Можете ли вы иметь диск без диска ?

У меня есть две разные платы с разными дисковыми цепями, которые позволяют USB, установив низкий уровень диска. Может быть, есть доски, которые позволяют USB с активным высоким. Я добавил атрибут DISC_EN, чтобы покрыть это дело.

[Squonk42 - Ср. 06 февраля 2019 г. 9:14 вечера] - Мы могли бы использовать 0x0000001C - 0x0000002B для хранения конфигурации PIN -кода и настройки их во время выполнения, а не исправлять их во время компиляции, как сегодня, это не потребует большого кода в BL.

Это интересно !

[Squonk42 - Ср. 06 февраля 2019 г. 9:14 вечера] - Но тогда есть необходимость в том, чтобы инструмент прошивал эту конфигурацию: он может быть с помощью ST-Link или Serial BL или использования конкретного наброска, но я не знаю, насколько это практично для пользователя, хотя и на этом Тема приветствуется!

Может быть, особый атрибут инструмента Hid-Flash может сделать эту работу

[Вассилис - Ср. 06 февраля 2019 г., 23:55] - Да, это для высокой памяти BL. В тестовом скрипте, который я написал, размер области кода пользователя рассчитывается на лету во время компилятора загрузчика в соответствии с атрибутом flash_size. Адрес начала загрузчика передается в качестве атрибута для STM32F103.LD файл.

Прямо сейчас сгенерированный код сборки почти независимый от положения. Все инструкции по вызовам и филиалам являются ПК-релагированными, неконфессиональные данные хранятся в оперативной памяти, поэтому не проблема, единственная проблема-это данные CONST, к которым доступны относительно ПК, но используя бесполезную литеральную таблицу. ценности Мы могли бы переделать созданный источник сборки, но это будет больно, так как эта работа должна быть выполнена для каждой версии. Я думаю о чистом решении C, которое состоит в том, чтобы определить все данные Const (в основном USB-дескрипторы) в одну структуру, и определить указатель на эту структуру как неконфессиональную (i.эн., В ОЗУ), что мы будем инициализировать себя сразу после загрузки (поскольку у нас нет сгенерированного неконфессиональным инициализатором данных, сгенерированным инструментами, автоматическим инициализатором данных при запуске). Затем мы могли бы разместить этот указатель в соответствии с нашей кодовой позицией в флэш -памяти и косвенно получить к нему доступ к правой перемещенной позиции... Это решение, которое я сейчас исследую. Если это сработает, нам придется только генерировать одну версию HID Bootlader в произвольном месте в флэш-памяти, которая, таким образом, будет переместить свои не связанные с ПК данные Const, и настройка Flash_Size больше не потребуется.

[Вассилис - Ср. 06 февраля 2019 г., 23:55] - Обычно атрибут ram_size не требуется, но добавляется, потому что сценарий линкера также определяет размер ОЗУ. Серия F103 имеет от 6 до 96 кбайт ОЗУ

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

[Вассилис - Ср. 06 февраля 2019 г., 23:55] - У меня есть две разные платы с разными дисковыми цепями, которые позволяют USB, установив низкий уровень диска. Может быть, есть доски, которые позволяют USB с активным высоким. Я добавил атрибут DISC_EN, чтобы покрыть это дело.

С помощью кодирования моего штифта, описанного выше, вы действительно можете определить диск как активный низкий или высокий.

Хорошо, теперь у меня есть загрузчик HID STM32F1, который полностью перемещается, все еще не требуется сборка, размер - 1960 байт. Я имею в виду: то же самое .Файл корзины можно вспыхнуть в любом месте, вам просто нужно указать обработчик сброса в векторной таблице @ 0x4 на базовый адрес HID Bootloader + 1 (для флага большого пальца Arm в адресе LSB). Теперь я должен выяснить, как сохранить и декодировать конфигурацию PIN -кода, и у нас будет один двоичный файл HID -загрузчика STM32F1, который будет обрабатывать все конфигурации PIN и память. Затем он может быть интегрирован как капля в эскиз установщика, который может сжечь его в верхней части флеш.

Очень хорошо !

Если/когда версия High MEM выходит в Интернет, может ли версия снова нанести удар, а поддержка версии с низкой памятью остается нетронутой в инструменте HID-Flash?

Да, версия будет удручена, и в любом случае, BL останется в низкой памяти для F4, так как страницы с высокой памяти больше. Но для небольших MCU версия с высокой памятью была бы хорошей особенностью, так как она добавит поддержку процессоров Cortex M0, которые не имеют регистров VTOR, при условии, что мы можем иметь единый релокатный двоичный файл для всех комбинаций памяти и GPIO.

У меня здесь около 20 устройств F1 с Hid 3.0 Вкл - я не хочу снова их прошивать