gerber

Это особенность работы BLE-стека от Nordic, так называемый Soft Device, который дается Нордиком в бинарном виде. Простыми средствами тут вряд ли что-то можно сделать, разве что посмотреть на отладках последнюю версию Soft Device, в надежде, что они пофиксили этот баг.

Осваиваю работу с GPS приемником U-BLOX MAX-M10S, через программу u-center 20.10. Меняю что-нибудь в конфигурации (например, включаю GLONASS в CFG-GNSS config), это работает до повторного включения питания приемника. Пробую сохранить конфигурацию во FLASH (CFG-CFG -> Save Current Configuration ... ) - тоже не помогает. Даже смена baudrate uart порта не запоминается приемником. Что я делаю не так? Есть подозрение, что у приемника вообще нет флэшки, только вот как удостовериться в этом?

Вот-вот, и у меня сложилось именно такое же впечатление, как будто бы флюс из пасты растекся по паду раньше припоя и создал некую оболочку, через которую расплавленному припою сложно протечь, этакая граница двух горячих жидкостей. После демонтажа непропаянных 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-диоды...

Думаю, что светодиод стоит для индикации активности обмена, при включении в обратной полярности он бы светился в пассивном состоянии линии. По фото видно (по шелкографии светодиода), что он стоит параллельно светодиоду оптрона, анод к аноду, катод к катоду. Возможно. Но 1) зачем их обозначать ref des - ом "FET", 2) как они защищают без соединения с землей устройства? Если соединить входы диодами с землей - теряется весь смысл опторазвязки, как бы... Вобщем, запросил срисовать маркировку этих SOT-23.

На руках только фотография. Схемы платы также нет. Шелкография на плате подписывает транзисторы как FET, из этого делаю вывод, что это полевые транзисторы. К сожалению, добраться до живой платы нет возможности. Хочу сделать аналогичный опторазвязанный вход RS-422 в своей схеме, поэтому интересен вопрос схемотехники входа в серийном устройстве. Не похоже, TVS диоды соединяются одним выводом к земле, здесь очевидно, что соединения с землей нет. SOT-23 элементы стоят "на проходе" каждой линии A/B. Как я понимаю, если подать линию RS-422 напрямую на оптрон, то когда оптрон будет закрыт, к нему будет приложено обратное напряжение порядка 5 вольт, что близко к предельно допустимому для оптрона. Возможно, это обычные диоды (и поэтому вывод 1 никуда не соединен), только с высоким допустимым обратным напряжением?

Это вход RS-422, через транзисторы заведен на оптрон, его открытый коллектор далее идет в схему (левая часть картинки) и там все понятно. Вопрос про транзисторы, зачем они, и как реализуют защиту от перенапряжения по входу, о которой идет речь в документации на плату.

На приведенной картинке фрагмент платы, реализующий опторазвязку дифференциального входа RS-422 с защитой (если верить документации на плату) от перенапряжения по входу. Оптопара - HCPL-0600, D4/R19 - индикация наличия сигнала на входе. Все цепи сверху, с обратной стороны платы в этой части никаких цепей нет. Как я понимаю, защита входа от перенапряжения реализована двумя FET-транзисторами FET6, FET8, тип транзисторов на фото не виден, можно предположить, что один P, другой N-типа. Также не видно, куда уходят Gates этих транзисторов, либо "висят в воздухе" (что маловероятно), либо соединены с Drain-выводом под корпусом SOT-23. Может кто-нибудь пояснить, как работает такая защита входа?

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

Когда-то изучал похожий вопрос, есть микросхемы Static RAM со входом резервного питания. Суть в том, что при наличии основного питания память работает как обычно, чтение/запись, а при пропадании основного питания переходит в режим хранения, питаясь при этом от батарейки и потребляя сущие микроамперы. Батарейки типа 2032 должно хватить примерно на год, что для большинства применений более чем достаточно.

Та же самая история с ДКО "Электронщик", заказал товар как физ. лицо с доставкой, оплатил с карты, через 1 минуту приходит письмо, что заказ отменен, из всего товара в счете осталась только "доставка" При этом эта позиция фигурировала до оплаты как доступная к заказу, так и после оплаты осталась доступной, причем в нескольких вариантах со слегка разными ценами (надо понимать - разные склады). Казалось бы, раз такое дело - сделайте сразу возврат средств на карту обратно (как делают магазины при ошибочных списаниях), но нет ... следующий квест - "получи деньги обратно", нужно писать письмо с просьбой (!!!) вернуть деньги, и по закону в течение 10 (!!!) дней поставщик обязан вернуть деньги, типа расторжение договора поставки по инициативе потребителя. Как я понял из разговора с менеджером магазина - они не могут до оплаты сообщить реальное наличие товара на удаленных складах. Возможно, у них такой доступ к базе - можно только сразу зарезервировать (с внесением денег). Справедливости ради надо сказать, что с "Терраэлектроникой" у меня таких проколов не было ни разу, до оплаты они как-то проверяют счет 10-15 минут, и уж если предлагается ссылка к оплате, то есть уверенность, что товар будет и не будет квеста с возвратом денег.

Если кратко - останавливать SoftDevice при записи во флэшь необязательно, и даже ненужно так делать. В Nordic SDK есть специальные функции-обертки над SoftDevice, которые производят безопасные операции с периферией при включенном SD, а точнее, они просто вызывают сам SD через известные им точки входа для работы с периферией. Эти функции имеют префикс sd_ и расположены в SDK в файлах с постфиксом _sd, к примеру, запись во флешь через SoftDevice функция sd_flash_write(...) в файле nrf_fstorage_sd.c