Минимальный российский RISC. MDR1215LGI и MDR1219LGI от Миландр.

[Adrift]

Какие-то совсем новые чипы?

Последняя серия, если не считать анонсированного V8, на днях платку от Weact получил. За счет 40nm техпроцесса ST сделала камни на M33 дешевле, чем 90nm STM32G0 на M0+.

Да, реально заварили 4 проволочки с чипа на один и тот же вывод! А чё, так можно было, что-ли?!

Такое давно делают:

[ejsanyo]

Такое давно делают:

О, не иначе опять кто-то у кого-то подсмотрел! Хотя, у STm-а то наверно ноги мультиплексируются через коммутатор, а не запараллелены напрямую, как здесь?

Кстати о ногах, осталось упомянуть ещё один момент, без которого тема входов-выходов не будет полностью раскрыта:
Упомянуть, что в наших чипах, к сожалению, все ноги умеют работать либо только входами, либо двухтактными (push-pull) выходами. В смысле режима "открытый сток" тут не завезли, а жаль, в I2C и ему подобных интерфейсах было бы удобнее. Никакой "5В толерантности" у входов нет, что также печально. А выходы весьма слабые по нагрузочной способности, есть 2 градации мощности: до 2 мА и до 4 мА. Так что какой-то внешний буфер, по хорошему, придётся вешать даже чтобы нормально зажечь светодиод. И всё это вдвойне странно в свете того, что в ARM-чипах Миландра (да в том же К1986ВЕ92) всё перечисленное есть, и выходы нормальные, может, даже сильнее, чем в этих ваших STM32! Попытались сделать какой-то особо экономичный выходной каскад? Или у них отняли лицензию на нормальный IP-блок портов? Ну хотя бы сохранили возможность активировать слабую подтяжку как на плюс, так и на землю. "Атомарные операции" (выставить 0 или 1 в определённом разряде, не затрагивая остальные) поддерживаются на аппаратном уровне через специальные регистры (кстати, в К1986ВЕ92 такого не было).

[Adrift]

Хотя, у STm-а то наверно ноги мультиплексируются через коммутатор, а не запараллелены напрямую, как здесь?

Соединены. Мультиплексируется только пара ног, там где PA12[PA10] и PA11[PA9].

[ejsanyo]

Соединены. Мультиплексируется только пара ног, там где PA12[PA10] и PA11[PA9].

Не совсем понял из даташита на серию...т.е. здесь тоже можно включить пару выходов на конфликтующие уровни? И ладно бы Миландр и его дохлые пара мА (кстати теперь думаю, уж не по этой ли причине их так придушили по току? ), но у ST-а то минимум полные 20! Неужто буржуи и правда такое допустили?!
Впрочем, вернёмся к нашим баранам MDR-ам. Пришло время, наконец, что-нибудь на них попробовать сделать. И начнём, пожалуй, с простого, с MDR1215LGI. Как уже отмечалось, более-менее полноценно на его ногах представлен 32-битный Таймер 1. А раз так, логично попробовать сделать на его основе, скажем...частотомер?
Захотелось тут, было дело, сделать такой индикатор нам на производство, чтобы контролить частоту напряжения при настройке. Напряжение порядка несколько сотен вольт, частота где-то от 50 до 400 Гц. Но точность при этом хотелось иметь повыше, как и "отзывчивость" прибора, т.е. период обновления показаний чтобы был почаще, чем в среднетипичном тестере, скажем, но ещё не слишком мельтешащим и раздражающим. Этому неплохо соответствует метод измерения частоты через период. Берём генератор импульсов с образцовой частотой, считаем при помощи таймера, сколько в попугаях количестве этих импульсов длится период измеряемого сигнала, и по сути получаем значение его периода. А пользователю выводим обратное значение от этой величины, это и будет частота. Так что в минимальном случае результат измерений у нас будет готов уже через один период сигнала. Дополнительно можем позволить себе сделать "скользящее среднее" из нескольких отсчётов, чтобы снизить флюктуации показаний.
Покажем уже наконец схему и по ней покажем, что тут к чему:

Если форум снова зашакалит картинку, здесь полный проект в Altium Designer 10 и исходники прошивки: https://drive.google.com/file/d/1dbp3GH ... sp=sharing hex-файл лежит в папке MDR1206_FLASH_RELEASE.
Начнём с цепей входного сигнала. Поскольку с той стороны высокое напряжение, сделаем его гальваническую развязку на китайском трансформаторе напряжения ZMPT101, подозрительно похожем на трансформатор тока. Действительно, на самом деле он передаём именно ток в соотношении 1:1, который задаётся двумя резисторами R1, R2. Резюки должны быть достаточно могучими, чтобы выдерживать напряжение и мощность. Рекомендую взять их на мощность не менее 1 Вт, этого должно хватить для диапазона входных напряжений от нескольких десятков до 500В. Но, собственно, сам уровень напряжения нас сейчас не интересует, нам нужна частота. Поэтому дальше стоит простейший ключ-формирователь импульсов на VT1, который заводится на вход таймера для захвата (input capture). Кстати, вы обратили внимание, как мы лихо скооперировали его с подтяжкой JTAG в виде R4? Причём, пока сигнала на входе нет, ключ закрыт и на работу JTAG влиять не будет!
Вот и минимальный набор для измерения готов...но чего-то, кажется, не хватает? Генератора опорной частоты, конечно. Да, мы можем использовать внутренний RC-генератор чипа в качестве опоры, но, несмотря на заводскую подгонку, с точки зрения метрологии это такое себе. Поэтому хотелось бы чего-нибудь кварцевого для таких целей. И вот здесь как раз пригодится возможность работы входа ETR в качестве источника тактовых импульсов таймера! Просто берём и вешаем туда модуль кварцевого генератора. Я взял его на 4 МГц, и конечно, рассчитанный на питание 3,3В. Хотя не совсем "просто", лучше сделать это через резистор. При этом, при подключенном JTAG, его выходной буфер будет пересиливать ток генератора, ограниченный резистором, благодаря чему генератор нам хотя бы не помешает зашить прошивку. Естественно, чтобы таймер заработал, после зашивки JTAG придётся отключить (если сам JTAG-адаптер не переведёт свои выходы в Z-состояние). Поначалу я взял R5 на 10 кОм, и в принципе всё работало, но не понравилось, как на такой частоте заваливались фронты импульсов. Видимо постоянная времени получается с учётом входной ёмкости уже слишком большой, поэтому уменьшил его до 1 кОм. Мой ULINK2 вроде справляется нормально, но если есть сомнения в буферах вашего JTAG-адаптера, придётся, наверно, временно разрывать цепь, джампером например.
Вот теперь измерительный тракт точно готов, осталось сделать индикацию. Для этого возьмём банальный TM1637 и повесим на него большой и красивый модуль индикации E60561-IOOW, который идеально вписывается в возможности чипа. Поскольку иных вариантов особо нет, интерфейс с контроллером делаем по ардуиновской классике, "ногодрыгом". Не забывая при этом, что режима "открытый сток" в наш контроллер не завезли! Так что придётся его "эмулировать", почти как на AVR: переключая режим работы ноги то на выход с зажатым нулём, то на вход. Но есть ещё пара нюансов с этим подключением:
Питание на TM1637 мы даём полные 5В, чтоб индикаторы горели хорошо и ярко. Но согласно даташиту гарантированно распознаваемый уровень лог. 1 у него составляет "0,7 * Udd". Т.е. при питании 5В это будет 3,5В. Но контроллер-то питается у нас от 3,3В! Вообще пишут, что в жизни это не так критично, у людей всё нормально работает и с 3,3В уровнями. Но попробуем немного перестраховаться и подтянем R8, R9 прямо на 5В. "А так можно, что-ли?" Почему бы и нет. Конечно, в недрах контроллера при этом откроются внутренние защитные диоды на плюс питания и будут нам значительную часть потенциала лог. 1 туда сливать...ну и что? Чип от этого не сломается, с таким-то током подтяжки. а с учётом падения напряжения на диодах, мы хотя бы можем рассчитывать на уровень единицы не ниже 3,8В. И формально выполнить требование даташита!
По каким-то неписанным китайским правилам, на готовых модулях с TM1637 на линиях интерфейса всегда распаивают пару конденсаторов. Очевидно, для снижения влияния помех. Требуется ли это на самом деле, или нет - вопрос неоднозначный. Но я не стал нарушать традиций и поставил C4, C5.

Эта приспособа, дополненная блоком питания на 5В, уже во всю трудится по прямому назначению.

[ejsanyo]

Пройдёмся немного по коду прошивки и поясним наиболее существенные моменты:

Код: Выделить всё

Не забываем закомменить #define USE_JTAG в MDR32VF0xI_config.h!

Да, тем самым мы отключаем последний рубеж защиты - программный, который разработчики библиотек тщательно выстроили в своём коде. Если эту строку оставить, библиотечные функции будут блокировать все "опасные" действия, которые могут отключить JTAG. Но, во имя функциональности, нам придётся идти на определённый риск.

Код: Выделить всё

RST_CLK_HCLK_InitStructure.RST_CLK_PLLCPU_Multiplier = RST_CLK_PLLCPU_MUL_2; //будет 16 МГц
RST_CLK_HCLK_InitStructure.RST_CLK_CPU_C2_ClockSource = RST_CLK_CPU_C2_CLK_SRC_PLLCPU;
и далее...

Здесь, очевидно, мы включаем PLL и немного умножаем частоту RC-генератора...но зачем? Неужели 8 МГц не хватит на такие простые задачи? И здесь мы плавно переходим к разговору о серьёзных ограничениях возможности таймера. Взглянем на структурную схему из даташита:

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

Код: Выделить всё

RST_CLK_PER1_C2_Cmd(RST_CLK_PER1_C2_TIM1, ENABLE);
RST_CLK_PCLKCmd(RST_CLK_PCLK_TIMER1, ENABLE);

Да, в этом смысле наш чип, пожалуй, уступает некоторым PIC16, в которых таймер можно было гнать гораздо быстрее частоты ядра. Чем активно пользовались создатели любительских частотомеров. Но для нашей задачи и её частот имеющихся возможностей всё ещё достаточно.
Но всё-таки, зачем тогда мы включаем умножитель? 8 МГц частоты RC-генератора как раз в 2 раза больше кварцевой. Так...да не совсем: у любого генератора есть допуски по частоте, а также нестабильность во времени. И этот хрупкий баланс частоты в результате может нарушаться, что у меня и происходило на практике - частотомер показывал какой-то случайный бред. Так что реально разницу частот придётся делать с запасом, больше двух. И раз уж кварц я уже впаял на 4 МГц...пришлось выкручиваться разгоном внутренней тактовой частоты.
Кстати, на входе активации захвата таймера подобный фильтр также присутствует, и здесь как раз будет разумно этой функцией воспользоваться, адекватно настроив его полосу пропускания.
Из нетипичного можете увидеть в коде пример использования аппаратного блока для расчёта контрольных сумм. Он там весьма удобен и функционален. А также правильную последовательность инициализации и работу с Watchdog-ом.
Местную систему прерываний и правила работы с ней весьма подробно расписал в специальной статье один из разработчков (?) чипа. Отметим только, что здесь мы использовали векторный режим прерываний (а в чём вообще смысл им не пользоваться?!). Одно прерывание, очевидно, срабатывает на событие захвата таймера. Но также очевидно, что при пропадании сигнала на входе события захвата таймера также пропадут, и цикл измерений так и зависнет в бесконечности. Так что нужно предусмотреть некоторый таймаут, по истечении которого показать пользователю, что частоты на входе нет. Для этого включаем в работу Таймер 2 (какая разница, всё равно без дела простаивает) и его прерывания по счёту до заданного порога.
Часть интерфейса TM1637 реализована по самому банальному принципу, с активным использованием программных задержек DELAY_WaitUs(), DELAY_WaitMs() для задания длительности импульсов. Хочется ещё раз похвалить разработчиков библиотек за грамотную реализацию этих функций.

[ejsanyo]

А здесь у нас ещё один пример самоделки на MDR1215LGI. Тоже вполне рабочий

[ejsanyo]

Кстати да, следует уточнить кое-какие моменты про MDR1219LGI:

• Ноги PA10, PA11 можно задействовать не только под UART, но и под Таймер 4, аналогично PA6, PA7 в MDR1215LGI.
• Кроме того, нога PA10 может стать входом внешнего прерывания.
• А вот SPI, к сожалению, в нормальном виде здесь использовать не получится, поскольку сигнал SSP2_CLK остался в недрах чипа. Так что пригодится он, разве что, в каком-нибудь нестандартном применении, вроде генератора импульсов.

И конечно, в Eclipse чтобы скомпилировать проект в выбранной конфигурации, необязательно жмать "Build All", лучше выбрать "Build Project".

[Zapolyarny]

То есть, вместо нормального RM, будет эта ветка? Заодно с "обучением" работы в Eclipse? А зачем?

[ejsanyo]

То есть, вместо нормального RM, будет эта ветка?

"Нормального"...кого?

[Zapolyarny]

Руководства по применению. Reference Manual. У них его нет?

[ejsanyo]

них его нет?

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

[Zapolyarny]

Ясно. Тогда полезно.
Однако, насчёт других микроконтроллеров... я пока лишь один раз нашёл "косяк" в PIC18F14K50 - описание работы модуля USB в одном месте не соответствовало действительности. А так-то обычно более чем описаны импортные. И если для этого мк нужны такие изыскания, то как-то он не вызывает желания приобретаться...

[smacorp]

Ну так и не приобретайте. Если Вы не понимаете зачем Вам нужны именно российские комплектующие микроконтроллеры, значит они Вам не нужны.

[Zapolyarny]

Я искренне рад за Вас, что Вы понимаете, зачем Вам нужны псевдороссийские микроконтроллеры на порядок дороже с сомнительной поддержкой и практически фабрика-лесс.
Мне-то, ущербному, этого не понять.

[ejsanyo]

я пока лишь один раз нашёл "косяк" в PIC18F14K50

Уверен, что наверняка этим дело не ограничивается. Наверняка имеются какие-то нюансы использования MPLab-а (или под чем сейчас предлагается кодить под микрочипы ), которые вам очевидны, а другим - не особо? Вы бы могли сделать в соседнем разделе свою ветку и провести в ней обзор свежих псевдо-американских PIC-ов, наверняка эта контора не сидела без дела с тех пор, как скушала псевдо-норвежский Atmel? Ну, или не знаю в каком разделе, но провести полный сравнительный обзор воистину-китайской линейки ESP32...хотя да, с рассовой чистотой там тоже всё спорно.
В данной же ветке мы продолжим делиться знаниями, полученными относительно новой миландровской продукции. А что же именно мы недавно узнали? Например то, что в MDR1219LGI у нас присутствует вход АЦП. Не опробовать ли нам его в деле? Например, как он себя покажет в качестве...вольтметра?
Даташит нам скромно обещает "10 бит, в качестве опоры - напряжение питания, до 500 кВыборок/с, нелинейность в районе 1 МЗР". В общем, всё как обычно.
Есть канал встроенного датчика температуры, громоздкая, хоть и не особо сложная формула для которого приведена в соответствующем разделе. Как всегда, для встроенных датчиков, эта формула весьма примерная, и результаты зависят от конкретного экземпляра чипа. Так что сойдёт либо только для очень грубой защиты устройства от перегрева, либо делайте сложную нудную индивидуальную калибровку, либо просто используйте более точный внешний датчик.
Можно в специальных регистрах задавать две уставки, если очередной отсчёт АЦП их пересекает, генерится прерывание (это обзывают "Преобразование с контролем границ"). Может пригодиться, если будем делать какое-нибудь пороговое устройство.
Но если присмотреться к структурной схеме, можно увидеть, что для АЦП можно включить в качестве опоры гораздо более стабильный, чем питание, встроенный источник опоры VREF_INT, с номинальным напряжением 2,4В. Хоть в корпусе MDR1219LGI он наружу не выведен, но он есть, и его на самом деле можно включить. И он работает! Почему были сомнения? Потому что в даташите есть раздел "Предельно-допустимые и предельные параметры", в котором, если присмотреться, старательно не нормируют параметры АЦП при работе с VREF_INT. Странно...тогда я спросил у ясеня техподдержки Миландра, что бы это значило? Оказывается, суть как раз в том, что в отличие от "полнокорпусного" MDR1206, опора не выведена наружу. В результате, на производстве после корпусирования...изготовитель просто не в состоянии адекватно измерить параметры VREF_INT. А потому и не может давать гарантии относительно него в данном исполнении. Но технически, да, источник VREF_INT внутри такой же, и с технической точки зрения его параметры должны быть те же самые, что и у "полной версии" чипа.
Но кажется, мы ещё о чём-то забыли. Даташит нам говорит, что мы можем тактировать АЦП либо частотой, которая идёт на процессорное ядро, либо включить отдельную ветку делителей от тактового генератора. И довольно кратко упоминает, мол, "Максимальная частота не может превышать 28 МГц". Хорошо, а как насчёт...минимальной частоты? А она явно должна быть, поскольку обязательный элемент любого современного АЦП - устройство выборки-хранения, которое способно сохранять мгновенное значение сигнала лишь ограниченное время! Техподдержка Миландра прокомментировала это так, что официально они нормируют лишь максимальную частоту. Разработчик чипа рассчитывал на минимальную тактовую частоту не менее 1 МГц, хотя при заводских испытаниях АЦП вполне соответствовал заявленным требованиям и на гораздо более низких тактовых частотах. У меня он, по факту, адекватно работал на тактовых частотах порядка нескольких кГц. Опять скромничают? Хотя совсем дотошно, во всём диапазоне температур, я его пока не проверял.