Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 19
Много картинок, много рассуждений, а самое главное не написали - ваши таймстампы будут сильно зависеть от температуры, от точности настройки rtc и т.д. Так, побаловаться пойдет, а что-то серьёзное на них не построить.
Удивился на цитату. Ну что же, тогда вот и мои три копейки. Не критика, а просто в дополнение.
По совпадению, примерно с месяц назад откопал свою старую макетку STM32F4 DISCOVERY и решил оживить. Последний раз я что то кодил для мк более 10 лет назад, и тогда же последний раз писал на Си, т.е. забыл почти все по этой теме. Но, мне было очень интересно как LLM может помочь в эмбиддерстве. Что я сделал:
- спросил чатгпт, какой софт ставить. Был дан ответ, ставить STM CubeMX и CubeIDE. Поставил, запустил.
- спросил чатгпт, как сгенерить профиль в CubeMX для проекта VirtualCom port для моей платы. Не сразу, но по наводящим вопросам удалось пробиться через конфиги и сгенерить проект. Т.е. все изложенное в этой публикации я проделал под четким руководством чатагпт буквально минут за 15, без чтения документации/гайдов, и вообще не включая мозг (гордиться нечем, знаю, но сам факт).
- попросил чатгпт сгенерить мне код для VirtualCom port, включая небольшой обработчик команд / эмуляцию консоли. Заработало почти сразу: Я копипастил код в IDE, запускал, ошибки копипастил обратно в чатгпт, и следовал его указаниям. После нескольких таких итераций все заработало.
- потом еще спросил чатгпт от файн-тюнить код для максимальной пропускной способности виртуального компорта. Ну и заодно спросил хороший терминал для винды, чтобы все это погонять в железе.
Что я хочу сказать. У меня несколько знакомых программистов сейчас сидят без работы. Компании сокращают штат в пользу LLM, отсюда массовые увольнения. Похоже, это скоро коснется и эмбиддеров. А там и до меня доберутся. Но! Есть и плюсы. Для хоббистов теперь открыты все возможности, порог вхождения опустился ниже плинтуса.
Сейчас модно ембеддидь на RP2350. А ещё у него есть к основному ядру маленькие ядра PIO, привязанные к GPIO. Эти PIO работают на частоте ядра (150 МГц), у них есть простенький ассемблер из 7 комманд, а также несколько сдвиговых регистров и линий для прерывания основного ядра. Код и для основного ядра и для PIO пишется на Питоне. Разумеется код на Питоне пишут сейчас при помощи LLM.
Так что вероятно, плату с STM32F4 можно отложить обратно на полку :)
Они сидят без работы, потому что экономика хромает, а не из-за ИИ. Эмбедеры будут нужны, потому что у них есть лапки, а у ИИ нет.
Попробуйте что-то посложнее. Скажем, что то несложное для джуно-миддла в эмбедде. Например - "напиши на HAL для STM32F4 рабочий драйвер датчика AM2302. Вывод результатов через UART. Постарайся написть так, чтобы можно было просто подставить твой код в пустой проект STM32CubeIDE". Результат ИИ вас разочарует. Мягко говоря, придется подебажить и совершить много итераций.
Я сам использую ИИ и рад такому инструменту. Но реклама его возможностей, на мой, субъективный взгляд, пока опережает эти возможности.
Чат умеет читать даташиты, использовал его для поиска ОУ на замену, в частности искал аналоги TI у AD, и наоборот. Для такой задачи работает, но - требовать написать драйвер на основе описания регистров в даташите, конечно же перебор. Т.е. в данном примере я бы попросил сгенерить код для чтения/записи по интерфейсу (I2C?), а вот уже с регистрами команд и данных этого конкретно датчика разбирался бы вручную. Проверять как это сработает в реале не буду, разумеется. Просто мысли с дивана :-)
У себя по работе (топология ИС) тоже теперь часто использую ИИ. Буквально за последний год все изменилось, стало проще накидать промт, чем кодить самому. Но - не агитирую, и не спорю что пока это костыли, а не тул
У себя по работе (топология ИС) тоже теперь часто использую ИИ.
Ого. Круто. Прямо кристаллы проектируете? Приятно, что эксперты вашего уровня есть в русскоязычном коммюнити.
У себя по работе (топология ИС)
Кстати, любопытно, что происходит с топологом после того, как микросхема выпущена в производство?
Я имею ввиду, что в до-ИИ-шные времена линейные программисты какого-нибудь энтерпрайза могли работать в режиме "фигак-фигак-в-продакшн", а потом долго сидеть "на поддержке".
С электронщиками всё сложнее. Пока устройство разрабатывается, электронщик нужен, но он не приносит доход бизнесу. Как только устройство выпущено, бизнес начинает получать прибыль, однако электронщик, вообще говоря, перестаёт быть нужным.
Но в электронике хотя бы порог входа исчисляется сотней долларов. Простенькая плата в Резоните тысяч 5; МК, рассыпуха, монтаж - тоже плюс-минус также.
То есть
во-первых при наличие серъезных проблем с первой версией изделия всё-таки есть возможность выпустить версию №2;
во-вторых есть возможность работать над единичными устройствами.
А в разработке микросхем как?
Как представляется, единичное производство - это вообще не про микросхемы.
Да и выпуск ver.2, ver.3, ver.100500 - тоже накладен.
Прогоняет ли менеджмент такую тему, типа:
"Мы всё понимаем и искренне ценим ваш вклад. Но и вы нас поймите, мы коммерческая организация. После успеха нашего чипа мы ориентированы на масштабирование его производства и расширении сбыта. На данный период мы заинтересованы скорее в большем количестве маркетологов. Но мы помним о вас и обратимся, если решим расширить линейку. Просто сейчас для этого не самый подходящий момент"?
Кстати, любопытно, что происходит с топологом после того, как микросхема выпущена в производство?
Вы все верно написали. Чем больше штат, тем больше заказов, и эффективнее загрузка инженеров работой. Не говоря уже про лицензии на софт.
Разовые проекты интересны инженеру только если это твой стартап, либо если работаешь как ИП с несколькими клиентами. Понятно, что в РФ мало кто так может, поэтому предпочитают сидеть на зарплате ровно и пинать балду между проектами. Так же и менеджменту интереснее работать с ИП, а не содержать штат, но на деле мало кто готов бодаться с налоговой (за работу с ИП "кошмарят").
Еще потихоньку развиваются аутстафф сервисы, но туда идут работать только с иностранцами (китайцами), во всех остальных случаях это никому не выгодно - ни инженерам, ни их клиентам. Могу ошибаться.
Чем больше штат, тем больше заказов, и эффективнее загрузка инженеров работой. Не говоря уже про лицензии на софт.
Как представляется, выпускать каждую неделю по принципиально новой микросхеме ни у какого отдельного заказчика нет необходимости. А значит, команда разработчиков будет сбиваться в инжиниринговый центр и "засасывать" все возможные заказы, чтобы пустить равномерный поток работы через себя.
Если с разработкой смартфонов происходит именно так (Ваш Xiaomi — это не Xiaomi. Кто делает китайские телефоны на самом деле?), то уж с разработкой микросхем, как кажется, - и подавно должно.
Но укрупнение и концентрация ресурсов должны приводить к монополии.
А монополия - к унификации и отсутствию конкуренции. По идее.
И, типа, варианты для решения какой-то технической задачи:
- либо, условно, покупается готовый MIK32 Амур;
- либо "разрабатывается кастомная микросхема", но она будет разрабатываться в том же центре, где разрабатывался Амур, людьми, лучше всего разбирающимися в Амуре, и она будет чрезвычайно похожа на Амур.
Второй вариант приводит к мысли, а не проще ли тогда всё-таки использовать первый вариант? Не проще ли, условно, сделать свой SoM на базе Амура и дискретных компонентов, чем заказывать разработку новой микросхемы?
Если взять STM32U031R с максимальной частотой тактирования ядра в 56 МГц и попытаться охватить периодом измерения 1 год, обеспечив при этом максимально возможную точность
интересно зачем может потребоваться год измерения с такой точностью?
Но если в прерываниях таймера просто инкрементировать 32-битный ИНТ, то на месяц вполне хватит значения счетчик таймера+32 бит переменная, и таймеры соединять не надо (и никого продавать не надо, как говорил дядя Федор). Но максимальная точность (=тактовой частоте проца) у вас все равно не получится потому что нужно время чтобы считывать значения, а в это ВРЕМЯ может произойти прерывание... и не только от этого таймера.
Перефразируя классика можно сказать что, "вопросы времени самые сложные вопросы в программировании (а может и вообще в технике)".
Спасибо за статью.
В постановке задачи генерации абсолютных временных меток есть не упомянутая в статье сложность. Понятие абсолютного времени предполагает привязку либо к мировой инфраструктуре синхронизации времени (условно, NTP), либо к другим устройствам, использующим эти же абсолютные временные метки.
По указанной причине рассматривать применение RTC для генерации точных абсолютных меток некорректно без учёта точности значения, лежащего в самом RTC. А если в рассмотрение взять синхронизацию абсолютного времени, то точность абсолютного времени будет зависеть в большей степени от него.
Для задачи измерения длительности интервала времени проще использовать интерфейс 64-битного бегущего счётчика. Такой можно построить на основе 32-битного системного таймера в STM32.
таймстампы будут сильно зависеть от температуры, от точности настройки rtc и т.д.
применение RTC для генерации точных абсолютных меток некорректно без учёта точности значения, лежащего в самом RTC.
Уже второй комментарий в этом не слишком бурном обсуждении со словосочетанием вроде "точность самого RTC". Есть точность тактового сигнала, используемого RTC, это да.
А что такое "точность самого RTC"?
Часы реального времени хранят текущие дату и время. В сответствие с тактовым сигналом, от которого запитан RTC, происходит увеличение текущего значения времени. В этом процессе играет роль точность генератора тактового сигнала RTC (сдвиг частоты генерации от заявленной производителем, стабильность частоты генерации).
Но надо не забывать, что часы реального времени начинают отсчёт с некоторого значения, которое тоже может быть неточным. Это может играть роль только если значение абсолютного времени, полученного из этого RTC, сопоставляется со значением времени, полученным из другого RTC (на какой-то другой машине).
Если сопоставлять таймстемпы событий нужно только в рамках одной машины, то RTC здесь не единственное решение, и более точный результат по измерению длительности интервала времени обычно дают счётчик или таймер, но не часы реального времени.
На STM32 системный таймер 32-битный, и требуется обрабатывать прерывания по переполнению. rdtsc на x86, конечно, удобнее.
Если сопоставлять таймстемпы событий нужно только в рамках одной машины, то RTC здесь не единственное решение, и более точный результат по измерению длительности интервала времени обычно дают счётчик или таймер, но не часы реального времени.
Дано: вам нужно собирать таймстампы и измерять между ними интервалы времени длительностью, скажем, до 10 суток, ядро микроконтроллера затактировано от внешнего кварцевого генератора (HSE). Также от HSE через делитель затактированы RTC.
Расскажете, как таймер окажется точнее, чем RTC?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Электроника как социальный конструкт: микросекундные таймстампы на STM32