Перейти к содержанию
    

_3m

Участник
  • Постов

    1 020
  • Зарегистрирован

  • Посещение

Репутация

5 Обычный

Информация о _3m

  • Звание
    Профессионал
    Профессионал

Контакты

  • Сайт
    Array
  • ICQ
    Array

Посетители профиля

6 840 просмотров профиля
  1. Тут есть ньюансик: потребитель посмотрит на ваш горе-прибор и сравнит с показаниями счетчика а они без спец-микрухи для счетчиков будут различаться процентов на 30. Такое безобразие никакой клиент не потерпит так что придется вам за свои деньги полностью переделывать изделие, заменять поставленную продукцию и еще неустойку выплачивать. Такое произойдет потому что ток в сети нынче не имеет ничего общего с синусоидой и правильно измерить его без счетчиковых микрух непросто. Так что если не хотите чтобы было "мучительно больно" придется измерять по ГОСТ или аналогичному регламенту Евросоюза еще и учитывая нормативные перегрузки опять же из ГОСТ. И нормативы по электробезопасности тоже придется соблюсти.
  2. На винде есть хотя бы теоретический DCB.EvtChar а в линкуксе в неканоническом режиме даже этого нет. А канонический ... ну не знаю на что он годен в 202* году.
  3. Да, я тоже думал в эту сторону, похоже в линуксе нет эффективных способов решить эту задачу в userspace. Еще есть мысль подстроиться под кукую либо из уже имеющихся line discipline, тут трудность в том что оно плохо документировано.
  4. Здесь форум про Linux. То есть tty, termios, read(), write() и все! Не нашел в Linux tty сигнала по приходу программируемого символа. И stm32 такое умеет совсем новый серии G. В винде есть но пишут что оно не работает потому что реализация Vendor specific и на нее производители просто забивают болт. Более того задача кроссплатформенная - надо и под win то же самое.
  5. Парсинг пакетов от serial port

    На вход последовательного порта поступают пакеты произвольной длины, конец пакета обозначен специальным (зарезервированным) символом который в теле пакета не встречается. Пакеты могут следовать как слитно так и с паузами, причем паузы могут быть в произвольном месте как между пакетами так и между байтами внутри пакета. Например конец пакета - символ '\n': ...\n__idle__<packet1>\n<packet2>\n<packet3a>__idle__<packet3b>\n<packet4>\n<packet4>__idle__\n... Мне необходимо передавать пакет на обработку с минимальной задержкой после получения символа конца пакета. Как это можно реализовать максимально эффективно ? Я пошерстил гитхаб и гугл. Типовые реализации работают либо по таймауту либо по размеру ожидаемого пакета.
  6. Оттуда что древнее гавно 16550 аппаратно не обрабатывает сигналы flow control. Их проверяет драйвер и если сигнал готовности снят - перестает грузить fifo а передачу того что уже легло в fifo не остановить. Электроника давно ушла вперед но с упорством баранов продолжают лепить "Industrial standart 16550-compatible UART" причем не только в ПК но и в разнообразные Arm-SOC и даже в некоторые МК, в части случаев даже прерывание TX Complete "забывают" завести. [beep-beep-beep!!!]
  7. В ПК если использовать типовые UART не бывает отсечки 1 байта по CTS. Совсем!!! Классические 16550-compatible UART выдают все содержимое FIFO а у современных это 64...128 байт, USB переходники могут творить все что угодно.
  8. Никак. С февраля платежи не проходят, более того из Китая возвращают и январские платежи причем товар уже получен. Решения вопроса на данный момент нет. Думаю вы не там спрашиваете. Задайте этот вопрос властям.
  9. Данное измышление необходимо обосновать. Пока оно выглядит высосанным из пальца даже если приплести влияние ART акселератора. В большой программе функции как правило лежат не в порядке их вызова при исполнении так что в любом случае будет обращение не в линейном порядке адресов. Это кому как.
  10. GNU LD не умеет работать с регионами в которых есть "дырки". На это тикет уже лет 10 висит, разработчикам похер. Либо заполняйте вручную либо будет потеряно место. IAR - умеет.
  11. Давайте отметим что при написании программ под ПК никто не читает интеловских мануалов на чипсет. Совсем, от слова вообще. И даже систему команд процессора 99% погромиздов не изучало. Тем не менее программы пишутся и они даже работают. И даже линуксоиды не учат регистры чипсета. Мир МК неминуемо проследует той же дорогой как "взрослое" IT нравится это кому то или нет. Это смотря какой процессор. Для меги8 не требуется. А все регистры какого нибудь f407 не факт что за 10 лет выучишь. Если следовать логике регистроучителей писать ПО на чип уровня imx6 вообще невозможно - там мануал на десятки тысяч страниц, человеческой жизни не хватит все выучить. Но пишут ... с использованием bsp от вендора, то есть презренный "куб"!
  12. Бюрократические отчеты содержат примерно 0% информации о фактических причинах происшествия, оно так не только в Роскосмосе но и вообще везде. Что там на самом деле произошло знают только разработчики гироскопов и системы управления двигателем и то не факт. Насчет индусов уверен что они работали исключительно через API и даже мыслей смотреть регистры у них не возникало (менталитет такой). В результате успех миссии. НЕ МОЖЕТ!!! Зубрители регистров и битиков неспособны подняться на архитектурный уровень и продумать систему в целом. На высокоуровневые абстракции у таких не хватает ни времени ни мозгов, все отнимают тысячи битов в сотнях регистров. Человеческие возможности конечны и если все их растратить на регистры то на решаемую задачу ума и времени уже не останется.
  13. Это кто ж так отличился ? Имя производителя плат огласите пожалуйста чтобы случайно не вляпаться. Подобного рода платы я паял как то правда единичные макеты и вручную. Намучился...
  14. 8266 - устаревшее кривое гумно и озу в ней мало - современные протоколы SSL/TLS не тянет, тупо ОЗУ ни на что полезное не остается. ESP32 получше только потребляет много.
  15. Это только в воображении нужны быстрые ключи а на практике с быстрыми ключами схема загенерит. Дело в том что источники неидеальны: при подключении нагрузки напряжение проседает (пока ОС отработает) а при снятии оно возвращается в норму. Поэтому недоучки из LT специально делают переключатели с линейным участком чтобы преключение источников проходило плавно.
×
×
  • Создать...