xvr

А 'борд с wifi' весь стек TCP/IP поддерживает? В частности DHCP (используется для получения IP) и ICMP ECHO (который для Ping используется) Ещё можно посмотреть на AP список подключённых клиентов - есть ли там ваша борда (и выдан ли её DHCP адрес)?

Имя, не IP. Курите маны на тему DHCP

Яндекс свои IoT поделия делает на платформе tuya (но это не точно). Так что вам сюда - https://developer.tuya.com/en/

Я ничего не предполагаю. И не строю никаких догадок по тому, что подключено на выходе этого автомата. Да, по любому переходу он в конце концов свалится в STATE_STM_WAIT, но по дороге он может пройти не по тому маршруту, что описан в verilog описании. И это целиком вопрос к ТС - устраивает его это, или нет. IMHO слишком мало информации, что бы гарантировать устойчивость (неизвестного нам) протокола к таким переходам :) Например можно предположить, что в результате непредвиденного перехода STATE_STM_FLAG->STATE_STM_END дальнейшая схема потеряет команду вообще (перехода через STATE_STM_DATA и STATE_STM_OPER не будет) Никак, вообще ничего не сделает

В любые: STATE_STM_CLANK1, STATE_STM_CLANK2, STATE_STM_CLANK3, STATE_STM_DATA, STATE_STM_OPER, STATE_STM_END. Какие именно из этого списка будут (2 штуки) зависит от того, как синтезатор разложит номера на состояния. Например если кодировка будет такая: STATE_STM_WAIT 000 STATE_STM_CLANK1 001 STATE_STM_CLANK2 011 STATE_STM_CLANK3 010 STATE_STM_FLAG 110 STATE_STM_DATA 111 STATE_STM_OPER 101 STATE_STM_END 100 То переход STATE_STM_FLAG->STATE_STM_WAIT будет 110->000, т.е. могут получиться 100 STATE_STM_END 010 STATE_STM_CLANK3 ну и ожидаемые STATE_STM_FLAG и STATE_STM_WAIT

Я писал где именно. При переходе STATE_STM_FLAG->STATE_STM_WAIT будет изменено более одного бита в регистре состояния автомата. Все другие переходы происходят последовательно, и при них меняется 1 бит (автомат кодируется в коде Грея). Этот переход НЕ последовательный - как минимум 2 бита будет изменено. Изменение зависит от асинхронного внешнего сигнала (STM_U_QBUS_IN_L) - автомат может попасть как минимум в 2 неожиданных состояния

Я вам и привожу конкретный пример - посмотрите первое сообщение темы, там приведён вполне конкретный автомат. Там не такое

Ещё как играет. У ТС автомат в кодах Грея, при этом все переходы последовательные, кроме STATE_STM_FLAG->STATE_STM_WAIT. При последовательном переходе меняется 1 бит, что не приведёт к неправильным переходам (бит либо изменится, либо останется прежним - автомат либо перейдёт в правильное состояние либо останется в прежнем состоянии). В переходе STATE_STM_FLAG->STATE_STM_WAIT будет меняться несколько битов (он не последовательный). Из за метастабильности реальный набор изменившихся битов может быть подмножеством требуемого. Какие при этом получатся переходы предсказать трудно. Например, если изменяются одновременно 2 бита, то возможно 4 варианта реального изменения. При этом 1 вариант будет соответствовать правильному переходу, в ещё 1 варианте автомат останется в прежнем состоянии и в 2х вариантах будут переходы в неправильное состояние.

Ну например вместо STATE_STM_FLAG->STATE_STM_WAIT может улететь куда угодно (этот переход в Грей не ложится)

Давайте уточним - такой автомат действительно будет работать как CDC цепь, и метастабильность за его пределы не выйдет. НО - переходы в таком автомате (в присутствии несинхронизированных входных сигналов) могут отличаться от логики, описанной в Verilog исходнике. Если неправильные переходы автомата для ТС допустимы, то можно считать, что всё ок

А из за метастабильности в регистрах, хранящих состояние, не может произойти переход в неправильное состояние? Например должны переключиться 2 регистра и оба они перейдут в метастабильное состояние, из которого могут выйти в разные состояния (один переключится, а второй вернётся в оригинальное состояние). Автомат из этого состояния выйдет, но переход явно будет неправильный

Т.е. вместо нормального CDC для внешних сигналов вы добавили safe в автомат? Это не решение проблемы, а 'заметание её по ковёр'. Автомат не будет виснуть в запрещённых состояниях, но возможны самые непредсказуемые переходы между разрешёнными состояниями.

Супер бюджетное: GW1N-9 Умножителей как раз хватит. https://www.aliexpress.com/item/1005002029783987.html Или GW1N-4, но умножители придётся мультиплексировать. В младших моделях умножителей нет.

Шутить изволите? Какие умножители в CPLD? Вы бы ещё 22V10 взяли :)

Прототип msg в месте вызова виден?

Какой нибудь Hantek, например https://www.aliexpress.com/item/32456894731.html Ну или что нибудь подешевле

2 ТС - вам уже посоветовали взять логический анализатор. Присоединяюсь к совету. Взять можно на Ali, они там есть, стоят копейки (по сравнению с осциллографами на полосу 1GHz)

Автор, вы задали как минимум 2 вопроса: какой самый простой МК (что бы было проще програмировать), и как его запрограммировать на самом низком уровне. Вам старожилы мягко намекают - что ответы на эти вопросы диаметрально противоположны. И мы не понимаем ваши задачи - вы хотите изучить как применять МК или как он устроен внутри? (Первый вариант соответствует вашему первому вопросу, второй - второму). Для первого и второго варианта будут совершенно разные советы. Вы уж сориентируйте нас

Лучше смотрите в сторону SDR

У вас сам массив не константный (добавьте const после static). Но даже это для С может не помочь - там не всё то, что написано с const, является действительно константой :)

https://app.ultralibrarian.com/search?queryText=TORX177 TX нету увы - придётся самому рисовать

Немного занудства - va_list это не массив, а некий псевдо указатель на параметр в вызове функции. Реализация его полностью зависит от архитектуры процессора и иногда от компилятора. Далеко не на всех архитектурах это реальный массив :(

Неа. Там было устроено хитрее. Сначала АОН гасил индикатор и считывал область с плавающими битами. Потом он зажигал все разряды на индикаторе, что приводило к существенному повышению потребляемого тока, что в свою очередь приводило к снижению напряжения питания (стабилизатор там был не ахти). Область плавающих битов снова считывалась. Если 2 считывания давали один и тот же результат - подделка.

Возможно заполняет дырки в пайплайне (обращение в память требуют больше тактов, и если не вставить что нибудь после неё, то процессор просто сам вставит туда nop). Так что влиять на это не стоит - результат будет совсем не таким, какой вы ожидаете

Да. но насколько существенным зависит от процессора Да. как минимум используйте функцию memmove - она оптимизирована для копирования массивов памяти. Если надо ещё быстрее - делайте промежуточный массив указателей на строки - char TERMINAL_TEXT_BUF[256][100]; char* TERMINAL_TEXT[256]; for(i=0;i<256;++i) TERMINAL_TEXT[i] = TERMINAL_TEXT_BUF[i]; Потом копируете указатели в TERMINAL_TEXT (не забудьте их зациклить по исходному массиву - иначе затрёте память)