andrey_p

Теперь понял! @mitya1698, @aaarrr спасибо!

Ток я узнаю для подключённого светодиода. Вопрос в том, на какой ток рассчитана коробочка, залитая компаундом. Если она сгорит, проработав минут 5, то замена коробочки обойдётся тысяч в 20, если её вообще можно будет купить. Светодиод на 20мА я уже подключал. Работает, но по ощущениям не такой яркий по сравнению с оригинальным.

Добрый день! Я понимаю, что вероятность небольшая, но вдруг. Мне нужно опознать светодиод по фотографии. Не саму марку, а хотя бы рабочий ток. Белый светодиод из подсветки шуруповёрта Festool, диаметр 5мм, сгорел после нескольких лет эксплуатации. Шуруповёрт недешёвый, подсветка была довольно яркая. Блок управления представляет из себя коробочку, залитую компаундом, то есть доступа к управляющим элементам нет. Я так понимаю, что рабочий ток 20мА или 40мА. Заранее спасибо!

С WebRTC вам не нужен ни Zoom, ни Skype - вы получаете всё из коробки. Набираете условный номер и получаете видеозвонок с каналом для MIDI данных. К тому же Вы можете сделать UI точно под Ваши потребности (ноты, задачи, и т.п.)

Сейчас в драфте находится стандарт WebUSB, который позволяет из браузера работать с устройствами USB. Стандарт (драфт) уже поддержан многими браузерами по умолчанию. Подозреваю, что у Вас планируется параллельно использовать видеозвонок / конференцию, поэтому хорошим решением может оказаться связка WebRTC для аудиопотока / видеопотока и передачи данных для MIDI, считанных через WebUSB. WebRTC использует прямое соединение двух клиентов, однако нужен сигнальный сервер для установления соединения и "пробивки" каналов через NAT посредством ICE. Еще потребуется сервер STUN для ICE. Сейчас можно пользоваться множеством открытых сервисов STUN, но даже в случае их недоступности этот сервис можно поднять самому. Сервис TURN Вам вряд ли понадобится, так как вероятность того, что Ваши клиенты окажутся за симметричным NAT или они будут в связке симметричный NAT / port restricted NAT, стремится к нулю. Ещё потребуется сертификат для https, но это не проблема с Let's encrypt. Ах да, и бесплатно. Если кратко, то всё можно сделать через WEB. Если нужна помощь, обращайтесь. Знаю всё, кроме WebUSB и MIDI, с которыми ещё не работал.

Конструктивно) Этот "бред какой-то" используется известными Вам производителями телекоммуникационного оборудования. Но Вам, конечно, виднее... P.S.: Каюсь, внесу уточнение:) Для использования JITA нужно иметь ОСРВ на обоих концах, а также канал с практически постоянной задержкой. То есть это не описываемый случай. Идея JITA заключается в том, что один терминал говорит другому, в какой момент тот должен подготовить и отправить пакет с голосовыми данными. Этот момент выбирается таким образом, чтобы на принимающей стороне пакет пришёл ровно в тот момент, когда "едва" хватит времени на его преобразование. При этом "канал" в одном из решений выглядел так: терминал 1 - радиоканал - устройство 1 - Ethernet (IP) - устройство 2 - E1/T1 - устройство 3 - E1/T1 - устройство 4 - Ethernet (IP) - устройство 5 - радиоканал - терминал 2 В случае "непрямого" канала мы не можем гарантировать постоянство задержки, поэтому придётся вырабатывать jitter адаптивными буферами по худшему варианту. Поэтому от RTP просто так уйти не удастся. RTP бесполезен для ОСРВ в случае постоянной задержки канала, в противном случае необходим. P.P.S.: Но SIP на устройство тащить точно не нужно, здесь я остаюсь при своём мнении.

Just-in-Time Audio. Грубо говоря, приёмник управляет буфером отправки передатчика, минимизируя задержку на стороне передатчика. То есть необходимое количество отсчётов собирается в аккурат ко времени отправки буфера.

Можно, конечно, без сервера, но тогда все устройства должны каким-то образом поддерживать актуальные "адреса" остальных устройств. Также придётся решать проблемы аутентификации и ещё много чего. Вам это не нужно, поверьте. У Вас стоит задача сделать закрытую систему связи, ориентированную на сеть IP. Судя по контроллеру, сильно "закрытую". Выбор SIP выглядит вполне логичным. Для работы со стационарных компьютеров Вам понадобятся "клиенты" SIP. Также нужен сервер SIP, в обязанности которого будет входить регистрация "клиентов", маршрутизация и парковка вызовов, поддержка конференций (с микшированием звука), запись разговоров при необходимости и ещё много стандартных и нестандартных функций PBX. Подозреваю, что любой из этих компонентов должен иметь открытый исходный код, который "некто" будет проверять с лупой. Явно потребуется отказоустойчивость, которая будет гарантировать работоспособность системы при выходе одного или нескольких(?) серверов SIP из строя. Тут есть разные варианты, для закрытых систем они несколько проще. Что касается "переносного" устройства на микроконтроллере, то на него я бы не тащил SIP (+RTP), а сделал бы упрощённый протокол сигнализации. И про RTP - для ОСРВ он бесполезен, на ОСРВ для передачи голоса используются другие подходы (вроде JITA, например). Со стороны сервера SIP нужно сделать адаптер для подключения данных устройств. Сейчас, наверное, только интернет. Я этой темой с 1998 года занимаюсь (проводная телефония, SIP телефония, мобильная связь, транкинговая связь, и т.п.). Работал и над "сильно закрытыми" системами, но здесь об этом писать не буду. Как показывает мой опыт, порог входа в эту область сейчас достаточно большой - "обзорные" курсы не сильно помогут.

Не нужно тащить полный SIP на микроконтроллер, лучше использовать что-нибудь легковесное и сделать шлюз на компьютере. По аналогии с verto у freeswitch - когда все тащили полный SIP на JS, эти ребята придумали урезанный протокол поверх JSON, а в SIP перешли на шлюзе. Что-нибудь подобное нужно реализовать и здесь. И ещё нужно не забыть про STUN / TURN (хотя последний вряд ли будет у Вас задействован) и RTP. Я бы резал всё на контроллере и переносил функционал SIP в шлюз. И ещё, не используйте Asterisk, лучше базироваться на Freeswitch или Yate. Я в своё время выбрал последний - за 8 лет эксплуатации крупной боевой системы не было ни одного нарекания. P.S.: @Chameleos, будут вопросы - обращайтесь

Это неверная оценка ситуации. Вы, видимо, не видели, что происходит с талантливыми инженерами, "свалившими" в крупные компании в США. Через два года они либо уходят в менеджмент двигать "колбаски", либо перестают быть талантливыми инженерами. Жизнь для живота не располагает к полному погружению в работу. Именно поэтому эти компании ощущают кадровый инженерный голод и активно аутсорсят проекты, в том числе и в нашу страну. Даже компании под отдельных людей создают. Остальные причины Ваших проблем и неудач объяснили выше.

Если речь о разработке уникального решения подобного масштаба, то таких компаний нет нигде. Если, конечно, у Вас не безграничный бюджет. Если система более-менее типовая, то есть компании интеграторы. Но они строят систему на основе готовых компонентов. Возможно, с небольшой доработкой. Именно с небольшой. Если доработка существенная, то обычно выставляется заградительный ценник. Для примера: некий компонент, разработанный в отечественной компании с нуля, обошёлся примерно в 20 млн. руб. Западный вендор, собиравшийся адаптировать своё решение под наши требования, выкатил ценник в 60 млн. руб. Я считаю доработку решения вендора несущественной, так как очень хорошо знаком с их решением.

Ниже описан процесс разработки некой системы схожего масштаба. Разработка велась западной компанией, в которой я работал. Заказчик хочет сделать "чтобы было зашибись". Свои пожелания он излагает в кратком документе (1-2 страницы) "своими словами". Этот документ называется WP (White Paper) и/или VoC (Voice of the Customer). Действия исполнителя (сначала потенциального исполнителя): На основе WP / VoC создаётся HLSA (High Level Solution Approach). Обычно HLSA делается в виде презентации для демонстрации заказчику с целью согласования единого видения функционала. Причём техническая часть презентации создаётся группой системных инженеров / архитекторов (эта группа тесно связана с "продаванами"). В некоторых случаях проводится НИОКР. По результатам обсуждения HLSA с заказчиком вырабатывается общее понимание. HLSA может итеративно дорабатываться исполнителем в ходе обсуждения. На основании HLSA создаётся TRD (Technical Requirements Document). Это те самые высокоуровневые требования, под которыми подписывается заказчик и по которым делается оценка. На основании TRD заказчик будет проводить приемо-сдаточные испытания. На основании TRD исполнитель создаёт SRD (System Requirements Document), включающий внутренние требования, невидимые заказчику. Это часть очень важна, так как требования в TRD являются слишком высокоуровневыми для создания системы. Количество требований в SRD может в десятки раз превышать количество требований в TRD. Делается TM (Tracability Matrix) из TRD в SRD. На основании SRD делается SAD (System Architecture Document), описывающий декомпозицию и интерфейсы между компонентами. Делается TM из SRD в SAD. На основе SAD для каждого компонента делаются BR (Box Requirements) и TM из SAD/SRD в BR. BR используется тестировщиками для создания документов по тестированию, а затем и самих тестов. Создаются TM до самых тестов. На основе SAD для каждого компонента делаются HLD/LLD (High Level Design / Low Level Design) со сквозными ТМ. Создаются сами компоненты. Низкоуровневые части компонентов тестируется разработчиками на основании HLD/LLD (Unit Testing) Каждый компонент проверяется соответствующей группой тестирования на соответствие конкретному BR. Вся система тестируется на соответствие SRD. Этот этап разделяется на два: системная интеграция / системное тестирование SI/ST (System Integration / System Testing) Система передаётся заказчику для приемо-сдаточных испытаний (по TRD) Писал по памяти, но, вроде, ничего не упустил:) Ещё есть документы финансовые, по линии проектного менеджмента, QA, сопроводительная документация, но о них я даже не пишу - это вообще отдельный мир. Каждый из перечисленных этапов оплачивается заказчиком. На начальном этапе может быть несколько потенциальных исполнителей. Мне удалось поработать на всех этапах, кроме последнего (11) и мне очень хорошо знаком этот процесс изнутри. По мере возможностей пытаюсь внедрять этот подход в отечественных компаниях. Что-то получается, что-то нет. Грамотные руководители очень хорошо понимают необходимость подобного подхода к разработке сложных систем. Мне кажется, что разработать описываемую Вами систему без подобного процесса невозможно в принципе.

Только почему-то технологически доминирующий запад приходит на наш рынок за мозгами. И не только на наш. Поэтому у нас открывается куча как подразделений головных компаний, так и аутсорсинговых компаний. Вы удивитесь, но "американских" инженеров в США не существует уже давно. Я жил и работал в США в крупных западных компаниях и знаю, о чём говорю. Они давно здесь. Некоторые уезжают "туда", но большинство работает здесь. Большинство уехавших "туда" теряют свою квалификацию через несколько лет. От сытой жизни.

То же самое происходит в крупных западных корпорациях. Когда-то я этому удивлялся, теперь нет. Не хочется повторяться, но всё то же самое происходит в крупных западных корпорациях. Линейные менеджеры об этом знают и очень внимательно отслеживают настроения этих 3-4 разработчиков. Любой проект в период становления держится на конкретных людях. Это потом можно заменять всех универсальными винтиками, о которых бредит менеджмент. Попробуйте декомпозировать задачу и ищите исполнителей на отдельные подзадачи. И Вам придётся отбирать компании, которые умеют делать реальные вещи. Методом проб и ошибок. Таких компаний много, но они редко побеждают в тендерах. В противном случае Вам придётся искать кого-то, кто сделает это за Вас. Но вот только стоимость результата там будет совсем другая.

Работал с Google S2T, Deepgram и одним отечественным решением. Решение от Amazon, насколько я знаю, не поддерживает русский язык. Самое лучшее качество распознавания было у Google S2T. Единственный нюанс, это работа с ключами. Google выдаёт сертификат, на основании которого каждый час генерируются ключи. Ключи используются в запросах на распознавание и генерируются сервисом от Google. Библиотека для запроса ключей по сертификату закрыта, написана под .NET core. Для разработки нужны требования по задержкам. Большинство "распознавалок" работают в пакетном и потоковом режимах. Для пакетного режима нужно перекрытие фреймов, но работать с ним проще. Для повышения эффективности использования канала хорошо бы задействовать VAD. Ну и разбор ответов нетривиальный.

Ниже описание по горячим следам (2012 год). В первый раз заказывал DE2-115 + переходник. Заказывал весной 2011 напрямую у Terasic с доставкой в Россию. Брал для себя — для саморазвития:) После переписки с куратором по связи с университетами получил возможность купить по «академической» цене. Насколько я понимаю, при продаже по университетской программе Altera компенсирует стоимость чипа. А теперь о главном… В то время, когда я покупал, реально оплатить можно было только по PayPal, соответственно доставка осуществлялась только в Россию и только fedex-ом. Посылка долетела за 4 дня. А дальше началось. Позвонил в fedex. Они сказали, что нужно воспользоваться услугами таможенного брокера по очистке, иначе можно сразу отсылать все обратно. Были посланы, ибо брокер ничего не гарантировал, но просил больше 10000 рублей за услуги (точную сумму не помню). Забрав комплект документов, поехал на таможню. В последующие 5 дней мне пришлось побывать там 4 раза — каждый раз требовали все новые и новые документы. Хорошо, что работал неподалеку. Итак, вот список всего, что было предоставлено: 1) Таможенные декларации и прочая хрень по списку fedex-а 2) Гарантийное письмо о том, что беру для себя 3) Заверенная справка с работы, что я не буду использовать эту штуковину в рабочих целях 4) Письмо производителя (Terasic), подтверждающее отсутствие в данном устройстве модулей шифрования и криптографии. Я заодно попросил Terasic добавить пункт про отсутствие радиопередающих устройств. По требованию таможни письмо было переведено, а перевод нотариально заверен. Хорошо, что моя девушка имеет диплом переводчика:) 5) Классификация по ТН ВЭД — это вынос мозга. Кто в курсе, тот поймет. Эта плата попала в раздел [Ядерные реакторы]->[Запчасти]->[Пишущие машинки и прочее]-> Пункт 4 можно заменить нотификацией ФСБ, которая делается первым, кто ввозит некое электронное устройство на территорию России. Эту нотификацию вы НИКОГДА не найдете, несмотря на то, что товар уже продается в России. Таможенник и слушать меня не хотел, когда я говорил, что эта плата здесь продается… Да, а плату я получил:) Во второй раз всё сделал за одну поездку, так как подготовил все документы заранее (тот же комплект, но на плату SoCKit от Terasic). К тому моменту девушка-переводчица уже стала моей женой:) При этом я поменял своё отношение к таможенникам - ничего сверхестественного и незаконного они не требовали. Не было даже намёка на деньги. Плату выпустили. Единственное, что таможенник сказал мне напоследок, так это то, что больше не примет электронное письмо от производителя. Сказал, что требования ужесточились и теперь нужно письмо производителя на оригинальном бланке.

В СПб такой специалист обойдётся недёшево. Результат не гарантирован. Причина проста - считанные данные могут быть в левом формате, а если в чипе-таблетке ещё какой-нибудь синтезатор китайского, то вообще труба. Можете рискнуть. Купите этот или подобный программатор (с этим работал, проблем нет). Подпаяйтесь к чипу или купите такой переходник. Если нога питания не просядет, то считайте содержимое и выложите сюда. Скорее всего, проблем со считыванием не будет - я такой комбинацией ноут восстанавливал. Правда, у меня принципиальная электрическая схема ноута была:) Если формат считанного удастся понять, то перепрошить устройство можно будет тем же комплектом.

ЭАК, ЭКГ, ЭЭГ. В такой комбинации похоже на полиграф. Это я к тому, что контроллер (или законченное устройство) обрабатывает не один канал. Вы хотите применить все доступные в библиотеке функции или только те, что Вам нужны? Альфа, бета и гамма ритмы находятся выше 5 герц. Что от чего Вы хотите очистить? Может быть Вам нужен свой полосовой фильтр для каждого ритма? Опишите задачу и применяемое устройство.

Ага, спасибо. Я в январе буду заниматься оптимизацией RTOS с Linux под гипервизором на ARM. Сегодня посмотрю на target, если там тот же контроллер, то посмотрю его и тогда отпишусь. Уточняющий вопрос: у Вас таблицы трансляции сделаны один в один? Можете скинуть таблицы на всякий случай?

Этого мало. Это зависит от конкретного устройства (cache arch, TLB, SDRAM controller), от подключенной динамической памяти и от менеджера памяти (отображение физической памяти на виртуальную). Также неплохо было бы посмотреть на саму тестовую программу. Вообще все эи тестовые программы без адаптации к конкретной платформе - сравнивание тёплого с мягким. А что за тестовая программа? Какая-то стандартная или самописная?

Нужно смотреть на организацию кэша и подсистему памяти в целом. Даже в случае ассоциативности она работает только внутри индекса (исключение - полная ассоциативность, что для L2 нереально на сегодняшний день). Да и строение TLB стоит учитывать.

Я исключительно про документ, в котором делаются выводы о скрещевании ужа и ежа. И выводы дают пищу для размышления, учитывая тренд. Мне кажется, что при правильном подходе RTOS под гипервизором должна жить нормальной жизнью. Меня в последнее время не покидает тревожное чувство, что в один прекрасный день цена этих производительных дешевых камней улетит в небеса и придётся возвращаться к дешевым камешкам, цена на которые подскочит не так сильно. Учитывая, что и рынок готовых изделий схлопнется. Но это уже отдельная тема.

Хороший документ. Схема венчания через гипервизор на embedded нынче модная. Интересно было бы посмотреть, что там с кэшами и доступом к памяти.

Подключите MCP2515 через SPI. Инструкции здесь: https://www.raspberrypi.org/forums/viewtopic.php?t=141052

В таком случае от посимвольного ввода на уровне приложения Вам не уйти. Во время ожидания лучше не прыгать по таймаутам. Однако нужно предусмотреть возможность обработки copy/paste в консоль, то есть после приёма первого символа от пользователя есть смысл перейти на буферный приём и обработать все данные из буфера до следующей паузы. Таким образом Вы уменьшите количество вызовов read().