turnon

Все что требует от пользователя каких либо действий с компом (настройки сети, установки драйверов) крайне желательно избегать. Это источник проблем. Потому да, голый USB HID самое то.

https://ru.wikipedia.org/wiki/Модульное_тестирование

Мне нравится вариант как описал @jcxz здесь

У меня работа с железом 10% от всего кода. И если я 90% кода буду отлаживать светодиодами и сообщениями, это займет на порядок больше сил и времени. Сейчас вообще сделал консольное приложение, где гоняю юнит тесты на googletest. Вся разработка ведется через написание тестов. Модератор: решили почти через год продолжить тему? Это хорошо. Только не забывайте о правиле 3.3.3.

Неужели вам это нравится?

Это вы еще не добрались до новой версии настроек модуля a, размер которых станет больше и затрет все что ниже (модуль b и с). Надо резервировать пустое место между модулями, контролировать что они не пересекаются при добавлении настроек.

Вот правильно, тоже все так делаю. Только разъем компактнее - PLL-1.27. И RST все таки обвязан конденсатором и подтягивающим резистором. BOOT0 да, на землю, никогда не было необходимости его использовать. Еще на SWDIO/SWCLK вешаю по 100 pF, где-то подсмотрел, при длинном проводе от программатора может помочь. В итоге один программатор и один разъем и на STM32F0, и на STM32F2/F4, да и вообще на любые кортекс. На входе LDO немного заморочился, поставил проходной конденсатор типа NFM21P, чтобы "иголки" давить. Ну это скорее плацебо.

Я активно использую симулятор, гоняю юнит тесты. 80% времени разработки провожу в симуляторе. Это почему же? А как отлаживать, светодиодами и printf'ами?

Соглашусь, в Вашем случае это именно так. У меня другой сценарий - хранятся накопленные данные с датчика температуры, потеря информации тем критичнее, чем больше объем потери. Почему сектор не читается - я не знаю, нигде нет информации о том, как именно выходит их строя NOR-флеш. Но предполагаю, что с износом ячеек они не могут установиться в 0xFF при очистке сектора. И износ разных секторов может быть неравномерным несмотря на равномерную перезапись. Обеспечивается точно также как и в Вашей. Вся разница - у вас признак головы в виде сектора-дырки, в моем случае (точнее piconomix) - в виде максимального индекса в хидере сектора. Все.

А я рассматриваю. Какой х?

Я же давал ссылку на описение - Piconomix FW Library, там и исходники есть, все можно посмотреть. Как есть я ее не использую, использую заложенные принципы работы - нарастающий индекс в хидере каждого сектора. В Вашей тоже много интересного - COBS, маскирующий 0xFF и разделитель записей в виде байта 0xFF, "двухфазное" стирание. Остюда еще думаю задействовать побитовую запись статусного байта. Отсюда - принцип посекторного сжатия данных. Теряются не больще чем в Вашем алгоритме при сбоях питания. И намного меньше терятеся в случае проблем с чтением сектора-дырки.

Нет, если не удалось прочитать последний сектор, читаем предпоследний - тот что был 1 изменение назад. Ну и у меня там хранятся архив измерений с датчика, потерять 1 сектор - не так критично как потерять весь объем фоеша из-за порчи местоположения головы. Там как раз все потерять нельзя, потому как все сектора равнозначны, нет какого-то специфичного, как в Вашем алгоритме.

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

Например как в Piconomix FW Library: "To figure out which page contains the oldest records (FIRST page) and which page contains the newest records (LAST page), a rolling (or wrapping) number is assigned to each page. This means that each consecutive page is labelled with an incrementing number. If the number exceeds the maximum, it starts again at zero (rolls over)." Это не столь важно. Просто возьмем случай что сектор не читается.

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