1. Нужна ли для развития микроэлектроники в России и смежных с ней областей инженерной деятельности ассоциация специалистов?

[dxp 34]

22 часа назад, makc сказал:

Вообще да, даже уверен. В области геймдева, веба и мобильных приложений отношение чаще другое. Разработчики, например, не стесняются писать юнит-тесты и стремятся к покрытию тестами кода. Но много ли вы видели проектов для МК, где бы были полноценные юнит-тесты?

С интересом посмотрел бы на юнит тест для таймера или UART'а.

[makc 192]

25 минут назад, dxp сказал:

С интересом посмотрел бы на юнит тест для таймера или UART'а.

Иронию оценил, но речь шла немного о другом. В целом это решается с помощью моков, например, как описано здесь: https://interrupt.memfault.com/blog/unit-test-mocking

Другое дело, что нужно себя сильно заставлять идти этим путем, когда для получения казалось бы того же результата приходится писать в 2.5 раза больше кода. И если в рамках проекта это не требуется (на уровне руководства проектом), то ... никто и не будет этим заниматься. Ресурсов всегда не хватает и умножить сроки на два из-за какой-нибудь мелкой прошивки МК никто не готов, также как мало кто готов нанимать/выделять отдельного верификатора.

Если тема действительно интересна, то смотрите в сторону книги Grenning J.W. Test-Driven Development for Embedded C.

[dxp 34]

МКшные проекты очень тесно завязаны на железо и прочий аппаратный контекст. Симуляциями и программными тестами сложновато будет создавать те реальные кейсы, которые возникают в реальности. При этом запуск ПО как раз и происходит в этой самой реальности, поэтому и отладка идёт на достоверных кейсах. Юнит-тестирование хорошо себя проявляет на сугубо программных вещах - например, реализация алгоритмов. Такие вещи действительно удобно проверять отдельно, и это можно и нужно использовать в проектах на МК. Но по объёму это не доминирует. Целевую же прошивку зачастую проще и эффективнее запускать на реальном железе, тем более, что оно всегда под рукой. Думается, в этом основная причина "перекоса".

[makc 192]

29 минут назад, dxp сказал:

Симуляциями и программными тестами сложновато будет создавать те реальные кейсы, которые возникают в реальности.

Вы этом вы правы и неправы одновременно. ;-) Реальные кейсы при тестировании железа далеко не всегда возникают в реальности. Например, если всё исправно и ничего не отвалилось, то откуда возьмутся таймауты? А они могут быть. Также могут быть и другие сугубо аппаратные проблемы, которых не видно до поры, до времени. И получается есть два пути: вносить все возможные отказы в железо чтобы протестировать эти исключительные ситуации, либо же мокать железо и отлаживать реакции отдельных функций и поведение всей прошивки в целом на модели.

Но повторюсь, очень мало кто этим занимается. Обычно всё заканчивается на доп.проверках в коде и исключении блокирующих ожиданий + сторожевой таймер на самый крайний случай. И оно в таком виде в 90% случаев нормально работает.

[one_eight_seven 3]

1 hour ago, dxp said:

МКшные проекты очень тесно завязаны на железо и прочий аппаратный контекст. Симуляциями и программными тестами сложновато будет создавать те реальные кейсы, которые возникают в реальности. При этом запуск ПО как раз и происходит в этой самой реальности, поэтому и отладка идёт на достоверных кейсах. Юнит-тестирование хорошо себя проявляет на сугубо программных вещах - например, реализация алгоритмов. Такие вещи действительно удобно проверять отдельно, и это можно и нужно использовать в проектах на МК. Но по объёму это не доминирует. Целевую же прошивку зачастую проще и эффективнее запускать на реальном железе, тем более, что оно всегда под рукой. Думается, в этом основная причина "перекоса".

Согласен с @makc, что вы правы и неправы одновременно.

Микроэлектроника, которой вы пользуетесь, проверяется огромным количеством симуляций и программных тестов. ПО, которое используется вами для производства - также. Но да, объёмы и трудозатраты на это колоссальны, и прощают довольно небрежное последующее использование (я сейчас не о вас, и не о вашем подходе, а о сложившейся ситуации вообще). И это нормально.

Также и в разработке firmware, если это нужно, можно подобрать подход и аккуратно выбирать границы абстракций, тогда большую долю программной части можно сделать абстрактной от железа и проверить исключительно программно. Вопрос только в целесообразности.

Более того, и взаимодействие программной части с аппаратной тоже можно поставить на автоматизированное тестирование. Это ещё реже целесообразно, но и такое я видел, в том числе и в России.

[dxp 34]

Мне понятно, о чём вы (оба) говорите. Приходится работать с FPGA, и уже тут подходы иные: отдельные модули целесообразно гонять на верификации, т.к. потом на железе ловить глюки очень затратно, а создать даже не все возможные, но какие-нибудь редкие кейсы для полного проекта на симе зачастую не получается. На МК сам процесс отладки в железе несравнимо проще - тут тебе и отладочная печать, и доступ к потрохам через JTAG/SWD, а рабочие кейсы создаются достаточным количеством испытаний, что обычно намного быстрее организовать (хотя случаи, конечно, бывают разные - иной раз для этого необходимо городить немаленькие и недешёвые стенды).

[makc 192]

10 минут назад, dxp сказал:

На МК сам процесс отладки в железе несравнимо проще - тут тебе и отладочная печать, и доступ к потрохам через JTAG/SWD, а рабочие кейсы создаются достаточным количеством испытаний, что обычно намного быстрее организовать (хотя случаи, конечно, бывают разные - иной раз для этого необходимо городить немаленькие и недешёвые стенды).

Как вы правильно заметили всё сводится к цене ошибки. Если это мигалка светодиодом на МК, то проще отлаживаться на железе и даже если что-то пойдет не так, то будет обидно, но не более того. А если прибор улетел куда-нибудь на орбиту и обновление прошивки невозможно или запрещено? Если речь идёт о системе тормозов в автомобиле и или другом подобном life-critical приложении? Думаю, что тормоза отлаживать на трассе будет немного желающих. ;-)

[one_eight_seven 3]

13 hours ago, makc said:

Если тема действительно интересна, то смотрите в сторону книги Grenning J.W. Test-Driven Development for Embedded C.

Кстати, эта книга у меня уже есть. Лично для меня она оказалась пустой тратой денег.
Да и вообще - это странно книга по TDD без единого рабочего примера. Вся эта эджайловская чушь и так из каждого утюга льётся, но вот рабочий вариант найти - это как алмазы известно где искать.

[makc 192]

5 минут назад, one_eight_seven сказал:

Кстати, эта книга у меня уже есть. Лично для меня она оказалась пустой тратой денег.
Да и вообще - это странно книга по TDD без единого рабочего примера.

Книга о методологии разработки, а не руководство к действию (не методика). Далее выбирается инструментарий и начинается работа...
И да, порог вхождения весьма высок, что ни говори. Так же как и в случае применения UVM, но это уже совсем другая история. ;-)

[one_eight_seven 3]

1 hour ago, makc said:

Книга о методологии разработки

Да, но  я её брал именно посмотрев, что там есть примеры. Потом оказалось, что это всё надо переписывать. Т.е. примеры из книги о разработке через тестирование, не прошли ни одного теста. У меня такое вызывает крайнее недоверие.

Про UVM, как и по SystemC есть разные книги. У меня невыброшенными остались только те, которые я могу дать начинающему инженеру, зная, что эта книга сэкономит мне время, а не отнимет его.

[dxp 34]

12 часов назад, makc сказал:

Как вы правильно заметили всё сводится к цене ошибки. Если это мигалка светодиодом на МК, то проще отлаживаться на железе и даже если что-то пойдет не так, то будет обидно, но не более того. А если прибор улетел куда-нибудь на орбиту и обновление прошивки невозможно или запрещено? Если речь идёт о системе тормозов в автомобиле и или другом подобном life-critical приложении? Думаю, что тормоза отлаживать на трассе будет немного желающих. ;-)

Сделано немало приборов изрядно посложнее мигалки светодидом. Все вопросы выявлены в ходе тестов и испытаний в железе. С успешной последующей эксплуатацией. Что касается отладки тормозов автомобиля, согласен, что на ходу это делать несколько не с руки. Но в этом конкретном случае всё равно необходимо строить стенд, на котором проверять, тестировать, ибо цена вопроса. Программные тесты могут просто снизить стоимость в целом, т.к. помогут выявить ряд ошибок и сократить время использования дорогостоящего сложного стенда. Но предфинальные проверки-тесты всё равно нужно делать на реальном железе.

[makc 192]

2 часа назад, dxp сказал:

Сделано немало приборов изрядно посложнее мигалки светодидом. Все вопросы выявлены в ходе тестов и испытаний в железе.

Как анализировалось покрытие тестов на железе? Вопрос совсем не праздный.

2 часа назад, dxp сказал:

Программные тесты могут просто снизить стоимость в целом, т.к. помогут выявить ряд ошибок и сократить время использования дорогостоящего сложного стенда.

Программные тесты можно сравнить с логическим моделированием, которое используется на постоянной основе при проектировании чего либо на HDL. Они позволяют эффективно решать задачи раннего тестирования, но совсем не отменяют временное моделирование и тесты на реальном железе. Я не испытываю иллюзий, что реальная система имеет свои, специфичные только для нее, физические и временные характеристики, которые никакое логическое моделирование или программный тест учесть не может. Эти методы дополняют друг друга для получения более качественного результата в более короткие сроки.

PS: тесты на железе, про которые вы говорили, проверяли поведение прошивки при ошибках выделения памяти, когда из-за фрагментации кучи malloc начал возвращать NULL? Современные программисты привыкли, что памяти так много, что зачастую даже не проверяют результаты выделения памяти. И это только один пример из многих. Как проверить все эти случаи на железе?

8 часов назад, one_eight_seven сказал:

Да, но  я её брал именно посмотрев, что там есть примеры. Потом оказалось, что это всё надо переписывать.

Повторюсь, это описание метода и принципов, а не инструкция по применению. Примеров таких проблем очень много, взять, например, известную книгу Linux Device Drivers (LDD) - как вы думаете, получится запустить примеры из этой книги в актуальной версии Ubuntu? Некоторые самые простые - да. Но любые более-менее сложные - нет. Однако это не отменяет ценности этой книги.

[one_eight_seven 3]

6 hours ago, makc said:

Повторюсь, это описание метода и принципов, а не инструкция по применению.

Да, мне это понятно. Я методологию знал и до этого. Без примеров эта книга не отличается от любой другой по TDD. Оценить полезность книги для человека, который об этом не задумывался и подобных вещей не делал, я не в состоянии: для этого надо абстрагироваться от собственного опыта и ещё раз её прочитать хотя бы по-диагонали, я к этому пока не готов.

А так - согласен:
Мышки:

- Мудрый филин, нас все обижают! Что нам делать?
- Мышки, станьте ёжиками, у ёжиков есть иголки, их не обижают.
- Но как мы станем ёжиками?
- Вы меня ерундой не беспокойте, это тактика, а я  стратегией занимаюсь.

Изменено 1 июня, 2022 пользователем one_eight_seven

[dxp 34]

21 час назад, makc сказал:

Как анализировалось покрытие тестов на железе? Вопрос совсем не праздный.

 

21 час назад, makc сказал:

Программные тесты можно сравнить с логическим моделированием, которое используется на постоянной основе при проектировании чего либо на HDL. Они позволяют эффективно решать задачи раннего тестирования, но совсем не отменяют временное моделирование и тесты на реальном железе. Я не испытываю иллюзий, что реальная система имеет свои, специфичные только для нее, физические и временные характеристики, которые никакое логическое моделирование или программный тест учесть не может. Эти методы дополняют друг друга для получения более качественного результата в более короткие сроки.

Это всё прекрасно работает  там, где надо отладить алгоритм. Но, например, при отладке работы периферии это делается исключительно путём включения этой периферии в железе и проверки того, как оно работает реально. А это изрядная доля работы с МК. Никакими юнит-тестами это не закрыть, особенно если учесть, что периферийные модули имеют "особенности", зависимые от семейства и ревизии чипа - баги.

 

Другой случай, где я с трудом могу представить себе сугубо программное тестирование: доводилось писать GUI на "голом железе" (МК/Blackfin). Очень хорошо легло на ООП С++: event loop, иерархия классов, методы и т.п. Проверяется это путём запуска: что-то добавил-поправил, скомплилось, залилось в проц, тыкаем на кнопки, наблюдаем правильную (или неправильную) работу. Вполне быстро и эффективно получается. Программный тест, который будет осуществлять нажимание кнопок и анализ отклика GUI, это просто на порядке более сложное и трудоёмкое ПО.

 

Таких примеров можно ещё привести немало, и именно из области низкоуровневого программирования, близко завязанного на железо.

 

Да, в мире HDL ситуация несколько иная - там акценты очень сильно сдвинуты в сторону тестирования, и там это 100% оправдано. Даже при работе с ПЛИС (про ASIC и говорить нечего - цена ошибки огромна, поэтому параноидальное тестирование на всех этапах). За это говорит и наличие и популярность в этой области HDL симуляторов, которые являются весьма недешёвым инструментом, но при этом очень популярным - нет без них жизни в этой сфере.

 

В типовом проекте на ПЛИС 99% (а может и 99.9%) проблем выявляется на симуляторе. Все модули, которые возможно, покрываются верификацией. Финальный проект, который собирает все модули в единую систему тоже прогоняется на симуляторе, но это скорее функциональное тестирование, которое проверяет, что всё подключено, ничего не забыто, не перепутано. На полном проекте уже не реально выловить какие-то хитрые баги. Но они, как правило, есть. И запуск в железе уже выявляет какие-то хитрые кейсы, которые крайне сложно воссоздать на симе.

 

У нас был случай, когда возникала ошибка при прогоне в железе. С помощью ILA и "ловушек" в коде удалось локализовать место - это происходило из-за несогласованности на стыке двух модулей, приём проявлялось только при совпадении четырёх или пяти условий. Модули были по отдельности оттестированы и работали правильно. Воссоздать ситуацию на симе не удалось - для этого нужно было подавать на вход пакеты-задания (там через PCIe скачивались данные для обработки на ускорителе вычислений, реализованном на ПЛИС) с определёнными задержками для отдельных пакетов и их групп. И иногда возникало хитрое наложение, т.ч. на стыке модулей возникала несогласованность и терялось последнее слово пакета. В итоге, чтобы убедиться, что это именно то место, просто сделали останов в симе в нужной временной точке и с помощью force активировали сигнал, который предположительно и приводил к сбою. Всё подтвердилось. Внеслись правки, сим повторили с этими же условиями, корректировка кода показала устойчивость к возникшей ситуации, после прогон в железе подтвердил, что ошибка ушла. 

Наверное, и методами верификации можно отловить подобное - для этого надо гонять на верификации не только отдельные модули, но и их связки. Но это уже увеличение трудоёмкости по экспоненте. Тем более, что заранее не знаешь, какая связка может оказаться проблемной. В проекте десятки модулей, комбинаций их тоже не меньше. Для ASIC дизайна это, возможно (а то и наверняка), оправдано. Но для ПЛИС, имхо, нет. Достаточно довести на симе проект до более-менее стабильно работающего состояния (верификация отдельных модулей, функциональное тестирование всего проекта), после добить уже на проверками на реальном трафике. При прогоне в железе просто пролетают миллиарды пакетов в совершенно непредсказуемых сочетаниях. Никакими тестами на симе это не покрыть. Да и модель хоста на симе описать тоже можно только очень приблизительно, а она очень сложна - у хоста своя "жизнь". 

 

Другая крайность, встречал таких неоднократно, - когда люди отрицают полезность симуляторов и программного тестирования, пишут код и отлаживают в железе (SignalTap, ILA). На это больно смотреть. Ну, и излишне говорить, что сложность проектов там где-то околоначальная. 

 

Для МК же ситуация качественно иная. Уже забыл, когда в последний раз видел симулятор и его использование. Всё отлаживается либо прогоном на реальном железе, контролируемом через эмуляторы и/или отладочную печать - это касается проверки работоспособности программы в целом и всего, что касается периферии, либо отдельные алгоритмические части тестируются в своём отдельном окружении, зачастую это делается даже на другой целевой платформе - РС, т.к. это удобнее и быстрее. Процент такого да, имхо, весьма небольшой для проектов на МК.

 

22 часа назад, makc сказал:

PS: тесты на железе, про которые вы говорили, проверяли поведение прошивки при ошибках выделения памяти, когда из-за фрагментации кучи malloc начал возвращать NULL? Современные программисты привыкли, что памяти так много, что зачастую даже не проверяют результаты выделения памяти. И это только один пример из многих. Как проверить все эти случаи на железе?

Пример, наверное, не очень удачный. Тут больше похоже на ошибку проектирования: в критичных системах целесообразно полностью исключать такие ситуации - фрагментация рано или поздно приведёт к отказу, и спрогнозировать (предсказать) этот случай не реально. Даже если проверять значение указателя, при возврате 0 что делать, когда нажата педаль тормоза и препятствие неотвратимо приближается? Такой ситуации в программе просто не должно быть от слова совсем.

[Arlleex 131]

Как покрыть тестами "плавающий" баг, который может вылезти только через 1000 часов? В тех же ARM Cortex-Mx этого можно добиться, например, "забыв" про выравнивание стека на 8 байт или случайно допустив (непреднамеренно) эту невыравненность. Тесты будут показывать что все ок (алгоритмически), но callstack может выстроиться таким образом, что относительный доступ к какому-либо объекту станет невыравненным и вывалится fault. То же самое касается, к примеру, с виду "невинного" кода, который на самом деле задействует FPU для ускорения действий в исходнике, в котором и намека на плавучку нет. Без грамотно организованной атомарности доступа никакие тесты этого не увидят, ибо не проверяют ассемблерные листинги, да и "натурные" тесты не факт что выстрелят в первую минуту отладки в железе. А как тестировать приложения, в которых важна не только сама логика (или математика) алгоритмов, но и скорость их выполнения, ибо эта скорость может быть определяющей во всей многозвенной цепочке обработки? А как оценить влияние банального месторасположения исполняемого кода в МК (регион ОЗУ/Flash) на детерминизм времени исполнения, если тесты понятия не имеют о том, что, например, DMA не может "достучаться" до региона CCM-памяти, а до обычного ОЗУ - может, и соответственно, может похерить всю временную диаграмму? Ну вот еще говорят, что можно некие алгоритмы отлаживать на ПК, а потом переносить под МК. А кто сказал, что это равноценное тестирование? Как ПК-шная программа протестирует логику работы кода под Cortex-M3, в котором активно используются атомарные операции на LDREX/STREX (да или мало ли чего архитектурно-плюшечного)? Но это еще пол беды - как то самое тестирование поможет гарантировать, что скомпиленный код действительно при этом будет соответствовать ожиданиям? ИМХО, только компилить и глазами смотреть листинг. Увы, только так.

Не верю я в целесообразность покрытия тестами кода под МК. Я десяток раз подходил к TDD под МК, брал примеры "100%-го покрытия" какого-то кода и ломал его. Вывод был железным - раз сломал (тест прошел, а логика нарушена) - значит не место TDD там.