Статья крута, да, и полезна. Наверное, стоило начать с этой фразы, а я тут с ноги дверь вышибаю. Извините.
Технический аспект статьи лично я не считаю сильно полезным. Честно :)
технических решений может быть много, и они должны быть к месту
В том всё и дело. Периодически, технических решений много, но абсолютно каждое из них не к месту.
Уместно ли писать свой програмный "велосипед" при наличие аппаратной поддержки функционала? Ну, как бы, такое себе...
Уместно ли использовать аппаратный функционал, который представляет из себя стопку заплаток над порядком устаревшим легаси, при том, что сведения о функционале именно что находятся в "закоулках тех.описаний", куда почти никто не заглядывает? Уместно ли его использовать лишь потому, что он, типа, есть? Точно также - такое себе...
Это первый аспект.
Второй для вас, возможно, менее актуален, если вы фрилансер, лично выполняющий проект от и до.
Многие проекты выполняются в команде. В команде старший должен махнуть шашкой и сказать "Хорошего выбора нет. Будем делать криво, но единообразно. Из всех вариантов я авторитарно выбрал для нас кривой способ N2". На чём будет основан этот выбор? Короткое, понятное, (и неправильное) техническое обоснование подвести можно под что угодно. Но по сути, это будет не технический выбор.
"Ну да, совершил", "Был пьян, каюсь", "Больше такого не повторится"
Оправдываться у меня в планах не было :) Скорее, я хотел показать различные решения с различных сторон без шаблонного сюжетного приёма "а на самом деле правильно вот так".
Не нужно в пол-статьи оправдываться, как, зачем, и почему вы применили именно это решение.
Обычно это делается быстрее и короче, например так: "я не применяю RTC для таймстампов потому, что RTC можно затактировать лишь от 32768 Гц. Который даст точность в 30мкс, а вдруг нам понадобится 1мкс".
Это простое, понятное, неправильное объяснений.
Правильное было бы: "я ни разу не использовал аппаратные таймстампы, предчувствую забег по граблям и потому лучше использую привычные мне приёмы". Но признаваться в таком неприятно :)
скажите, а какое _практическое применение у вас для таймштампов с точностью 1мкс?
Это вы можете спросить непосредственно у зилота вот здесь :)
арм счётчик тактов процессора. не помню, 32 или 64 бит
32 бита. И у Cortex-M0/0+ (STM32U0) он отсутствует, а у Cortex-M3/4 по нему нет прерываний - он именно для отладки. Хотя для своих целей - измерять время исполнения участков кода при отладке - он идеально подходит.
И вот посмотрите, как живут такие статьи: просмотры приходят и приходят, это «вечнозелёный» или «долгоиграющий» материал.
Следует отметить, что лучше всего просмотры потом приходят, если ссылка на публикацию постится на какой-нибудь крупной платформе вроде Пикабу или наоборот, в узкоспециализированном сообществе, поддерживающим свою тематическую обособленность.
Но оно как будто бы... кажется возвращаться в начало цикла смысла уже нет... Очень внимательно надо смотреть что вы хотите получить!
...или использовать готовое аппаратное решение и стандартные библиотечные функции. Ага.
Мой изначальный вопрос относился к вашему тезису:
более точный результат по измерению длительности интервала времени обычно дают счётчик или таймер, но не часы реального времени.
И таймер и RTC, в своей основе имеют счётчики, считающие импульсы. Мне было интересно, за счёт чего вы предполагаете увеличение точности первого в сравнении со вторым, если они могут быть затактированы от единого источника?
На этот вопрос вы вполне ответили:
С учётом того, что тут десятка два инструкций (реализация на ASM), решение всё-таки не даст точности больше 1 мкс при HSE=100 МГц...
Если сопоставлять таймстемпы событий нужно только в рамках одной машины, то RTC здесь не единственное решение, и более точный результат по измерению длительности интервала времени обычно дают счётчик или таймер, но не часы реального времени.
Дано: вам нужно собирать таймстампы и измерять между ними интервалы времени длительностью, скажем, до 10 суток, ядро микроконтроллера затактировано от внешнего кварцевого генератора (HSE). Также от HSE через делитель затактированы RTC.
Чем больше штат, тем больше заказов, и эффективнее загрузка инженеров работой. Не говоря уже про лицензии на софт.
Как представляется, выпускать каждую неделю по принципиально новой микросхеме ни у какого отдельного заказчика нет необходимости. А значит, команда разработчиков будет сбиваться в инжиниринговый центр и "засасывать" все возможные заказы, чтобы пустить равномерный поток работы через себя.
Но укрупнение и концентрация ресурсов должны приводить к монополии. А монополия - к унификации и отсутствию конкуренции. По идее.
И, типа, варианты для решения какой-то технической задачи: - либо, условно, покупается готовый MIK32 Амур; - либо "разрабатывается кастомная микросхема", но она будет разрабатываться в том же центре, где разрабатывался Амур, людьми, лучше всего разбирающимися в Амуре, и она будет чрезвычайно похожа на Амур.
Второй вариант приводит к мысли, а не проще ли тогда всё-таки использовать первый вариант? Не проще ли, условно, сделать свой SoM на базе Амура и дискретных компонентов, чем заказывать разработку новой микросхемы?
таймстампы будут сильно зависеть от температуры, от точности настройки rtc и т.д.
применение RTC для генерации точных абсолютных меток некорректно без учёта точности значения, лежащего в самом RTC.
Уже второй комментарий в этом не слишком бурном обсуждении со словосочетанием вроде "точность самого RTC". Есть точность тактового сигнала, используемого RTC, это да. А что такое "точность самого RTC"?
Главная проблема не в том, чтобы хоть чем-то досчитать до 2⁶⁴. Главная проблема, как при 32-битной шине памяти атомарно скопировать имеющееся значение из регистра в эту самую память.
Кстати, любопытно, что происходит с топологом после того, как микросхема выпущена в производство?
Я имею ввиду, что в до-ИИ-шные времена линейные программисты какого-нибудь энтерпрайза могли работать в режиме "фигак-фигак-в-продакшн", а потом долго сидеть "на поддержке".
С электронщиками всё сложнее. Пока устройство разрабатывается, электронщик нужен, но он не приносит доход бизнесу. Как только устройство выпущено, бизнес начинает получать прибыль, однако электронщик, вообще говоря, перестаёт быть нужным.
Но в электронике хотя бы порог входа исчисляется сотней долларов. Простенькая плата в Резоните тысяч 5; МК, рассыпуха, монтаж - тоже плюс-минус также. То есть во-первых при наличие серъезных проблем с первой версией изделия всё-таки есть возможность выпустить версию №2; во-вторых есть возможность работать над единичными устройствами.
А в разработке микросхем как?
Как представляется, единичное производство - это вообще не про микросхемы. Да и выпуск ver.2, ver.3, ver.100500 - тоже накладен.
Прогоняет ли менеджмент такую тему, типа: "Мы всё понимаем и искренне ценим ваш вклад. Но и вы нас поймите, мы коммерческая организация. После успеха нашего чипа мы ориентированы на масштабирование его производства и расширении сбыта. На данный период мы заинтересованы скорее в большем количестве маркетологов. Но мы помним о вас и обратимся, если решим расширить линейку. Просто сейчас для этого не самый подходящий момент"?
Не то, чтобы тонкий. Мне самому STM32 привычней. Но я попробовал RP2350 и вынужден признать, что это очень даже новаторское изделие и вполне себе может вытеснить STM32 из... да из всего.
Сейчас модно ембеддидь на RP2350. А ещё у него есть к основному ядру маленькие ядра PIO, привязанные к GPIO. Эти PIO работают на частоте ядра (150 МГц), у них есть простенький ассемблер из 7 комманд, а также несколько сдвиговых регистров и линий для прерывания основного ядра. Код и для основного ядра и для PIO пишется на Питоне. Разумеется код на Питоне пишут сейчас при помощи LLM.
Так что вероятно, плату с STM32F4 можно отложить обратно на полку :)
Дмитрий хотя бы какой то вклад делает в эту платформу...
...лишь в сравнении с вами, "вложившим" в платформу 125 комментов.
Я тоже не во всём с ним согласен (даже очень много в чём не согласен). И он бывает иногда назойлив в пропаганде своего мнения. Но...
...но что же делать с саморегуляцией платформы, если ув.сообщество говорит некоторым пользователям своё веское "он нам не нравится", а эти пользователи пролезают через подпол? Чего стОит такая саморегуляция, раз уж автор оригинального поста о ней заговорил?
Саморегуляция Хабра тут без нашей помощи не вывозит. Поэтому нам надо взять инициативу нас себя:
1. Видим нейрослоп статью - ставим минус и ей, и её автору. Даже если кажется, что в этой мутной воде что-то есть. Это что-то скорее всего либо банально, либо попросту лживо.
Вот правильно! И с мультоводами тоже надо что-то делать! А то, понимаешь, саморегулируемое сообщество отправляет их в нокаут (@vintage), а они всё лезут и лезут (@nin-jin). Прям хоть зови@Exosphere ;)
RK3568 не содержит нужной периферии, и габариты не те.
Окей -TX8M имеет габариты 67х26мм и он 2020 года. -TityraCore Z7 хотя имеет габариты 67х40мм, на борту ПЛИС Zynq7000, который может выполнять роль практически любой периферии.
Я не то, чтобы критикую ваши технические решения, я скорее хочу понять, может я чего-то не знаю. Не идёт на ум такой периферии и таких ограничений по габаритам, где разработка кастомного SoM была бы безальтернативна. Но вот может я что-то упускаю.
Мать в 4 слоя - теперь понятно. Это просто не сервер 2025 года разработки.
А чего понятно? :) Мать? Мать. Процессор х86 на гигагерц, PCIe, модули DDR - всё есть и всё на 4-х слоях :)))
С сервером та проблема, что если я найду и сервер, и 2025 года, и на 4-х слоях, то всё равно ж это будет не тот сервер :)
Не совсем :) Вот тут история расписана подробней.
Технический аспект статьи лично я не считаю сильно полезным. Честно :)
В том всё и дело. Периодически, технических решений много, но абсолютно каждое из них не к месту.
Уместно ли писать свой програмный "велосипед" при наличие аппаратной поддержки функционала? Ну, как бы, такое себе...
Уместно ли использовать аппаратный функционал, который представляет из себя стопку заплаток над порядком устаревшим легаси, при том, что сведения о функционале именно что находятся в "закоулках тех.описаний", куда почти никто не заглядывает? Уместно ли его использовать лишь потому, что он, типа, есть? Точно также - такое себе...
Это первый аспект.
Второй для вас, возможно, менее актуален, если вы фрилансер, лично выполняющий проект от и до.
Многие проекты выполняются в команде. В команде старший должен махнуть шашкой и сказать "Хорошего выбора нет. Будем делать криво, но единообразно. Из всех вариантов я авторитарно выбрал для нас кривой способ N2". На чём будет основан этот выбор? Короткое, понятное, (и неправильное) техническое обоснование подвести можно под что угодно. Но по сути, это будет не технический выбор.
Оправдываться у меня в планах не было :) Скорее, я хотел показать различные решения с различных сторон без шаблонного сюжетного приёма "а на самом деле правильно вот так".
Точно! Я вёл дискуссию с одним собеседником и задавал вопрос ему, но не обратил внимание, что вы влезли поперёк обсуждения.
На Cortex-M0 есть RTC но нет DWT->CYCCNT.
CYCCNT на 50МГц переполняется через каждые полторы минуты. Такие себе аппаратные таймстампы из него.
Обычно это делается быстрее и короче, например так: "я не применяю RTC для таймстампов потому, что RTC можно затактировать лишь от 32768 Гц. Который даст точность в 30мкс, а вдруг нам понадобится 1мкс".
Это простое, понятное, неправильное объяснений.
Правильное было бы: "я ни разу не использовал аппаратные таймстампы, предчувствую забег по граблям и потому лучше использую привычные мне приёмы". Но признаваться в таком неприятно :)
Это вы можете спросить непосредственно у зилота вот здесь :)
32 бита. И у Cortex-M0/0+ (STM32U0) он отсутствует, а у Cortex-M3/4 по нему нет прерываний - он именно для отладки. Хотя для своих целей - измерять время исполнения участков кода при отладке - он идеально подходит.
Следует отметить, что лучше всего просмотры потом приходят, если ссылка на публикацию постится на какой-нибудь крупной платформе вроде Пикабу или наоборот, в узкоспециализированном сообществе, поддерживающим свою тематическую обособленность.
Вот, например, моя статья Delta Chat. Короткая инструкция в картинках и график её просмотров:
...или использовать готовое аппаратное решение и стандартные библиотечные функции. Ага.
Мой изначальный вопрос относился к вашему тезису:
И таймер и RTC, в своей основе имеют счётчики, считающие импульсы. Мне было интересно, за счёт чего вы предполагаете увеличение точности первого в сравнении со вторым, если они могут быть затактированы от единого источника?
На этот вопрос вы вполне ответили:
Дано: вам нужно собирать таймстампы и измерять между ними интервалы времени длительностью, скажем, до 10 суток, ядро микроконтроллера затактировано от внешнего кварцевого генератора (HSE). Также от HSE через делитель затактированы RTC.
Расскажете, как таймер окажется точнее, чем RTC?
Как представляется, выпускать каждую неделю по принципиально новой микросхеме ни у какого отдельного заказчика нет необходимости. А значит, команда разработчиков будет сбиваться в инжиниринговый центр и "засасывать" все возможные заказы, чтобы пустить равномерный поток работы через себя.
Если с разработкой смартфонов происходит именно так (Ваш Xiaomi — это не Xiaomi. Кто делает китайские телефоны на самом деле?), то уж с разработкой микросхем, как кажется, - и подавно должно.
Но укрупнение и концентрация ресурсов должны приводить к монополии.
А монополия - к унификации и отсутствию конкуренции. По идее.
И, типа, варианты для решения какой-то технической задачи:
- либо, условно, покупается готовый MIK32 Амур;
- либо "разрабатывается кастомная микросхема", но она будет разрабатываться в том же центре, где разрабатывался Амур, людьми, лучше всего разбирающимися в Амуре, и она будет чрезвычайно похожа на Амур.
Второй вариант приводит к мысли, а не проще ли тогда всё-таки использовать первый вариант? Не проще ли, условно, сделать свой SoM на базе Амура и дискретных компонентов, чем заказывать разработку новой микросхемы?
Уже второй комментарий в этом не слишком бурном обсуждении со словосочетанием вроде "точность самого RTC". Есть точность тактового сигнала, используемого RTC, это да.
А что такое "точность самого RTC"?
Главная проблема не в том, чтобы хоть чем-то досчитать до 2⁶⁴. Главная проблема, как при 32-битной шине памяти атомарно скопировать имеющееся значение из регистра в эту самую память.
Кстати, любопытно, что происходит с топологом после того, как микросхема выпущена в производство?
Я имею ввиду, что в до-ИИ-шные времена линейные программисты какого-нибудь энтерпрайза могли работать в режиме "фигак-фигак-в-продакшн", а потом долго сидеть "на поддержке".
С электронщиками всё сложнее. Пока устройство разрабатывается, электронщик нужен, но он не приносит доход бизнесу. Как только устройство выпущено, бизнес начинает получать прибыль, однако электронщик, вообще говоря, перестаёт быть нужным.
Но в электронике хотя бы порог входа исчисляется сотней долларов. Простенькая плата в Резоните тысяч 5; МК, рассыпуха, монтаж - тоже плюс-минус также.
То есть
во-первых при наличие серъезных проблем с первой версией изделия всё-таки есть возможность выпустить версию №2;
во-вторых есть возможность работать над единичными устройствами.
А в разработке микросхем как?
Как представляется, единичное производство - это вообще не про микросхемы.
Да и выпуск ver.2, ver.3, ver.100500 - тоже накладен.
Прогоняет ли менеджмент такую тему, типа:
"Мы всё понимаем и искренне ценим ваш вклад. Но и вы нас поймите, мы коммерческая организация. После успеха нашего чипа мы ориентированы на масштабирование его производства и расширении сбыта. На данный период мы заинтересованы скорее в большем количестве маркетологов. Но мы помним о вас и обратимся, если решим расширить линейку. Просто сейчас для этого не самый подходящий момент"?
Не то, чтобы тонкий. Мне самому STM32 привычней. Но я попробовал RP2350 и вынужден признать, что это очень даже новаторское изделие и вполне себе может вытеснить STM32 из... да из всего.
Сейчас модно ембеддидь на RP2350. А ещё у него есть к основному ядру маленькие ядра PIO, привязанные к GPIO. Эти PIO работают на частоте ядра (150 МГц), у них есть простенький ассемблер из 7 комманд, а также несколько сдвиговых регистров и линий для прерывания основного ядра. Код и для основного ядра и для PIO пишется на Питоне. Разумеется код на Питоне пишут сейчас при помощи LLM.
Так что вероятно, плату с STM32F4 можно отложить обратно на полку :)
...лишь в сравнении с вами, "вложившим" в платформу 125 комментов.
...но что же делать с саморегуляцией платформы, если ув.сообщество говорит некоторым пользователям своё веское "он нам не нравится", а эти пользователи пролезают через подпол? Чего стОит такая саморегуляция, раз уж автор оригинального поста о ней заговорил?
Вот правильно! И с мультоводами тоже надо что-то делать! А то, понимаешь, саморегулируемое сообщество отправляет их в нокаут (@vintage), а они всё лезут и лезут (@nin-jin). Прям хоть зови@Exosphere ;)
OCP?
Эти что ли? :)
Окей
-TX8M имеет габариты 67х26мм и он 2020 года.
-TityraCore Z7 хотя имеет габариты 67х40мм, на борту ПЛИС Zynq7000, который может выполнять роль практически любой периферии.
Я не то, чтобы критикую ваши технические решения, я скорее хочу понять, может я чего-то не знаю. Не идёт на ум такой периферии и таких ограничений по габаритам, где разработка кастомного SoM была бы безальтернативна. Но вот может я что-то упускаю.
А чего понятно? :)
Мать? Мать.
Процессор х86 на гигагерц, PCIe, модули DDR - всё есть и всё на 4-х слоях :)))
С сервером та проблема, что если я найду и сервер, и 2025 года, и на 4-х слоях, то всё равно ж это будет не тот сервер :)
А этот, например?
Вот:
Скрытый текст