Если у вас почти полностью цифровой дизайн, то при наличии полного RTL - переход на другую фабрику относительно тривиальный процесс. Ну т.е. поменяли обёртки вокруг Flash, блоков памяти, падов, меняете в настройках тулов RTL2GDS пути к стандартным цифровым библиотекам и погнали. Таким образом можно получить относительно быстро полностью совместимый со старым дизайн на уровне софта и пинов, но на другой фабрике. Вот перенос аналоговых блоков/дизайнов - это уже более сложное приключение. Если кратко, то если у вас есть исходники дизайна, то перенос на другую фабрику принципиально возможен за какое-то обозримое время. Естественно, с некоторыми ощутимыми трудозатратами. Но вот если у вас этого нет - то воспроизвести дизайн "один в один" с функциональной точки зрения имея только даташит - практически невыполнимая задача.
Кадры и компетенции. Большинство топовых разработчиков микроэлектроники в мире - это fabless. AMD печёт свои чипы на TSMC, даже Intel начал печь свои чипы на TSMC. Если у нас будут просто делать перемаркировку зарубежных чипов - то откуда взяться инженерам способным что-то разработать.
Блок Flash - это очень закрытая история. Даже не у всех фабрик доступен компилятор Flash, у некоторых доступны только фиксированные конфигурации в виде HardMacro. Простым смертным (то бишь разработчиком конечных чипов) даже не дают доступ к слоям, которые необходимы для разработки блока Flash. Т.е. нет возможности самим нарисовать топологию структуры с плавающим затвором. У российских фабрик с Non Volatile Memory всё плохо, а с Flash вообще полный швах - ни у кого нет. Поэтому выпустить современный микроконтроллер на условном Микроне нельзя. У них доступен только маленький EEPROM. А вот контроллер, обёрнутый вокруг этой Flash - это каждый уже делает сам как может.
Периферия, как правило, 50/50. Контроллеры вокруг аналоговых блоков почти всегда свои. Высокоскоростные интерфейсы типа PCIe, DDR и т.п., ммм..., я бы сказал с большой долей вероятности покупные. Тут проблема, в том что они стыкуются с достаточно сложными блоками PHY. Мелкая периферия (UART, SPI, CAN), так как её относительно просто разработать самостоятельно - может быть как своя, так и покупная. Даже такая простая, на первый взгляд, периферия требует трудозатрат на верификацию.
Interconnect/Crossbar, как правило либо самописные, либо генерируются специальными доморощенными тулами.
Вряд ли в таком корпусе его кто-то будет применять в счётчиках. У Миландра находится внешний сигма-дельта АЦП в пластике: https://www.milandr.com/ic/42635/
Это я всё видел. Мне интересно что там в реальности.
Ну вот смотрите, таблица 2.4. Пункт 19 (почему-то без номера): SAR ADC INL+-3 LSB Пункт 20: SAR ADC DNL: +-2 LSB
При таком DNL там должны быть выпадающие коды, это достаточно посредственные параметры. При том эти параметры получены на номинальном питании 3.3В и при низкой частоте преобразования (fs = 250 kHz). Но правда это в диапазоне температур от -40 до +85 градусов Цельсия.
Смотрим дальше. Пункт 21 (опять без номера). SINAD (Signal-to-noise and distortion ratio) 60 dB. Из этого параметра можно легко высчитать эффективную разрядность (ENOB, Effective Number of Bits). ENOB = (SINAD - 1.76) / 6.02 = (60 - 1.76) / 6.02 = 9.67 bit Это, на самом деле, не плохо. Но в таблице указано что частота преобразования fs = 1 MHz, но при этом не указана частота входного сигнала на которой это было получено.
Offset Error, Gain Error я там не вижу, механизма для калибровки оффсета тоже не вижу (может просто проморгал).
Ладно, для SAR мы что-то нашли. Ткните меня, пожалуйста, в параметры сигма-дельта АЦП. Что-то я их не вижу.
То что пишут большие допустимые ошибки INL, DNL - это понятно. Это делают для того чтобы увеличить выгод годных.
Но вот для счётчика электроэнергии нужны хорошие метрологические свойства, которые обеспечиваются в первую очередь АЦП.
В итоге: для SAR АЦП указано три параметра, да и те посредственные, для сигма-дельта параметров нет вообще.
Вот поэтому мне очень хотелось бы посмотреть что там в реальности, есть подозрения что контроллер от НИИЭТ не позволит обеспечить нужный класс точности.
Там по ряду решений и по списку ошибок сразу чувствуется что чип разрабатывался в России. Вот характеристики встроенного АЦП посмотреть интересно было бы, это да.
Покопавшись в коде я обнаружил ошибку в программе SNANDer при инициализации программатора в режиме работы с микросхемами серии 24Сxxx. Потом я нашел еще одну ошибку с порядком следования байт при записи и чтении микросхем MicroWire - 93xxx в 16-битном режиме. Так я понял, что придется писать программу самому.
Плюс вам за то, что отправили Pull Request-ы с обновлением базы данных чипов в SNANDer, но вот обоснование необходимости писать свою программу какое-то слабенькое. То есть в существующем решении проблема была найдена и локализована, было понятно как её поправить. Признайтесь честно, реальная причина "потому что могу", тут никто не осудит %)
Вспоминается книга Д. Канемана "Шум. Несовершенство человеческих суждений". Там как раз рассказывается про то, что настроение судьи из-за погоды или близости времени обеда может влиять на выносимое им суждение.
Я такой же. Следил за игрой и оформил предзаказ Oil Rush именно потому, что они пообещали поддержку Linux. По тем же причинам покупал игрушки в составе Humble Bundle (4 или 5 выпусков). Но должен признаться честно, почти ни во что из купленного я толком не играл. Максимум запускал "на посмотреть" на пару часов %)
Знаете, у меня в такие моменты в голове возникает примерно такая картинка: сидит чиновник в своём кабинете, бьёт себе по лбу лютый facepalm и восклицает: "Ах, так вот зачем была нужна эта куча разнообразных НИИ в СССР, которые мы так старательно банкротили и превращали в ТЦ и бизнес-центры!"
А кто что может вспомнить про OpenRISC?
Ну кроме того что когда-то Cadence на его основе проводил пару тренингов.
Так-то оно вроде пока живое, относительно недавно даже его поддержку в upstream GCC продвинули.
Я в него палочкой потыкал, с помощью FuseSOC собрал битстрим для платы DE0-Nano, запустил mainline Linux 5.1.2 + BusyBox и на этом пока успокоился.
У меня дома лежит пачка старых роутеров и ADSL модемов.
Что-то отличное от Linux встречается очень редко.
Могу вспомнить разве что VxWorks и ZyNOS. Всё-таки ядро Linux — это весьма хороший framework для написания драйверов, плюс там очень много поддерживаемых «плюшек» (сетевых протоколов, алгоритмов шифрования и прочего). А тут важен параметр Time To Market, поэтому в большинстве случаев берут именно его, ибо цена доработки под свою железку минимальна.
А с WinCE и Platform Builder мне пришлось немного пострадать, не могу сказать что мне понравилось.
Я пользуюсь ОС на базе ядра Linux примерно с 2004 года.
С поддержкой железа за это время стало значительно лучше. Я помню как искал в киосках с дисками драйвера для Linux для моей NVidia GeForce2 MX400. И даже нашёл.
Когда я всё это заставил работать с Mandrake 10 — счастью не было предела.
Сейчас же всё гораздо проще, поддержка железа в разы шире. Но ноутбуки я до сих пор выбираю предварительно изучая списки совместимости. Как правило, найти нужную по характеристикам совместимую железку можно без проблем, но выбирать «не глядя» я бы не рискнул.
Я немного в другой области работаю, но могу сказать одно: лучше просто не знать что наворочено внутри любого коммерческого закрытого продукта, а иначе про спокойный сон можно забыть.
Ключевое преимущество ядра Linux в данном случае (как и любого другого открытого/свободного продукта) — это возможность найти причину неполадки и исправить её самостоятельно. Да, для этого нужен определенный уровень, да, мало кто этим станет заниматься. Но сама возможность — это уже много.
Приведу пример «сбоку». Мне приходится работать с дорогущими проприетарными САПР и, как по мне, там просто адский ад. Куча глупейших багов и проблем, тикеты на которые висят годами.
Однажды мне пришлось перехватывать вызов unlink с помощью подключения самописной so-шки через LD_PRELOAD, чтобы посмотреть содержимое временных файлов с нетлистами из-за которых падала симуляция. Посмотрев в то, что генерит эта софтина, я ужаснулся содержимому, нашёл причину проблемы, сделал не менее жуткий костыль и в итоге всё завелось. Но мой тикет пофикисили только через пол года, и то не полностью.
Так что альтернатив Linux я пока просто не вижу. Если там что-то не работает, то хотя бы можно докопаться до истины.
Лично я ничего страшного в этом не вижу, так как User Agent всё равно содержит информацию об ОС.
У меня, например, это выглядит так:
Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
Если верить этой статистике: http://www.w3schools.com/browsers/browsers_os.asp, то пользователей Linux больше 5%, правда на хабре и ГТ есть километровые обсуждения корректности этих данных и репрезентативности выборки, но это уже совсем другая история.
По поводу стабильности тактовой частоты… Поделюсь собственным опытом.
Приобрел я на всем известной китайской торговой площадке 5 модулей ESP-07.
Распаял первый модуль на монтажке согласно общим рекомендациям.
Питание заводится с отдельного стабилизатора на 3.3 В. По питанию стоит 100 мкФ электролитический конденсатор и непосредственно у ног питания модуля — керамический.
CH_PD через 4.7 кОм подтянут к питанию, GPIO15 посажен на землю.
Включаю, цепляюсь через PL2303, а оно мне в терминал мусор сыпет. То есть эхо-ответ работает. В теории, код того символа что я набираю на клавиатуре приходит на порт RXD ESP8266, и ровно такой же код я должен получить на порту TXD ровно до момента завершения команды (на AT-прошивке CR+LF). Я потыкался осциллографом в RXD и TXD и понял что импульсы у кода в эхе слегка короче плюс короткие паразитные выбросы. Как итог — я вижу мусор. Потом была куча потуг понять почему уплывает частота. Пытался отмывать модуль и плату от канифоли и занимался прочей ересью.
Кто-то ещё с таким сталкивался? Можно ли с этим как-то бороться?
В итоге всё заработало нормально со вторым модулем.
С вашего позволения, совершу каст разработчика.
CC:@Strijar
В данных рассуждениях есть несколько упущений.
Если у вас почти полностью цифровой дизайн, то при наличии полного RTL - переход на другую фабрику относительно тривиальный процесс.
Ну т.е. поменяли обёртки вокруг Flash, блоков памяти, падов, меняете в настройках тулов RTL2GDS пути к стандартным цифровым библиотекам и погнали.
Таким образом можно получить относительно быстро полностью совместимый со старым дизайн на уровне софта и пинов, но на другой фабрике.
Вот перенос аналоговых блоков/дизайнов - это уже более сложное приключение.
Если кратко, то если у вас есть исходники дизайна, то перенос на другую фабрику принципиально возможен за какое-то обозримое время. Естественно, с некоторыми ощутимыми трудозатратами.
Но вот если у вас этого нет - то воспроизвести дизайн "один в один" с функциональной точки зрения имея только даташит - практически невыполнимая задача.
Кадры и компетенции. Большинство топовых разработчиков микроэлектроники в мире - это fabless. AMD печёт свои чипы на TSMC, даже Intel начал печь свои чипы на TSMC.
Если у нас будут просто делать перемаркировку зарубежных чипов - то откуда взяться инженерам способным что-то разработать.
Как уже писали в комментариях к прошлой статье, что у НИИЭТ, что у Миландр ядро лицензировано у питерксой компании https://cloudbear.ru/
У НИИЭТ BM-310S6 (https://niiet.ru/wp-content/uploads/2025/02/РП-К1921ВГ015_250219.pdf ,раздел 3)
У Миландр тоже BM-310 https://www.milandr.com/ic/42635/
Так что ядро у обоих производителей самое что ни на есть отечественное.
Блок Flash - это очень закрытая история. Даже не у всех фабрик доступен компилятор Flash, у некоторых доступны только фиксированные конфигурации в виде HardMacro.
Простым смертным (то бишь разработчиком конечных чипов) даже не дают доступ к слоям, которые необходимы для разработки блока Flash. Т.е. нет возможности самим нарисовать топологию структуры с плавающим затвором.
У российских фабрик с Non Volatile Memory всё плохо, а с Flash вообще полный швах - ни у кого нет. Поэтому выпустить современный микроконтроллер на условном Микроне нельзя. У них доступен только маленький EEPROM.
А вот контроллер, обёрнутый вокруг этой Flash - это каждый уже делает сам как может.
Периферия, как правило, 50/50. Контроллеры вокруг аналоговых блоков почти всегда свои. Высокоскоростные интерфейсы типа PCIe, DDR и т.п., ммм..., я бы сказал с большой долей вероятности покупные. Тут проблема, в том что они стыкуются с достаточно сложными блоками PHY. Мелкая периферия (UART, SPI, CAN), так как её относительно просто разработать самостоятельно - может быть как своя, так и покупная. Даже такая простая, на первый взгляд, периферия требует трудозатрат на верификацию.
Interconnect/Crossbar, как правило либо самописные, либо генерируются специальными доморощенными тулами.
Разработка микросхем для счётчиков электроэнергии есть у НИИЭТ и ПКК Миландр.
Если говорить про микросхемы конкретно в данной статье, то это сигма-дельта АЦП.
У НИИЭТ с наскоку находится только такой сигма-дельта: https://niiet.ru/product/1273пв19т/
Вряд ли в таком корпусе его кто-то будет применять в счётчиках. У Миландра находится внешний сигма-дельта АЦП в пластике: https://www.milandr.com/ic/42635/
Простите, а что не так?
2999 рублей за 3 чипа, т.е. примерно 1к за 1 чип.
Это я всё видел. Мне интересно что там в реальности.
Ну вот смотрите, таблица 2.4.
Пункт 19 (почему-то без номера): SAR ADC INL+-3 LSB
Пункт 20: SAR ADC DNL: +-2 LSB
При таком DNL там должны быть выпадающие коды, это достаточно посредственные параметры. При том эти параметры получены на номинальном питании 3.3В и при низкой частоте преобразования (fs = 250 kHz). Но правда это в диапазоне температур от -40 до +85 градусов Цельсия.
Смотрим дальше. Пункт 21 (опять без номера). SINAD (Signal-to-noise and distortion ratio) 60 dB. Из этого параметра можно легко высчитать эффективную разрядность (ENOB, Effective Number of Bits). ENOB = (SINAD - 1.76) / 6.02 = (60 - 1.76) / 6.02 = 9.67 bit
Это, на самом деле, не плохо. Но в таблице указано что частота преобразования fs = 1 MHz, но при этом не указана частота входного сигнала на которой это было получено.
Offset Error, Gain Error я там не вижу, механизма для калибровки оффсета тоже не вижу (может просто проморгал).
Ладно, для SAR мы что-то нашли. Ткните меня, пожалуйста, в параметры сигма-дельта АЦП. Что-то я их не вижу.
То что пишут большие допустимые ошибки INL, DNL - это понятно. Это делают для того чтобы увеличить выгод годных.
Но вот для счётчика электроэнергии нужны хорошие метрологические свойства, которые обеспечиваются в первую очередь АЦП.
В итоге: для SAR АЦП указано три параметра, да и те посредственные, для сигма-дельта параметров нет вообще.
Вот поэтому мне очень хотелось бы посмотреть что там в реальности, есть подозрения что контроллер от НИИЭТ не позволит обеспечить нужный класс точности.
Там по ряду решений и по списку ошибок сразу чувствуется что чип разрабатывался в России. Вот характеристики встроенного АЦП посмотреть интересно было бы, это да.
Разработать процессор на котором запускается Linux - это лишь часть проблемы, при том не самая большая.
Почему-то никто не говорит про самое интересное... А что там будет в качестве GPU?
Это последовательное преобразование типов .
1) (long)-1 -> 0xFF..FF
2) + 0xFF..FF -> 0xFF..FF
3) (int) 0xFF..FF -> 0xFF..FF
4) - 0xFF..FF -> 1
5) +(char)1 -> 1
6) (byte)1 -> 1
Т.е. куча унарных операций перемажающихся преобразованием типа. (byte) - (int) - 1 по идее даст тоже самое.
Плюс вам за то, что отправили Pull Request-ы с обновлением базы данных чипов в SNANDer, но вот обоснование необходимости писать свою программу какое-то слабенькое. То есть в существующем решении проблема была найдена и локализована, было понятно как её поправить. Признайтесь честно, реальная причина "потому что могу", тут никто не осудит %)
Вспоминается книга Д. Канемана "Шум. Несовершенство человеческих суждений". Там как раз рассказывается про то, что настроение судьи из-за погоды или близости времени обеда может влиять на выносимое им суждение.
Я такой же. Следил за игрой и оформил предзаказ Oil Rush именно потому, что они пообещали поддержку Linux. По тем же причинам покупал игрушки в составе Humble Bundle (4 или 5 выпусков). Но должен признаться честно, почти ни во что из купленного я толком не играл. Максимум запускал "на посмотреть" на пару часов %)
Знаете, у меня в такие моменты в голове возникает примерно такая картинка: сидит чиновник в своём кабинете, бьёт себе по лбу лютый facepalm и восклицает: "Ах, так вот зачем была нужна эта куча разнообразных НИИ в СССР, которые мы так старательно банкротили и превращали в ТЦ и бизнес-центры!"
Ну кроме того что когда-то Cadence на его основе проводил пару тренингов.
Так-то оно вроде пока живое, относительно недавно даже его поддержку в upstream GCC продвинули.
Я в него палочкой потыкал, с помощью FuseSOC собрал битстрим для платы DE0-Nano, запустил mainline Linux 5.1.2 + BusyBox и на этом пока успокоился.
Что-то отличное от Linux встречается очень редко.
Могу вспомнить разве что VxWorks и ZyNOS. Всё-таки ядро Linux — это весьма хороший framework для написания драйверов, плюс там очень много поддерживаемых «плюшек» (сетевых протоколов, алгоритмов шифрования и прочего). А тут важен параметр Time To Market, поэтому в большинстве случаев берут именно его, ибо цена доработки под свою железку минимальна.
А с WinCE и Platform Builder мне пришлось немного пострадать, не могу сказать что мне понравилось.
С поддержкой железа за это время стало значительно лучше. Я помню как искал в киосках с дисками драйвера для Linux для моей NVidia GeForce2 MX400. И даже нашёл.
Когда я всё это заставил работать с Mandrake 10 — счастью не было предела.
Сейчас же всё гораздо проще, поддержка железа в разы шире. Но ноутбуки я до сих пор выбираю предварительно изучая списки совместимости. Как правило, найти нужную по характеристикам совместимую железку можно без проблем, но выбирать «не глядя» я бы не рискнул.
Ключевое преимущество ядра Linux в данном случае (как и любого другого открытого/свободного продукта) — это возможность найти причину неполадки и исправить её самостоятельно. Да, для этого нужен определенный уровень, да, мало кто этим станет заниматься. Но сама возможность — это уже много.
Приведу пример «сбоку». Мне приходится работать с дорогущими проприетарными САПР и, как по мне, там просто адский ад. Куча глупейших багов и проблем, тикеты на которые висят годами.
Однажды мне пришлось перехватывать вызов unlink с помощью подключения самописной so-шки через LD_PRELOAD, чтобы посмотреть содержимое временных файлов с нетлистами из-за которых падала симуляция. Посмотрев в то, что генерит эта софтина, я ужаснулся содержимому, нашёл причину проблемы, сделал не менее жуткий костыль и в итоге всё завелось. Но мой тикет пофикисили только через пол года, и то не полностью.
Так что альтернатив Linux я пока просто не вижу. Если там что-то не работает, то хотя бы можно докопаться до истины.
У меня, например, это выглядит так:
Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
Если верить этой статистике: http://www.w3schools.com/browsers/browsers_os.asp, то пользователей Linux больше 5%, правда на хабре и ГТ есть километровые обсуждения корректности этих данных и репрезентативности выборки, но это уже совсем другая история.
Приобрел я на всем известной китайской торговой площадке 5 модулей ESP-07.
Распаял первый модуль на монтажке согласно общим рекомендациям.
Питание заводится с отдельного стабилизатора на 3.3 В. По питанию стоит 100 мкФ электролитический конденсатор и непосредственно у ног питания модуля — керамический.
CH_PD через 4.7 кОм подтянут к питанию, GPIO15 посажен на землю.
Включаю, цепляюсь через PL2303, а оно мне в терминал мусор сыпет. То есть эхо-ответ работает. В теории, код того символа что я набираю на клавиатуре приходит на порт RXD ESP8266, и ровно такой же код я должен получить на порту TXD ровно до момента завершения команды (на AT-прошивке CR+LF). Я потыкался осциллографом в RXD и TXD и понял что импульсы у кода в эхе слегка короче плюс короткие паразитные выбросы. Как итог — я вижу мусор. Потом была куча потуг понять почему уплывает частота. Пытался отмывать модуль и плату от канифоли и занимался прочей ересью.
Кто-то ещё с таким сталкивался? Можно ли с этим как-то бороться?
В итоге всё заработало нормально со вторым модулем.