Axel

Может и не единственное, но безусловно правильное. Со времен 51-х контроллеров (а может и раньше) DIP-свитчи рекомендуют подключать через резисторы и TVSы.

Ну да, непросто. А Вам критично использовать 32 бита? Как вариант: развести 16 бит на частоту выше 150 MHz вполне реально (сам делал, без резисторов). Может в этом случае скорости хватит?

Ну почему же? Если сможете 8/8 (а лучше 8/10), плюс ресисторы (30÷50)Ohm, то вполне можно разогнать до 100 MHz и выше.

Вам критики надо? Их есть у меня:) Очень поверхностно: - 850 mil -> 200 ps. Гарантированная работоспособность не превысит 100 MHz - 6/6 mil без сериальных резисторов - замучают звон и кросстоки. В лучшем случае заработает с приторможенными пинами (в случае STM32F429 это 50 MHz) Conclusion: (ИМХО) не полетит...

В лампочку? Да еще в марице... И с целью экономии... Ну да...

Правильный был ШИМ... При таком управлении пиковые токи могут существенно превышать средний, соответственно снижение надежности.

Необходимость выравнивания легко оценить по временнЫм диаграммам с учетом погонной задержки ПП 6 ps/mm. Аналогичный дизайн с проводниками в пределах (10÷21)мм (адрес, данные, команды) устойчиво работает на 168 MHz. Более существенно растащить их пошире для минимизации кросстоков (калькулятор Saturn в помощь). Заливка на таких частотах (и при размещении сигнальных проводников только на внешних слоях) имеет смысл (ИМХО) только для поддержания баланса меди.

В общем случае Вы безусловно правы. Но при наличии повышенных требований к защите информации, Заказчик может позволить себе не заморачиваться формулированием их (требований) в весьма мудреных терминах отрасли, а потребовать использования уважаемых им (Заказчиком) протоколов.

BLE5.0. В SDK от Nordic MTU определена 247 байт. Объяснение где-то видел (но где - сейчас не помню). Минус три служебных байта (opcode и connection handle)

Может оно и так... Я недавно соорудил что-то типа "bulk" сервиса на базе примера UART (Nordic). Там все нормально работает: notification сообщает объем, и все, что приготовил, нормально прилетает , естественно в пределах MTU (244 байта). Со стороны телефона использовал для отладки nRF connect. В том, что происходит внутри нее, не разбирался (пока).

В дескрипторе вроде как можно только ограничить размер (сверху и снизу). Длину конкретной транзакции все равно надо сообщать через "notification"

Так вроде для этого есть "indication". Хотя в Вашем случае восможно проще было-бы ввести статусный байт (передавать 2 или 3 байта - разница не драматическая).

Здесь как-то бсе больше про ARMы... А по сути: если только "read" - то нет. Для жтого нужно "notification". И минимальная длина "0" для "read" выглядит несколько странно...

Прошу прощения за вероятный оффтоп... В последней (15-й) версии nRF52 SDK появилась симпатичная примочка: task manager. Скромная (есть только task и event), но экстремально легкая. Под спектр задач, которй я могу представить себе для, например nRF52832, вполне годится.

Вдумчивость - она по способнастям, так что я уж как могу... Проект у меня собирается, и даже начинает шевелиться в железе. А на счет что С не замечает ворнингов... "Вот ты суслика не видишь, а он есть! ©". Но Вашему совету вероятно последую. Спасибо.

Не поэтому. Я C++ пользую, а он к этим моментам относится более трепетно...

Я пока так и сделал, спасибо.

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

"...в каком месте FreeRTOS этот ворнинг и какая версия OС?" Версия довольно старая - 8.2.1 (она идет в составе последнего SDK от Nordic). Обновлять до последней (10-й) версии для меня - ввязаться в процесс починки непонятного неизвестным. Не вдохновляет (пока)... Ворнинги - по поводу компиляции файла "task.c" в ситуациях типа "portRESET_READY_PRIORITY( pxCurrentTCB->uxPriority, uxTopReadyPriority );" "Да, уж..."©

В связи с упражнениями с nRF52832 и евойным SoftDevice пришлось обратиться к FreeRTOS. Естественно возникли вопросы, например: при компиляции проекта возникает куча жалоб типа "Warning[Pa082]: undefined behavior: the order of volatile accesses is undefined in this statement...". Суть понятна, но поскольку отследить использование этих volatile'ов в коде ОС непросто, присутствует "неприятный осадок". Стоит ли переживать по этому поводу?

Ну да, я вдогонку тоже сообразил... Такой подход может снизить влияние дрейфа и, судя по параметрам Ваших датчиков, имеет смысл, если Ваша плата в процессе работы ощутимо меняет температуру. Но более серьезную проблему - шум, он не решает. Здесь только правильное подлючение, усиление, аналоговый фильтр и последующая обработка. Ну и STM32f373 в Вашем случае выглядит (ИМХО) несколько избыточным.

Рискну предположить, что рассчитывать на 12 бит с опорой 1В (на ST) - затея малоперспективная. Более предпочтительно (ИМХО) использовать хорошо подключенный 2.5 V ИОН и усилить входные сигналы. Что-то подсказывает, что Ваша газовая среда может быть несколько проводящей, т.е. возможны утечки на землю (и не только). Поэтому имеет смысл подумать о защите и использовать отдельный сигнальный общий провод.

В общем - нет. Вот наоборот - да (но это Вы и сами знаете).

Option bytes в обоих случаях (J-Link и ST-Link) не сравнивали?

По моим впечатлениям - помогает. По крайней мере так советуют (напр. здесь). Видел также рекомендации использовать коденсаторы с бОльшим Ripple Current. В гугле по этому поводу много чего...