gerber

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

Из опыта монтажа QFN на автоматических линиях. Часто сталкивался с тем, что центральный пад QFN после пайки оказывался непропаянным и не контачил электрически с площадкой на плате, как бы парадоксально это ни казалось. В том случае, когда этот пад GND, и это единственная "земля" в распиновке чипа - схема оказывается неработоспособной, причем иезуитски неработоспособной, так как "на первый взгляд" она работает, но при более тщательном тестировании отказывает. По всей видимости, это особенно актуально на малослойных платах, где подвести полноценный медный полигон к центральному паду (который подведет и тепло при оплавлении) не всегда возможно. А прогревать этот массивный пад и его площадку, зажатые между корпусом чипа и текстолитом - надо. При отсутствии нормального полигона прогрев пойдет фактически по дорожкам. Таким образом, большая "дыра" просто облегчает подведение тепла к паду в центре, играя роль массивного медного полигона, ну и путем конвекции. К тому же и облегчает оптический контроль пропаянности без применения рентгена.

Проще после дисконнекта в ребут уходить.

Наверное, Vendor ID ? Вряд ли дело в этом, хранить в BIOS весь перечень вендоров? А обновлять его как? Если что и может влиять - это класс PCI устройства, я видел, что некоторые мат. платы не работают с BIOS Extension, если устройство произвольного класса. Точно работают, к примеру, сетевые контроллеры.

А как вы определяете сей факт, если у вас нет в штате "аппаратчиков"? Определить это можно, только подключившись к FPGA "чипскопом" (или как там у Альтеры...) Тут 2 варианта: 1) код вычитывается, но ему просто не передается управление, смотреть в сторону UEFI и цифровой подписи содержимого Boot ROM плат расширения, 2) код не вычитывается. Тут, видимо, вряд ли что-то можно сделать, просто на данной платформе функция PCI Boot ROM Extension урезана за ненадобностью. Вообще говоря, это анахронизм x86 платформы, идущий со времен DOS-а, когда код, спрятанный в BIOS Extension, позволял упростить драйвера сетевых/видео карт. Сейчас это вряд ли кому нужно, драйвера в ОС подхватывают сложное железо и без таких заморочек.

Мелкая плата явно не 35 точек пайки, скорее всего, опечатка и там 350 точек.

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

Помнится мне, что inline работает при высоких уровнях оптимизации, при нулевом inline-функции вызываются, как обычно. Также inline-функции должны находиться в h-файле. И ещё можно посмотреть в сторону noinline/forceinline атрибутов.

Если речь про SoftDevice, то пример от Нордика, запущенный на их отладке PCA10040, передающий на ПК данные на PHY-скорости 2 Mbit/s с использованием Nordic USB dongle показывает среднюю скорость около 10 Кбайт/c.

Можно пойти ещё дальше, в этой же структуре хранить указатель на функции, которые с ней работают. Ещё немного, и C++ заново изобретем. А идеология структурного программирования на C предполагает, что грамотно структурированная программа так разделена на функции, что каждая из них делает какое-то одно осмысленное действие, и соответственно, не требует на входе множества разнородных параметров.

Похоже, что координаты. А при чем тут скорость? ТС интересует адекватность пришедших данных шкале времени, именуемое в просторечии "реалтаймом".

Ну фиг знает, изохронные каналы в Bluetooth заточены, в основном, под передачу звукового потока, и все примеры ориентированы на это. Я пробовал (на другой платформе, не Nordic) задействовать изохронные каналы под передачу произвольных цифровых данных с минимальной задержкой. Получилась такая петрушка, что baseband эти данные подвергает сжатию перед передачей по эфиру, а на приемной стороне распаковывает поток. И сжатие это совсем не lossless, то есть производится с учетом ограниченной полосы звука. На стороне приема байты "не те", что были переданы. Таким образом, придется городить что-то вроде программного модема, и "вечер перестает быть томным" :)

Когда-то делал удлинитель RS-485 по Bluetooth, для железа, очень требовательного к таймингам. Работало. Путем выкручивания QoS удавалось добиться задержек не более 4 мс. НО: это не BLE, классический Bluetooth на своем миниатюрном стеке поверх HCI протокола.

Никакого реалтайма от BLE в исполнении nRF52832 (S132) ожидать не приходится, запустил демо от Нордика, измеряющее пропускную способность BLE-канала на 2 Мбит/с на отладке PCA10040, которое шлет порции данных по 1 Кб, разброс времени на каждый пакет от 20 до 600 мс.

Как работает защита на встречных стабилитронах, мне понятно. А можете пояснить, как 2 встречных NMOS обеспечивают ограничение входного напряжения? Ведь в них же есть body-диоды...