Да какая мне разница что там "на самом деле". Я пилю фичи. Кодовая база - 1500 файлов. Создает новые экраны, сенарии экранов, дизайны иконок, оконнные процедуры в объёме по нескольку тысяч строк. Пишет потом тесты для этих экранов тоже тысячи строк. Пишет потом утилиты для развертывания. Идет ровно. Не было такого чтобы не мог без ошибок написать простенький модуль на 2 тыс. строк. Я уже не помню когда последний раз отладчик открывал. Ни одной синтаксической ошибки или промаха с утечками памяти уже много месяцев. Что еще надо?
Вчера вечером по UTC+3 модель Opus 4.8 явно просела, прямо на глазах. Рассуждения стали отрывочными, сбивчивыми. Сегодня работает как ни в чем не бывало. Да и неделю назад, когда отключили Fable не сильно то и заметил. Продолжал кодить на Opus 4.8 с той же силой. Кстати сам Fable мне сейчас нашел во вчерашних чатах просадку интеллекта. Так что вывод о том что нельзя проверить просадки ложный. Проверяется и легко.
Про переключение моделей тоже не верно, переключение показывается юзеру явно. Сегодня три раза уже Fable у меня переключался на Opus.
На прошлой неделе Claude лежал пару часов в самый пик. Но что точно я заметил, так это то что такие деградации все реже случаются. Еще пару месяцев назад все было хуже. Наверно контекст научились лучше держать.
Ну так Fable и подскажет какой алгоритм применить. PID у нужны четкие чистые данные без задержек. Есть более эффективные алгоритмы не требуещие таких чистых данных. И тогда да, на пару умножений дольше, зато датчики сильно дешевле.
Те же чувствительные автоматические двери с нелинейной упрощенной механической передачей. Вполне себе хороший объект для нейросетевых алготимов.
Да даже теплый пол. Человека не интересует какая температура самого пола. Ему нужен комфорт. Ну угадайте PID-ом когда человеку комфортно.
Это тоже здорово. Но про большинство реальных систем мне кажется Fable знает лучше. Во всяком случае мне еще в прошлом году слабенький Sonnet сделал отличное управление на основе Калмана прямо в железе вообще без всяких симуляторов.
Смысл-то в чём? PID - один из десятков возможных алгоритмов управления, и застревать на нём - плохая идея.
Мне Fable5 сейчас предложил сделать на ADRC (Active Disturbance Rejection Control), а может и MPC организовать - всё сразу под железо, включая оптимизацию. Надо просто снять и дать Fable лог.
Крутить коэффициенты PID руками на сегодняшний день - просто трата времени.
И вас не смущает что на железе будет Composer Studio со всеми отптимизациями под фичи DSP, а в Similink будет какой-то GCC или VS без понятия о DSP фичах? Т.е. разница в вычислениях. Потом вижу двигателю нагрузку не симулируете. Откуда уверенность что вообще правильно симулируете среду?
Что-то совсем запутали. Так генерит ваш инженер из Similink исходники или нет?
Или он где-то на стороне пишет исходники. Потом вставляет их в C-блок Simulink и таким образом тестирует эти исходники? Тогда да - это уникальная инновация.
Но если все же генерит симулинком, то знаете, каждая следующая версия симулинка генерит исходники по своему. У них там до сих пор морока с приведением типов. А у вас на модели нет ни одного блока контроля или преведения типов. А сомневаюсь, что вы показываете настоящий свой рабочий процесс.
Странная модель в Simulink. Подозрительно простая. Ни сенсоров нет, ни машин состояний. Как будто с ней один раз кто-то работал , и сильно ничего не исследовал. Вы бы там хоть минимальный Stateflow сделали для отработки основных аварийных сценариев. А если у вас сценарии отрабатываются вне модели, то это уже костыли. И не видно четкого отделения модели софта от модели внешнего окружения. Вы уверены что софт генерится именно из этой модели?
Кстати, SIL уже много десятков лет существует. Чего это вы его называете до сих пор "уникальная программно-модельная методика"?
Как-то мутно и фрагментарно написано. Как будто про железо , но о железе очень слабые представления у автора. С кэшем он больше знаний показывал. Начнем с того что сначала надо ждать пока разгонится PLL, и ждать надо с запасом. Потом надо ждать запуска часового кварца, потом надо калибровать тактирование DDR. Потом надо ждать пока очухаются периферийные модули, раз уж он собрался всю периферию инициализировать в загрузчике. Одна только SD карта может 500 мс не выходить на рабочий режим.
Ну а так в учетом возможностей Claude я бы сам UBoot отправил в утиль с его деревьями, динамической памятью и HAL-ами. Claude не нуждается в абстракциях и не дрожит за переносимость. Может написать большинство драйверов с нуля с полностью статическим выделением памяти.
Приколько , но мне буквально на прошлой неделе Calude сделал точно такой же экранный интрефейс для подключения к WiFi сети.
Еще рекомендую - затребуйте у AI чтобы каждый раз пароль AP в дивайсе менялся. Поскольку канал не защищен. Сейчас много у кого в телефонах работает постоянный сканер всех WiFi точек. И он просто раньше перехватит вашу страницу и зафлудит. Тут можно сколько угодно сбрасывать и ничего не поможет.
ценность даёт не количество агентов, не «параллельность» и не персонажи, а три вещи — изоляция контекста, границы прав и независимая проверка. Если этих причин нет — отдельный агент не нужен, достаточно ясной задачи в одном промте.
На сильных современных моделях персона почти не даёт прироста. «Будь дотошным проверяющим», «ты senior-инженер» — модель от этого не становится умнее. Виртуальные «человеческие роли» — в основном театр
Питание 1.8 нужно сенсору потому что он молотит SPI на 50 МГц. А 50 МГц нужно чтобы передать огромные фреймы данных АЦП Поэтому стоят буфера переводящие 1.8 в 3.3 В для адаптации к обычными микроконтроллерам. SD карты на 50 МГц тоже работают только на 1.8 В. Так что это не экзотика.
Ну и далее. Напечатайте такой корпус (чтоб гладкий был , как заводской) , купите аккумлятор и такую светодиоднуб панель. И за всё заплатить 5$. Вот тогда поговорим.
Потом, радары BGT60TR13C не самые новые и крутые в линейке радаров Infineon. Пришлось смирится, поскольку такой только был в KIT-е.
К тому же я не утверждал, что разрабатываю примитивный датчик движения. Я ж написал "сенсорный хаб". С этим хабом совместим и протестирован фирменный софт Radar Fusion GUI. Там куча экзотических приложений, включая очень дорогие и востребованные. К этому я еще возможно вернусь.
Начнем с того что эти платки KIT-ов профессиональным разработчкикам дистрибуторы раздают бесплатно. Они просто пылились у меня без дела.
Я сам был в шоке от того за сколько модули на BGT60TR13C продаются на Alieхpress
Сделать на этом сенсоре свою плату - дело пары часов. Даю мою типовую схему
На LCSC все детали есть . Обойдется не дороже 20 Евро. Делайте и продавайте на алике. 1000% навар даже если сделаете скидку.
Так что самая дорогая часть в моем проекте была бы печать корпуса такого размера , аккумулятор и светодиодная панель. И я этого успешно избежал. В этом и есть фишка данной статьи.
А вот процессорный модуль тема отдельная. Его проект в принципе открыт. Но я бы его хотел достойно описать. Но это сложная работа. Думаю.
Да ладно вам постить эту лабуду. Fable 5 конечно нет, но и Opus 4.8 снегерит рабочее окружение для билдинга и отладки Corteх-M4 для любой IDE. И бы рекомендовал VS Code.
Не знаю за STM32 низких серий, но на AT32F вы сделаете еще более эффективный драйвер и в 10 раз больше плюшек. Смотрите https://biricha.com/design-software/st-wds/ Там регуляторы 3..4 порядка. Сверхэффективные. Для широчайших диапазонов тока. С тучей защит и детекциями деградаций. Там attiny85 просто нечего делать.
Китайские чипы AT32F435 гораздо круче. Раз в три дешевле и раза в два быстрее Вчера пока работал Fable5 он мне накатал из китайского pdf подробный компонент со всеми альтернативными функциями и оптимальным способом раскидал сигналы
Получил конроллер с управлением не менее 16 фарами и радаром ближнего действия, с дисплеем и аудиплейером.
А вы не пробовали спросить у Claude: «Как всё устроено в этом проекте?» Уверяю, он объяснит так, что ни один сеньор, работавший над этим проектом 10 лет, лучше не объяснит.
Нет никакого долга. Хотя бы потому, что Claude умеет создавать абсолютно точную и исчерпывающую документацию - в любом стиле и с любой степенью детализации. Он даже может предположить, почему в прошлом архитектура была сделана именно так. Но это уже неважно.
Статья разочаровала. Надеялся на более глубокий анализ. Похоже, автор задавал GPT неправильные промпты. Так-то мне статьи от GPT нравятся.
Да какая мне разница что там "на самом деле". Я пилю фичи.
Кодовая база - 1500 файлов.
Создает новые экраны, сенарии экранов, дизайны иконок, оконнные процедуры в объёме по нескольку тысяч строк. Пишет потом тесты для этих экранов тоже тысячи строк. Пишет потом утилиты для развертывания. Идет ровно. Не было такого чтобы не мог без ошибок написать простенький модуль на 2 тыс. строк.
Я уже не помню когда последний раз отладчик открывал.
Ни одной синтаксической ошибки или промаха с утечками памяти уже много месяцев.
Что еще надо?
Вчера вечером по UTC+3 модель Opus 4.8 явно просела, прямо на глазах. Рассуждения стали отрывочными, сбивчивыми.
Сегодня работает как ни в чем не бывало.
Да и неделю назад, когда отключили Fable не сильно то и заметил. Продолжал кодить на Opus 4.8 с той же силой.
Кстати сам Fable мне сейчас нашел во вчерашних чатах просадку интеллекта.
Так что вывод о том что нельзя проверить просадки ложный. Проверяется и легко.
Про переключение моделей тоже не верно, переключение показывается юзеру явно. Сегодня три раза уже Fable у меня переключался на Opus.
На прошлой неделе Claude лежал пару часов в самый пик.
Но что точно я заметил, так это то что такие деградации все реже случаются. Еще пару месяцев назад все было хуже. Наверно контекст научились лучше держать.
Ладно.
Назовем так " P-регулятор по калмановской оценке"
А то сейчас начнем спорить ни о чем.
Ну так Fable и подскажет какой алгоритм применить.
PID у нужны четкие чистые данные без задержек.
Есть более эффективные алгоритмы не требуещие таких чистых данных. И тогда да, на пару умножений дольше, зато датчики сильно дешевле.
Те же чувствительные автоматические двери с нелинейной упрощенной механической передачей. Вполне себе хороший объект для нейросетевых алготимов.
Да даже теплый пол. Человека не интересует какая температура самого пола. Ему нужен комфорт. Ну угадайте PID-ом когда человеку комфортно.
Ну почему же, если он стоит в обратной связи?
Просто Fable лучше оценит что нужно для управления.
Зачем делать калькуляторы для PID, когда столько возможностей просто взглянуть на проблему выше?
Это тоже здорово.
Но про большинство реальных систем мне кажется Fable знает лучше.
Во всяком случае мне еще в прошлом году слабенький Sonnet сделал отличное управление на основе Калмана прямо в железе вообще без всяких симуляторов.
Смысл-то в чём?
PID - один из десятков возможных алгоритмов управления, и застревать на нём - плохая идея.
Мне Fable5 сейчас предложил сделать на ADRC (Active Disturbance Rejection Control), а может и MPC организовать - всё сразу под железо, включая оптимизацию. Надо просто снять и дать Fable лог.
Крутить коэффициенты PID руками на сегодняшний день - просто трата времени.
Теперь яснее.
И вас не смущает что на железе будет Composer Studio со всеми отптимизациями под фичи DSP, а в Similink будет какой-то GCC или VS без понятия о DSP фичах? Т.е. разница в вычислениях.
Потом вижу двигателю нагрузку не симулируете.
Откуда уверенность что вообще правильно симулируете среду?
Что-то совсем запутали. Так генерит ваш инженер из Similink исходники или нет?
Или он где-то на стороне пишет исходники. Потом вставляет их в C-блок Simulink и таким образом тестирует эти исходники? Тогда да - это уникальная инновация.
Но если все же генерит симулинком, то знаете, каждая следующая версия симулинка генерит исходники по своему. У них там до сих пор морока с приведением типов. А у вас на модели нет ни одного блока контроля или преведения типов. А сомневаюсь, что вы показываете настоящий свой рабочий процесс.
Странная модель в Simulink. Подозрительно простая.
Ни сенсоров нет, ни машин состояний.
Как будто с ней один раз кто-то работал , и сильно ничего не исследовал.
Вы бы там хоть минимальный Stateflow сделали для отработки основных аварийных сценариев.
А если у вас сценарии отрабатываются вне модели, то это уже костыли.
И не видно четкого отделения модели софта от модели внешнего окружения.
Вы уверены что софт генерится именно из этой модели?
Кстати, SIL уже много десятков лет существует.
Чего это вы его называете до сих пор "уникальная программно-модельная методика"?
Как-то мутно и фрагментарно написано. Как будто про железо , но о железе очень слабые представления у автора. С кэшем он больше знаний показывал.
Начнем с того что сначала надо ждать пока разгонится PLL, и ждать надо с запасом.
Потом надо ждать запуска часового кварца, потом надо калибровать тактирование DDR.
Потом надо ждать пока очухаются периферийные модули, раз уж он собрался всю периферию инициализировать в загрузчике. Одна только SD карта может 500 мс не выходить на рабочий режим.
Ну а так в учетом возможностей Claude я бы сам UBoot отправил в утиль с его деревьями, динамической памятью и HAL-ами. Claude не нуждается в абстракциях и не дрожит за переносимость. Может написать большинство драйверов с нуля с полностью статическим выделением памяти.
Приколько , но мне буквально на прошлой неделе Calude сделал точно такой же экранный интрефейс для подключения к WiFi сети.
Еще рекомендую - затребуйте у AI чтобы каждый раз пароль AP в дивайсе менялся. Поскольку канал не защищен. Сейчас много у кого в телефонах работает постоянный сканер всех WiFi точек. И он просто раньше перехватит вашу страницу и зафлудит. Тут можно сколько угодно сбрасывать и ничего не поможет.
Как сказал Claude Opus 4.8
Питание 1.8 нужно сенсору потому что он молотит SPI на 50 МГц.
А 50 МГц нужно чтобы передать огромные фреймы данных АЦП
Поэтому стоят буфера переводящие 1.8 в 3.3 В для адаптации к обычными микроконтроллерам.
SD карты на 50 МГц тоже работают только на 1.8 В. Так что это не экзотика.
Ну и далее. Напечатайте такой корпус (чтоб гладкий был , как заводской) , купите аккумлятор и такую светодиоднуб панель. И за всё заплатить 5$. Вот тогда поговорим.
Потом, радары BGT60TR13C не самые новые и крутые в линейке радаров Infineon. Пришлось смирится, поскольку такой только был в KIT-е.
К тому же я не утверждал, что разрабатываю примитивный датчик движения.
Я ж написал "сенсорный хаб". С этим хабом совместим и протестирован фирменный софт Radar Fusion GUI.
Там куча экзотических приложений, включая очень дорогие и востребованные.
К этому я еще возможно вернусь.
Начнем с того что эти платки KIT-ов профессиональным разработчкикам дистрибуторы раздают бесплатно. Они просто пылились у меня без дела.
Я сам был в шоке от того за сколько модули на BGT60TR13C продаются на Alieхpress
Сделать на этом сенсоре свою плату - дело пары часов.
Даю мою типовую схему
На LCSC все детали есть . Обойдется не дороже 20 Евро. Делайте и продавайте на алике. 1000% навар даже если сделаете скидку.
Так что самая дорогая часть в моем проекте была бы печать корпуса такого размера , аккумулятор и светодиодная панель. И я этого успешно избежал. В этом и есть фишка данной статьи.
А вот процессорный модуль тема отдельная. Его проект в принципе открыт. Но я бы его хотел достойно описать. Но это сложная работа. Думаю.
Да ладно вам постить эту лабуду.
Fable 5 конечно нет, но и Opus 4.8 снегерит рабочее окружение для билдинга и отладки Corteх-M4 для любой IDE.
И бы рекомендовал VS Code.
Не знаю за STM32 низких серий, но на AT32F вы сделаете еще более эффективный драйвер и в 10 раз больше плюшек.
Смотрите https://biricha.com/design-software/st-wds/
Там регуляторы 3..4 порядка. Сверхэффективные. Для широчайших диапазонов тока. С тучей защит и детекциями деградаций.
Там attiny85 просто нечего делать.
Ну так что заставило опять на STM32 вернутся?
Китайские чипы AT32F435 гораздо круче. Раз в три дешевле и раза в два быстрее
Вчера пока работал Fable5 он мне накатал из китайского pdf подробный компонент со всеми альтернативными функциями и оптимальным способом раскидал сигналы
Получил конроллер с управлением не менее 16 фарами и радаром ближнего действия, с дисплеем и аудиплейером.
Эх, крутая штука была Fable 5.
Проблема, по-моему, высосана из пальца.
А вы не пробовали спросить у Claude: «Как всё устроено в этом проекте?»
Уверяю, он объяснит так, что ни один сеньор, работавший над этим проектом 10 лет, лучше не объяснит.
Нет никакого долга. Хотя бы потому, что Claude умеет создавать абсолютно точную и исчерпывающую документацию - в любом стиле и с любой степенью детализации.
Он даже может предположить, почему в прошлом архитектура была сделана именно так.
Но это уже неважно.
Статья разочаровала. Надеялся на более глубокий анализ.
Похоже, автор задавал GPT неправильные промпты. Так-то мне статьи от GPT нравятся.