Комментарии 132
Первые впечатления, что судя по маркировке, он Ленина живым видел
Если во времена Ленина выпускались РИСК-5 (ну не на иностранном же языке маркировать!) микросхемы с мегабайтом ЭСППЗУ... А вообще, это скорее последствия отмывки или неудачно выставленного света.
Может он про логотип и стандартное обозначение? Видел похожий логотип на советских микросхемах от спектрума.
РИСК-5 (ну не на иностранном же языке маркировать!)
Тогда уж МУНИ-5 (Микропроцессор с Упрощённым Набором Инструкций) :-)
Так то существует ГОСТ, который говорит, как должны называться микросхемы. И как правило, отечественные микросхемы имеют два названия: для сертификационных документов и нормальное. Например,К1986ВК025 и MDR1206FI.
Которого года сей ГОСТ? Ну и емнип, ГОСТы, которые не оказывают влияние на здоровье и жизнь людей не обязательны к применению
А где его реально делают? И делают ли?
Ядро риск5 — делают в Петербурге.
СФ-блоки — скорее всего собственные проекты компании в Воронеже.
Топологию всего чипа делают в Воронеже.
Кристаллы выпекают, наверное, в поднебесной.
Корпусировку чипа делают в Воронеже, хотя именно эта партия, может и нет.
Тестирование делают в Воронеже.
Отладочные платы делают во Владивостоке.
Рабочую документацию и системный софт делают в Воронеже и Владивостоке.
Я имею ввиду именно изготовление кристаллов.
А тот просто наши производители CPU никак не могут осилить изготовление в Китае, а внутри РФ только Амур делают - хочется понять - это реально изготавливается или как с Эльбрусами - все выпущенные партии распроданы, ждите.
Во Владивостоке производство ведётся на база какой компании?
Компания Восток. На Хабре есть статьи про их совместные с НИИЭТ продукты..Они давно сотрудничают. Это плата 2023 года, когда ВГ015 был ещё в керамике.
Нашёл только некую АО "Восток", зарегистрированную в Санкт-Петербурге.
Легко ищется по ссылкам из статей на Хабре.
Как пример, Embox отправляется на Vostok. Сам дизайн-центр Восток расположен во Владивостоке на острове Русский в ДВФУ.
Тоже интересуюсь этим впросом. Есть у кого-то информация на сей счет ?
Судя по описанию, там внутри сэндвич из двух кристаллов - сам МК и flash память. Flash понятно что китайская, а где произведен кристалл МК ?
Ну разве ж это дело, молча зависать при любом исключении!
Насколько помню, штатный код для STM32 делает так же. А нужно это, чтобы можно было увидеть, что контроллер завис, подключиться отладчиком через JTAG и увидеть, что программа циклит в обработчике исключения, и дальше уже разбираться, как так вышло. Например, прочитать регистры, в которые сохранилось значение PC, при котором было выброшено исключение (STM32 так делает; как здесь реализовано, не знаю).
Принцип максимизации ошибки это, конечно, хорошо. Плохо, когда ошибку не дают отследить из юзерского кода. Самое простое - могли сделать дефолтный обработчик исключений и объявить его weak. Соответственно, если юзер напишет свою альтернативу - использоваться будет она. И, насколько я понимаю, в stm32 используется именно такой подход. Те же ecall-ы как иначе отслеживать? Это же не ошибка, это именно системный вызов.
Демка зачёт (камень тоже) ! Может её ещё подробно опишете? Я бы почитал)
А вот тут разработчики решили обойтись необходимым минимумом. В стандарте RISC-V описана единственная точка входа в обработчик, вот и нам хватит. Никаких таблиц векторов прерываний, никаких таблиц адресов
Сейчас у RISC-V с этим вроде все ОК. Но похоже МК делался долго и процессорное ядро еще не включало последних обновлений.
А можно подробнее? Сейчас пролистал спецификацию на risc-v, не увидел ничего более интересного, чем парсинг того же mcause.
У больших ARMов почти так же. Хотя, все же есть отдельные точки входа для прерывания и для исключения. А дальше - либо лезем в контроллер прерываний смотреть что там пришло, либо в регистр ESR, разбираться что за исключение.
в RISC V есть векторные прерывания, но с PLIC (как в нашем МК) они не работают. Vectored Interrupts | Five EmbedDev
Что бы это исправить, в МК обычно используют, контроллер CLIC, подробнее про типы контроллеров прерываний можно почитать тут SiFive Interrupt Cookbook
Но с векторными прерываниями есть одна неприятность, в RISCV перед обработкой прерываний нужно сохранить все регистры процессора в стек, а если есть fpu то еще и их, а на выходе вернуть их из стека. Так вот этот код сохранения контекста продублируется в каждом векторном обработчике прерывания. вместе с fpu это 104 инструкции на каждый обработчик или 208 байт. для 16 прерываний уже имеем 3 кб кода в никуда. Об этом даже упоминается в спецификации в пункте 5 riscv-fast-interrupt/src/clic.adoc at master · riscv/riscv-fast-interrupt
спасибо за обзор! мне вот показалось странным, что уартов аж 5, а I2C всего один.
во всей своей практике не видел применения для более 3 уартов, а вот разделять слейвы по I2C шинам приходилось (когда нет возможности смены адреса).
Имею обратный опыт, уартов надо 5 и более, а шины i2c одной хватает, на нее 3-4 микросхемы можно вешать. Тут уже каждому свое
У меня ощущение, что этот контроллер делался под конкретную задачу (оттуда и 16 бит АЦП и хитрый бутлоадер)
Какой еще хитрый бутлоадер? В вг015 бутлоадера вообще нет.
Почти все отечественные СБИС делаются под конкретное применение, в частности, эта - под счётчики. Иначе не выбить денег на разработку.
Тогда уж все СБИС в мире делают под конкретные применения. Зачем делать под случайные не просчитанные задачи? Кстати, у этого ВГ015 неизвестна дола между коммерческими инвесторами, кредитами и госбюджетным заказом. Вполне возможно, что там чип — чисто коммерческая инициатива НИИЭТ. К тому же он напрямую конкурирует по назначению с миландровским риск5 чипом Счётчик, который выпускается серийно несколько лет.
Нет. Вот, к примеру, STM32 с такой же мегабайтной флешкой - там и таймеров больше десятка, причём с кучей режимов работы, и все (кроме BOOT0) ноги видны как GPIO, включая ноги резонаторов и программирования, и ремап есть почти на все ноги, и даже у F373 ремап на входы 16-битного АЦП никак не влияет на этот самый АЦП. Тут же таймеров всего 4 шт, чего достаточно какой-то АТмеге, но уже маловато для 32-битника с большой программой... Треть ног прибита гвоздями к какой-то одной функции, из которых конкретно мне сейчас вообще ничего не нужно - может кнопки повешу на WAKEUP-ноги, если не хватит GPIO, но там, возможно, будет не просто фильтровать дребезг и удержание. И вот по этим безальтернативным функциям виден заказчик - какая-то измерительная штука с защитой от вскрытия и шифрацией данных.
может кнопки повешу на WAKEUP-ноги, если не хватит GPIO, но там, возможно, будет не просто фильтровать дребезг и удержание.
Это вы здорово недооцениваете бездну геморроя с использованием WKUP как входов. Нормального чтения там нет вообще никак. Единственный способ, которым мне удалось воспользоваться - через прерывание RTC. И этот способ невероятно кривой. Хотя есть шанс, что это я чего-то недоглядел.
Про какой из итальянцев речь? SMT32 не чип, а большая линейка совершенно разных чипов под разные задачи.
У НИИЭТ линейка разнообразная в выпускаемых чипах и в проектируемых. Для примера только чипы на риск5 системе команд:
— К1921ВГ015 в серии
— К1921ВГ1Т разработка
— К1921ВГ3Т разработка
— К1921ВГ5У разработка
— К1921ВГ7У разработка
Под какое конкретное применение делали stm32?
под счётчики
Но встроенный модем/трансивер делать не стали...
Спасибо за обзор. Как там дела с сишными библиотеками, они есть вообще? Не хочется самому USB стек делать. И я не вижу реальное применение криптоядра, кроме как делать криптофлешки, ключи и т.п. Жаль, что нет MII, считаю, что добавление Ethernet стека должно быть стандартом 32х битных современных микроконтроллеров.
С usb, если верить еррате, там все плохо. Работает только одна конечная точка, и то нестабильно. Впрочем, возможно, это верно только для старых ревизий, а в новых уже все исправлено. Не знаю.
Сишные библиотеки какие-то есть, но лично по мне они неудобные (но я-то вообще не показатель).
Для криптомодулей - хз, возможно, для военных или какой-нибудь бюрократии важен сам факт их наличия. Вряд ли ведь контроллер делали с нуля специально для продажи всяким радиолюбителям.
Ethernet - не знаю, скорее все же нет. Возможность (и желание) протащить к устройству витую пару все же меньше, чем USB или даже CAN. В любом случае, не стоит требовать слишком многого сразу. Именно этот МК заточен больше под аналоговые схемы, чем под сложные вычисления или обмен.
Так Ethernet не только про вычисления и обмен. Делать промавтоматику на езернет - благодать, стек обеспечивает большую надёжность и отказоустойчивость, чем RS485, особенно при разработке нового. См. промавтоматику Овен, построенную на stm32.
Для меня применение USB более экзотическая сфера. Флешки вставлять странно, делать клавиатуры и мышки избыточно, делать криптотокен хорошо, но нишевая сфера.
В целом - смотря какая задача. Изобразить из контроллера флешку, на которой хранится снятые данные - а почему бы и нет? Или некое комбинированное устройство. Или, в порядке извращения, программатор для таких же микросхем.
В любом случае, вряд ли производительность ядра позволит отличить аппаратный эзернет от spi-ного.
езернет легко подключается по SPI. да, надо будет брать MAC+PHY, а не просто PHY, ну так и ладно, зато экономия ног - на RMII нужно 9 штук + резет, на SPI MAC+PHY надо 6 (4 SPI + int + rst). 10 мбит/с вполне потянет.
И на каком чипе вы "легко" подключите езернет по SPI? KSZ8851 будет смотреться весьма странно в импортозамещающем девайсе, учитывая, что сайт Микрочипа даже не открывается без VPN, а на чипах WCH это не легко и с кучей ограничений по сравнению с нативным MAC.
речь как раз о CH392T - лично подключал, работает нормально. у него там есть претензии на поддержку IP, но их можно смело игнорировать, переводить в raw MAC режим и вперёд, с песнями. у него немного странный протокол и местами глючный SPI, но 2.5 мбита/с он мне выдавал.
Отчественный Ethernet PHY всё равно не завезли, так что большой разницы нет что и как там будет смотреться. Но в целом, я согласен, что такие МК уже должны иметь встроенный MAC.
стек обеспечивает большую надёжность и отказоустойчивость, чем RS485
но обвязка на порядок дороже и требовательнее к вычислительным ресурсам.
Мы же должны стремиться в светлое будущее, а опираться на RS-485 в новом - путь в никуда. Дешевеет сетевое оборудование, оптика, придуманы надежные отказоустойчивые решения. На моем опыте, с RS-485 на объектах возникает намного больше проблем, нежели с Ethernet, т.к. нет нормального стека с избыточным кодированием, адресацией, контролем линии, приходится каждый раз своё городить. Здесь в чипе пять эрэсов обалдеть, кто-то же ТЗ для поддержки своего легаси писал. CAN убирать не надо.
А еще я перед сном мечтаю об ОКРе с российской PHY микросхемой с xMII интерфейсом. Миландр был близок, но что-то не задалось.
У Миландра есть контроллер со встроенным PHY. Но у них другая крайность - 128к флеш, чего даже на SSL маловато, не говоря уже о поддержке кучи протоколов.
Хорошее замечание, что для езернета память нужна. Мы используем LWIP и ModbusTCP на ВЕ3Т, вроде умещается, но стек реально половину объема занимает. Впрочем, можно подключить дополнительное ОЗУ.
Зато во время отладки, стыковки, работы в условиях сильных наводок и помех, проблем было существенно меньше, чем с RS-485. С эрэсом по-классике перепутали RX и TX, землю припаяли не туда, кто-то всю шину повалил, и всё ради баснословной скорости в 921600 бод/с.
На моем опыте, с RS-485 на объектах возникает намного больше проблем, нежели с Ethernet, т.к. нет нормального стека с избыточным кодированием, адресацией, контролем линии, приходится каждый раз своё городить.
Да, точно. Так и норовит поймать наводку, особенно если не на специальном кабеле да с заземлением хреново.
В местах, где будет применяться сабж и другие контроллеры из треда, не экономят на кабеле с заземлением.
Ethernet PHY хорошо проработанная область из-за большого рынка. Можно обеспечить шифрованное TCP соединение на кабеле с плохим, окисленных контактом. Кастомный канальный протокол на RS-485 вряд ли будет также продуман, как в Ethernet.
Более того, если имеется MII интерфейс, то можно подключить оптический SFP, который с лихвой побеждает RS485 по дальности связи, скорости и защите от помех. И при более дешёвом кабеле.
отдельный чип флешки и криптозадачи - не очень стыкуются. То ли дело в каком-то чипе для электросчетчиков: флеш на чипе, да еще и заэкранирован проводящими слоями с защитой от иголочки стирания и пр.
А что по цене?
Со скрипом взяли в работу К1948ВК018 (Амур), хотя в нем очень не хватает CAN интерфейса.
1921вг015 по-жирнее, судя по всему?
Отпуская цена в мелких партиях — около 500 ₽ плюс НДС.
Розница у перепродавцов — около 1 500 ₽.
В марте компания обещает начать официальные розничные продажи через маркетплейсы.
Чет с такой ценой - это не перемаркированный ли китаец?
Перемаркированный вряд ли, уж больно странные решения и странные косяки. Изготовление в Китае возможно. Но давайте верить в лучшее :)
Это не единственный русский чип в этой ценовой категории. Есть у Миландра на том же ядре риск5 и давно в серии, причём АЦП у Миландра, говорят, лучше получается. Скоро у других компаний ожидается выход риск5 чипов. Вариантов больше чем один.
речь не про Амур, надеюсь?
АМУР в другой ценовой категории и он пока такой один. Вторую ревизию АМУРа или даже совсем новый чип проектируют, но это не раньше следующего года в производстве. Хотя даже текущие возможности фабрики позволяют изготовить чип с гораздо лучшими характеристиками, как показал МИЭТ со своим экспериментальным риск5 чипом Хаки, выпущенным на том же Микроне.
В процессорном ядре есть всякие ID , в отладочном интерфейсе. Можно посмотреть чьё.
Отдельная опция для ростовчан — бесплатно по дружбе))
1921вг015 по-жирнее, судя по всему?
Ну да. Плюс встроенная флешка аж на мегабайт есть. И подешевле вроде как. Впрочем, что там с Амуром не знаю, может, у него есть и свои преимущества. Но лично меня вг015 впечатлил больше.
Разительно жирнее, флеша (встроенного) и ОЗУ много, куча интерфейсов. По сути это весьма современный контроллер по всем ТТХ. Если облагородить SDK, то вообще станет хорошо.
Но тут неясно сколько там своего. Та же периферия. Вот будет сейчас народ глюки находить, сможет ли производитель выпускать ревизии чипов с фиксами или нет. Если нет, то китайского в этих чипах сильно больше чем заявляют.
Китайцы быстро выпускают ревизии оем чипов по требованию заказчика. Проблема в том, что эти ревизии обычно ломают больше, чем исправляют.
С OEM производством ниразу не сталкивался, но все китайские STM заменители, которые пришли к нам, вообще ревизий не выпускают.
Читаешь reference manual, пробуешь так настроить какие нибудь регистры - что то работает, а что то нет. Потом выясняется что это глюк чипа. Проблем причем много, а китайцы говорят что ревизий делать не будут, пробуйте другие чипы из семейства, может там заработает, если вам это критично. Такое ощущение что они сами только корпусируют, а вся начинка покупная
Про покупность СФБ.
Вы смотрите на это с позиции энд юзера, ради которого никто ревизий делать не будет. Энд юзер для китайцев вообще не является заказчиком, его запросы для них - как письма в редакцию газеты Крыжопольский садовод. Если же ревизию запросит контрактор с объемами, китайцы становятся очень гибкими. Правда, обычно становится только хуже.
Работаю в компании с весьма приличными объемами потребления микросхем. Всякие ST и TI, если были проблемы, всегда шли на встречу или фиксили проблему (естественно не сразу, вполне могло и больше года пройти) или предлагали временные пути обхода или скидки. С китайцами, увы, такого и близко нет.
Разговор то был изначально о том смогут ли НИИЭТ править глюки (а они будут) или забьют. Заказчик то у них видимо уже есть и ему деваться некуда. Но как мы такими путями наразвиваем свою микроэлектронику - неясно.
Спасибо за статью. Но всё же тема Bad Apple не раскрыта. ;)
ВГ3Т тоже интересная машинка.
Протестируйте пожалуйста, как плывёт результат измерений сигма-дельта АЦП при изменении температуры: поморозить корпус freezer-ом и погреть феном. В официальной документации про точность измерений ни слова, а без этого применять этот МК для точных измерений как-то слишком авантюрно.
Если есть чем, можно при этом ещё померить опорное напряжение на выводе 25 "SDADC_CAP". В документе "РП-К1921ВГ015-v3.pdf" в разделе 22.1 очень интересно написано, что напряжение на этом выводе составляет (1,250 ±0,125) В. Это же 10% разброс! Мне интересно, это допустимый разброс от экземпляра к экземпляру, или оно может в этих пределах во время работы плавать? Если второе, то о какой точности измерений вообще можно говорить?
По стабильности ИОНов есть более интересные планы (не только вг015), но там надо здорово с установкой замороситься. Не малейшего представления найдется ли вообще на это время.
А что до SDADC, там же, наверное, можно внешний ИОН подключить на крайний случай?
А что до SDADC, там же, наверное, можно внешний ИОН подключить на крайний случай?
Как я понял, нет. Потому что SDADC_CAP - это выход встроенного ИОН для подключения конденсатора 0,1 мкФ. То есть подавать сюда напряжение с внешнего ИОН нельзя - они подерутся. Про возможность использования внешнего ИОН и куда его в таком случае подключать, в руководстве не сказано. Или я не нашёл.
Не буду настаивать. Я к местным АЦП пока что и близко не подходил. Важнее было с базовыми цифровыми интерфейсами разобраться. И даже сейчас важнее написать нормальный бутлоадер и собрать стенд для удобной прошивки. В общем, основной специфике вг015 придется подождать
А чем прошивка через openocd неудобна на стенде?
Про возможность использования внешнего ИОН и куда его в таком случае подключать, в руководстве не сказано. Или я не нашёл.
Вроде есть вход AREF.
Извините, у них погрешность внутренней тактовки 5%, о какой точности измерений в принципе может идти речь?
При чём тут это? Или речь о соответствующем временном джиттере дискретизации?
Во-первых, речь об отношении разработчика/производителя к точности в целом. Во-вторых, интегрирование в АЦП завязано на тактовку, со всеми вытекающими.
Джиттер будет если задаваемая частота нестабильна.
Сдается мне, вы путаете точность и стабильность. То есть систематическую погрешность и случайную. То, что HSI отличается на 5% от номинала, не значит, что он на 5% плавает во время работы - это всего лишь значит, что НИИЭТ не стали его калибровать. Для АЦП важна именно стабильность частоты, а не точность. И интуитивно мне кажется, что стабильность у любых встроенных RC-генераторов будет примерно одинаковая, что у stm32, что у ch32, что у вг015.
Ничего я не путаю. Результат измерения сигнала в сигма-дельта ацп зависит от ширина окна интегрирования, т.е. от тактовой частоты: https://microtechnics.ru/profilegrid_blogs/princzip-raboty-sigma-delta-aczp/?ysclid=m7dbc84bk4373676324
Условно говоря, если интегратор ацп расчитан на окно интегрирования в 1 мкс, а реальное окно 1.05 мкс, это вызовет погрешность интегрирования, которая выльется в погрешность измерения.
Существуют способы уменьшить зависимость чувствительности ацп к тактовой частоте, но очень сомневаюсь, что они реализованы в недорогом мк.
Недорогие ширпотребные АЦП, вроде встраиваемых в МК, строятся на принципе поразрядного уравновешивания зарядов (последовательных приближений). Поэтому там нет особых требований к стабильности частоты во время квантования сигнала.
Интегрирование - более характерно для измерительных приборов. И там оно делается двухстадийным, для снижения требований к тактовому сигналу.
В этом контроллере заявлен сигма-дельта ацп
Для него важно только насколько уплывет частота генератора за время одного преобразования. Абсолютная величина частоты никакого значения не имеет.
Абсолютная величина частоты никакого значения не имеет.
Ну как это не имеет, если значение на выходе интегратора линейно от времени, а дальше идет сравнение выхода с опорным напряжением?
Оно N тактов линейно увеличивается, потом M тактов линейно уменьшается. И значение имеет только отношение N к M, а не их абсолютные величины. Только в примитивных АЦП однократного интегрирования измерялось абсолютное время. Но они практически нигде не применяются. Именно поэтому.
Вы сейчас описали схему работы ацп многотактного интегрирования, у них да, опорная частота не дает погрешности. А в статье сами написали, что в мк стоит сигма-дельта ацп, он не так работает. Какого порядка там модуляция, кстати, есть инфа?
Вы же сами кидали ссылку на описание сигма-дельты. Там именно это и написано. А относительно вг015 вам открыть документацию ничуть не сложнее, чем мне. Но лично я там подробностей не нашел. Разве что то, что в источник опорного напряжения "выполнен с использованием напряжения запрещенной зоны полупроводника".
Не-не-не. Вот АЦП многотактного интегрирования:
http://www.gaw.ru/html.cgi/txt/doc/adc/adc_5_1.htm
Обратите внимание на ремарку - именно для этого типа АЦП результат не зависит от точности тактовки.
А вот сигма-дельта АЦП:
http://www.gaw.ru/html.cgi/txt/doc/adc/adc_5_2.htm
У него лучше SNR и ниже нелинейность, но он чувствителен к точности тактовки.
А то, что источник опорного напряжения выполнен как бэндгап, оно и так очевидно, других вариантов особо и нет для МК.
Попробуем еще раз. Сигма-дельта АЦП отличается тем, что подстраивает сигнал порционно, то плюс опорой, то минус. И считает их соотношение.
В тактовые периоды 2 и 7 состояния системы идентичны, так как при неизменном входном сигнале Uвх=0,6 В цикл работы занимает пять тактовых периодов. Усреднение выходного сигнала ЦАП за цикл действительно дает величину напряжения 0,6 В: (1-1+1+1+1)/5=0,6.
Видите: складываются дискретные отсчеты и делятся на количество. Абсолютное значение времени там никакой роли не играет.
Упустил.
В таком случае, ЕМНИП, опять же важна не абсолютная точность генератора, а кратковременная стабильность и джиттер частоты (за время одного преобразования и между последовательными битами в модуляторе) в зависимости от напряжения питания, температуры и пр. возмущающих факторов. Что достигается существенно проще, чем высокая абсолютная точность.
Увидел фото печатной платы - и начал читать статью. Чтобы убедится, что это сделано сейчас, а не во времена моей далёкой молодости. Убедился, удивился.
Что, недостаточно апокалиптично? Вот такая, наверное, покрасивее будет: https://habrastorage.org/r/w1560/webt/tq/q2/2b/tqq22bjmf-yx77utxwt-v0ia8u4.jpeg
Неужели резцом?:)
Когда то помню старшие товарищи затачивали полотно от ножовки крючком под определённым углом. Самому повторить так не удавалось, что бы резало также хорошо.
Сурово как. Посадочное место под МК тоже руками вырезали? Респект!
А как же. Ради интереса решил попробовать сделать плату максимально подручными средствами, даже без принтера. Даже записал процесс этого мракобесия: https://www.youtube.com/watch?v=tPAHEwi4Fzg&list=PLc7FYD_FgfqcgaWyrxhSr8cy2q23xCY3Q&index=14
Нвидиа вздрогнула:)) я одину плату с мин обвязкой взял, и чувствую что надо более глобальное сделать. Нормальный проект.
Отсутствие таблицы прерываний. Отсутствие бутлоадера.
Меньше аппаратуры - меньше errata. Не забывайте что с этим контроллером россияне будут жить лет 30-50
(Вообще, мне лично кажется странным когда производители пытаются напихать аппаратную поддержку в те места, которые "без штрафа" реализуемы программно)
Поддерживается прошивка обычными JTAG-программаторами (это-то достоинство), но все же нужен пропатченный openocd.
Такой "патч" нужен любым микросхемам, поддерживаемым openocd: это патч к конфигу, которым краёвая конфигурация задаётся. Со временем он попадёт в ~master
Целых семь ног отвели под какую-то ерунду — AT_IN, WKUP, плюс еще две под USB. Сами-то функции, может, и могут где пригодиться, но их стоило совместить с GPIO.
Видимо, корпус выбран по каким-то другим соображениям и недостатка в ногах не было
Под контроллеры же обычно позиционно-независимый код не пишут, и все наши обращения к переменным из Си будут развернуты в тот же la, что сводит смысл от страдания со стартапом на нет.
Есть как минимум два сценария, когда нужен абсолютный адрес, а не относительный:
флеш может располагаться по адресу 0x0800_0000, но выполнение кода происходить по адресу 0. Можно конечно с помощью ld-скрипта разместить код тоже по адресу 0, но тогда прошивка чипа может перестать работать
в чипе могут быть регионы кэшируемой и не кэшируемой памяти, и выполнение может начинаться с не кэшируемой памяти, а потом переходить в кэшируемую в стартапе. До тех пор, пока адрес выполняемой инструкции не будет 100% известен, пользоваться la опасно.
Помимо всего этого когда вы запускаете прошивку под дебаггером, он может начать её выполнять с "правильного" адреса, а потом после ресета микроконтроллер начнёт выполнять её с того, который ему кажется правильным. В общем, загрузка абсолютного адреса позволяет минимизировать проблемы, связанные с особенностями конкретного МК, потому что она работает всегда одинаково.
Во всех этих случаях заботиться о позиционно-независимом коде приходится самому программисту. А речь-то шла о том, что компилятор gcc по умолчанию будет генерировать обычный, позиционно-зависимый код.
И, на самом деле, это проблема: я-то надеялся написать бутлоадер, который бы располагался в начале флеша, а юзерский код записывал где-нибудь дальше. И если бы прошивка получалась позиционно-независимой, проблемы бы не было: ну стартует он не с 0x8000'0000, а с 0x8001`0000 - не страшно, переходы-то относительные. Но вот обращение к ОЗУ из-за la поломается. Поэтому придется либо вкручивать флаги компилятору (пока не знаю с какими побочными эффектами), либо править ld-скрипт. А раз так, то и возня с позиционно-независимым загрузчиком не особо полезна.
А самое обидное, что я так и не нашел способа передать в li адрес метки, компилятор ругается и требует la.
Я пока тут не вижу никакого позиционно-независимого кода, вижу только обычный позиционно-зависимый. Тот факт, что код может выполняться из других адресов -- проблема исключительно стартап-кода, он должен сделать так, чтобы остальной код ничего не заметил.
Проблема с li, насколько я понимаю, в том, что компилятор не может её сразу скомпилировать если он не знает адрес метки. А адрес метки неизвестен до линковки. В зависимости от значения адреса нужно сгенерировать или одну инструкцию, или две, поэтому на этапе компиляции просто выдаётся ошибка. Если всё же очень хочется, приходится выписывать вручную li как две инструкции (lui+addi), тогда всё будет ок, но addi в итоге может оказаться лишней.
Еще раз. Любое обращение к памяти из юзерского кода на Си. Оно разворачивается в auipc, а не в lui. Если не предпринимать дополнительных мер. И с этой проблемой стартап-код никак не поможет, будь он хоть трижды позиционно-независимым.
Вероятно у нас какие-то очень разные компиляторы или параметры компиляции, потому что у меня разворачивается в lui:
int C = 5;
int foo(int a, int b) {
return a + b + C;
}
0000000000010244 <foo>:
10244: 67c5 lui a5,0x11
10246: 2507a783 lw a5,592(a5) # 11250 <C>
1024a: 9d2d addw a0,a0,a1
1024c: 9d3d addw a0,a0,a5
1024e: 8082 ret
Но даже безотносительно этого, если у вас доступ к памяти через auipc, стартап-код как раз может обеспечить корректность выполняемого кода, передав на него управление по правильному адресу. По тому, который ожидает линкер во время линковки.
int C = 5;
int foo(int a, int b) {
return a + b + C;
202: 952e add a0,a0,a1
204: 20000797 auipc a5,0x20000
208: dfc7a783 lw a5,-516(a5) # 20000000 <C>
}
20c: 953e add a0,a0,a5
20e: 8082 ret
Похоже, дело во флаге -mcmodel. У меня стоял medany, а у вас, вероятно, medlow. По крайней мере, я сейчас его поменял и ваше lui получилось. Так вот зачем этот флаг нужен. Спасибо что пнули в нужном направлении.
Что забавно, в документации позиционно-независимым назван как раз medany:
The code generated by the medium-any code model is position-independent, but is not guaranteed to function correctly when linked into position-independent executables or libraries.
если у вас доступ к памяти через auipc, стартап-код как раз может обеспечить корректность выполняемого кода, передав на него управление по правильному адресу.
Если в ld-скрипте адрес начала прошивки указан 0x8000'0000, в реальности ее располагают в 0x8001'0000, а для доступа к оперативке используется auipc, стартап никак не может на это повлиять.
Другое дело, что если mcmodel действительно позволяет отвязать адреса оперативки от адресов флеша и генерировать позиционно-независимый код (надо будет еще проверить ссылки на функции, таблицы переходов и т.п.), то со стартапом заморачиваться уже стоит.
По поводу пинов WAKEUP и AT_IN и AT_OUT по моему мнению они отдельно по 2м причинам:
1. Эти пины специализированы под применение МК в счетчиках для определения факта вскрытия корпуса, т. к. функция критически важная этим решением уменьшили вероятность ошибок в дизайне и в софте.
2. Эти пины находятся в батарейном домене питания, и должны работать с минимальным потреблением при отключённом "ядре". Если эти пины добавить в мультиплексор с GPIO, то пришлось бы и мультиплексоры перемещать в батарейный домен и непонятно как бороться с утечками на отключенную периферию через эти мультиплексоры.
Первые впечатления от 1921вг015, отечественного RISC-V контроллера