Nagisa

такая мысль уже была, но всякую мелочь типа аттини я уже распродал

Прошу подсказать: Нужно выделить КСИ и ССИ из видеосигнала. Важный момент: исходный видеосигнал генерится разными старыми железками и он прогрессивный. Полностью решает задачу - субмодуль УСР от телевизоров 3УСЦТ на К174ХА11. Но тут очевидна проблема - габариты, очень объемная ее обвязка. LM1881 увы не катит ибо не может выделить кадровую хочется чего-то компактного типа LM1881 (если будет в SOPе то вообще отлично) ps: если еще оно умеет сразу форировать back porch то вообще будет супер!

наступил на теже самые грабли: STM32F407VET6 RTC от батарейки и тоже утечка с батарейки на шину STM32 со всеми спецэффектами. эффект повторяем - проверил на 15ти платах. хотя на некоторых все нормально - потребление меньше 100мка. пробовал: 1. подал вместо батарейки от лабораторного БП питание и STM32 запустился! 2. стер прошивку, питание прошло опять на выход. 3. проверил все выходы на предмет подтяжек - никак не влияет. Куда копать ? UPD: проблема оказалась в другом месте.

накопал схемку https://www.electronics-lab.com/sepic-converter-based-on-mt3608-is-open-source/

можно подсказать имя ? ибо облазил сайт http://www.xlsemi.com/products_n_sync_MV.html и не нашел ничего для работы с lion - минималка 3.6V

не буду создавать новую тему, прошу подсказать, на что посмотреть в 2022м году для решения этой задачи ? LTC3440 всем нравится кроме цены. Может китайцы наклепали нормальных аналогов ?

Огромное спасибо за развернутый ответ! буду делать макетку для обкатки

Странного хочется: хочу облегчить процедуру обновления прошивок на железке, и вижу такой путь: у меня есть на плате STM32 с MicroSD карточкой, что соответственно позволяет хранить прошивку для ПЛИС (циклон2) и есть время при старте на прошивку (2секунды). Подозреваю, что я не первый озадачился таким путем, но вот что-то не нашел описаний подобного. Интересно: - протокол - особенности реализации на STM32, подводные камни - надо ли как-то переформатировать прошивку *.sof для заливки ? и если есть какие-то ccылки / примеры будет супер

отвечаю самому себе это 3 регистра а не 8 - те в индексе идет перечисление а не диапазон бит reg [12:0] pre_reg_az_mem[2:0];

дабы не плодить темы про индексы спрошу снова вот у меня массив reg [12:0] pre_reg_az_mem[2:0]; те это 8 регистров по 13bit каждый - всё верно ? соответственно в кейсе хочу занести туда данные always @ * begin case (SMK_MODE) 4'b0111: // Start - используется для запуска, пересылки данных на БК10 и RAM-BIOS'ом (он - всегда в 0-й странице); begin pre_reg_az_mem[3'd7]<=13'o112; pre_reg_az_mem[3'd6]<=13'o112; pre_reg_az_mem[3'd5]<={6'b000001,SMK_PAGE,3'd1}; // 6+4+3=13bit pre_reg_az_mem[3'd4]<={6'b000001,SMK_PAGE,3'd0}; но получаю матюг: методом тыка обнаружил что 0 1 2 - прокатывают, а 3 уже за пределами хотя 3бита = 8 значений что я делаю не так ?

источник STM32F407, тестирование показало, что он меняет состояние на порту за 1 такт внутренней частоты 162MHz (понятное дело, что есть оговорки) конечно, в идеале надо было использовать SPI и не парится с костылями, но что есть то есть. да, добавка safe полностью решила проблему, и сейчас тест оперативки идет даже на 162MHz (при заявленных 133).

это я в курсе, тут задача в том, что надо сразу отреагировать на изменение (1 такт) а полноценный CDC даст отставание на 2 такта

причина получается в том, что оптимизатор кодирует автомат в onehot и как следствие у него есть недопустимые состояния, а они, очевидно из работы с асинхронными процессами, могут быть соответственно необходимым и достаточным является указание кодирования без недопустимых состояний или их блокировка - те хинт safe

так для того и автомат, дабы синхронизировать вылечил так reg [2:0] state_stm /* synthesis syn_encoding="safe,gray" */; reg [2:0] next_state_stm /* synthesis syn_encoding="safe,gray" */;

Странная проблема с автоматом состояний localparam STATE_STM_WAIT = 3'd0; // ждем =0 на STM_U_QBUS_IN_L localparam STATE_STM_CLANK1= 3'd1; // антизвон localparam STATE_STM_CLANK2= 3'd2; // антизвон localparam STATE_STM_CLANK3= 3'd3; // антизвон localparam STATE_STM_FLAG = 3'd4; // ждем установки флагов операции localparam STATE_STM_DATA = 3'd5; // запоминаем данные для команды localparam STATE_STM_OPER = 3'd6; // выполняем операцию localparam STATE_STM_END = 3'd7; // ждем завершения - снятия синка reg [2:0] state_stm; reg [2:0] next_state_stm; always @ (posedge CLK) begin state_stm<=next_state_stm; end always @ * begin case (state_stm) STATE_STM_WAIT: if(STM_U_QBUS_IN_L==0) next_state_stm=STATE_STM_CLANK1; else next_state_stm=STATE_STM_WAIT; STATE_STM_CLANK1: next_state_stm=STATE_STM_CLANK2; STATE_STM_CLANK2: next_state_stm=STATE_STM_CLANK3; STATE_STM_CLANK3: next_state_stm=STATE_STM_FLAG; STATE_STM_FLAG: if( stm_sync==1)// есть команда next_state_stm=STATE_STM_DATA; else if (STM_U_QBUS_IN_L==1) next_state_stm=STATE_STM_WAIT; else next_state_stm=STATE_STM_FLAG; STATE_STM_DATA: next_state_stm=STATE_STM_OPER; STATE_STM_OPER: next_state_stm=STATE_STM_END; STATE_STM_END: if( stm_sync==0 || STM_U_QBUS_IN_L==1) next_state_stm=STATE_STM_WAIT; else next_state_stm=STATE_STM_END; default: next_state_stm=STATE_STM_WAIT; endcase end соответственно на определенные состояния привязаны действия вообщем обычный автомат который понимает квартус (которых в проекте куча и все работают нормально) но засада в том, что он висит на STATE_STM_WAIT и игнорирует STM_U_QBUS_IN_L который регулярно падает в 0 (смотрю сигналтапом) поведение странное, те при определенном схождении звезд может получится рабочая сборка, но в большинстве своем не рабочая. проблема гарантированно лечится выводом на любой пин любой части регистра state_stm, что явно переключает оптимизатор автомата вопрос первый - в чем причина ? что не нравится оптимизатору, что он делает нерабочий автомат ? и второй - как лечить ? те может какой-то хинт есть дабы объяснить оптимизатору оставить state_stm регистром ?