_3m

Я пытался использовать vosk. Вывод - непригоден для реальных условий "в поле". Дикторский текст распознает хорошо если например читать книжку в микрофон, как дело доходит до разговора в комнате выдает ахинею. Хорошо работает whisper с моделью large v3 но оно дико медленное и нужны гигабайты ram, причем при работе на cpu параллелится только на 4 потока и Xeon не загружает совсем а топовой видеокарты с Cuda у меня не было.

Совместимость, переносимость, интероперабельность .... нет, не слышали! Чего только не придумают лишь бы уменьшить продажи.

Затем что внутри сборки китайцы могут поставить какую угодно память лишь бы объем совпал и продадут это под тем же партнамбером. Закрытый аллвинеровский инит DRAM автоматически детектит память любого типа манипулируя в том числе напряжением LDOB (а у более старших процессоров - соответствущим AXP***). Если применен фиксированный стабилизатор автодетект не работает и остается только молиться чтобы в следующей партии не поменяли тип DRAM.

Откуда такая дезинформация ??? Ничего именно аллвинером там не зашито кроме серийника и конфига которым отключены "вредные" блоки. Везде где видел - нехитрым алгоритмом генерился LAA из серийника. Если где то и зашито это делает производитель оборудования заодно с прошивкой ключей HDCP и ключом шифрования firmware.

Думаю раз вопрос поставлен значит это не случай изолированной сети и уникальные MAC таки жизненно необходимы.

Почему вы думаете что на самых дешевых картах MAC уникальный ? Китайцы - ребята простые они зашьют туда все что угодно. Например в нескольких партиях RTL8710 был один и тот же MAC. Тут вопрос в ответственности. С китайцев не спросишь, в суд не подашь и рекламации не предъявить. Жить в таких условиях намного проще.

Совет негодный! Если серьезный корпоративный заказчик с действительно работающей службой информационной безопасности он в ТЗ впишет требование уникальности MAC. Не дай бог коллизия - разборки на уровне СИБ, немедленное отключение всей поставленной продукции до приведения к требованиям ТЗ. Все за счет поставщика + компенсация убытков и упущенной выгоды.

Процессор STM32G031, отладчик Jlink, среда Chibi studio. Не получается отлаживать приложение созданное с использованием Chibios-NIL. Если ставлю брекпойнт в main loop или внутри потока - все ОК. А останов в обработчике прерываний потоки перестают исполняться, работает только main loop но ошибок или исключений при этом не возникает. Пока перевел проект на RT, с ним отладка работает нормально но RT в данном случае избыточна и ненужно раздувает объем кода.

Я полностью читаю мануалы на используемые чипы, причем всегда начинаю с того что напечатано мелким шрифтом и с errata если есть, в последнюю очередь читается первая страница ДШ. Мануал на МК полностью не читаю - на это жизни не хватит. Кстати с точки зрения менеджмента когда разработчик читает мануал - он бездельничает, код в это время не пишет, схему не составляет и плату не трассирует. Баклуши бьет, гад.

И практически никто не понимает необходимости и не документирует неудачные ходы, отброшенные варианты решения поставленной задачи. При разработке необходимо знать не только как сделано но и почему именно так а не каким либо другим образом. Эта информация остается только в памяти зачинателей проекта.

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

В "большом" IT софт именно так и разрабатывают! Ну подумаешь что оно работает только в облаках, какие проблемы: арендуешь под задачу Дата-Центр и вуаля. Законы большого мира неизбежно будут применены и в мире embedded.

Не мгновенна но реакция компьютера на появление питания таргета была бы намного быстрее чем запускать отладку руками и RTT благодаря буферу заработал бы без потерь.

Ничем не поможет. Подцепиться к работающему процессу может и STM32CubeIDE и даже обычный Eclipse. Проблема в GBD сервере. Он завершается когда теряет коннект с таргетом что и происходит при снятии питания (RTT - тоже). Процедура автоматического коннекта при появлении питания в сеггеровском ПО почему то не предусмотрена.

Озвучен: это как раз вариант б)