_3m

Если вы хотите реально производить продукцию то ваш выбор должен быть в пользу массово производимых компонентов. Причем даже санкционка если она массовая вполне себе покупается. А вот применять "аналоговнет" - это залет в том числе "КНР, но сделанный для нас".

Спасибо за попытку помочь однако *link V7 сделан на AT91SAM7S64.

Еще как работают! Но не уверен что за 150тыр.

Здравствуйте! Откопал в залежах старенький OLink V7, новый софт ругается что это клон. Убрал GbdFull, менял серийники - все равно палит. Прошивка обновляется. Что нужно прошить в V7 чтобы работало ? Еще я не вполне понял функциональность. В табличке указано что поддержка SWD есть а процессоров Cortex-M нет. С LPC11C14, STM32G031 оно будет работать хотя бы с софтовой эмуляцией или V7 можно сразу в помойку отправить ? --- Upd1 Отладка stm32g031 отлично работает до появления сообщения о клоне и еще несколько минут. Потом блокируется. GDBserver с F405 коннектится но отладка не работает, это похоже я ступил - забыл прописать GDB, RTT работает но безбожно тормозит. Еще ошибка: серийник в дескрипторе USB не совпадает с серийником Jlink тогда как у рабочего V9.43 они совпадают.

В качестве отправной точки можно взять с любой прошивкой.

Интересует пропускная способность и поведение модуля HC-06 (Bluetooth-Serial) при работе с ПК. Модуль древний как говно мамонта наверняка исследовано и где то описано. HC-06 сконфигурирован на скорость 230400 или 115200 формат 8N1, данные бинарные. Сценарий обмена с ПК: короткий запрос ПК->HC06->slave, ответ от слэйва размером килобайты непрерывным потоком без пауз. Управления потоком в HC06 нет так что он видимо будет терять байты. Вопрос начиная с какого размера блока и каким образом.

Потребление BT вас тоже огорчит. В ESP вся RF часть мегажручая.

В первую очередь это характеризует не ESP32 а "какого-то погрoмизда". Или заказчика, может он исполнителю денег не платит. Если ESP32 будет общаться с WiFi точно будет удивление от времени работы при батарейном питании. С отключенным wifi ничего сверхъестественного.

С учетом пик-фактора ну скажем 5 нельзя. Причем 5 это не фантастика а рядовой компьютерный БП без PFC, то есть практически повсеместно. 18-22 битные АЦП в счетчиках не от хорошей жизни ставят.

Тут есть ньюансик: потребитель посмотрит на ваш горе-прибор и сравнит с показаниями счетчика а они без спец-микрухи для счетчиков будут различаться процентов на 30. Такое безобразие никакой клиент не потерпит так что придется вам за свои деньги полностью переделывать изделие, заменять поставленную продукцию и еще неустойку выплачивать. Такое произойдет потому что ток в сети нынче не имеет ничего общего с синусоидой и правильно измерить его без счетчиковых микрух непросто. Так что если не хотите чтобы было "мучительно больно" придется измерять по ГОСТ или аналогичному регламенту Евросоюза еще и учитывая нормативные перегрузки опять же из ГОСТ. И нормативы по электробезопасности тоже придется соблюсти.

На винде есть хотя бы теоретический DCB.EvtChar а в линкуксе в неканоническом режиме даже этого нет. А канонический ... ну не знаю на что он годен в 202* году.

Да, я тоже думал в эту сторону, похоже в линуксе нет эффективных способов решить эту задачу в userspace. Еще есть мысль подстроиться под кукую либо из уже имеющихся line discipline, тут трудность в том что оно плохо документировано.

Здесь форум про Linux. То есть tty, termios, read(), write() и все! Не нашел в Linux tty сигнала по приходу программируемого символа. И stm32 такое умеет совсем новый серии G. В винде есть но пишут что оно не работает потому что реализация Vendor specific и на нее производители просто забивают болт. Более того задача кроссплатформенная - надо и под win то же самое.

На вход последовательного порта поступают пакеты произвольной длины, конец пакета обозначен специальным (зарезервированным) символом который в теле пакета не встречается. Пакеты могут следовать как слитно так и с паузами, причем паузы могут быть в произвольном месте как между пакетами так и между байтами внутри пакета. Например конец пакета - символ '\n': ...\n__idle__<packet1>\n<packet2>\n<packet3a>__idle__<packet3b>\n<packet4>\n<packet4>__idle__\n... Мне необходимо передавать пакет на обработку с минимальной задержкой после получения символа конца пакета. Как это можно реализовать максимально эффективно ? Я пошерстил гитхаб и гугл. Типовые реализации работают либо по таймауту либо по размеру ожидаемого пакета.

Оттуда что древнее гавно 16550 аппаратно не обрабатывает сигналы flow control. Их проверяет драйвер и если сигнал готовности снят - перестает грузить fifo а передачу того что уже легло в fifo не остановить. Электроника давно ушла вперед но с упорством баранов продолжают лепить "Industrial standart 16550-compatible UART" причем не только в ПК но и в разнообразные Arm-SOC и даже в некоторые МК, в части случаев даже прерывание TX Complete "забывают" завести. [beep-beep-beep!!!]