ctrlX CORE это 64 Bit Quad-Core ARM CPU и 2 Гб RAM И все ради каких-то 125 мкс И вы хотите сказать, что будущее вот такое - дорогущие платформы на избыточном софте?
Я же думаю : Там все это только лишь от того, что код был по любому дороже. А теперь когда код стал дёшев, они разорятся на таких монстрах.
Ну да, если что не сходится, то надо привлечь магию. А именно асушника, который способен в doсker запаковать приложение организующее доступ к клемам через K-Line, не выключая runtime и не вынимая ПЛК из рабочей стойки. Фантастика. Он там только WEB страничку поменять может и то не факт.
Знаете, CODESYS ведь изначально был сделан под микроконтроллеры с RTOS, а не Линукс. И да, там изначально пользоваетель грузил приложения не пересобирая runtime. Пересобирать runtime или нет - это очень мелкий ворос.
У меня к примеру сейчас приложение из пары тысяч файлов , они состовляют фреймворк общий для кучи проектов. Я мог бы спокойно его изолировать и сделать из него такой отдельный модуль. Но мне это не нужно. Зачем мне от себя что-то изолировать? Я его перекомпилирую каждый день вместе с прикладным кодом. Благодаря этому он у меня теперь проверен вдоль и поперёк, при любых уровнях оптимизации , при любых раскладах памяти. А если вы держите runtime как священную корову, к ней не прикасаясь, то сами себя лишаете гибкости. Кто решил что такой runtime эффективен? Тот кто даже не видел ваши задачи! Нет, runtime можно и должно менять. Теже протоколы, они постоянно меняются. А ведь они в runtime. К кому бежите чтобы там поменять пару команд?
Так что аргумент "зато мы не трогаем runtime" ну совсем не катит.
А некритичным задачам так и вовсе ПЛК не нужен. Он и дорог, и место занимет и потребляет как не в себе.
WEB сервер по HTTPS и всеми поддержками сертификатов у ThreadX не хуже чем в Линуксе.
И еще момент. В WAGO PFC200 runtime c CODESYS единолично захватывает драйвер шины клемников K-Line. Свое приложение либо должно отключить CODESYS чтобы забрать драйвер и само организовать цикл, либо в runtime химичить мост. И опять ваше утверждение про "зато мы не трогаем runtime" не катит.
Тут еще прикол буквально сейчас я схватил. Claude Fable отказывается работать с исходниками, где просишь сделать защиту доступа к контроллеру. Т.е. теперь trust zone в Линуксе вне закона для простых смертных. Это еще один повод не лезть в системы с внешними носителями кода.
Просто вы почему-то странно заостряете внимание на "пересобрать, загрузить и заново протестировать". Как будто в Линуксе не нужно загружать и тестировать. Пересобрать да, если у вас скрипты, то не нужно. Но и реальное время тогда вам не светит. А если мне не нужно реального времени, то я и планшет могу приспособить под ПЛК и даже терефон. Т.е. это это уже не совсем ПЛК. Пересборка под RTOS длится секунды. Не надо думать что подгружаемые исполняемые модули есть только в Линуксе. В ThreadX также есть механизм подгрузки исполняемых модулей. Это не какая-то магия, а довольно примитивный процесс. И под RTOS можно все подключть позднее. Или хотитет сказать, что изучить сам API Modbus RTU и все опции запуска и их влияние вы под Линуксом быстрее сделаете? Да нет, вы это сделаете это медленнее. Потому что имеете там меньше инструментов отладки реального времени. Потому что вы лишаетесь сквозной отладки. В жестком реальном времени нужна сквозная отладка от момента вызова файловой операции и до выдачи команды CMD52 на интерфесе SDIO. Иначе месяцами будете ждать ответа вендора и ручками бегать сбрасывать свой контроллер. В RTOS я могу через трассировку в SWD видеть не то что все вызовы, а все потоки прерываний в реальном времени и не использовтаь при этом никакого инструментального кода. Про архивы вообще бы не говорил. У вас там такая же SD карта, как и в RTOS. Но ваш драйвер этой карты не вылизан так как они вылизаны под RTOS. Не согласованы каналы DMA, не выставлены приоритеты у этих каналов, не очищено все от избыточности косвенных вызовов и абстракций, не убраны избыточне объекты синхронизации и т.д. и т.п.
SQLite, OPC UA, Modbus-RTU уже давно портированы на RTOS для мелких контроллеров. Им Линукс не нужен от слова совсем. InfluxDB - требует от 1 Гб RAM-а , это не про Линукс, а про масштаб. Python и Grafana - в embedded лишние надсройки. ИИ агенты теперь делают графики в каком угодно стиле и формате вообще не привлекая сторонние тулсы на голом css и js Конверетеры протоколов однозначно на RTOS будут работать быстрее и детерминирование Подключаться к облакам теперь умеет любой ESP. А Amazon специально для FreeRTOS сделал модуль подключения к AWS. В ThreadX есть спецально под нее модуль подключения к Microsoft Azure IoT. И там есть всё: апгрейд прошивки по воздуху , автоматическое развертывание миллионов дивайсов, телеметрия, управление по MQTT и проч.
Но какие приложения? Можете назвать что нибудь стоящее, кроме питона , Node-RED, Arduino и прочих интепретаторов-прокладок, необходимость в которых полностью отпадает при наличии агентов прямо пишущих на C. С вашим понятием "открытости" и Windows можно назвать полностью открытой операционкой. Потом интересно какой минимальный период цикла поддерживает ваше решение на Линуксе? На обычном микроконтроллере 240 МГц нормально держать жесткий цикл в 100 и меньше мкс.
Да уж и времена когда для подключения к AWS по MQTT, OPC UA или WEB сервер нужен был Линукс тоже прошли. Сейчас это достаточно легко делается на обычной легковесной RTOS типа ThreadX или FreeRTOS. Современные агенты за пару дней перенесут все нужные стеки на RTOS включая навороченные GUI и базы данных.
Кстати, ПЛК типа WAGO PFC200 не делают на одном процессорном чипе. Вот у меня такой один убитый лежит :
Тут как минимум два SoC и две разные операционки. И по ходу есть место еще для одного SoC
Убить такие контроллеры достаточно легко. Программа выполняется из DDRAM, грузится из NAND. Куча мест где что-то может пойти не так. Но они никогда не станут открытыми, потому что в них всегда есть какой нибудь кастомный чип на шине. Их межмодульная шина - самый большой секрет. Проблема еще в том что программу хранимую вне SoC гораздо труднее защитить. А в Европе, к примеру, вступает в силу Cyber Resilience Act. И с ним сделать защиту Линукса ох как нелегко. Придется возится с Trusted Firmware-A или с OP-TEE. А иначе не дадут разрешение на использование нигде. А с обычным микроконтроллером прожег фьюзы и все! Дело сделано.
Поэтому на мой взгляд надежней ПЛК будет на SoC с интегрированной Flash и RAM с Error-Correcting Code. Таких сейчас достаточно много дешевых: RP2354 , ESP32-P4 , RA8P1 , STM32N657 ... Вот за ними-то и вижу перспективы. И дёшево, и надёжно.
А смысл? Индивидуальный Allan-анализ каждого MEMS врядли существенно повысит точность INS. Только время будет зря потеряно на тюнинг алгоритмов. Температура и время свое отыграют. С другой стороны в даташитах и так написаны предельные шумы и девиации.
Проект не слишком сложный Авторских файлов где-то 300 штук и где-то 170000 строк кода. Но еще 200000 строк кода взято из сторонних проектов. Решения по установке канала через интренет сторонние и ненадежные. Опирается на собственный открытый сервер в сети. Это сомнительно.
Да , на пару лет тянет. Но для современных ИИ это неделя работы. Софт обесценился. Поэтому повсюду его и открывают.
Немного так голословно пишете. И что такое этот "энтерпрайз" в embedded, не объясните?
Но я вам приведу данные, которые снял буквально сейчас. Статическими анализаторами никогда не пользуюсь, потому что они дают море ложных срабатываний. Но тут просто для сторонних наблюдателей.
Вот сейчас я запустил такой анализатор от IAR уровня MISRA/CERT, но под присмотром Fable5. Проанализировал 203 файла 179072 строки кода. Вышло мне это в 3% пятидневного лимита Fable. Т.е. без всяких переживаний план Pro от Claude выдержит сотни таких проверок в месяц. План 100$ , значит проверка обошлась в 1$, и это если работать только на Fable
Что вышло. Статический анализатор C-STAT (не думаю что ваш сильно умнее) выдал 2727 сообщений Из них 1871 - просто шум макросов. Ну запутался анализатор в макросах. Потом 660 значимых сообщений. Из них только 17 реальных, Из них только 5 действительно могли привести к сбою программы. Из них только одна проблема могла произойти при реальном сценарии использования. Вот такова цена статического анализатора.
А вот сам Fable 5 мне весь день исправляет ошибки такие как: гонки задач , распределение приоритетов задач, оптимизация стека, логика автоматов состояний и т.д. и т.п. Не менее десяка проблем логики прикладного кода в день.
Словом думайте.
Хотите могу вам провести анализ всей ThreadX (без middleware). Прямо здесь, задаром. Вы будете искать своим инструментом, а я своим. И сравним.
Ну да боту зачем-то интересно чем может в embedded помочь PVS-Studio. Нет, вы просто оскорбляете другого автора, а ваши люди элементарно не могут объяснить ценность вашего продукта. Давайте по чесному поспорьте с Claude Fable 5. Это теперь я так понимаю "экзистенциальный" спор. И пока вы проигрываете. Ценность PVS-Studio тает на глазах. Мне это интересно только с точки зрения может ли программный продукт такого направления вообще выжить.
Потому что Хабр - это реклама, а не рецензируемый научный журнал. Автор тяп-ляп и настругал аргументов, никаких глубоких исследований не проводил. Лишь бы хайп был. А мне Claude выдал на его исходник вот такую оптимизацию:
Т.е. я читаю это как признание, что ваш иструмент весьма ограничен и неудобен. Потому что он ищет ошибки только в текущей компилируемой конфигурации. А все остальные сотни возможных конфигураций просто проигнорит.
В это же время Claude сообщает о всех ошибках (какие увидит) независимо от конфигурации сборки.
Так чем ваш инструмент тогда интересен? По поводу MISRA, то коммерческие компиляторы это и так умеют. Да и тот же Claude это сделает влёт тоже.
Где такую галюцинирующую модель нашли? Уже и ChatGPT так не галюцинирует.
В реальности так:
The FreeRTOS kernel was originally developed by Richard Barry around 2003, and was later developed and maintained by Barry's company, Real Time Engineers Ltd. In 2017, the firm passed stewardship of the FreeRTOS project to Amazon Web Services (AWS).
А по существу не понял. В embedded давно, но не припомню чтобы когда-то было нужно мониторить запуск компилятора. Это вообще зачем нужно? Если отвечать будет ChatGPT, то отвечать не надо.
Аналогично, было. Копьютер с таким же объемом памяти , карта GeForce 3070, только процессор I9 Точно также спонтанно выключался без логов и в простое. Так ему любые шамантсва помогали. Вплоть до того что переносили в другое место и он месяц там мог работать нормально. В BIOS-е чего только не меняли. Правда за Gen5 сказать не могу. Карту меняли на RTX2070 Стресс тесты давали и на карту и на процессор. Выдерживал без единого сбоя. Подключали через UPS. Потом через некоторый период ремиссии снова начинает выключаться. Ну вот года 2 так и работает.
Что-то ChatGPT скептически относится к данному методу. Там даже микро изменения температуры создадут невообразимые помехи. Плюс само наличие вибрации мало информативно, информативней вектор вибрации.
А вот если поставить 6D IMU на стойки стабилизатора по типу тех что стоят в шинах , вот это бы резко упростило жизнь сразу.
1. Конфиг сборки не указан — цифры не воспроизводимы
// эти две сборки различаются в разы, а в статье не сказано, какая:
#define TX_DISABLE_ERROR_CHECKING // 3 вызова × шелл _txe_* минус
#define TX_INLINE_THREAD_RESUME_SUSPEND
#define TX_NOT_INTERRUPTABLE
// vs дефолт (всё выключено) + TX_ENABLE_EVENT_TRACE
Плюс грабли: правки в tx_user.h не работают, если библиотека собрана без TX_INCLUDE_USER_DEFINE_FILE.
2. Меряется не то, что в шапке таблицы
TEST1_PRIORITY = 15, TEST2 = 16, в ThreadX 0 — старший ⇒ task1 приоритетнее и не вытесняется:
perf_test_prepare(sid1); // t1
OS_queue_send(...); // task2 ready, НО не вытесняет
OS_evf_get(&TEST1SrvEvf, ...); // ← вот здесь блокировка + switch
// task2: fixCnt() // t2
Строка queue = 0.564 = queue_send + evf suspend + switch. Одна и та же добавка сидит во всех четырёх строках. Фикс — сделать получателя старше:
#define OS_LIBMODE_R // release ← так надо
#define OS_LIBMODE_DP // debug+profiling ← дефолт стартпроекта SEGGER
Отставание ×2–2.5 и +25…110% инструкций — ровно порядок слоя проверки параметров. Вывод «у ThreadX код лучше» недоказан.
4. Вывод сделан по среднему, а джиттер выброшен
mutex, uni: min 0.458 max 0.583 → разброс 0.13 мкс
mutex, разн. ядра: min 0.750 max 2.083 → разброс 1.33 мкс (×10)
Среднее почти вернулось — детерминизм рухнул. Для hard real-time это и есть результат. И 64 прохода на worst case не годятся: нужны десятки тысяч и перцентили, а не min/max.
Мелочи: для мьютекса кросс-ядерно ×3.2, а не заявленные «1.5–2»; SMP-прогон шёл на DRAM 936 против 792 МГц (штраф SMP скорее занижен).
Да , Altium не пишет никаких материалов. Они тупо ставят аббревиатуры : CF-004 - это Copper Foil толщиной округленно 004 PP-022 - это PrePreg толщиной 022
Но в сети точно есть информационный сайт , выглядящий солидно , который указывает, что CF-004 это какой-то инновационный материал. Весь сайт сгенерен AI в прошлом году, когда они еще нещадно галюцинировали. Но есть кто на это покупается.
ctrlX CORE это 64 Bit Quad-Core ARM CPU и 2 Гб RAM
И все ради каких-то 125 мкс
И вы хотите сказать, что будущее вот такое - дорогущие платформы на избыточном софте?
Я же думаю :
Там все это только лишь от того, что код был по любому дороже.
А теперь когда код стал дёшев, они разорятся на таких монстрах.
Ну да, если что не сходится, то надо привлечь магию.
А именно асушника, который способен в doсker запаковать приложение организующее доступ к клемам через K-Line, не выключая runtime и не вынимая ПЛК из рабочей стойки.
Фантастика.
Он там только WEB страничку поменять может и то не факт.
Знаете, CODESYS ведь изначально был сделан под микроконтроллеры с RTOS, а не Линукс. И да, там изначально пользоваетель грузил приложения не пересобирая runtime.
Пересобирать runtime или нет - это очень мелкий ворос.
У меня к примеру сейчас приложение из пары тысяч файлов , они состовляют фреймворк общий для кучи проектов. Я мог бы спокойно его изолировать и сделать из него такой отдельный модуль.
Но мне это не нужно. Зачем мне от себя что-то изолировать?
Я его перекомпилирую каждый день вместе с прикладным кодом.
Благодаря этому он у меня теперь проверен вдоль и поперёк, при любых уровнях оптимизации , при любых раскладах памяти.
А если вы держите runtime как священную корову, к ней не прикасаясь, то сами себя лишаете гибкости.
Кто решил что такой runtime эффективен? Тот кто даже не видел ваши задачи! Нет, runtime можно и должно менять. Теже протоколы, они постоянно меняются. А ведь они в runtime. К кому бежите чтобы там поменять пару команд?
Так что аргумент "зато мы не трогаем runtime" ну совсем не катит.
А некритичным задачам так и вовсе ПЛК не нужен. Он и дорог, и место занимет и потребляет как не в себе.
WEB сервер по HTTPS и всеми поддержками сертификатов у ThreadX не хуже чем в Линуксе.
И еще момент.
В WAGO PFC200 runtime c CODESYS единолично захватывает драйвер шины клемников K-Line. Свое приложение либо должно отключить CODESYS чтобы забрать драйвер и само организовать цикл, либо в runtime химичить мост. И опять ваше утверждение про "зато мы не трогаем runtime" не катит.
Тут еще прикол буквально сейчас я схватил. Claude Fable отказывается работать с исходниками, где просишь сделать защиту доступа к контроллеру.
Т.е. теперь trust zone в Линуксе вне закона для простых смертных. Это еще один повод не лезть в системы с внешними носителями кода.
Просто вы почему-то странно заостряете внимание на "пересобрать, загрузить и заново протестировать".
Как будто в Линуксе не нужно загружать и тестировать. Пересобрать да, если у вас скрипты, то не нужно. Но и реальное время тогда вам не светит.
А если мне не нужно реального времени, то я и планшет могу приспособить под ПЛК и даже терефон. Т.е. это это уже не совсем ПЛК.
Пересборка под RTOS длится секунды.
Не надо думать что подгружаемые исполняемые модули есть только в Линуксе. В ThreadX также есть механизм подгрузки исполняемых модулей. Это не какая-то магия, а довольно примитивный процесс.
И под RTOS можно все подключть позднее. Или хотитет сказать, что изучить сам API Modbus RTU и все опции запуска и их влияние вы под Линуксом быстрее сделаете? Да нет, вы это сделаете это медленнее. Потому что имеете там меньше инструментов отладки реального времени. Потому что вы лишаетесь сквозной отладки.
В жестком реальном времени нужна сквозная отладка от момента вызова файловой операции и до выдачи команды CMD52 на интерфесе SDIO. Иначе месяцами будете ждать ответа вендора и ручками бегать сбрасывать свой контроллер.
В RTOS я могу через трассировку в SWD видеть не то что все вызовы, а все потоки прерываний в реальном времени и не использовтаь при этом никакого инструментального кода.
Про архивы вообще бы не говорил. У вас там такая же SD карта, как и в RTOS. Но ваш драйвер этой карты не вылизан так как они вылизаны под RTOS. Не согласованы каналы DMA, не выставлены приоритеты у этих каналов, не очищено все от избыточности косвенных вызовов и абстракций, не убраны избыточне объекты синхронизации и т.д. и т.п.
SQLite, OPC UA, Modbus-RTU уже давно портированы на RTOS для мелких контроллеров. Им Линукс не нужен от слова совсем.
InfluxDB - требует от 1 Гб RAM-а , это не про Линукс, а про масштаб.
Python и Grafana - в embedded лишние надсройки. ИИ агенты теперь делают графики в каком угодно стиле и формате вообще не привлекая сторонние тулсы на голом css и js
Конверетеры протоколов однозначно на RTOS будут работать быстрее и детерминирование
Подключаться к облакам теперь умеет любой ESP. А Amazon специально для FreeRTOS сделал модуль подключения к AWS. В ThreadX есть спецально под нее модуль подключения к Microsoft Azure IoT. И там есть всё: апгрейд прошивки по воздуху , автоматическое развертывание миллионов дивайсов, телеметрия, управление по MQTT и проч.
Но какие приложения?
Можете назвать что нибудь стоящее, кроме питона , Node-RED, Arduino и прочих интепретаторов-прокладок, необходимость в которых полностью отпадает при наличии агентов прямо пишущих на C.
С вашим понятием "открытости" и Windows можно назвать полностью открытой операционкой.
Потом интересно какой минимальный период цикла поддерживает ваше решение на Линуксе?
На обычном микроконтроллере 240 МГц нормально держать жесткий цикл в 100 и меньше мкс.
Да уж и времена когда для подключения к AWS по MQTT, OPC UA или WEB сервер нужен был Линукс тоже прошли.
Сейчас это достаточно легко делается на обычной легковесной RTOS типа ThreadX
или FreeRTOS.
Современные агенты за пару дней перенесут все нужные стеки на RTOS включая навороченные GUI и базы данных.
Кстати, ПЛК типа WAGO PFC200 не делают на одном процессорном чипе.
Вот у меня такой один убитый лежит :
Тут как минимум два SoC и две разные операционки. И по ходу есть место еще для одного SoC
Убить такие контроллеры достаточно легко. Программа выполняется из DDRAM, грузится из NAND. Куча мест где что-то может пойти не так.
Но они никогда не станут открытыми, потому что в них всегда есть какой нибудь кастомный чип на шине. Их межмодульная шина - самый большой секрет. Проблема еще в том что программу хранимую вне SoC гораздо труднее защитить. А в Европе, к примеру, вступает в силу Cyber Resilience Act. И с ним сделать защиту Линукса ох как нелегко. Придется возится с Trusted Firmware-A или с OP-TEE. А иначе не дадут разрешение на использование нигде.
А с обычным микроконтроллером прожег фьюзы и все! Дело сделано.
Поэтому на мой взгляд надежней ПЛК будет на SoC с интегрированной Flash и RAM с Error-Correcting Code.
Таких сейчас достаточно много дешевых: RP2354 , ESP32-P4 , RA8P1 , STM32N657 ...
Вот за ними-то и вижу перспективы. И дёшево, и надёжно.
А смысл?
Индивидуальный Allan-анализ каждого MEMS врядли существенно повысит точность INS.
Только время будет зря потеряно на тюнинг алгоритмов. Температура и время свое отыграют.
С другой стороны в даташитах и так написаны предельные шумы и девиации.
Проект не слишком сложный
Авторских файлов где-то 300 штук и где-то 170000 строк кода. Но еще 200000 строк кода взято из сторонних проектов.
Решения по установке канала через интренет сторонние и ненадежные. Опирается на собственный открытый сервер в сети. Это сомнительно.
Да , на пару лет тянет.
Но для современных ИИ это неделя работы.
Софт обесценился. Поэтому повсюду его и открывают.
Немного так голословно пишете.
И что такое этот "энтерпрайз" в embedded, не объясните?
Но я вам приведу данные, которые снял буквально сейчас.
Статическими анализаторами никогда не пользуюсь, потому что они дают море ложных срабатываний. Но тут просто для сторонних наблюдателей.
Вот сейчас я запустил такой анализатор от IAR уровня MISRA/CERT, но под присмотром Fable5.
Проанализировал 203 файла 179072 строки кода. Вышло мне это в 3% пятидневного лимита Fable. Т.е. без всяких переживаний план Pro от Claude выдержит сотни таких проверок в месяц. План 100$ , значит проверка обошлась в 1$, и это если работать только на Fable
Что вышло. Статический анализатор C-STAT (не думаю что ваш сильно умнее) выдал 2727 сообщений
Из них 1871 - просто шум макросов. Ну запутался анализатор в макросах.
Потом 660 значимых сообщений. Из них только 17 реальных, Из них только 5 действительно могли привести к сбою программы. Из них только одна проблема могла произойти при реальном сценарии использования.
Вот такова цена статического анализатора.
А вот сам Fable 5 мне весь день исправляет ошибки такие как: гонки задач , распределение приоритетов задач, оптимизация стека, логика автоматов состояний и т.д. и т.п. Не менее десяка проблем логики прикладного кода в день.
Словом думайте.
Хотите могу вам провести анализ всей ThreadX (без middleware).
Прямо здесь, задаром. Вы будете искать своим инструментом, а я своим. И сравним.
Ну да боту зачем-то интересно чем может в embedded помочь PVS-Studio.
Нет, вы просто оскорбляете другого автора, а ваши люди элементарно не могут объяснить ценность вашего продукта.
Давайте по чесному поспорьте с Claude Fable 5.
Это теперь я так понимаю "экзистенциальный" спор. И пока вы проигрываете.
Ценность PVS-Studio тает на глазах.
Мне это интересно только с точки зрения может ли программный продукт такого направления вообще выжить.
Потому что Хабр - это реклама, а не рецензируемый научный журнал.
Автор тяп-ляп и настругал аргументов, никаких глубоких исследований не проводил. Лишь бы хайп был.
А мне Claude выдал на его исходник вот такую оптимизацию:
Ну давайте , сделайте оптимальней.
Т.е. я читаю это как признание, что ваш иструмент весьма ограничен и неудобен.
Потому что он ищет ошибки только в текущей компилируемой конфигурации.
А все остальные сотни возможных конфигураций просто проигнорит.
В это же время Claude сообщает о всех ошибках (какие увидит) независимо от конфигурации сборки.
Так чем ваш инструмент тогда интересен?
По поводу MISRA, то коммерческие компиляторы это и так умеют. Да и тот же Claude это сделает влёт тоже.
Где такую галюцинирующую модель нашли? Уже и ChatGPT так не галюцинирует.
В реальности так:
А по существу не понял. В embedded давно, но не припомню чтобы когда-то было нужно мониторить запуск компилятора. Это вообще зачем нужно?
Если отвечать будет ChatGPT, то отвечать не надо.
Не понял что там можно еще 10% кодить самому?
Если это когда лимиты кончились и надо дотянуть до конца 5-часового интервала?
Аналогично, было.
Копьютер с таким же объемом памяти , карта GeForce 3070, только процессор I9
Точно также спонтанно выключался без логов и в простое.
Так ему любые шамантсва помогали. Вплоть до того что переносили в другое место и он месяц там мог работать нормально.
В BIOS-е чего только не меняли. Правда за Gen5 сказать не могу. Карту меняли на RTX2070 Стресс тесты давали и на карту и на процессор. Выдерживал без единого сбоя. Подключали через UPS.
Потом через некоторый период ремиссии снова начинает выключаться. Ну вот года 2 так и работает.
Ну во-первых, Baseline не устраняет фазовое замирание
А во-вторых, Baseline не существует.
Что-то ChatGPT скептически относится к данному методу. Там даже микро изменения температуры создадут невообразимые помехи. Плюс само наличие вибрации мало информативно, информативней вектор вибрации.
А вот если поставить 6D IMU на стойки стабилизатора по типу тех что стоят в шинах , вот это бы резко упростило жизнь сразу.
Кратко: 4 претензии
1. Конфиг сборки не указан — цифры не воспроизводимы
Плюс грабли: правки в
tx_user.hне работают, если библиотека собрана безTX_INCLUDE_USER_DEFINE_FILE.2. Меряется не то, что в шапке таблицы
TEST1_PRIORITY = 15,TEST2 = 16, в ThreadX 0 — старший ⇒ task1 приоритетнее и не вытесняется:Строка
queue = 0.564= queue_send + evf suspend + switch. Одна и та же добавка сидит во всех четырёх строках. Фикс — сделать получателя старше:3. embOS мог быть слинкован в debug-режиме
Отставание ×2–2.5 и +25…110% инструкций — ровно порядок слоя проверки параметров. Вывод «у ThreadX код лучше» недоказан.
4. Вывод сделан по среднему, а джиттер выброшен
Среднее почти вернулось — детерминизм рухнул. Для hard real-time это и есть результат. И 64 прохода на worst case не годятся: нужны десятки тысяч и перцентили, а не min/max.
Мелочи: для мьютекса кросс-ядерно ×3.2, а не заявленные «1.5–2»; SMP-прогон шёл на DRAM 936 против 792 МГц (штраф SMP скорее занижен).
Да , Altium не пишет никаких материалов. Они тупо ставят аббревиатуры :
CF-004 - это Copper Foil толщиной округленно 004
PP-022 - это PrePreg толщиной 022
Но в сети точно есть информационный сайт , выглядящий солидно , который указывает, что CF-004 это какой-то инновационный материал. Весь сайт сгенерен AI в прошлом году, когда они еще нещадно галюцинировали. Но есть кто на это покупается.