Timmy

Я прекрасно знаю, что делают OIS и MOE, проблема в том, что нормально сделанная инициализация для TIM1 у меня не работает, она должна делать то же, что и для TIM2, и дополнительно установить MOE в 1. Согласно табличке, OIS при включенном MOE вообще не должны ни на что влиять, а у меня очень даже влияют.

Всем привет! Работающий код инициализации простейшего ШИМ получился следующий: auto tim = TIM1; tim->ARR = 5; tim->CCR3 = 3; tim->CR2 = TIM_CR2_OIS3; tim->CCMR2 = TIM_CCMR2_OC3M_0*6; //tim->CCER = TIM_CCER_CC3E; tim->CR1 = TIM_CR1_CEN; //tim->BDTR = TIM_BDTR_MOE; Да, именно так, CR2_OIS3 обязательно надо в 1, иначе не работает, а CCER_CC3E не устанавливать, иначе выход управляется только битом OIS3. Установлен, или нет, BDTR_MOE, ему пофиг. На TIM2 то же самое работает строго по даташиту auto tim = TIM2; tim->ARR = 5; tim->CCR3 = 3; tim->CCMR2 = TIM_CCMR2_OC3M_0*6; tim->CCER = TIM_CCER_CC3E; tim->CR1 = TIM_CR1_CEN; Если не поднимать CCER_CC3E, выходной бит как и положено, не управляется, остаётся в нуле. Проверял на двух платках с Алиекспресса, одна свежая, другая куплена лет 7 назад, всё одинаково, на обоих маркировка STM32F103. Или это всё-таки хитрые перемаркированные китайские клоны, или я очень туплю, ну или даже не знаю, что и думать.

Насколько я вижу, победить ISE не так уж сложно, это удобнее, чем потом всё время возиться с виртуалкой, основные заморочки были с Синплифаем.

В Spartan6 LUT6 имеет дополнительный вывод с младшей половинки(LUT5), за счёт чего один лут может хранить ROM таблицу 2 разряда по 32 бита, а слайс соответственно 8x32.

Насколько я помню, эта кора в принципе не поддерживает денормализованные числа(у которых в поле порядка стоит 0), поэтому все они считаются равными нулю, это экономит ресурсы и повышает быстродействие. Так что не глюк, а фича:). Кстати, вы забыли, что числа с минимальным порядком денормализованы, и к ним старшая единица не добавляется, поэтому неправильно переводите в десятичную экспоненциальную форму.

https://microchipdeveloper.com/mplabx:avr-updi-info - то есть PICkit 4 и Power Debugger. Можно и самостоятельно сколхозить схемку для разлочки, там не сложно.

Оператор {*}, позволяющий непосредственно разворачивать список в несколько параметров, появился относительно недавно.

Тогда непонятно, как кавычки могли повлиять. Ещё хочу заметить, чтобы в vlog можно было передать несколько ключей, заданных в Keys списком, как независимые параметры, а не одной строкой, нужно написать в compilation.tcl eval vlog +acc $Keys [list $CurrDirectoryPath/*.$Extension2Compile] list нужен, чтобы eval не разобрал путь с маской на несколько параметров, если в пути вдруг будут пробелы. Или в современном варианте vlog +acc {*}$Keys $CurrDirectoryPath/*.$Extension2Compile

Это выглядит потрясающе. Для стандартного TCL парсера не должно быть никакой разницы. Я специально проверил в tclsh: set a "+define+TEST_NUMBER=3" set b +define+TEST_NUMBER=3 put [expr {$a==$b}] 1 Неужели у Квесты парсер какой-то не стандартный?

Можно попробовать написать аналог $clog2, через define с операторами ?: внутри, возможно, прокатит за простую арифметику.

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

Я уже поднимал однажды этот вопрос, и привёл вариант решения, к сожалению не самый удобный - создавать локальную копию проблемной глобальной переменной, и в конце блока переносить её в глобальную переменную.

Насчёт всегда не могу гарантировать, а на stm32 успешно пользуюсь этим приёмом при оцифровке сигналов с высоким импедансом. К сожалению, там нет внутренней коммутации на землю, которую лучше всего использовать в качестве источника постоянного напряжения, обычно приходится одну внешнюю ногу для этого выделять.

Вот ещё простой пример с арифметикой, где VHDL удобнее: надо умножить две переменных произвольной разрядности, записав результат в другую переменную произвольной разрядности, с выравниванием по старшим битам, при необходимости обрезав лишние младшие биты, либо дополнив недостающие младшие биты нулями. Для этой достаточно типичной операции я написал универсальную функцию align_left, которую можно вызвать: c := align_left(a * b, c'length); А вот с Верилогом, кажется, придётся мудрить.

На примере задачи из топика: function bitsum(v:unsigned; l:natural) return unsigned is variable s:unsigned(l-1 downto 0); begin s := to_unsigned(0, l); for i in v'range loop s := s + resize(v(i downto i), l); end loop; return s; end function; И попробуйте сделать такую же удобную в использовании функцию общего вида на Верилоге.