Лидеры

А у вас наверно - программиста грамотного нет. Боюсь представить какого размера получаются ваши платы... с таким-то подходом... Лучше бы микроконтроллер как следует осваивали. Тогда бы не пришлось вешать снаружи гирлянду ненужных микросхем. Отправьте вашего погромиста на курсы повышения квалификации. Как правило - таймеров в МК намного больше, чем SPI. Например в МК, на котором сейчас работаю общее число таймеров = ~25шт.; а последовательных портов - всего = 6 (совмещающих UART, SPI, I2C, I2S). Это уж не говоря о том, что и на один таймер несложно повесить сразу много функций. И это проще, чем несколько устройств на один SPI. Практически во всех проектах у меня на каждом таймере висит гирлянда разных функций. А тем более - когда речь о периодическом прерывании с низкой частотой (которое нужно дин.индикации) - вообще не проблема. Производители МК почему-то не считают это неграмотным решением. И рекомендуют использовать для UART. Но вы видимо лучше их знаете Может лучше всё-таки почитать мануал на МК? У моего указана погрешность встроенного RC-генератора в диапазоне рабочих температур и питаний с включённой функцией автокалибровки = +-0.5% Всего-то 0.5% А ошибки обычно делают те, кто мануалы не читает. Вообще-то в каждом конкретном случае применяют то, что наиболее удобно пользователю, а не разработчику. В моём случае - удобен светодиодный индикатор. А не ЖК, к которому пришлось бы ещё подсветку лепить.

@makc @slonok В Logos2/Titan2/Kosmo2 с TMDS всё оказалось ещё хуже, чем я вчера думал: Сегодня поставил 2023.2-SP3 и вот не поленился прочитать Release_Notes_2023_2_SP3 (microterra).pdf (ещё раз благодарю @Gas Wilson за предоставленные PDS и документы). И в нём вдруг обнаружилось (в последнем BUG fix'е): 3. SP3 Features 1) BUG fixes: ....... ✓ Delete the IO standard "TMDS" (Logos2, Titan2, Kosmo2 involved) Проверил, действительно, в User Constraint Editor в 2023.2-SP1 можно было выбрать TMDS, а в 2023.2-SP3 (от 2024.05.07) TMDS'а больше нет. Так что нам всем явно нужна более свежая документация на Logos2/Titan2 (DS + соответствующие UG), как минимум отражающая отсутствие поддержки TMDS в этих ПЛИС. @Gas Wilson При наличии возможности, пожалуйста, посодействуйте в этом вопросе.

Прочитайте последний комментарий в теме. Просьба была удовлетворена модератором и я с этим полностью согласен - такие темы нужно дробить. Иначе в них потом ничего никогда найти не получается Так же самая история, что и выше. Для новых вопросов нужно создавать отдельные темы, а не перегружать тему с максимально общим названием.

Т.е. еще корпус и коммутатором еще и управлять надо. Итого изделие получается никому не нужным франкинштейном. Зачем осваивать то, что только мешает? Это проблема не программ, а программиста. Тогда зачем он нужен? В каждой программе так или иначе есть системный таймер который периодически вызывается(скажем, раз 1 мс) и на базе которого строятся все остальные программные таймеры. Он и так есть. На базе его ничего не стоит вызвать нечто, скажем, каждые 10мс.

Ага, иногда в виде бесплатного цирка на такое посмотреть можно, за одним разобрать "вредный пример" из раздела "как нельзя делать". Вот смотрите, там представлен самый простейший случай коммуникации, судя по скринам состояния регистров CR1, CR2, CR3: базовый UART с включенным передатчиком и приемником, однобайтовая коммуникация без FIFO и DMA, разрешен запрос прерывания только по приему байта (RXNE) и запрещена реакция на переполнение приемника. Всё. Каким образом должна работать такая конфигурация - при приёме байта выставляется запрос RXNE и вызывается обработчик прерываний USART. То есть, исходя из показанных настроек, должен вестись только прием байтов в однобайтовом режиме. Но что у автора написано в тексте обработчика прерывания? А там начинается цирковая дичь: безусловная проверка всех подряд флагов, в том числе и самая фатальная ошибка - проверка флага TXE, который всегда, за исключением одного случая, = 1. Следствием этого будет непрерывная передача TX, как я показывал на осциллограмме ранее. Для решения этой проблемы что делает автор - он просто переносит программную переменную tx_flag = 1 в другое место, под проверку флага завершения передачи TC. По умолчанию после сброса модуля USART этот флаг присутствует, поэтому так же возможен ложный запуск в таких условиях, и это вторая ошибка. Однако, появление TC можно предотвратить, если его предварительно сбросить и ничего не передавать, тогда он больше не будет появляться. Эта часть кода в блоке if(tx_flag), к сожалению, не показана. Теперь что касается RXNE. Автор придумал цирк такого плана: usart_sr_my = UART5->ISR - то есть, получил независимую копию ISR с флагами. Далее, он без проверки флагов читает usart_rdr_my = UART5->RDR. При этом в исходном ISR сбрасывается флаг RXNE. Остальные флаги этим действием не сбрасываются. Однако, перед этим участком присутствует блок со сбросом большинства флагов, которые могли выставиться, в том числе и ключевых для приема - NE, FE, PE. То есть, фактически уже неоткуда взять информацию об ошибках приема. Далее, несмотря на фактический сброс RXNE при чтении RDR, в независимой копии usart_sr_my, полученной ранее, срабатывает if((usart_sr_my & USART_ISR_RXNE). Дальнейшие действия с принятым байтом в представленном коде не показаны. И после этого следует еще один блок с двухкратным сбросом всех флагов в ISR, сначала записью 0xFFFF, затем "контрольный выстрел в голову" в виде дополнительного сброса уже сброшенных флагов. Про |= уже не говорю, это мелочи. Что нужно сделать в этой ситуации. Как в анекдоте - оставить скобки { }, а между ними вложить новый код обработчика прерывания. В коде: для передачи - проверка флага TXE совместно с битом разрешения запросов TXEIE, при истинном результате - запись в TDR очередного байта; для приема - проверка флага RXNE, и затем, после проверки отсутствия NE, FE, PE - считывание байта из RDR и складирование его в массив. При выставленных NE и FE - сброс RXNE и, либо запуск автодетектирования скорости, либо сообщение об ошибке приема. При PE - либо продолжить прием, сбросив PE, а считанный байт пометить как поврежденный, либо остановить прием и вывести сообщение о помехах в связи. Таким образом будут отсечены большинство коммутационных помех и ошибок неверной скорости. Так же следует реализовать обработку флага Idle для обнаружения начала блока принимаемых данных. Про реализацию аппаратной поддержки таймингов модбаса тут пока что речь не идет. Автору нужно научиться правильно управляться с базовым функционалом. Например, вот, работа с обнаружением коммутационных шумов в линии (петля TX-RX) и остановка передачи TX с завершающим сигналом Break (он же Framing Error на приемной стороне):

Есть много вариантов диэлектрических охлаждающих жидкостей на основе: - перфторполиэфиров (жидкость ПЭФ, используется в вакуумных насосах например); - фторкетонов (Novinec); - перфторуглеродов (Fluorinert); -полидиметилсилоксана (Wacker AK-10); - полиолефинов; - минеральных масел и т.д. Все они по теплопроводности в 4-10 раз хуже деионизированной воды, но зато стойкие в отличие от. Жидкости для иммерсионного охлаждения так же могут быть разные - например для т.н. двухфазного охлаждения жидкость имеет точку кипения при 50-55 градусах. Но. В этой теме, как я понимаю, предлагать такое просто неприлично 🙂 Тут надо что-то вроде керосина, лампадного масла, ослиной мочи и т.п. ТС не ищет лёгких путей.

1000 ppm это "стабильная частота"??? "Куда катится этот мир?"..

У хорошей подложки потери маленькие, тем более у керамики. Чтобы достоверно измерить их надо линию в полметра- метр городить. Если на ламинате, где и потери больше, можно змейкой уложить полметра линии, то на мелкой керамической подложке это маловероятно. Поэтому измеряют потери по добротности резонатора. Получается всего несколько точек по частоте, по числу резонаторов, ну а потом интерполируют. Говорят, AlN подложки можно слегка перестаривать по частоте, используя ультрафиолетовые светодиоды. Получается новый тип перестраиваемых фильтров и резонаторов.

А что именно непонятно? Если речь про МК на Cortex-M то стартуют они так: По сигналу RESET все регистры МК переводятся в исходное (RESET) состояние, далее - делается выборка из RESET-вектора таблицы прерываний адреса верхушки стека и стартового адреса исполняемого кода, происходит переход на исполняемый код. Всё. Если в RESET-векторе находится стартовый адрес бутлоадера, то переход произойдёт на него.