flammmable

Спасибо за наводку на DWT. Погуглил - здесь про него написано весьма неплохо. Однако я бы хотел узнать несколько другое - как узнать среднее и максимальное время исполнения участка кода? В DWT можно всматриваться N минут. И за это время найти максимальное и среднее число тактов, за которые выполняется участок кода. Но при работе устройства длительностью M минут (M >> N) данные значения могут оказаться иными. Нельзя ли узнать точно, за какое максимальное количество тактов выполняется тот или иной код и быть спокойным, что данный показатель (в отсутствие всяких там прерываний, разумеется) не будет превзойдён никогда?

Добрый день! Имеется два кода на ассемблере, которые я запускаю на Nucleo-F103RB. Первый: LDR R0, =0x00000000 LDR R1, =0x0000FFFF LDR R2, =GPIOA_ODR turnON: STR R1, [R2] turnOFF: STR R0, [R2] delayDone: B turnON Второй: LDR R0, =0x00000000 LDR R1, =0x0000FFFF LDR R2, =GPIOA_ODR turnON: STR R1, [R2] B turnOFF turnOFF: STR R0, [R2] delayDone: B turnON Я вывел SYSCLK на MCO и подключил один щуп осциллографа к порту А, а другой к MCO. Графики я прилагаю. Инструкции STR у первого кода выполняются с интервалами 2-2-2-4 такта. Соответственно, минимальное время итерации цикла составляет 4 такта среднее время итерации цикла составляет 5 тактов максимальное время итерации цикла составляет 6 тактов Инструкции STR у второго кода выполняются с интервалами 3-3-3-3 такта. То есть минимальное, среднее и максимальное время итерации цикла равны 6 тактам. Видимо, подобное поведение происходит из-за работы системы предсказания ветвления. Документации по детальному алгоритму работы данной системы я не нашёл. Хотелось бы понять, возможно ли как-нибудь посчитать или просимулировать среднее и максимальное время исполнения участка кода (вроде макроса или процедуры) на ассемблере у STM32F103 ?

Всем спасибо, но короче отбой. Я затупился и в сгенерённый Кубом код скопипастил инициализацию тактирования с включённым PLL. Когда я нашёл ошибку и переключился на чистый HSI всё заработало как надо - GPIO щёлкают исключительно по восходящему фронту HSI.

Добрый день. Если в качестве источника тактирования STM32F103 выбран внутренний высокоскоростной источник HSI (8 МГц), а все делители в древе тактирования установлены в единицу, то на какой частоте будет работать АЛУ? Я пишу прошивку для STM32F103 и некоторые её фрагменты необходимо выполнять за минимально возможное время. В ходе отладки я вывел на пин MCO тактирование HSI и обнаружил, что GPIO переключается то по переднему фронту HSI, то по заднему, то ровно посередине между фронтами. Такое ощущение, что АЛУ работает в 4 раза быстрее, чем HSI. Я попробовал вывести на MCO тактирование от SYSCLK (путём установки RCC_MCO1SOURCE_SYSCLK в функции HAL_RCC_MCOConfig), но линия MCO установилась в верхний уровень и не выдала ничего. Собственно, основной вопрос: на какой частоте будет работать АЛУ? И побочный - почему SYSCLK не выводится на MCO, хотя HSI - вполне выводится.

The harsh truth is that the OP post date is December 24, 2020. My project where I tried to use on-chip memory has stalled. Now I can not explain to you all the details about using on-chip memory in MAX-10 immediately. Thus you can try to analyze the above example or wait several moungth for my article about on-chip memory.

Предположим, имеется устройство в котором присутствуют два питания: 3,3В и 5,0В. При этом у устройства помимо питания от USB есть опция внешнего питания. Хорошей практикой является установка сразу после разъёма USB диода, который не позволит току потечь из устройства в компьютер через USB. Однако, если шина питания устройства "5В" идёт от этого диода, то (ввиду падения напряжения на диоде) на этой линии будет 4,5...4,7В. Предположим, что устройству требуются честные 5,0В (4,95...5,05В к примеру). Соответственно потребуется DC-DC Step-up. Вопросы: 1) Так ли нужен данный защитный диод? 2) Какая схема подключения является наилучшей: - 5.0USB->диод->4.7V->LDO->3.3 и 5.0USB->диод->4.7V->DCDC->5.0PCB - 5.0USB->диод->4.7V->LDO->3.3 и 3.3->DCDC->5.0PCB - 5.0USB->диод->4.7V->DCDC->5.0PCB и 5.0PCB->LDO->3.3 3) Если требуется особо чистые 5,0В, имеет ли смысл поднять напряжение до 5,5В, а затем порезать его до 5,0В?

Сам себя не похвалишь - никто не похвалит ))))) Раз уж такое дело, то вот тут один тип тоже интересные вещи рассказывает )

Вернёмся к изначальному вопросу. У Вас есть GreenPAK Serial Debugger? Если нет, то хотелось бы пообщаться с теми, у кого есть. Альтернативные варианты, вроде: 1. Дизассемблировать GreenPAK Designer 2. Купить GreenPAK Serial Debugger на Mouser самому (учитывая, что он сейчас out of stock) 3. Спросить на форуме Renesas 4. Спросить на electronics.stackexchange 5. Отказаться от ПЛИС GreenPAK ...я обсужу в других темах и/или на других ресурсах. Если, конечно, посчитаю нужным.

Я не умею в ИДУ.

Хочу подсунуть среде разработки GreenPAK Designer голую микросхему MCP2221A, которая является ядром отладчика GreenPAK Serial Debugger. На форуме Renesas прочитал, что у GreenPAK Serial Debugger VID/PID соответствуют 2DCF/D006. У MCP2221A по умолчанию это 04D8/00DD. Переписал при помощи MCP2221 Utility VID/PID своей микросхеме MCP2221A и в GreenPAK Designer раздел System Information стал показывать не... Development Board Type: N/D Hardware ID: N/D Firmware ID: N/D ...а... Development Board Type: GreenPAK Serial Debugger Hardware ID: N/D Firmware ID: N/D Я полагаю, что данные ID берутся из того, что MCP2221 Utility называет descriptor string. По умолчанию у MCP2221A она равна "MCP2221 USB-I2C/UART Combo". Если у кого-нибудь есть GreenPAK Serial Debugger, можете посмотреть через MCP2221 Utility что там понастроено в MCP2221A Ренесасом?

Как мне кажется, здесь имеется очень важный момент для неосознанного запутывания: "отсутствовать падающие на устройство волны" на самом деле, не равно "Snn = 0 для портов, т.е. не должно быть отражений от портов". Поясню на оптическом примере примере. Пускай выходной порт вашего устройства является частично прозрачным зеркалом. И вы светите сквозь устройство на чёрный бархат или же на чистый лист бумаги. В первом случае на "выходной порт" не вернётся ничего. Во втором - вернётся. При этом Snn для выходного порта будет одним и тем же в обоих случаях. Применительно к электронике, я полагаю - важный момент состоит в том, что согласуются не порты двух устройств, а порт одного устройства с линией, соединяющей устройства и порт второго устройства с линией, соединяющей устройства. Поэтому, честно говоря, даже условие S22=0 представляется излишним. Если мы не светим в порт №2 и измеритель мощности на порте №2 ничего не отражает обратно в линию в направлении порта №2, то S22 может быть абсолютно любым - это не повлияет на измерение S21 или S11.

Так. Давайте посмотрим систему для четырёхполюсника. bx - то что выходит из порта x ax - то, что входит в порт x b1=S11*a1+S12*a2 b2=S21*a1+S22*a2 При S22=0 получаем b1=S11*a1+S12*a2 b2=S21*a1 Берём второе уравнение и... b2/a1=S21 Или если развернуть другой стороной, то... S21 = b2/a1 А причём здесь S11=0 ??

Спасибо! В принципе я нечто в этом роде и ожидал, просто хотел найти тому подтверждение.

Именно этот вопрос меня и интересует с академической точки зрения. На мой взгляд, параграфы различных стандартов, начинающихся со слов "Термины и определения...", не всегда, но периодически представляют из себя нечто вроде пятен Роршаха, где каждый инженер видит что-то своё. Мой любимый пример - термин "Амплитуда сигнала". Для синуса она отсчитывается от среднего значения, для меандра она peak-to-peak. В результате можно (и иногда так и происходит) накрутить апорию не хуже "Значит я сам себе дедушка" и прочих "Кто брил брадобрея?" и "Ахилес против черепахи". Хотелось бы понять, S-параметры из той же обоймы? То есть, хочу - S11 входит в S21, не хочу - не входит, или же есть чёткие критерии, согласно которым можно ответить однозначно? Пример с "кучей кабелей" я привёл как образец четырёхполюсника (черного ящика), отражающего не только разъёмом порта, но и своим (чёрным) нутром. Привёл я его с той целью, что не совсем понимаю выражение "S11 говорит лишь о том, какая часть энергии не попала внутрь устройства". А если оно попало, но отразилось (обратно, в направлении входа) внутренностями устройства, это тоже часть S11 или нет? На electronics.stackexchange в ответ на мой вопрос утверждают, что IL включает в себя все (все-все-все) потери, из-за которых входная мощность не вышла из выхода устройства. В том числе и потери на отражение.

Согласен. Представим, что наше оборудование измеряет сразу в дБм и временно абстрагируемся от всяких "двадцать логарифмов". Этот момент не совсем понятен. Представим, что наше устройство состоит из гирлянды разъёмов, вставленных друг в друга (или из отрезка 50-омной линии, к которому приделан отрезок 75-омной линии, к которому приделан ещё один отрезок 50-омной линии). У каждого разъёма есть какие-то свои возвратные потери. Да, можно сказать, что та часть мощности, что отразилась от самого первого разъёма порта №1 "не попала внутрь устройства". Но та мощность, что прошла первый разъём на пути от порта №1 к порту №2 внутри устройства будет продолжать натыкаться на неоднородности и отражаться-отражаться-отражаться в сторону источника. Представляется, что S11 - это всё же суммарная мощность, отражённая всем устройством, а не только первым разъёмом. Или нет? Если нет, то почему? Переведённый ГОСТ IEC 60050-702—2022 (и его англоязычный оригинал) определяют вносимые потери, как: 702-07-08 вносимые потери (четырехполюсника) [insertion loss (of a two-port device)]: Обычно выражаемое в децибелах отношение кажущейся мощности в точке канала передачи к мощности в этой точке, после внесения в него данного четырехполюсника непосредственно перед этой точкой. Я бы сказал, что согласно такому определению, в вносимые потери войдут и возвратные потери. Или возможна ещё какая-то трактовка данного определения?

Большое спасибо, что отвечаете. Но я всё-таки не пойму. Если мы посмотрим на S-параметры с точки зрения измерений. Подали 0 дБм на порт №1, замерили X на порте №2. Взяли из X корень (ну или нет, не суть). X - это S21 или нет? Если да, то, объективно, он же включает в себя отражение? Если нет, то на момент получения X мы всё ещё не можем сказать, чему равен S21. Для точного определения нам нужно измерить S11 и исключить его влияние из X. Верно? P.S. Тут на форуме 16 лет назад писалось: А ему отвечают: Правильно ли я понимаю, что S11 не входит в S21, но вполне входит в Insertion Loss? P.P.S. На electronics.stackexchange мне написали, что Return Loss входит в Insertion Loss. И вообще, всё, что уменьшает (ну, для пассивных устройств) выходную мощность - входит в Insertion Loss.

"Поэтому" - почему? Если мы подали 0 дБм на порт №1, что-то рассеялось, что-то отразилось, что-то утекло в другие порты (если они есть), к которым были подключены неотражающие нагрузки и в итоге из порта №2 вышел некий X, который численно равен S21, которое "в том числе" является "Вносимыми потерями", то почему "Поэтому нет, не включают", когда получается, что включают? Один мой знакомы тоже сказал мне, что Insertion Loss не включает Return Loss, но с чего бы? Если оно так, то тогда получается, что, условно, не IL=S21, а IL=S21-RL.

На сколько верны следующие утверждения? 1) Если на вход №1 четырёхполюсника подано 0 дБм, то то, что выйдет из выхода №2 - это S21. 2) S21 - это вносимые потери (Insertion Loss). 3) Вносимые потери включают в себя возвратные потери.

Всё супер! Всё запустилось при помощи: DeviceIoControl(hUart, 0x22205C, (LPVOID)NULL, 0, (LPVOID)NULL, 0 ,&bytesReturned, (LPOVERLAPPED)NULL); P.S. Как знать, может ещё через месяц инженеры Exar, купленные MaxLinear, ответят на мой запрос и расскажут, почему именно 0x22205C и как это число следует из даташита.

Спасибо, но увы. Сам мост возвращает ошибку при попытке сконфигурировать его на 5 или 6 бит. Он поддерживает только 7, 8 и 9 бит. Указанный вами драйвер при попытке задать 5-битные символы начинает сам конфигурировать мост для передачи 9-битных символов. Но так как он написан для Linux, делает он это при помощи функции usb_control_msg, которой в Windows нет.

Ещё один сногсшибательный совет. Да, можно. Можно ещё ходить на руках. Или спиной вперёд. Можно еще попробовать как-нибудь извернувшись, через гланды, сэмулировать передачу 9N1 путём постоянного переключения битрейта. Но вопрос: а принимать символ 9N1 вы чем предлагаете? )))))) "Не, ну я так... Я типа вам 50% задачи решил, типа, подколупнул, а дальше - это уж мелкие детали" )))) К слову про неумение читать, перечитайте заголовок темы, а затем ваш нерелевантный поток сознания про FT232 и 8M1/8S1. Я уж было порадовался, но... Я бы мог спросить "И? Вы прошли по ссылке, которую я привёл в первом посте. Обнаружили там таблицу, о наличие которой я сообщил в первом посте. И подчеркнули название режима wide mode, о котором я сказал в первом посте. Как скопипащенный и раскрашенный вами рисунок отвечает на вопрос из первого поста "Что я должен поменять в своём коде, чтобы добиться от XR21V1410 полноценного режима 9N1?" ?" Я понимаю, что ответ и тут приблизительно тот же: "Не, ну я так... Я типа вам код регистра обвёл красным, 99% работы сделал, типа подколупнул, а дальше, как его передать в устройство - это уж мелкие детали" )))) Но учитывая, что... В функWinAPI по работе с устройствами USB вы (200% гарантии) не разбираетесь у вас режим 9N1 то стандартный, то нет у вас он, якобы, существует на FT232, но лично вы (666% гарантии) его никогда не запускали (и не запустили бы, потому что у FT232 его нет) на XR21V141x вы (100500% гарантии) его никогда не запускали сами вы то уходите, то остаётесь ...я мог бы сказать, что дискуссия именно с вами бессмысленна и бесполезна. Поэтому именно ваши последующие посты (если они ещё будут) я проигнорирую.

Ну да. А что? Учитывая, что "была ситуация для F030F4, когда куб для ацп генерил тактирование от RC генератора, а не от системной шины как в настройках", можно сказать, что ваше заявление противоречит инженерному опыту.

Референс мануал на STM32F0x0 составляет 779 страниц, а попробовать - 1 минута. Моё мнение, нужно идти от простых решений к сложным. Спасибо, но не возымело. Ну, видимо, придётся действительно начать ковырять регистры, сверяясь с даташитом. STM32 и его инфраструктура сделаны специально так, чтобы программистов МК никогда не заменил бы ChatGPT. Это и плохо и хорошо одновременно.

STM32CubeIDE делает её в отдельном файле - stm32f0xx_hal_msp.c - в функции HAL_TIM_MspPostInit, которая вызывается в конце MX_TIM17_Init, который в main.c. Я попробовал (а вдруг!) вытащить (скопипастить) оттуда инициализацию пинов в MX_GPIO_Init, и поставить его после MX_TIM17_Init в main(void). Но это не помогло. Причём, когда я в редакторе .ioc , в разделе TIM17 на вкладке GPIO Settings, в выпадающем списке GPIO Pull-up/Pull-down выбрал Pull-up, пин подтянулся к питанию.

Пытаюсь при помощи кодгенератора STM32CubeIDE вот по этой инструкции вывести для микроконтроллера STM32F030F4P6 (TSSOP-20) на пины PA7 и PB1 ШИМ с таймеров TIM17 и TIM14. И чего-то не получается. Проверил выводы ногодрыгом - контакт есть, всё выводится. Вроде всё, что нужно указал: Channel1 - PWM Generator CH1 auto-reload preload - Enable Counter period - 500 Pulse - 250 В Clock Configuration вроде тоже всё ок, затактировался от HSI, напрямую, не через PLL - 8 МГц. Пробежал глазами по коду, вроде всё должно работать. Но почему-то на выходах PB1 и PA7 полная тишина. Может кто-нибудь подсказать, в чём дело?