SimpleSoft 0 3 января, 2018 Опубликовано 3 января, 2018 · Жалоба С Новым, уже 2018 годом. Всех благ! Добавлю еще от себя. Мы попробовали двинуться дальше в области качества ПО. Приобрели LDRA пакет вместе с TBManager, TBrun, LDRAcover, LDRAunit. Данный пакет умеет увязывать требования написанные в Word или из JIRA/Polarion с кодом. А также запускать тесты прямо на железе используя JTAG. Более подробно - презентация. Возник попутно вопрос - а что вы используете для отладки кода, когда ещё железо не готово? Отладки спаянные воедино? Может есть софтовые эмуляторы? (как например QEMU) или что-то иное? (Особенно если 60% кода копируется из проекта-в-проект, меняется только приложение) К примеру: есть проект на FreeRTOS который конвертирует аналоговые входы используя алгоритмы в цифру и гонит по Ethernet по спец протоколам. Нужно сделать ещё пару приложений, которые основу имеют туже, но кол-во аналоговых входов другое, уровни другие, выхлодной протокол другой - но железо не готово. Как разрабатывать софт параллельно максимально абстрагируя софт от железа пока оно не готово? Какие при этом риски? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SSerge 4 3 января, 2018 Опубликовано 3 января, 2018 · Жалоба Как разрабатывать софт параллельно максимально абстрагируя софт от железа пока оно не готово? Этом не просто хороший, это отличный вопрос, в нём содержится 100% ответа. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SimpleSoft 0 3 января, 2018 Опубликовано 3 января, 2018 · Жалоба Этом не просто хороший, это отличный вопрос, в нём содержится 100% ответа. Я скорее имел ввиду - возможно кто-то знает техники, как это сделать малой кровью. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 33 3 января, 2018 Опубликовано 3 января, 2018 (изменено) · Жалоба Я скорее имел ввиду - возможно кто-то знает техники, как это сделать малой кровью. Если малой кровью, то "включайте голову", ибо это самый лучший эмулятор, плюс макеты, которые никто не отменял. :rolleyes: Или еще так, пока железо не готово, беру стандартные модули от прошлых разработок, делаю на них основу программы, а когда подъезжает новое железо уже окончательно правлю под него. И время экономится и без дела не сижу.. Изменено 3 января, 2018 пользователем mantech Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Студент заборстроительного 0 3 января, 2018 Опубликовано 3 января, 2018 · Жалоба Я скорее имел ввиду - возможно кто-то знает техники, как это сделать малой кровью. Волшебство в программировании мало распространено "включайте голову", ибо это самый лучший эмулятор +100 Поддерживаю данного оратора :beer: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SimpleSoft 0 7 января, 2018 Опубликовано 7 января, 2018 · Жалоба Спасибо! Про голову, это конечно замечательно:) Но я хочу спросить за конкретику. Может кто-то знает хорошие техники из опыта? Я понимаю, что нужно соблюдать баланс между стоимостью решения для тестирования/отладки без железа и производства реальных образцов. Однако время простоя тоже денег стоит. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 33 7 января, 2018 Опубликовано 7 января, 2018 (изменено) · Жалоба Спасибо! Про голову, это конечно замечательно:) Но я хочу спросить за конкретику. Может кто-то знает хорошие техники из опыта? Я понимаю, что нужно соблюдать баланс между стоимостью решения для тестирования/отладки без железа и производства реальных образцов. Однако время простоя тоже денег стоит. Да никто не скажет про конкретную методику, ибо ее нет таковой, чтоб конкретной. Одно дело тестировать железяку для узкого применения, например привод двигателя или контроллер передачи данных, тут тестирование просто сводится к тому, чтоб устройство работало под полной нагрузкой и не глючило или выходило из строя. Другое дело - устройства, предназначенные для работы с клиентами, например вендинговое оборудование, тут проверить его самому разработчику крайне сложно, даже работникам предприятия, в котором создается сей аппарат, ибо люди уже интуитивно знают, куда "тыкать" можно, а куда нет, поэтому тестирование такой техники возможно только "на клиентах", т.е. на торговой точке. Единственное, что должен сделать разработчик в этом случае - это грамотная система логов при сбоях. Изменено 7 января, 2018 пользователем mantech Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Студент заборстроительного 0 7 января, 2018 Опубликовано 7 января, 2018 · Жалоба Да никто не скажет про конкретную методику, ибо ее нет таковой, чтоб конкретной. Я ему уже сказал "Волшебство в программировании мало распространено" Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kabdim 0 8 января, 2018 Опубликовано 8 января, 2018 · Жалоба Использую gmock+gtest, но как правило тестирую не всю прошивку, а отдельные модули. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
topor_topor 0 18 ноября, 2018 Опубликовано 18 ноября, 2018 · Жалоба "Как разрабатывать софт параллельно максимально абстрагируя софт от железа пока оно не готово?" Для разработки софта до появления железа применяю такие варианты: - Если проект ASIC/FPGA и процессор есть в виде RTL, то создаются напрямую прошивки памяти и симулятся в цифровом симуляторе (аналоговая периферия моделируется в верилоге напр.) - До появления силикона (ASIC) делается FPGA и софт заливается через дебагер (железо процессора конечно должно иметь этот дебагер) - Использую программный эмулятор процессора + модели периферии написанные специально под платформу. Это часть аппаратного дебагера, которая вместо заливки программы в железо симулирует процессор. Такой вариант требует относительно длительного периода создания моделей периферии. Часто используется без моделей периферии. - Абстрагирование от железа достигается например применением RTOS. Т..е доступ к периферии делается через вызов стандартных функций ОС. Или как минимум периферийные адреса прячутся за DEFINE. Плюс пишется более-менее стандартный набор функций (напр. TimeEnable(), TimeSet(), TimeGet() итд.) - Касаемо тестирования софта, на уровне отдельных функций пишутся тести на том-же языке и считается код кавередж. Плюс встраиваются асершены (не компилируются в финальную прошивку) для проверки того что входные данные в рендже, что произошли нужные события итп. Создание и Тестирование софта для больших машин под Win\Unix это отдельная тема... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SimpleSoft 0 7 декабря, 2018 Опубликовано 7 декабря, 2018 (изменено) · Жалоба Время идёт и доработали нашу систему тестирования, моделями QEMU - особенно хорошо для Xilinx Zynq7000 & ZynqMP. Также симуляторы иногда выручают - например Cadence Vision P6 DSP имеет неплохой симулятор. Также ARM Fast models могут быть альтернативой. Изменено 7 декабря, 2018 пользователем SimpleSoft Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
KBH 0 30 октября, 2022 Опубликовано 30 октября, 2022 · Жалоба On 7/27/2017 at 7:52 PM, Николай Семёнович said: Скажу что Ваш начальник ИДИОТ. Даже ГОСТ говорит, что при разработке электронной техники 3 итерации - это норма Чем выше начальник тем дальше он от реальной жизни. И тем меньше он понимает как жизнь устроена и как делаются дела Так что не обращайте внимания на придурков Спасибо, мне только недавно сказали, что этого начальника давно хотели уволить за тупость, да только повода не находили. А надо мной специально поставили. Решили, что я этого дурака выдержу, только не предупредили. И таки выдержал, а его уволили. DCDC на 4 кВт потом допилили всем отделом без спешки. "Всем спасибо, все свободны", как в том анекдоте про начальника концлагеря утром 10 мая 1945. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
