Перейти к содержанию

    

SimpleSoft

Участник
  • Публикаций

    274
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о SimpleSoft

  • Звание
    Местный

Контакты

  • Сайт
    http://
  • ICQ
    0

Посетители профиля

3 506 просмотров профиля
  1. Вышел наконец 64-битный ARM у TI TI AM6548
  2. Спасибо! Про голову, это конечно замечательно Но я хочу спросить за конкретику. Может кто-то знает хорошие техники из опыта? Я понимаю, что нужно соблюдать баланс между стоимостью решения для тестирования/отладки без железа и производства реальных образцов. Однако время простоя тоже денег стоит.
  3. Цитата(SSerge @ Jan 3 2018, 16:03) Этом не просто хороший, это отличный вопрос, в нём содержится 100% ответа. Я скорее имел ввиду - возможно кто-то знает техники, как это сделать малой кровью.
  4. С Новым, уже 2018 годом. Всех благ! Добавлю еще от себя. Мы попробовали двинуться дальше в области качества ПО. Приобрели LDRA пакет вместе с TBManager, TBrun, LDRAcover, LDRAunit. Данный пакет умеет увязывать требования написанные в Word или из JIRA/Polarion с кодом. А также запускать тесты прямо на железе используя JTAG. Более подробно - презентация. Возник попутно вопрос - а что вы используете для отладки кода, когда ещё железо не готово? Отладки спаянные воедино? Может есть софтовые эмуляторы? (как например QEMU) или что-то иное? (Особенно если 60% кода копируется из проекта-в-проект, меняется только приложение) К примеру: есть проект на FreeRTOS который конвертирует аналоговые входы используя алгоритмы в цифру и гонит по Ethernet по спец протоколам. Нужно сделать ещё пару приложений, которые основу имеют туже, но кол-во аналоговых входов другое, уровни другие, выхлодной протокол другой - но железо не готово. Как разрабатывать софт параллельно максимально абстрагируя софт от железа пока оно не готово? Какие при этом риски?
  5. Добрый день, Собираем счётчики на базе Analog Devices ADE7978/ADE7933 и заказчик поднял вопрос о калибровке. Методику калибровки счётчиков заказчик не имеет (предыдущий подрядчик не отдаёт - саботирует производство). Необходимо разработать собственный стенд для калибровки. Необходима точность измерения 0.5% Смотрели Analog Devices AN-1259 APPLICATION NOTE для калибровки - но не ясна общая методика калибровки (какую нагрузку лучше подключать, как именно измерять лучше для достижения заданной точности) Мы рассматривали вариант покупки AC Voltage Source (например BK Model 9805), но у него выход с точностью ±(0.2% + 0.6 V), что неприемлемо. Fluke 6003A не рассматриваем - т.к. изначально высокая цена + цена калибровки каждый год. Подскажите, как калибровать счётчики? Возможно кто-то имеет методичку для "начинающих" по калибровке? Также рассматриваем вариант сотрудничества для консультаций. Спасибо
  6. Какая бы "тяжелая" дискуссия не была - для себя много интересного прочел. Цитата(AlexandrY @ Jul 28 2017, 18:01) Предлагаю остановить этот поток сознания, и дать ваше определение понятия "итерация". Поскольку как мне кажется никто не понимает о чем вы. Про умный дом? Так там что ни сделаешь всё пойдет, "итерации" теряют смысл ибо они и есть цель. Но есть проекты где какие-то итерации в принципе невозможны, например система управления промышленным объектом. А ведь про умный дом - это правда. В теме просто зарыт сундук с деньгами, надо только его найти. Цитата(AlexandrY @ Jul 29 2017, 09:35) Откуда этот постулат, что итерации повышают конкурентоспособность? Это в наши то дни, когда конкуренты синхронизируют релизы буквально по дням друг с другом чтобы выгоднее поделить волны спроса. С курсами валют работают на микросекундных интервалах. Переходите уже на метафоры волн и полей притяжения. Разработка нынче либо сейчас, либо вообще не нужна. Какие еще итерации? Я встречал клиентов, которые планируют бюджет на 1..3 года. И там закладывают суммы на проект достаточно большие и им безболезненно делать по 6-8 итераций. Главный результат после 1-3 лет проектирования - стабильный серийный продукт. И была реальная история: Инженер из Испании 8 раз переделывал схему платы. Спросите - а почему? А я отвечу - всё просто: он ленив. Он берёт референс и срисовывает 1 к 1 (бывает с ошибками), без моделирования в LTSpice и согласования с программистами. Разводят ему плату, производят, она приходит - а там косяк или софт не может реализовать его "хотелки". И так по циклу. Уволить не просто - ибо до пенсии осталось 3 года, а он и рад растягивать проект.
  7. Ещё добавлю: Попробовали Vector HIL (Hardware-in-the-Loop) - замечательная вещь. Взяли в аренду - прогнали тесты - повылазили глюки, которые не должны были. Заметили, что Static Analysis влияет также и на результат теста с HIL. По требованию от клиента - делали тестирование в климатической камере, а также механические испытания (1 млн раз нажимали пневматикой на кнопки, чтобы посмотреть как они будут вести себя ). По поводу убеждения заказчиков: 1) Как доказать правильность и полноту требований Тех задания (ТЗ), в т.ч. по физическим и функционально-логическим характеристикам? --->Как правило с первого раза в ТЗ не укажешь всех нюансов которые вылезут в процессе разработки. Конечно желательно, чтобы заказчик доверял исполнителю и трезво понимал риски. А риски нужно обозначить сразу и предложить варианты решения в случае чего. 2) Как доказать что програмное обеспечение 100% соответствует требованиям ТЗ? Просто на столе просчёлкать варианты - не подходит. Нужно формальное строгое доказательство правильности и полноты тестов. Нужно доказать что интерфейсы соответствуют стандарту и т.п. --->Заказчик делает входной контроль сам. Как минимум- можно предложить репорты из Static Analysis tool, unit test tools 4) Какие физические тесты (климатьика и т.д), в каком объёме и на каком этапе прроизводства\приёмки изделия надо проводить? --->Это определяется стандартами которые необходимо поддерживать. Открываем ГОСТ/IEC/ISO и знакомимся. Оттуда берём ссылки на другие стандарты и тд. Надо приложить усилия, конечно, чтобы распутать все это и сделать то что нужно, с достаточными требованиями.
  8. Добавлю информации: разработки стараемся делать по всем правилам: Software design request от клиента, потом пишем: software architecture doc, software development plan, software validation concept, software integration concept, dFMEA, sofware test plan. Для железа: system requirement secification. MTTF - анализ. Используем инструменты: 1C заинтегрирована со складом плат и радиодеталей. Прошивки для железа тоже с уникальным номером из 1С. Автоматический анализ кода (ночью, после работы Jenkins) - LDRA tool. Автоматические тесты - Labview + набор простых инструментов, таких как usb-ftdi-uart/i2c/spi, usb-relay. Дополнительные билд скрипты для git/svn.
  9. Добрый день. Компания dab-embedded выкладывала компилятор, uboot и Linux для bf70x. Гдето видел информацию на форуме
  10. CAN под Linux:

    Добрый день. Страшного ничего нет, просто canutils работать не будут. Тут главный вопрос как реализован драйвер, где прерывания обрабатываются? Где обрабатывается ошибки шины ( например busoff )?
  11. Добрый день, Попробуйте обратиться в Axonim Минск - у них есть порт eCos RTOS для этого проца с загрузчиком RedBoot. Спросите про цену и условие поставки.
  12. Можно чуть подождать и купить уже такой аппарат BeagleBone-X15 - link
  13. Помнится, в журналах Электронные компоненты за 2013 год были примеры реализации различных протоколов на PRUSS.
  14. Цитата(sanych2015 @ Apr 9 2015, 20:08) Спасибо за тему на форуме раскрыл немного свой кругозор в этой теме... Тестирование - это большая часть успешного проекта. И как правило уровень покрытия тестами влияет на конечное качество продукта, а знание технологий тестирования - это сильная сторона успешного коллектива.