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

[ejsanyo]

Удивительные вещи порой происходят в наше время. Не так уж давно известный в узких кругах НИИЭТ умудрился порвать шаблоны, нежданно-негаданно выйдя в люди прямо на Озон со своей продукцией! Можно сказать, первый, уникальный случай в российской практике. И пошли внезапно у них продажи новых контроллеров, явно бодрее, чем ожидали сами авторы эксперимента, и всё было хорошо. И увидели другие производители российской электроники, из тех, что ещё остались более-менее в живом состоянии к тому моменту, что это хорошо, и решили некоторые из них последовать их примеру. Вышел Микрон туда торговаться, со своими знаменитыми MIK32. Вышел и Ресурс с кучей своих новых резисторов. Вышел Синтез-ПСЖ со своими сердечниками, которые некогда делал для буржуев из Micrometals. И вот, весной сего года, не менее широко известный в узких кругах Миландр, без особого шума и рекламы, тоже взял, да и появился на Озоне со своими чипами, среди которых есть и новые, есть и относительно старый, но в новом корпусе, К1986ВЕ92. Но речь сегодня не о нём, а о наших новых друзьях, по имени MDR1215LGIи MDR1219LGI, на основе модного нынче в этой стране, да и в Китае, ядра RISC-V. Их обсуждению, собственно, предлагаю посвятить эту ветку форума.
Чем же таким нас могут удивить эти чипы с названием, написанным латинницей? Во-первых, бросается в глаза непривычный для российской продукции, очень мелкий, "безногий" корпус-"кубик". При этом, среди заморских чипов также не встречающийся.


В левом углу у нас MDR1215LGI, в правом - MDR1219LGI. Судя по всему, это собственная разработка конторы под названием GS Nanotech. Как известно, Миландр у нас "fabless"-компания, посему логично, если для корпусирования кристаллов они обратились за сторонней помощью. Привлекает внимание также настоящее золочение контактов корпуса! Редкая в наше время вещь, встречавшаяся ранее лишь у первых корпусированных образцов MIK32. Это на практике даёт отличный бонус к пайке. Но, очевидно, понимая, что для многих самодельщиков изготовление платы под такие мелкие контакты и их пайка всё равно представляет трудности, на днях производитель выкатил новую компоновку-полуфабрикат, в виде контроллеров, распаянных на мелкие платы со стандартным шагом. Да, это событие, на самом деле, и побудило к поднятию данного топика. Раз уж редактор статей на сайте по прежнему не готов.
Небезынтересна также сама история появления данных чипов. Она прям-таки в духе нынешнего времени! Помните ли вы "очень странные" модули ОЗУ российского производства, в которых вместо типичного чипа SPD был внезапно впаян целый MIK32? Зачем так делать? Как многие догадались, делается всё это ради пресловутого набора "баллов" от Минпромторга, чтобы с гордостью сказать, что, мол, "в нашем изделии есть хоть что-то российское". Так вот, эти чипы изначально создавались именно для этих целей, чего производитель совершенно не скрывает. Не буду касаться здесь логической, моральной и прочих оценок данного явления, здесь мы обсуждаем лишь техническую сторону. И в этом плане интересно, каким же образом производитель создал такие специализированные контроллеры? Оказывается, ничего принципиально нового он и не изобретал. Они просто взяли кристалл от контроллера под названием MDR1206FL, который изначально идёт для счётчиков электроэнергии и прочих подобных приборов, и разварил малую часть его выводов в мелком корпусе! Не утверждаю, конечно, что на такие вещи у них идёт совсем один в один такой же кристалл (возможно, ставят отбраковку с нерабочим трёхфазным сигма-дельта АЦП?), но, по крайней мере, чипы описаны в общем даташите. Некоторые вопросы, впрочем, вызывает выбор разваренных выводов: почему, например, не вывели на ноги аппаратный I2C (а он в чипе есть), из-за чего программистам пришлось городить софтовый эмулятор? Но что есть, то есть.
Ладно, а если помимо эмуляции баллов SPD, что ещё возможно выжать из MDR1215LGI и MDR1219LGI за эти деньги? Можно ли на их основе сделать вообще хоть что-то полезное? С этим и будем разбираться. Если у вас уже был опыт общения с этими чипами, не стесняйтесь присоединяться с обсуждению.

[ejsanyo]

С чего, как правило, начинается знакомство с новой платформой? Правильно, с вопроса "в чём мне это программировать и отлаживать?". С этим у российских RISC-V по жизни всё так себе. Миландр, увы, исключением не является. Читаем очередную "простыню" и пытаемся понять, откуда куда скачать Eclipse, подключить то, настроить сё, станцевать с бубном... Попытаемся хотя бы под Windows немного улучшить ситуацию. Подготовил я для себя такой самосбор из не самого свежего Eclipse-а и GCC, частично пропатченного CloudBear, рассово российским разработчиком ядра, которое использует Миландр. Изначально делалось это для других чипов, но и для этих подойдёт. По крайней мере, оно работает, и новичкам чтобы начать будет достаточно. А впоследствии, по мере развития, никто не мешает её улучшать, обновлять и т.д. Качать сборку тут: https://drive.google.com/file/d/1ImXHBZ ... sp=sharing Запускается файлом start-scr-ide.cmd Затем выбираем Open project from file system. Выбираем папку workspace\MDR1206FI_Template через кнопку Directory и жмём Finish. Это типично-шаблонный проект как для MDR1206, так и для сегодняшних героев, поскольку, как уже говорилось, кристалл у них идентичен. Здесь у нас заготовлены две конфигурации проекта. Одна оптимизирована для отладки, другая, очевидно, для продакшена. Выбирается правым кликом на корне проекта и далее в меню:

Выбрав конфигурацию, можем скомпилять наш проект. Через то же меню в Build Configurations -> Build All, или нажав "Молоток" в левом верхнем углу.

[Denis82]

я правильно понимаю, наши отечественные производители предлагают покупать плату за ~2к, потом помучатся с IDE и быть счастливыми ?
а ничего что тот-же заезженный stm32f103c8t6 (сравним с миландровким К1986ВЕ92FI) на том-же озоне ~200р и со средствами отладки и разработки вообще проблем нет (про VPN умолчим, он по умолчанию маст хев в РФ), плюсом гигантское комьюними на любых языках

ничего не упустил ?

[ejsanyo]

Ну вообще говоря, фирменные макетки от STm ой как недёшевы, даже до сих пор. Другое дело что Кетай вывозит своими копеечными аналогами, более или менее идентичными натуральным. Каких-нибудь своих "кубиков" Миландр, очевидно, не сделал, но библиотеки у них реально хорошие и грамотно сделаны, особенно последних версий. (С другой стороны, нынешний Куб такой перегруженный шлак генерит вместо кода, что, лично с моей точки зрения, да, с него можно начинать, чтобы получить быстрый старт, но в процессе развития лучше перейти на тот же STm-овсий SPL. ) Есть К1986ВЕ92FI, он на ARM-е среднетипичном, а значит, и всяких домомучений с опенсурсом можно избежать, например, взяв банальный Keil. Но сегодня речь у нас про RISC-V, а с ним по жизни всё не просто. Хотя если немного привыкнуть, оказывается, что вполне работает...это как с линуксом, наверно. В общем, наше дело рассказать, а выбирать вам.

[smacorp]

я правильно понимаю, наши отечественные производители предлагают покупать плату за ~2к, потом помучатся с IDE и быть счастливыми ?
а ничего что тот-же заезженный stm32f103c8t6 на том-же озоне ~200р
ничего не упустил ?

Упустили.

Если Вы делаете проекты для себя, для соседа или просто для внутренних нужд какой-нибудь конторы, заезженный stm32f103c8t6 нормальное и очевидное решение.
Но если Вы работаете с серьёзными организациями, завязанными на Минпромторг и вращающимися в высших сферах - крупнейшие банки, концертные залы, стадионы, промышленные предприятия - без импортозамещения, а значит отечественных производителей не обойтись. Это раз.

А два - если не пройти сейчас этап дорогих российских плат, мучений с IDE и прочих болячек развития, в России и в будущем будут уповать только на Китай и параллельный серый импорт, а это катастрофа. Если Вам присуща хоть малая толика патриотизма, Вам этот момент должен быть предельно понятен.

[smacorp]

Зачем так делать? Как многие догадались, делается всё это ради пресловутого набора "баллов" от Минпромторга, чтобы с гордостью сказать, что, мол, "в нашем изделии есть хоть что-то российское".

Насколько я в курсе, чтобы иметь рейтинг в Минпромторге необходимо минимум 10% российских комплектующих. И это считается "плохо".
"Неплохо и даже хорошо" это 25%. Сомневаюсь, что добавление всего лишь одного чипа позволяет набрать такие баллы. Значит там или есть другие российские комплектующие, или дело не только в баллах.

[JackSmith]

А два - если не пройти сейчас этап дорогих российских плат, мучений с IDE и прочих болячек развития, в России и в будущем будут уповать только на Китай и параллельный серый импорт, а это катастрофа.

дело не в этом. у нас маленький рынок. а стоимость разработки всегда делится на объемы продукции. поэтому суверенная электроника у нас всегда будет дорогой. это законы экономики.

[smacorp]

Как может быть маленьким рынок электроники в настоящее время и в такой стране, как Россия? Электроника сейчас везде и у каждого в десятках проявлений.

Рынок суверенной электроники потому и мал, что её пока практически нет. Но что-то делается, ситуация постепенно выправляется и первый пост ТС тому свидетельство. Поэтому пройдёт время, пройдут проблемы развития и будущим поколениям будет из чего выбрать именно из полностью российской электроники.

[JackSmith]

Как может быть маленьким рынок электроники в настоящее время и в такой стране, как Россия?

сравните наш рынок с рынком китая, сша, ес. с теми, с кем придется конкурировать. т.е. китайское всегда будет дешевле, что мы сейчас и имеем.

[smacorp]

JackSmith, то что Китай всегда (или очень долго) будет дешевле я, пожалуй, соглашусь. Только ведь и это не факт. Уж насколько широк рынок западного автопрома, а и наш российский имеет неплохой сбыт, да ещё и дешевле при этом. Похожая ситуация и на рынке лекарственных средств - большое количество российских дженериков, которые, опять же, дешевле западных дженериков, не говоря у же об оригиналах. Так почему бы когда-то не стать такой же и ситуации на рынке отечественной электроники?

[ejsanyo]

Насколько я в курсе, чтобы иметь рейтинг в Минпромторге необходимо минимум 10% российских комплектующих. И это считается "плохо".

На самом деле там ещё мо-ожно "добить", прописав в спецификацию рассово российские Р1-12, какие-нибудь кондёры, плату, корпус... Но в данном случае...

Но если Вы работаете с серьёзными организациями, завязанными на Минпромторг и вращающимися в высших сферах...

...ну его нафиг, все эти подачки Минпромторга, намного же интереснее попробовать именно "для себя" и понять, годны ли на самом деле эти чипы? Сами по себе, без политического и прочего контекста.

[ejsanyo]

А что нам потребуется дальше в обязательном порядке, помимо IDE? Правильно, как-то надо будет всё это дело зашивать, а лучше - потом и отлаживать прямо в схеме. Стандартным интерфейсом отладки в мире RISC-V считается старый добрый JTAG. Некоторые производители пытаются идти иным путём, вспомнить, например, тех же китайцев WCh и их линейку CH32V (и их SWD-подобный интерфейс, совместимый лишь с самим собой). Разработчики из Миландра не стали в этой части "изобретать велосипеды", а вставили в чипы стандартный JTAG, хоть и с минимальным для него набором сигналов. Что, пожалуй, в данном случае хорошо. Но есть у этого и обратная сторона, весьма неприятная для восьминогого корпуса: JTAG одним махом съедает половину этого количества! А ведь землю и питание тоже нужно куда-то подключить. Итого, совсем не занятых при отладке ног у нас остаётся...всего две! Ладно, для более нового MDR1219LGI этих ног уже остаётся целых три, поскольку там земля заводится через "пятак" на пузе чипа. Хорошо, что есть хотя бы возможность оперативно выключить из кода прошивки этот самый JTAG, освободив его ноги для других целей. Но делать это нужно осторожно, всегда держать в голове, что эти ноги могут понадобиться для перепрошивки! Забудете об этом - и, скорее всего, всё, контроллер превратится в "кирпич", поскольку внешних средств каким-либо образом вновь вернуть JTAG к жизни нет! Я эту проблему решаю тем, что вставляю в самом-самом начале прошивки, в аккурат перед отключением JTAG-а, задержку:

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

DELAY_Init(DELAY_MODE_MACHINE_TIMER); //настраиваем функции delay

DELAY_WaitMs(2000); //не пренебрегать этим!
BKP_SetRegistersLock(RESET);
BKP_JTAG_Cmd(DISABLE); //вырубаем JTAG, разрешая работать ногам PA6...PA9
BKP_SetRegistersLock(SET);

Обратите внимание, какая большая задержка, 2 секунды. Не мелочитесь, делайте так же! Практика показала, что пока вы даёте питание, пока жмякаете кнопку в IDE, пока проснётся OpenOCD, да растолкает отладчик...в общем, будет о-очень сложно поймать момент, если сделаете меньше.
Ладно, мы же забыли показать распиновку JTAG на выводах чипов?

• PA6 = TCK
• PA7 = TDO
• PA8 = TMS
• PA9 = TDI

Все эти ноги, согласно традициям JTAG, рекомендуется подтянуть на плюс питания. Я использую резисторы 10 кОм. И самое главное - если вы будете использовать эти ноги ещё для каких-либо целей (а вы наверняка будете), придётся учитывать в схемотехнике устройства тот факт, что к ним будет подключаться что-то ещё, причём сигналы не должны конфликтовать друг с другом! Нужен творческий подход. Если к ноге подключен какой-то вход вашей остальной схемы, то думайте, не могут ли сделать что-то нехорошее JTAG-сигналы, временно на этой ноге появляющиеся? Если подключается выход - дважды думайте, не будут ли сигналы этого выхода конфликтовать с JTAG? Не появятся ли они в какой-нибудь неловкий момент, заглушив процесс прошивки? Стоит ли подать сигнал на ногу напрямую, или лучше через резистор? Или, в крайнем случае, поставить джампер, разрывающий цепь на время прошивки?

[Denis82]

я правильно понимаю, наши отечественные производители предлагают покупать плату за ~2к, потом помучатся с IDE и быть счастливыми ?
а ничего что тот-же заезженный stm32f103c8t6 на том-же озоне ~200р
ничего не упустил ?

Упустили.

Если Вы делаете проекты для себя, для соседа или просто для внутренних нужд какой-нибудь конторы, заезженный stm32f103c8t6 нормальное и очевидное решение.
Но если Вы работаете с серьёзными организациями, завязанными на Минпромторг и вращающимися в высших сферах - крупнейшие банки, концертные залы, стадионы, промышленные предприятия - без импортозамещения, а значит отечественных производителей не обойтись. Это раз.

А два - если не пройти сейчас этап дорогих российских плат, мучений с IDE и прочих болячек развития, в России и в будущем будут уповать только на Китай и параллельный серый импорт, а это катастрофа. Если Вам присуща хоть малая толика патриотизма, Вам этот момент должен быть предельно понятен.

да я то только ЗА Российскую электронику но, я таки коснулся, хоть и краем, таких госпроектов как ТСПУ и безопасный город, и скажу вам откровенно, это расово верное железо одобренное Минпромторгом на поверку галимый Китай, ещё и хренового качества
государство тратит миллиарды на это, а выхлоп пшик, и мое имхо вся эта возня вокруг Минпромторга это чистой воды распил бабла
так что как бы это не печально но все эти миландры и прочих нанотехнологии будут востребованы только в госсекторе, там где бабло можно попилить, на широком рынке не выдержат конкуренции

[ejsanyo]

Раз уж мы теперь знаем, куда и как подключать отладчик, то теперь нужно понять, какой подключать отладчик? Казалось бы, всё просто: берём что-либо, имеющее на борту JTAG, и шьёмся? Не всё так просто. Во-первых, та или иная приспособа должна поддерживаться вашим IDE, во вторых, адекватно работать с конкретным чипом. Поддержка IDE, в случае нашего самосбора на Eclipse-е, означает поддержку в OpenOCD, причём именно в той версии, которая была специально подготовлена Миландром! Да, а вы что думали, что опенсурс-то должен быть свободен от политоты и прочих подобных заморочек? А вот и нет, после "самизнаетечего" ихний мейнтейнер OpenOCD отказывается включать официальную поддержку российских чипов в свой проект. Вот и приходится производителям брать исходники и патчить их под свои изделия самостоятельно.
Возвращаясь к теме JTAG-приспособ, из тех, что были опробованы лично автором: пожалуй, стабильнее всех показала себя коробка под названием...ULINK2!

Вот это поворот, кошки дружат с собаками ARM помогает отлаживать RISC-V! Тем не менее, факт. Возможный, благодаря тому, что начиная с какого-то времени ULINK2 стал поддерживать открытый api под названием CMISIS-DAP, который поддерживается в OpenOCD. Чтобы активировать поддержку, возможно, придётся взять Keil и станцевать несложный танец, согласно этой инструкции. Проверено как на рассово буржуйских оригинальных коробках производства Keil, так и на китайских практических 100-процентных клонах. Единственное что: при покупке будьте внимательны, иногда нехорошие продаваны подсовывают в таких корпусах убогие клоны STLINK-а!
Seggrer-овский JLink тоже мимоходом был однажды частично проверен, и он, по крайней мере, видит MDR1215LGI.
Далее пошло неоднозначное. Возможно, многие уже использовали такие небольшие китайские платы на основе чипов FT2232/FT4232 ?

Ключевой фичей данных чипов является то, что помимо функции USB-UART, да которой они создавались изначально, в них присутствует самый настоящий JTAG, который умельцы давно научились задействовать. В OpenOCD оно тоже поддерживается, так что...на практике у меня с нашими героями MDR12xx оно работало по разному, причём явной закономерности даже не скажешь. В каких-то самоделках и на каких-то компах не работало вообще, в то время как на других всё работало стабильно и быстро. Иногда работало, но с постоянными сбоями. Могу разве что отменить, что если идут сбои, но как-то отладчик всё же пытается работать, мне часто помогало взять более "чистый" от помех источник питания для прошиваемой схемы.
Ну а теперь то, что у меня по какой-то причине не заработало вообще никак. Есть такие дешёвые китайские платы под названием "Sipeed RV Debugger", в нескольких вариантах.

Как можно догадаться, впервые их (или, по крайней мере, общую концепцию и API) придумала контора Sipeed, один из ведущих разработчиков альянса RISC-V. В OpenOCD оно поддерживается, но у меня с этими контроллерами так и не подружилось, просто их не видит. Что несколько странно, поскольку ранее, например, даже MIK32 у меня с этими отладчиками отлаживался.
Аналогичная ситуация у меня получилась с китайским клоном (или, скорее, эмулятором) Altera USB Blaster

В OpenOCD поддерживается, но чипы не видит. Я так и не понял, в чём именно проблема.

Когда вы выберете судьбу отладчик, надо будет прописать его в IDE. В нашем самосборе для этого заготовлен файл my-link.cfg , находящийся по пути sc-dt_MDR\tools\share\openocd\scripts\interface . Отредактируйте его каким-либо редактором, поддерживающим линуксовский стиль завершения строки, например, с помощью Programmer’s Notepad. Вам нужно раскомментировать настройки, относящиеся к вашему отладчику, и закомментировать остальное.

[ejsanyo]

Не очень хочется пересказывать инструкции по отладке в Eclipse, которые существуют, в том числе, для других российских контроллеров. Но пары моментов, подготовленных в нашем самосборе, коснёмся:
Сначала нужно, конечно, скомпилировать проект, выбрав Debug-конфигурацию, как было показано ранее. Далее давим стрелку под "тараканом" и выбираем Debug Configurations.

В вывалившемся окне выбираем MDR1215LGI_Template FLASH with Bootloader и кое-что исправляем: в строке C/C++ Application вставляем MDR1206_FLASH_DEBUG/MDR1206FI_Template.elf

Да, несложно догадаться, что тут мы выбираем, откуда ему брать результат компиляции, чтобы залить и отлаживать. Жмём Apply и Debug. Если всё подключено и правильно настроено, отладка запустится.
А как быть, если вы не хотите отладку, а хотите просто взять и зашить прошивку? Тогда нужно скомпилировать проект, выбрав Release-конфигурацию. После чего давим стрелку под "красным кирпичом" и выбираем External Tools Configurations

После чего выбираем заготовленный профиль Flash FW

И давим Run.

[ejsanyo]

Теперь, пожалуй, стоит затронуть процесс загрузки этих миниатюрных контроллеров. Если вы листали между делом раздел загрузок на сайте производителя, то замечали странный пункт "Загрузочная программа для микроконтроллеров"? А самые-самые любопытные, копаясь в настройках отладки нашего самосборного Eclipse-а, могли обратить внимание, что в момент запуска там вставлен в предзашивку некий файл MDR1215LGI_Bootloader.hex . Что же это за "bootloader" такой и зачем он нужен?
Те, кому довелось иметь дело к ARM контроллерами Миландра ещё в те счастливые времена, когда российским конторам ещё дозволялось выпускаться на заводах TSMC, наверняка помнят об интересной особенности устройства flash-памяти К1986ВЕ92QI: в нём есть как 128 кБ нормальной обычной flash для хранения вашей прошивки, но также небольшой отдельный раздел 4 кБ, как его обзывала докуменатция, "информационной памяти". По сути, он играет ту же роль, что и встроенная маленькая EEPROM, например, в AVR контроллерах, её весьма прикольно использовать для хранения всяких пользовательских настроек, калибровочных коэффициентов и т.д. После "самизнаетечего", в следующем поколении чипов К1986ВЕ92FI разработчики решили не просто перевести кристалл под техпроцесс другого изготовителя, а добавить наличию этой выделенной памяти больше смысла: положили там по определённым адресам калибровочные коэффициенты для тактовых RC-генераторов и встроенного LDO. Да, они просто положили туда несколько байт, оптимальное значение которых было определено в ходе заводского тестирования. Предполагается, что пользователь в своей прошивке сам подберёт их по этим адресам и запишет в соответствующие регистры! Конечно, если захочет, чтобы его чип работал максимально близко к параметрам из даташита. А может этого и не делать. Причём здесь есть определённый казус из-за того, что "информационная память", в отличие от EEPROM, стирается лишь полностью одним махом, а не побайтово. Так что если вы захотите использовать свободное место в ней для хранения чего-то своего, то...можете запросто затереть эти уникальные драгоценные коэффициенты! Поэтому разработчики всячески предупреждают: если хотите писать в "информационную память", сначала сделайте временные копии всех этих коэффициентов во временных переменных в ОЗУ, а после стирания страницы снова запишите их на место!
А что же с RISC-V семейством, и в частности, в наших MDR12xx? Оказывается, разработчики не только не отказались от идеи двух раздельных флешек, но пошли дальше. Теперь у нас "информационная память" ёмкостью аж два блока по 8 кБ каждый. И эта память в режиме чтения воткнута в общем адресном пространстве, почти как основная флешка. Но самое главное, теперь выполнение прошивки при подаче питания стартует не с основной, а именно с этой дополнительной памяти! Теперь уже очевидно, что упомянутый вначале "bootloader" зашивается именно в эту самую область. Что-ж, весьма гибкое решение! Вместо того, чтобы делать железно зашитый загрузчик, как это было раньше у них (да и вообще у большинства конкурентов, все эти ваши STM32, LPC и прочие), они сделали его софтово прошиваемым, хоть и находящимся в отдельной области. А учитывая то, что они выложили все исходники, можно достаточно просто сделать собственный бутлодырь, чтобы, скажем, удобнее было перешивать контроллер через RS-485, через TFTP, через облако и пр. Более того, теперь возможно перешивать и сам бутлодырь непосредственно из кода основной прошивки!
В нынешней редакции фирменный бутлодырь для MDR1215LGI и MDR1219LGI (он для этих чипов одинаковый) сидит в начале первой страницы "информационной памяти" и всего лишь выполняет какие-то самые базовые системные настройки, прежде чем сделать переход на основную прошивку. Подробнее об этом пишут сами разработчики в специальном разделе справки. И да, можно не беспокоиться за адекватность работы свежекупленного контроллера, этот бутлодырь в нём уже записан на заводе.
Свободное же место никто не мешает вам использовать для каких-то своих нужд. Только не следует забывать, что на последней странице этой памяти, как и в ARM контроллерах, по прежнему лежит некоторая "производственная информация". Включающая в себя серийный номер чипа (просто число, которое сочинили в процессе тестирования чипа, так что его не жалко) и калибровочные коэффициенты (вот они уже могут понадобится). Подробнее о том, что там хранится, рассказано в п.10.3 даташита. И если не принять специальных мер, всё это можно ненароком снести! В общем, не забываем сохранять и восстанавливать.
Забавный факт: разработчики упоминают, что в этой памяти, помимо бутлодыря и "производственной информации", может присутствовать некоторый мусор, оставшийся после тестирования на заводе. Это не баг, а фича нам разрешают стереть его и использовать освободившееся место.

[smacorp]

Ну что, пока большая часть публикуемого ejsanyo, говорит о том, что разработчики сделали многое "по красоте". Молодцы, чо.

[Zikon]

Вот здесь обсуждают работу с MDR1206FI

https://electronix.ru/forum/topic/22067 ... i-milandr/

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

[Adrift]

Оказывается, разработчики не только не отказались от идеи двух раздельных флешек, но пошли дальше. Теперь у нас "информационная память" ёмкостью аж два блока по 8 кБ каждый. И эта память в режиме чтения воткнута в общем адресном пространстве, почти как основная флешка. Но самое главное, теперь выполнение прошивки при подаче питания стартует не с основной, а именно с этой дополнительной памяти! Теперь уже очевидно, что упомянутый вначале "bootloader" зашивается именно в эту самую область. Что-ж, весьма гибкое решение! Вместо того, чтобы делать железно зашитый загрузчик, как это было раньше у них (да и вообще у большинства конкурентов, все эти ваши STM32, LPC и прочие), они сделали его софтово прошиваемым, хоть и находящимся в отдельной области.

Вы с конкурентами какого года сравниваете? ) Возьмем новые простенькие STM32C5, там минимум 20 ног в корпусах размером от 3x3 мм. Внутри полноценный Cortex-M33 с кешем и FPU, у всех МК есть USB и может быть пара FDCAN. И конечно там есть встроенный загрузчик по USB/USART/SPI/FDCAN, но помимо основного двухбанкового флеша и области ST загрузчика есть еще 64K дополнительного флеша который может конфигурироваться для выполнения программ или под EEPROM. Стартовать выполнени программы можно откуда угодно, для этого в option bytes есть BOOTADD в которую прошивается полный стартовый адрес, т.е. при желании можно всегда стартовать с этих 64К. Еще есть 4.5-Kbyte однократно прошиваемой OTP.

[ejsanyo]

Возьмем новые простенькие STM32C5, там минимум 20 ног в корпусах размером от 3x3 мм.

Какие-то совсем новые чипы? С такими пока не сталкивался. Интересно, кто у кого подсмотрел идеи?

разработчики сделали многое "по красоте".

Скорее охарактеризовал бы как "многое неоднозначно и сомнительно, но в жизни на удивление работает" (Есть ощущение, что у Миландра всегда было так, вспомнить хотя бы целых два JTAG интерфейса в К1986ВЕ92!) И сейчас мы в этом ещё раз убедимся, перейдя к рассмотрению тех функций, которые из всего имеющегося разнообразия всё же были выведены наружу из недр наших новых чипов на выводы.
Но прежде всего, процитируем разработчиков: Важно: следует использовать только те выводы, которые разведены в данном корпусе! В разделе дополнительной справки они нас предупреждают, что не разведённые на корпусе ноги трогать нельзя. Вообще никак нельзя. Даже инициализацию их не выполняйте, просто обходите стороной! Иначе будте готовы к непредвиденным обстоятельствам, вплоть до открытия портала в мир Xen включения внутреннего короткого замыкания в чипе! Что мы там говорили о "неоднозначных вещах" от Миландра?

Итак, в MDR1215LGI у нас имеется:

• PD5, на котором есть вход Rx от одного UART блока
• PD7, на котором есть выход Tx внезапно от другого UART блока!

Следующие 4 ноги, напоминаю, конфликтуют с JTAG:

• PA6, на котором висит вход или выход номер 4 (и только он) блока 32-битного таймера 1. Можно использовать для Input Capture, можно использовать для вывода ШИМ сигнала
• PA7, на который можно вытащить инвертированный выход ШИМ того же 32-битного таймера.
• PA8, на котором висит специфический вход ETR того же таймера. Позже мы рассмотрим, для чего он может быть полезен.
• PA9 и ещё более узко специализированный вход BRK того же таймера.

Какой можно сделать из этого вывод? Ну-у, более-менее полноценно и аппаратно, получается, мы можем использовать...32-битный таймер 1. Можем попробовать использовать UART, хоть и "располовиненный", что на практике это не так уж важно. Однако не будем забывать при этом, что для тактирования UART-ов в данном исполнении у нас есть только лишь встроенный RC-генератор! Либо он же, пропущенный через PLL. Т.е. имеется ввиду, что никаких кварцевых генераторов, или хотя бы входа для внешней тактовой частоты сюда не завезли. И хоть заводские калибровочные коэффициенты (которые вы постараетесь не стереть, верно?) в какой-то мере точность тактовой частоты подтянут, большими скоростями UART-а увлекаться не стоит, поскольку стабильность бодрейта мы кардинально улучить не сможем.
Ну и, конечно, никто не отнимает у нас возможность использовать эти ноги просто как GPIO.

А что же "старшенький" MDR1219LGI нам предложит:

• PA0, который может стать либо входом/выходом номер 1 32-битного таймера 1, по аналогии как у MDR1215LGI, либо ногой FSS блока SPI 2. Это, если не знаете, обычно такой выход, который подключают к Chip Select-ам ведомых SPI устройств.
• PA10 и PA11, которые становятся Rx-ом и Tx-ом на сей раз одного UART-а номер 3.

Следующие ноги конфликтуют с JTAG:

• PA6, на котором висит вход/выход номер 4 блока 32-битного таймера 1, прямо как в MDR1215LGI
• PA8 и PA9, которые также повторяют функции из MDR1215LGI

Ну и вишенка на торте, нога 8 корпуса, на которую разварили...целых 4 физических контакта чипа! А именно:

• PA3, который может стать либо инвертированным выходом ШИМ таймера 1, либо выходом данных для SPI 2.
• PA5, на который можно вытащить инвертированный выход ШИМ того же 32-битного таймера 1.
• PA7, на который также можно вытащить инвертированный выход ШИМ того же 32-битного таймера 1.
• Канал 1 входа АЦП последовательных приближений!

Да, реально заварили 4 проволочки с чипа на один и тот же вывод! А чё, так можно было, что-ли?! С технической точки зрения...почему бы и нет. При подаче питания контроллер всегда начинает режим работы своих ног с режима входов, с высоким входным сопротивлением. Так что даже если они перемкнуты между собой, то ничего не сгорит и не законфликтует. Просто берём и используем тот контакт, который нам больше подходит по реализованным функциям, а другие пусть так и висят балластом, нам особо не мешают. Главное потом внимательно следить, чтобы не включить одновременно на двух контактах режим выхода, а то будет замыкание. И да, напомню, что чудо-нога, к сожалению, тоже пересекается с JTAG.
Остаётся гадать, почему же разработчики провернули такой финт лишь на одной ноге, а а остальных - нет? Это-ж насколько можно было бы расширить функционал чипа, сохранив малое количество выводов!
Ладно, что у нас в итоге получилось? Можем пользовать таймер 1 в большем или меньшем объёме. Можем задействовать какой-никакой, но вход АЦП. Либо вместо него включить SPI блок, но только на выход (и повесить на него MAX7219, например?). Ещё есть UART, с теми же нюансами, как и в младшем чипе.
Как видно, функционал нам оставили небогатый, но и не то, чтобы совсем бесполезный. На что его хватит в практическом применении? Далее попробуем это выяснить.