Комментарии 49
ТС открыл для себя эмуляторописание? Ну я последние 20 лет писал разные эмуляторы для разных CPU и MK. Первый писать было интересно, а теперь рутина необходимости.
FreeRTOS имеет порт под Винду. Пользовался, нормально работает. Учитывая, что мой проект изначально кросс-платформенный и написан на С++, дополнить его таймерами и UART под Винду оказалось делом не сложным. Собственно, для того FreeRTOS по Винду и занесли, чтобы делать то, о чём написал ТС.
мой проект изначально кросс-платформенный и написан на С++, дополнить его таймерами и UART под Винду оказалось делом не сложным.
То есть у вас тоже Run-Time работает по Виндой? Я правильно понимаю?
У меня статья про это была
Да. Нужно было разобраться со сторонним протоколом, поэтому оказалось проще занести свой проект с STM32 по Винду и там это всё раскрутить.
А началось всё с I-7188. Там вообще всё делалось под Виндой, а потом просто перекомпилировалось под MiniOS7. Ессно, была библиотека классов, работавшая и под Вынь, и под MiniOS7. Потом эта библиотека стала работать под AVR, а сейчас и под STM32.
надо же эти штуки: I-7188
компактные контроллеры серии I-7188 ... хорошо подходят для построения систем с несложным алгоритмом управления
дороже простенького ноутбука, не говоря уже о маленьких системных блоках
Они на 80188. Вроде, уже должны быть сняты с производства, но до сих пор доступны. Сейчас все переходят на ARM, так что, наверно, дни 80186/80188 сочтены. Да и ценник на них не маленький.
RISC-V неизбежен https://youtu.be/1zLxxxLc0xI?t=126
Вот поэтому я и пишу, строго отделяя логику от работы с "железом".
получается, что для работы с железом логика не нужна?
как-то вы не подумав написали, мне кажется.
Вы же когда пишите в своей программе printf( "Hellow, World!\n") не задумываетесь о том, куда подключен поток вывода и на каком устройстве будет отображено сообщение? Почему не задумываетесь? Потому что логика работы программы, выдающей сообщение, отделена от логики работы с "железом", принимающим и отображающим сообщение.
наверно я упустил из виду одну важную вещь. Мы проверяем не свой код, мы сами ничего не пишем, хотя даем рекомендации что писать или что исправить.
Относительно вашего примера наша задача как раз в том чтобы сказать, например:
у вас вот написано
printf( "Hellow, World!\n")
в такой-то строке, но это сообщение не доходит вот туда-то, и желательно причину указать почему оно не доходит, а еще лучше код предоставить который это фиксит.
или это сообщение в этом месте в это время нарушает работу другой системы...
конкретно эту модель снимать похоже никто не собирается: в каталогах и сертификаты от 2024 года, обновления 2022-2023 года. А софт кто переписывать будет, его могут быть огромные количества...
При этом для такого функционала хватает ESP32, внутри может быть даже эмулятор 80188
особо обращает внимание на то что образ ОС занимает 64 Килобайта и там даже немного свободного места есть
Не то что бы прям плохая идея, но пока сделаешь все эти эмуляции либо уже все косяки в системе и так станут понятны, либо произойдет столкновение с жестокой реальностью. Тут железо вынесено за скобки, но в нем проблем может быть не меньше чем в основном коде, и все равно решение будет половинчатое.
Как говорили в узких кругах: эмулятор - это первый шаг к резиновой женщине :)
Тут железо вынесено за скобки, но в нем проблем может быть не меньше чем в основном коде
ну мы вроде как раз воспроизводим-моделируем логику работы железа в модулях которые создаются как окружение для тестируемого кода. Собственно эта логика тоже проверяется, тестируется, диагносцируется в нашей системе. Наверено я не смог это достаточно раскрыть в статье, но там очень много специфики и проприетарного контента, очень не удобно об этом писать.
так я про это "воспроизводим-моделируем логику работы железа ". Есть хотя бы гарантия что это железо нормально работает и соответствует эмулиремому?
ну а как же? Конечно есть гарантия, тесты идут и на железе и на симуляторе, любая разница анализируется и оперативно дорабатывается. Иначе все это смысла не имеет.
А теперь пришли к тому что под новое железо создается-добавляется модель на симуляторе и код, соответственно, дорабатывается на симуляторе для работы с этой новой функцией. При наличии существующего опыта и наработок это уже не так сложно. И в конечном итоге, все равно, все проверяется на реальном железе. В режиме подтвердить результаты проверенные на отлаженой-отработанной модели работа идет в разы эффективнее.
Трудозатраты на разработку эмуляции и на работу с реальным железом сравнивались?
Это очень сложный вопрос как это измерить, дело в том что мы пришли на проект как тестировщики, и нам надо было вникать и в работу софта и в работу железа с которым этот софт работает, а еще анализировать примеры сохраненного трафика в файлах, собственно изначально система симуляции разрабатывалась как способ изучения аппаратно-программной системы и потоков данных из этой системы во всех ее проявлениях.
Поэтому система симуляции (или эмуляции) она не только снижает трудозатраты на отладку в реальном железе, она много чего еще дает.
Я абсолютно уверен в том что она делает процесс разработки во всех его проявлениях более эффективным, мне кажется затраты окупаются, тем более это делалось за зарплату которую разработчики в любом случае получали. Фактически можно сказать, что для фирмы затрат дополнительных не было.
А зачем вам прямо эмулировать железо? Тут же задача в первую очередь подтвердить что софт работает так как должно, по крайней мере как я понимаю из статьи. По сути автор просто написал обертки для системных вызовов с тем же интерфейсом что и в rtos.
Такое очень полезно в больших проектах, чтоб автотесты бизнес-логики делать. Вот, например, в НАСА написана своя абстракция для этих целей - Operation system abstaction layer. Представляет собой библиотеку, статически изолирующую системные вызовы, предоставляя совместимый интерфейс. В рамках нее можно отрабатывать довольно сложное поведение систем прямо в линуксе, вообще без железа на столе. Поведение железа при этом эмулируется в любом удобном виде, а использование cmake позволяет в любой момент сменить тулчейн и использовать другой компилятор и другой код непосредственно разговаривающий с железкой. Довольно удобно
А зачем вам прямо эмулировать железо?
Поведение железа при этом эмулируется в любом удобном виде
Отличный вопрос содержит в себе ответ :) В любом удобном виде это хорошо, но надо чтобы это не расходилось с реальным железом, поэтому возможны нюансы
Я не знаю как у вас, но у меня чаще всего бывало так, что довольно значительная часть кода проекта собственно с железом никак не связанна. Например какой-нибудь тестовый стенд собирает данные, сохраняет отчет на флешку. То как он соберет данные это важно, тут никаких вопросов, но вот отлаживать сохранялку в файл прямо на микроконтроллере откровенно запарно. Или коммуникация - работа с драйвером железозависима и не может не отрабатываться на нем, но форматы сообщений и протоколы высокого уровня очень удобно писать в платформонезависимом виде и проверять вот в таких вот эмуляциях. Железо в этом случае просто прячется за моком, сильно подробно копировать его поведение, в данном случае, не нужно, только проверять нужные тестовые сценарии.
При этом в такой модели разработки никто вам не запрещает подробную симуляцию железа и проверку непосредственно кода драйверов и других плохо изолируемых компонентов, тогда можно проводить действительно подробную верификацию софта в таких режимах, которые в железе повторять запарно или просто дорого. Это я собственно и имел ввиду под "любым удобным видом", хотите детализируете, хотите проверяйте только библиотеки которые могут быть платформонезависимы.
Тут же задача в первую очередь подтвердить что софт работает так как должно, по крайней мере как я понимаю из статьи.
код обрабатывает сигналы-сообщения-данные которые приходят из железа, в том числе в ответ на операции управления этим железом, поэтому важно в первую очередь проверять код в рамках такого взаимодействия. Мы стараемся максимально точно воспроизвести сигналы-сообщения-данные которые приходят из железа, в том числе в ответ на операции управления этим железом, это позволяет в том числе верефицировать насколько правильно-корректно спроектированно-реализовано железо и само взаимодействие между кодом и железом. Это позволяет в разы сократить время отладки на реальном железе, сделать эту работу более предсказуемой. Фактически работа с железом переводится в разряд: подтвердить результаты полученные в симуляции с моделями алгоритмов реализованных в железе.
Вы изобрели HIL (Hardware-in-the-loop) тестирование, без которого сейчас не обходится ни одна разработка в automotive для систем требующих чуть больше надежности чем infotainment.
Ничего не понял, как запустить проект ртос под виндой!?
Отлаживать код embbeded firmware на PC - это стандартный способ ускорить разработку.
Уже издавна такие IDE как Keil или IAR поддерживают симуляцию кода ARM Cortex M практически в реальном времени.
Т.е. не важно есть там RTOS или нет, в IAR вы все просимулируете на PC без всяких модификаций софта. RTOS-ам из аппаратуры нужен только таймер для тиков. Он симулируется достаточно просто.
Но бывает что просимулировать надо быстрее чем это выполняется на embedded платформе или в симуляторах Keil или IAR.
И тогда да, стоит портировать софт на Windows.
Я так делал для своей файловой системы.
Но идею RTOS портировать вместе с приложением я нахожу странной.
Если RTOS нужна для жёсткого риалтайма, то нельзя на PC до такта точно воспроизвести все процессы. Т.е. жесткий риалтайм не удастся проверить на PC. Дидлоки и заторы там просто не заметите и не воспроизведете.
Я много работал с обработкой звука на embedded платформах. Да, алгоритмы сжатия, парсеры протоколов симулируются на PC и RTOS там не нужна. Но целостность аудиопотока в среде RTOS отлаживается строго на целевой платформе.
Но могу понять если RTOS дана в виде закрытой библиотеки и нет полной ясности в работе ее сервисов. Вот тогда стоит конечно запускать ее на PC просто чтобы поисследовать.
Segger, насколько знаю, любит так предоставлять свою RTOS.
Если RTOS нужна для жёсткого риалтайма, то нельзя на PC до такта точно воспроизвести все процессы. Т.е. жесткий риалтайм не удастся проверить на PC. Дидлоки и заторы там просто не заметите и не воспроизведете.
Интересно, что бы вы сказали если бы увидели систему с достаточно жестким риалтаймом, которая все-таки работает на РС? Мы как раз воспроизводим и диагносцируем на ней дидлоки и заторы, которые на железе очень редко воспроизводятся, в том числе.
Я работаю и с системами симуляции в енвайронментах с кросплатформенной компиляцией, это другой способ построения симуляции.
Я думаю при ближайшем рассмотрении вы согласитесь что с точностью "до такта точно воспроизвести все процессы" нельзя даже в двух разных прогонах (запусках/сессиях) сценария на целевой embedded платформе, всегда есть какой-то разброс по периодам синхронизации, этот разброс вполне себе воспроизводится на ПК, хотя конечно требует некоторых не тривиальных решений для такого воспроизведения а также для идентификации и измерения параметров разброса на целевой платформе.
Я думаю при ближайшем рассмотрении вы согласитесь что с точностью "до такта точно воспроизвести все процессы" нельзя даже в двух разных прогонах (запусках/сессиях) сценария на целевой embedded платформе
На embedded платформе проблема с RTOS и аппаратурой воспроизводится в течении нескольких минут. Тот же конфликт каналов DMA или DTC или WDT. Ну можно на сутки поставить отладчик с трассировщиком и словить баг.
Но это будет реальный баг. А на PC в основном будут фантомные баги.
А во-вторых, множество аппаратуры просто невозможно эмулировать, поскольку она не описана в даташитах в достаточном объёме. Те же копресcоры JPEG. Или стек Wi-Fi.
Или любой другой стек внешнего модуля.
В-третьих, если вы уже так исследовали аппаратное обеспечение, что знаете все тайминги и все статистики, то зачем вам вообще симуляция и отладка? Они же и делаются чтобы это всё узнать.
Словом причинно-следственные связи в статье как-то не раскрыты.
множество аппаратуры просто невозможно эмулировать, поскольку она не описана в даташитах в достаточном объёме. Те же копресcоры JPEG.
Мы эмулируем только ту аппаратуру на которую есть описание, остальная симулируется через ее внешнее поведение. Проблемы мы воспроизводили в основном связанные с софтом, взаимодействие задач, проблемы с буферизацией... . У нас даже аудио декодеры софтварные, потому что их несколько и они могут добавляться..
То что
Словом причинно-следственные связи в статье как-то не раскрыты.
это я согласен, к сожалению я не могу глубоко в технические вопросы погружаться для илюстарации реализованной концепции, а без этого, действительно какая-то куцая статья получилась. Но мне в любом случае надо было сохранить описание хоть в таком виде, хотя бы, даже для себя.
Я конечно не знаю инструментов и платформ с которыми вы работаете, но скажу по своему опыту.
На платформах с ARM Cortex-M4 и выше отлаживать сложные алгоритмы в IAR на целевой платформе проще чем в том же Visual Studio или RAD Studio на PC и уж тем более в Eclipse
В основном благодаря уникальной гибкости брекпойнтов , трассировке и плагинам под RTOS.
Я давно не смотрю в сторону симуляции. Симуляция на PC уже слаба по сравнению с реальной отладкой на железе с быстрым SWD и трассировочным интерфейсом. Но опять же, если речь идет не о статистическо-теоретических исследованиях. Для этого предпочитаю MATLAB. Там есть полный набор блоков симуляции сервисов стандартной RTOS.
если речь идет не о статистическо-теоретических исследованиях.
речь фактически идет о том что десктоп платформа становится одной из целевых платформ, то есть код который работает на ARM Cortex-M7 (в нашем случае) портируется для работы на i7 (i5, ... например) в неизменном виде. Код же С-шный он не зависит от типа процесора, поэтому мы создаем условия чтобы код работал на i7, абсолютно в тех же условиях как когда он работает на АРМ, код видит те же регистры, прерывания, пользуется тем же интерфейсом РТОС хотя работает он на i7.
При этом ресурсов производительности на многоядерном процессоре достаточно в том числе чтобы программно симулировать паралельную работу аппаратной части, например алгоритмов декодера турбо кодов, интерливера, дисперсера, скрамблера которые в свою очередь обеспечивают правильную работу прерваний, и своевременное обновление данных в симулируемых регистрах памяти ввода вывода.
Конечно реализация симулируемых алгоритмов аппаратной части будет отличаться от их-же реализации (на VHDL например) в железе, но сам по себе алгоритм мы можем проверить, и можем проверить его взаимодействие с кодом который принимает и обрабатывает данные после этого алгоритма. Реализация алгоритма турбо декодера на чистом С (даже С++) позволяет запускать этот алгоритм в реальном времени и обеспечить любые возможности диагностики самого алгоритма и его взаимодействия с кодом следующего уровня. В такой схеме мы даже время можем остановить и симулируемый код этого не заметит, а можем запомнить последовательность временных интервалов, которая ведет к сбою и раз за разом ее воспроизводить, пока не поймем причину сбоя.
Вряд ли то что реализовано в Матлабе может работать в реальном времени и в таком режиме.
Код же С-шный он не зависит от типа процесора,
Ну это же очевидная неправда. Посмотрите проекты кросс-платформенного кода, он весь будет напичкан макросами, которые подставляют разные куски кода в зависимости не то что от платформы и процессора , а просто от смены компилятора.
И это самое главное зло. Код под другую платформу всегда другой.
А так конечно, вы тестируете теоретические алгоритмы так же как и я, как и все, на более быстрых платформах чем целевые. Им не нужно реальное время им нужно гораздо более быстрое время, чтобы сократить время тестирования.
И MATLAB это обеспечивает поскольку переводит модели в нативный код процесcора PC.
Но вопрос был зачем понадобилось портировать этот код вместе с RTOS?
Поскольку RTOS нужна для реального времени, а не для ускоренного.
RTOS борется за жёсткость, когда все вокруг тормозит и лагает. Такое на PC просто невозможно воспроизвести. Вы даже лаги SD карт не сможете воспроизвести на PC, поскольку PC читают карты совсем другими драйверами совсем с другими буферами памяти.
Но вопрос был зачем понадобилось портировать этот код вместе с RTOS?Поскольку RTOS нужна для реального времени, а не для ускоренного.RTOS борется за жёсткость, когда все вокруг тормозит и лагает.
Ну вы просто игнорируете то что я уже много раз повторил, у нас система работает в реальном времени - это многократно проверено-подтверждено-измерено. Как на АРМ платформе в код приходят прерывания одного типа три раза в секунду, другого типа 2.5 раза в секунду от аппаратного приемника, так и на десктопной платформе они приходят с той же частотой, и все таймеры и счетчики отрабатывают с правильными периодами, переключения задач контролируется Windows, но оно тоже вполне соответствует тому как это происходит на АРМ платформе. Я понимаю что в это сложно поверить, но оно у нас уже несколько лет работает таким образом и позволяет проверять адекватно изменения в ембедед коде прямо на ПК. У нас тоже никто не верил, что это возможно пока оно не заработало, а теперь на любой вопрос есть стандартный ответ: "А давайте посмотрим как эта ситуация отрабатывается на симуляции" и это, действительно, всегда является ответом, а если не ответом сразу, то способом получить этот ответ.
Действительно (само собой) некоторые дефайны или аппаратно зависимые функции пришлось переопределить, так же как и функции для обращений в РТОС пришлось переопределить, регистры пришлось отобразить на ОЗУ, но это не затрагивает основные алгоритмы работы с задержками, с прерываниями, с переключением задач, ... и поэтому все это создает картину совершенно адекватно отражающую реальность реального времени в другом железе.
Потом дажеесли мы находили какую-то разницу по временам во врем исполнения - это было очень полезной информацией само по себе, вообще говоря это всегда приводит к вопросу на какой аппаратной платформе это работает правильно? - то есть где это фиксить чтобы привести в соответствие поведение на разных платформах.
у нас система работает в реальном времени - это многократно проверено-подтверждено-измерено
Да, но доказательств то нет.
Нет даже демонстрации экспертизы по части доказательств. Не названы даже инструменты, чтобы соотнести ваши утверждения с реальностью.
Три раза в сек - это не реальное время во встраиваемых системах на Cortex M7. Такое на Arduino уместней делать. Либо вы сильно преувеличили комплексность вашего софта.
Три раза в сек - это не реальное время во встраиваемых системах на Cortex M7
там два разных прерывания по три раза в секунду + два других по 2.5 раза в секунду
итого 2*3 + 2* 2.5 = 11 прерываний в секунду, прерывания могут накладываться. По этим прерываниям приходит примерно 2.5 Мега байта данных в секунду из которых надо извлечь до 1000 стримов с аудиоданными или с данными описания аудио каналов для навигации по ним.
Еще есть прерывания от интерфейса управления (собственно команды навигации, запрос информации по существующим каналам), есть управление аудио выходом + работа совтового аудио-декодера, несколько видов буферизации, ну всякая мелочь которую не вспомнишь на вскидку, типа контроль температуры, частоты PLL, ....
Но аппаратная система действительно сделана с запасом - я измерял бывают моменты когда процессор остается не загружен, и в среднем свободного времени процентов 30% есть точно, но это не значит что когда например накладываются прерывания не существует проблем.
Да, но доказательств то нет.
тут я согласен, если что-то и можно назвать доказательством то только косвенным, но вряд-ли можно предоставить что-то другое без глубокого погружения в техническое описание задачи. Могу вприватном режиме маленько больше рассказать, если интересно. Мне интересно кому то доказать-обосновать жизнеспособность концепции, это дает мне возможность подготовиться к вопросам которые постоянно возникают, так или иначе.
Не раскрывать свои секреты не надо.
Но вот это я не понял:
По этим прерываниям приходит примерно 2.5 Мега байта данных в секунду из которых надо извлечь до 1000 стримов с аудиоданными или с данными описания аудио каналов для навигации по ним.
Пакетов такого размера не бывает, значит что-то на низком уровне принимает мелкими блоками и собирает это в памяти. Значит что-то там прерывается гораздо чаще и использует DMA по ходу. Кто это тестирует или симулирует? Что там за интерфейс SPI, SDIO, USB...?
Потом что значит 1000 стримов. У вас есть 1000 динамиков для их одновременного воспроизведения? Или все же речь об однократном парсинге списка доступных стримов и размещении его в массиве?
Так сколько же каналов воспроизведения в реальности у вас?
Пакетов такого размера не бывает,
это не Wi-Fi, это радио, я не буду писать ключевое слово и сигнал идет только на прием, радио на гигагерцах (также как wi-fi, поэтому я посчитал возможным подменить), в полосе 10-20 Мега герц вполне убирается что-то около 300 килобайт за треть секунды, и это один ОФДМ пакет в такой полосе на сколько я понимаю, я же там написал, турбодекодер, деинтерливер...
для справки там задержка до начала поступления данных после включения доходит до 12 секунд, пока все забуферизируется.
Сам приемник и его продуктовый алгоритм конечно тестируется отдельно, на всяких Руде-Шварцах и не знаю еще как, я про это только слышал, но я теорию знаю маленько. У нас для симуляция урезанная (так скажем) копия только для цифровой части, но вполне адекватная.
Динамик один обычно - это же радио, у вас есть много - сотни каналов, но слушаете вы один в каждый момент времени но у вас есть навигация, текстовые каналы могут отображаться одновременно со звуком, понятно. а! вот еще, вспомнил активность: анализ ключей подписки и соответствующее декодирование - тоже целая система.
Фишка того радио в том что у вас постоянный набор каналов на всем континенте и устойчивый везде прием в горах, в лесу, в пустыне и в каньоне :), а не как у нас отъехал от города и каналы пропали, а потом поменялись.
Вы как будто описываете приемник DAB+ типа SAF360x
Если так, то там для микроконтроллера совсем мало работы остается. Даже аудио-кодек в самом приемнике SAF360x есть.
Знай только по SPI принимай поток и отделяй аудиоканалы. Причем поток довольно медленный - 2 по 1.8 Mbit/s
Нет не вижу преимуществ отладка на PC. Вы просто лишаетесь уникальности брекпойнтов движка CoreSight.
Но если демультиплексор и парсер реализованы в MATLAB, то тогда другое дело.
интересно как у вас мысль работает, как будто вам обязательно все надо свести к тому, что вы знаете, как будто то, что вы не знаете не имеет права на существование.
Так не наводите тень на плетень. Сказали бы сразу что у вас не реальное время. Что можете работать с задержками в десятки секунд. Что работа в основном связана с парсингом.
А то интерливеры, турбокоды....
повторю еще раз, система работает в реальном времени, аудио декодируется на лету, аудио-декодер переключается тоже на лету при переключении канала (ААС, МР3, ... ), одновременно идет отображение текстовой и даже графической информации по активному каналу и по всем доступным каналам + может быть доступна некоторая текстовая трансляция параллельно + декодирование шифрования в коммерческих целях. Задержка в десятки секунд это задержка на прохождение данных в аппаратном декодере, которая связанна в основном с тем что данные из разных периодов общего потока данных перемешиваются, и с тем что пакеты в которых передаются данные очень длинные, пока не будет принят целый пакет, он не может быть декодирован, ембеддед софт эту задержку не видит, для него это задержка той же природы, как задержка связанная с распространнением сигнала в эфире.
DAB+ описывать не надо. Он подробно описан в Википедии.
Но ясно одно. Контроллеру есть куча времени для парсинга и переключения на другой канал. Это не реальное время.
Потом декодингом ААС, МР3 занимается приемник, а не микроконтроллер. Парсинг текстовой информации из потока DAB+ это занятие проще чем парсить HTTP.
Таким парсингом с расшифровкой на основе сертификатов и выводом графики между делом могут заниматься даже приводы сервомоторов.
Это не то что требует усилий по портированию RTOS и всего окружения на PC, чтобы там нарваться на собственно баги самих симуляторов.
Можно ли запустить ембедед С-проект на базе РТОС в режиме симуляции под Windows?