Как стать автором
Обновить

Комментарии 30

Ядро практически одинаковое

Ну нифига ж себе "практически одинаковое"! Вы в курсе, что значит RV32E? Половины регистров нет, ABI идёт по известному месту, вещь в себе. Да и отсутствие умножений и делений это тоже вполне себе минус.

Не пытаюсь выступать защитником Микрона, но всё же надо быть более дотошным, что ли. НИКАКИХ преимуществ у "CH" тут нет.

Хм, я не знал такой тонкости, мне казалось, что Е означает "расширенный" в противовес I, которая явно обозначена, как "базовый набор инструкций". Сходил на сайт RISCV, почитал, оказывается набор инструкций точно такой же, а регистров только 16 вместо 32, спасибо за поправку. Оценка по данной строке таблицы меняется на +2.

Наверное, ABI не совсем идет по указанному адресу, а смещается ?

ABI не совсем идет по указанному адресу, а смещается ?

Не знаю. Везде пишут про ABI на случай 32 регистров, на случай 16 я не видел (или пропустил)

Ну у gcc есть два флаг для E версии - march=rv32e и -мabi=rv32e.

По поводу CHv003:

документация у китайцев довольно своеобразная, но там и на v003, и на v203/303 она написана в духе "если чего непонятно, читай доки от аналога стм". Обычно принцип работает, раскладка регистров и битов примерно совпадает, часть имен тоже. Документацию на "Амур" не читал.

у WCH патченный gcc и gdb. Патчи связаны с вендорной обработкой прелюдии для прерываний с атрибутом "WHC-interrupt-fast". Документировано это похабно, но статьи на хабре были. Что в "Микроне" накрутили - без понятия.

А что, вполне себе рабочий метод, то есть если периферия снята с STM8 в режиме "1 к 1"?

С стм32. У gd32 сходный подход к документации, про Artery не скажу. Вообще похоже, что все китайцы так на документации экономят

Ну они вроде совместимость по корпусу и ножкам с STM8 декларировали.

Что в "Микроне" накрутили - без понятия.

В этом и фишка RISC-V -- можно взять и накрутить, добавив например аппаратное сохранение регистров при входе в прерывание, а можно сделать по дефолту (по базовому мануалу), тогда конечно удобностей будет не очень, но жить всё ещё можно. А вот в каком-нибудь cortex-M3 без вариантов -- за вас прибили гвоздями контроллер прерываний и аппаратный пуш регистров и живите только с этим.

зато какой геморрой получается с тулчейном. он как бы опенсорсный, но собрать его и подключить к неродной IDE становится приключением. Ну и у того же WCH версия ИДЕ по линукс заметно отстает от виндовой.

Да ладно, никакого геморроя с gcc и бинутилями нет. К обработчикам прерываний они никак не относятся. Конечно приятно, когда в cortex-m3 вместо пролога и эпилога единственного обработчика на асме (как для ARM7TDMI) можно писать хендлеры сразу на сях с сигнатурой void fname(void) и потом удобненько расставлять векторы в линкер-скрипте, но всё же тулчейн для этого менять не обязательно -- не он определяет, что именно и как вы компилируете в проект и какие у вас там обработчики.

подключить к неродной IDE становится приключением

Ну так любители свистопердящих IDE и должны страдать :)

Ну ок, посмотреть пролог-эпилог обработчиков и накатать такое же на ассемблере, чтоб не зависеть от китаепатченных бинарей.

А можно не надо? Когда я хочу писать на ассемблере, я пишу на ассемблере, но обычно не хочу

Микроконтроллеры MIK32 АМУР с отладочной платой от непосредственно АО "Микрон" уже попадают в цепкие руки разработчиков.

Является ли МК АМУР отечественным изделием — несомненно, иначе трудно
объяснить отсутствие в МК образца 2020+ года векторных прерываний. Пнп: в документации на 1 описание механизма прерываний отсутствует чуть менее, чем полностью, так что опираюсь на найденную в Интернете (не на сайте Микрона) программу обработки прерываний. Что характерно, с
точки зрения программистов Микрона (я сделал такой вывод, посмотрев
представленную ими набор функций для работы с прерываниями) работа с
прерываниями заключается единственно в установке и сбросу битов
разрешения конкретных прерываний.

Настоятельно рекомендую автору прочесть спецификацию RISC-V, она очень короткая. Более половины его текста это тезисы и домыслы основанные на полном непонимание архитектуры. Такое ощущение, что у автора в голове RISC-V и ARM это две почти одинаковые архитектуры, что категорически не так. Единственный весомый аргумент в статье это цена MIK32. Да, цена китайского шлака в десятки раз дешевле, ну и что ? А если китайцы завтра подчинятся американскому давлению и оставят автора даже без таких устройств, что он будет делать ? Профессию менять ?

Вообще странно всё это. Многие с пеной у рта вопрошали "где наше, отечетсвенное, а не сделанное на TSMC". Так вот оно, настоящее, сделанное в Зеленограде. Но теперь мы и этим не довольны - цена панимаишь не та. Интересно, если Микрон начнет раздавать эти микрсохемы по 1 руб за ведро, какой будет следующий уровень недовольства ?

Я отчетливо помню как в разгар ковидабесия и "дефицита полупроводников" все смело покупали STM32 по цене в десятки тысяч за штуку и не пыхтели, потому как надо было выполнять договорные обязательства. А иначе штрафные санкции и попадание в "Реестр недобросовестных поставщиков". Я сам тогда приобрел партию STM32F429 для выполнения проплаченной ранее серии изделий по цене 18 000 за штуку и был рад, что вообще что-то удалось выхватить.

PS: Как можно сравнивать МК в корпусе SOIC8 с аналогичным в корпусе QFN48 ?

1.Если какая либо части технического описания МК требуют для своего описания привлечения сторонних ресурсов, то в тексте это должно быть явным образом указано и в конце документа должен быть представлен перечень используемой литературы. Это по поводу призыва читать описание на RISC-V, какого бы размера оно не было.

2.Да, по моему мнению, две архитектуры весьма близки, и процедура обработки прерываний весьма похожа. А то, что ядро ARM само прячет рабочие регистры на стек, а в RISC-V это делается обработчиком - не принципиальное отличие, на мой взгляд.

3.И отсутствие векторов прерываний я ничем иным, кроме как отечественностью разработки, объяснить не могу. Если я неправ и на самом деле в МК АМУР наличествуют векторные прерывания и нет необходимости полингом определять источник, то укажите соответствующее место документации, поскольку я в ней нашел только фразу

  1. встроенный интегрированный программируемый контроллер прерываний отключен;

4.Отнюдь не только цена, хотя это, наверное, главные недостаток. И питание и потребление и размер память программ не являются сильными сторонами АМУР - но это совсем не означает, что его нельзя применять - надо просто понимать недостатки и нивелировать их. Идеальный вариант - устранять недостатки, но, похоже, с Вашей точки зрения, это необязательно, если оно "настоящее".

5. Что касается китайского "шлака", то в чем именно заключается "шлаковость" конкретно CH32V003? Параметры, как я показал в статье, весьма близки, значит и АМУР тогда тоже "шлак"? Хотя конечно же нет, ведь он "настоящий". Отметьте, что я подобного вывода не делал.

6.Я никогда "с пеной у рта" не спрашивал, хотя прекрасно понимал шаткость конструкции, основанной на зарубежных фабриках. И замечательно, что появляются отечественные ("по настоящему") МК. Но, как говорил незабвенный МихМих, "Общим видом овладели, теперь про подробности надо не забывать", так что испытывать гордость я бы пока поостерегся.

7.Если Вы не смогли оперативно перейти на изделия Giga Device и приобретали оригинал по конских ценам (и при этом радовались, что характерно), у меня для Вас не очень хорошие новости. Хотя, возможно, именно этот тип МК наши китайские друзья не заместили, вполне допускаю, но повода для радости не нахожу. Пнп: при этом я предполагаю, что в Вашем изделии функциональность конкретного МК была именно необходима, и он при разработке не выбирался по принципу "Давайте поставим кристалл пожирнее, он стоит всего лишь 15 баксов, зато сколько памяти, нам будет проще".

PS. Ну, вообще то, китайцы пакуют свой МК в разные корпуса, в том числе 20-ноговые и это явно указано в таблице. А почему нельзя сравнивать МК в разных корпусах, я так и не понял, просветите.

Постараюсь ответить коротко. RISC-V и ARM это две совершенно разные архитектуры. ARM это проприетарный CISC (буква "R" в его названии это рудимент), в то время как RISC-V это классический RISC с полностью открытой архитектурой. Подходы к обработчика прерываний у них совершенно разные. RISC-V в какой-то мере позаимствовал многое от MIPS, в том числе и способ обработки прерываний и Ваша фраза "иначе трудно
объяснить отсутствие в МК образца 2020+ года векторных прерываний" показывет что Вы совершенно не рубите в теме. EPIC в MIK32v0 был заблокирован (читай отключен) по причине того, что в нём закрался баг. Его исправят в следующих версиях, если уже не исправили в MIK32v2. Во всяком случае в репозитории я вижу примеры работы с прерываниями, сомниваюсь что их туда выложили для мебели (у меня есть девборд с MIK32v2 - проверю).

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

Например, в GD32 вполне себе живет векторный режим, наряду с не-векторным, причем оба вполне себе описаны в документации.
В рассматриваемом CH32V003 есть указания на VTF - не совсем вектора, но очень похоже.

Может, вместо того, чтобы раздувать щеки, можно просто признаться, что настоящая векторность в 2К слов памяти программ - слишком роскошное удовольствие?

Может быть, я и не рублю в теме, но мне совершенно непонятно, каким
именно образом отличие системы команд и открытая архитектура мешает
реализовать векторный обработчик прерываний

В спецификации RISC-V нет вектороного обработчика прерываний. Есть вариант векторного обработчика исключений, но это не одно и тоже. В спецификации есть всего два аппаратных прерывания - от встроенного в ядро таймера и от внешнего устройства. Вот на эту линию "прерывание от внешнего устройства" и подвешивается PLIC или EPIC. Как я уже упоминал, такой подход характерен для всех RISC процессоров - в ядро не суют то, чего там быть не должно.

Векторный обработчик прерываний для RISC процессоров легко реализуется программно, просто в случае с MIK32 никто не заморочился написанием соответствующего crt0, так как это лишний оверхед. Тех, кого лишний оверхед не беспокоит, могут сделать это самостоятельно в своём коде.

Векторные прерывания никак не связаны с объемом памяти программ. Более того, использование векторных прерываний эту память экономит, поскольку избавляет от необходимости анализировать, какое устройство выставило запрос, в обработчике. Если имеется в виду расход памяти под хранение таблицы векторов, то это уже вопрос реализации. Вектора могут храниться в регистрах контроллера прерываний или вообще быть фиксированными, как было в i51.

В каком месте "ARM это CISC"? Команд много? Так у AVR их тоже немало. Или RISC, - это только MSP430F1xx с его 27 командами?

Дело не в количестве команд (хотя и в нём тоже), а в их сложности и избыточности. В ARM ISA (во всех версиях) полно команд которые выполняют две и даже три операции за раз, есть команды которые частично или полностью дублирую функции. RISC предполагает минималистичный набор ортогональных команд. ARM уже 20 лет как перестал был чистым RISC и превратился в "x86 для мобильников".

Если подходить так, то ARM с самого начала не был "чистым RISC".

Был, некоторое время. На счет того, что такое RISC рекомендую почитать первоисточник.

Я немного полистал доку по MIK32. С контроллером прерываний все прозаично.

В RISC-V ядрах спецификацией предусматривается наличие встроенного контроллера презываний (PLIC), в MIK32 использовано Синтакоровское ядро SCR1 в котором по-дефолту имеется PLIC. В MIK32 этот контроллер отключен и заменен другим более гибким контроллером EPIC (внешним по отношению к ядру). В общем, еще раз рекомендую Вам погрузиться в спецификауию RISC-V хотя бы поверхностно, чтобы не порочь Чушь. ;)

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

Мне казалось, что тяжелая математика все таки не для МК (микроконтроллеров), а для МК (микрокомпьютеров), хотя, заказчик всегда прав.

наймите специалистов для подготовки нормальной КД, можете даже ко мне обратится.

Иронично...

Появились сборки SOM (System on module) с микроконтроллером MIK32 АМУР

https://elron.tech/elsom/

Параметры и состав сборки:

  • Микроконтроллер MIK32 АМУР

  • Память NOR FLASH 8 Мб (может быть изменена)

  • EEPROM содержит загрузчик по UART

  • Кварцевый генератор часовой 32 кГц

  • Кварцевый генератор высокочастотный 32 МГц

  • Отлаженные обвязки по питанию, обвязки кварцев, цепь сброса, подтягивающие резисторы

  • Размер: 25,4*25,4 мм, толщина текстолита 0,71 мм

  • Производство: Россия, Новосибирск

  • SOM не содержит опознавательных идентифицирующих знаков (позволяет использовать данные сборки в качестве OEM узлов в устройстве)

ELSOM BASE
ELSOM BASE

Ну что же, вполне ожидаемое изделие, если к нему сделают нормальный софт, то вполне может получиться и Ардуино совместимость.

Ядра ARM, включая Cortex-M0 и M1, и архитектура ARM (ISA) не могут "применяться свободно". Даже если производитель МК не использует покупные IP-блоки, а разрабатывает все "с нуля", он должен приобрести лицензию и платить лицензионные отчисления. Различные "серые схемы", - это другой вопрос.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории