LINUX.ORG.RU

Unit tests для микроконтролеров

 , ,


0

2

Имеем код для микроконтроллеров (stm32f4, tms570). Хочется выполнять юниттесты на самом микроконтроллере. Есть какие-нибудь инструменты? Что-нибудь, что может подергать с большого компа по serial тесты, сгенерировать отчет в стандартном формате итд? Что-то в стиле http://www.ldra.com/en/software-quality-test-tools/group/by-software-life-cyc...

Посмотри инструментарий для верификации кода по DO-178, должно решить твою задачу.

aiqu6Ait ★★ ()
Ответ на: комментарий от shkolnick-kun

Сгенерировано. И такого несоколько мегабайт. Вот к этому еще и тесты можно генерить.

vromanov ★★ ()
Ответ на: комментарий от shkolnick-kun

Просто не надо использовать всякое UB и недокументированный функционал.

Библиотеки к DSP тоже не использовать? И модули микроконтроллеров всегда работают, как в даташите, а не как в Errata?

И да, анонимус дело говорит, в автопроме надобно Ada + SPARK использовать ибо кошерно!

Ссылочку на стандарт можно?

aiqu6Ait ★★ ()
Ответ на: комментарий от aiqu6Ait

Отбой, DO-178 это авиация, а у тебя автопром. Но у тебя в автопроме должны быть свои стандарты, с рулевым колесом и запаской, поищи, под них (и к правильным микроконтроллерам) уже есть готовый инструментарий.

aiqu6Ait ★★ ()
Ответ на: комментарий от aiqu6Ait

Библиотеки к DSP тоже не использовать?

Использовать, только смысла в автотестах нет, если ты не автор библиотек.

И модули микроконтроллеров всегда работают, как в даташите, а не как в Errata?

Нет, конечно.

Ссылочку на стандарт можно?

Конечно и не только на стандарт.

shkolnick-kun ★★★ ()
Ответ на: комментарий от shkolnick-kun

Чет я не понял причину твоего бугурта, ну да ладно... Вроде и сам пишешь что написал на компе запустил на stm8 и увидел что всё точно так же. Потому протестировав код на ПК можно быть уверенным на код МК, или я ошибаюсь? Если ошибаюсь, то прошу адекватно скорректировать :)

И да, верно говорят про модули МК, которые невозможно эмулировать на ПК.

I-Love-Microsoft ★★★★★ ()
Последнее исправление: I-Love-Microsoft (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Отвечу, как ВВП:

Их там нет!

Но в последние месяц-два я осознал, что профессия имбеддера вымрет в привычном мне виде в течение ближайших нескольких лет.

То есть профессия как таковая будет, но количество олдскульных рабочих мест сократится на порядки.

Почему?

А вот, почему:

http://www.eluaproject.net/

http://nodemcu.com/index_en.html

https://micropython.org/

https://www.zerynth.com/

Почти любая веб-макака сможет вкатиться в имбед.

Соответственно ищу, куда перекатиться, пока думаю начать осваивать Ada для души и Java/C# для тела...

shkolnick-kun ★★★ ()
Ответ на: комментарий от I-Love-Microsoft

Если ошибаюсь, то прошу адекватно скорректировать :)

Если не писать всякие там синтезаторы частоты на переполнениях uint16_t, и прочем UB и недокументированных фичах/багах тулчейга/библиоткек/аппаратуры, то вполне можно обойтись юнит-тестами на ПК.

Во всяком случае, если дело касается средних и верних уровней софта.

В случае драйвером аппаратуры да, тесты нужны, но нафига их прогонять постоянно?

У вас часто обновляются модули микроконтроллера?

shkolnick-kun ★★★ ()
Ответ на: комментарий от shkolnick-kun

в автопроме надобно Ada + SPARK использовать ибо кошерно!

расскажи о своем опыте использования SPARK.

сам не использую, но слышал, что круто

Окей.

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от shkolnick-kun

думаю начать осваивать Ada для души и Java/C# для тела

Просто прими свою тайную порочную страсть: ты хочешь писать на крестах.

anonymous ()
Ответ на: комментарий от vromanov

Вот к этому еще и тесты можно генерить.

Ага.

Степень ответственности БОЛЬШАЯ. Я, блин, сдохнуть могу если он плохо отработает. И не только я.

Понял, тесты нужны для системы менеджмента качества, то есть чтобы показать аудиторам/ревизорам во время сертификации красивенькие отчеты с графиками и таблицами?

shkolnick-kun ★★★ ()
Ответ на: комментарий от vromanov

Если это не нужно непосредственно для бизнеса, то можно адаптировать OpenSource, но костылить придется самим...

shkolnick-kun ★★★ ()
Ответ на: комментарий от shkolnick-kun

На стандарт, который предписывает использовать Ada или SPARK. Иначе похоже на танцора, которому вроде как сцена кривая, а на самом деле яйца мешают.

aiqu6Ait ★★ ()
Ответ на: комментарий от aiqu6Ait

iso 26262 есть, под него есть инструментарий, смотрели? Я только по аналогии могу подсказать, мы с DO-178 работаем.

aiqu6Ait ★★ ()
Ответ на: комментарий от vromanov

Ого, какая штучка.

В таком случае, для тестов лучше наколхозить бутлоадер по типу ардуины и не париться с этими дорогими мокрыми письками.

anonymous ()
Ответ на: комментарий от anonymous

А в чем разница, если серьезно? Кривожопы на Аде напишут как попало, нормальные пацаны на крестах ровно пишут.

aiqu6Ait ★★ ()
Ответ на: комментарий от anonymous

ИМХО, дебажить таки лучше через отладчик + отладочный интерфейс, который должен быть во всех модулях прошивки. Потому что иногда (у меня - всего пару раз) под отладчиком работает код, который не работает без него.

aiqu6Ait ★★ ()
Ответ на: комментарий от aiqu6Ait

нормальные пацаны на крестах ровно пишут.

Красивым почерком, ага.

tailgunner ★★★★★ ()
Ответ на: комментарий от fsb4000

Строго говоря, по причине наличия разрешённых стандартом undefined behaviour и отсутствия наличия гарантий что этих самых случаев undefined behaviour в коде нет, то юнит тестирование на C или C++ имеет весьма ограниченный спектр применения.

Например, проверить отсутствие неадекватности поведения кода при неадекватном инпуте невозможно. Тесты могут не валиться. А раз так - то и смысла в пуризме нет. Если свалится на живом железе тест в полнолуние третьего солнца, то и замечательно.

dzidzitop ★★ ()
Ответ на: комментарий от dzidzitop

Охренеть! У вас наверное вышел приказ - «писать без багов!»

vromanov ★★ ()
Ответ на: комментарий от vromanov

нет. эти мысли возникли при попытках писать юнит тесты на C++ код, который тестирует граничные случаи. корректное поведение алгоритмического кода (что сортировка сортирует итд) проверить юнит тестами более менее на C++ можно. стрессовые случаи (типа что будет если передать nullptr и size = 0 в sqlite3_bind_text() ) - нет, ибо если код не завалится, то это ничего не означает.

dzidzitop ★★ ()
Ответ на: комментарий от vromanov

Имеем код для микроконтроллеров (stm32f4, tms570)

stm32f4, tms570

KivApple ★★★★★ ()
Ответ на: комментарий от aiqu6Ait

Ну я какбе на Си-шечке сейчас пишу в основном. Так что со сценой все в порядке, и с яйцами тоже :)))

shkolnick-kun ★★★ ()
Ответ на: комментарий от aiqu6Ait

Разница в том, что человек делает ошибки, всегда, вообще всегда...

Даже когда он думает, что он ровный пацанчег...

А у таких языков, как Ada, Pony, Rust компилятор берет на себя проверку кода на наиболее частые ошибки, если не обходить ограничения, накладываемые компилятором, то вероятность совершения ошибок по невнимательности резко падает.

shkolnick-kun ★★★ ()
Ответ на: комментарий от shkolnick-kun

вероятность совершения ошибок по невнимательности резко падает.

бу-га-га

anonymous ()

Набираю на работу человека на решение этой и других задач.

vromanov ★★ ()
Ответ на: комментарий от vromanov

Пишу в некротред, но он по теме.

Вы не решили свою проблему? Если да, то хотелось бы узнать как.

Anvladislavmf ★★ ()
Ответ на: комментарий от vromanov

Качество звука в видео то еще, но понятно, что говорите. Спасибо за него. А как вы получаете результат тестирования? Мне интересно то, как вы понимаете, что тест пройден(или нет) и что вы считываете по RS-232 или USB. Хотелось бы узнать по-подробнее, если не затруднит.

Anvladislavmf ★★ ()
Ответ на: комментарий от Anvladislavmf

если все в порядке, то тест просто выдает !OK. Если ошибка, то !ERROR. Другой вариант - таймаут ответа. Это происходит по двум причнам - тест завис, тогда плата будет перезагружена и тест будет повторен еще раз. Либо просто ошибка в передаче данных по rs-232 - тоже повтор. Ну и тесты выдают в консоль сообщения об ошибках и другую отладочную информацию

vromanov ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.