_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!!!]

В ПК если использовать типовые UART не бывает отсечки 1 байта по CTS. Совсем!!! Классические 16550-compatible UART выдают все содержимое FIFO а у современных это 64...128 байт, USB переходники могут творить все что угодно.

Никак. С февраля платежи не проходят, более того из Китая возвращают и январские платежи причем товар уже получен. Решения вопроса на данный момент нет. Думаю вы не там спрашиваете. Задайте этот вопрос властям.

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

GNU LD не умеет работать с регионами в которых есть "дырки". На это тикет уже лет 10 висит, разработчикам похер. Либо заполняйте вручную либо будет потеряно место. IAR - умеет.

Давайте отметим что при написании программ под ПК никто не читает интеловских мануалов на чипсет. Совсем, от слова вообще. И даже систему команд процессора 99% погромиздов не изучало. Тем не менее программы пишутся и они даже работают. И даже линуксоиды не учат регистры чипсета. Мир МК неминуемо проследует той же дорогой как "взрослое" IT нравится это кому то или нет. Это смотря какой процессор. Для меги8 не требуется. А все регистры какого нибудь f407 не факт что за 10 лет выучишь. Если следовать логике регистроучителей писать ПО на чип уровня imx6 вообще невозможно - там мануал на десятки тысяч страниц, человеческой жизни не хватит все выучить. Но пишут ... с использованием bsp от вендора, то есть презренный "куб"!

Бюрократические отчеты содержат примерно 0% информации о фактических причинах происшествия, оно так не только в Роскосмосе но и вообще везде. Что там на самом деле произошло знают только разработчики гироскопов и системы управления двигателем и то не факт. Насчет индусов уверен что они работали исключительно через API и даже мыслей смотреть регистры у них не возникало (менталитет такой). В результате успех миссии. НЕ МОЖЕТ!!! Зубрители регистров и битиков неспособны подняться на архитектурный уровень и продумать систему в целом. На высокоуровневые абстракции у таких не хватает ни времени ни мозгов, все отнимают тысячи битов в сотнях регистров. Человеческие возможности конечны и если все их растратить на регистры то на решаемую задачу ума и времени уже не останется.

Это кто ж так отличился ? Имя производителя плат огласите пожалуйста чтобы случайно не вляпаться. Подобного рода платы я паял как то правда единичные макеты и вручную. Намучился...

8266 - устаревшее кривое гумно и озу в ней мало - современные протоколы SSL/TLS не тянет, тупо ОЗУ ни на что полезное не остается. ESP32 получше только потребляет много.

Это только в воображении нужны быстрые ключи а на практике с быстрыми ключами схема загенерит. Дело в том что источники неидеальны: при подключении нагрузки напряжение проседает (пока ОС отработает) а при снятии оно возвращается в норму. Поэтому недоучки из LT специально делают переключатели с линейным участком чтобы преключение источников проходило плавно.

Может генератор на LSI переключается ?

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