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

    

let's see

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

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

  • Посещение

Репутация

0 Обычный

Информация о let's see

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

Информация

  • Город
    USA

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

2 356 просмотров профиля
  1. Embedded Software Testing

    Embedded Software Testing Краткий курс по-английски: FYI Для тех, кому интересно.
  2. Маленькая беспроводная сеть

    Спасибо за ответ. Точные цифры получу только вместе с заказом, а для этого надо сначала представить предложение, вот и спрашиваю в общем виде. По внешнему виду, в оригинальном проекте энергопотребление не самое болхшая проблема, а вот для добавляемых устройств, не считая фона, - критичная. Пока видится мастер, как и был, а все остальные слейвы, включая фон. Также полагаю, что сенсоры будут бродкастить, а исполнительные просто слушать. Обновление. В старом проекте идет обмен пакетами по 120 байт, каждые 4 миллисекунды, т.е. матер->слейв; подтверждение(8 байт) + свои 120 байт, мастер подтверждает и все сначала. Для обмена с фоном пакет 180 баит каждые 200 миллисекунд. Для сенсоров и актуаторов задержка не боле 4 миллисекунд при пакетах в 16 байт.
  3. Маленькая беспроводная сеть

    Имеется старый проект, в котором два устройства соединены классическим БТ. Естественно, один мастер, один слейв. Обмен данными двусторонний и достаточно интенсивный. Задержки - неприемлимы. Необходимо добавить к этой сети смартфон, в основном, в качестве индикатора и несколько(пока 4) сенсоров/актюаторов. Об'ем данныь низкий, требования к энергопотреблению очень жесткие, задержки совершенно неприемлимы. Пожалуйста посоветуйте возможные архитектурные решения с их обоснованием. Расстояние между устройстами до 3 метров.В случае потери соединения, сеть должна снова сама воссоединиться. Заранее благодарен.
  4. STM32 & ISO-TP стратегия

    А кто как не разработчик должен это определять?! Не надо смешивать доставку данных с их содержанием.
  5. STM32 & ISO-TP стратегия

    Делюсь собственным опытом/мнением. Использую систему команда - статус, запрос - ответ. Обе стороны имеют тайм-аут, по-которому переходят в другой режим работы. Например, послана команда усановить какую-то величину на каком-то выходе. В ответ передатчику посылается статус приемника как подтверждение приема. Скорее всего, значениеуказанного выхода уже включено в статус устройства. Если нет, то посылается отдельный запрос на чтение данного значения. Про тайм-ауты я уже упоминал. Это все, наверное, очень просто и слишком в общем виде, ну так проработка деталей - Ваша работа. Данная методология отлично себя зарекомендовала на множестве проектов, в том числе и с коммуникацией по CAN с наличием более сотни устройств на одной шине и, соответственно, с коллизиями и потерями пакетов по различным причинам, которые необходимо анализировать и принимать меры. Запомните, потери неизбежны, а вот фиксирование таких потерь и устойчивость системы к ним - это уже другая история. Успехов.
  6. По поводу I2C. До 2010 года активно использовал AVR8 для safety-critical проектов. Машина состояний там имеет аппаратную ошибку, подтвержденную тогда еще Atmel'ом. Сут= ее в том, что помехи на шине приводили к потере арбитража в Multi-master mode и шина зависала. Для решения, одновременно с циклом обмена, запускался таймер в режиме watchdog. Если цикл приема-передачи не завершался вовремя, таймер выключал и тут же включал периферию. После перехода проекта на Cortex-M проверял устойчивость I2C на FPGA(NIOS-II), NXP, Atmel, STM32F2xx/4xx(F1xx сильно отличается). Итого: к NXP нет никаких претензий, Atmel не давал никакой возможности stretch cycle, STM худо-бедно позволяла работать НО без всяких кубов/SPL. При этом, подчеркну, что создавал помехи, подключая на шину GPIO с открытым коллектором, управляемым хаотично(0/1) в короткие промежутки времени(единицы us) и проверял целостность и времена трансферов. The product safety tests were completed succesfully. Данная информация доведена до вашего сведения, а не для дальнейших дискуссий.
  7. STM32СubeMX и подобные

    Это если кому-то интересно. На робота, которого я разработал, поставили стрелялку. По этой причине с ним проводили BLACK BOX testing. Исходников не спрашивали, что с ним делали не могу знать, но по результатам испытаний претензии пред'явили к системам коммуникации и battery management. Через месяц, после повторных испытаний продукт был закуплен.
  8. STM32СubeMX и подобные

    Цитата(Quasar @ Feb 27 2018, 08:59) Вы по теме, не написали вообще ничего, при этом, постите сюда какие-то идиотские цитаты, которые считаете уместными в технической дискуссии. Попутно, как я понимаю, пытаетесь обозвать собеседника "Идиотом", "Мартышкой" или еще кем-то. Вы думаете вас воспринимают серьезно? Вы никто, и звать вас никак, ничего из себя не представляете, и ваши цитаты интересны только вам, и возможно вашему врачу. Очень хорошо, что читаете цитаты и знаете к кому их относить. К сожалению, сделать еще один шаг и понять, что я ни спорить, ни дискутировать по известным причинам не буду не получаеться. Уважаемую публику прошу извинить за офтоп, но что делать, если как сказал Жванецкий:" Товарищ не понимает" ну и что-то там еще про доцента... Больше не буду отвлекать.
  9. STM32СubeMX и подобные

    Цитата(Quasar @ Feb 26 2018, 12:34) Ну то есть, когда речь идет действительно о Safety-critical, а не о каких-то фантазиях, местных "гениев", всплывает сразу много красивых аббревиатур, которым надо соответствовать. Еще одна цитата
  10. STM32СubeMX и подобные

    Цитата(Quasar @ Feb 25 2018, 12:58) А любого, кто аргументировано возражает вашему мнению, вы считаете нужным назвать идиотом. Лечитесь, мой вам совет. Аргументы у каждого свои. А далее, см. приведенную выше цитату Марка Твена.
  11. STM32СubeMX и подобные

    Цитата(Quasar @ Feb 24 2018, 13:08) Да-да. При этом, судя по вашим последним сообщениям на форуме, вы считаете нужным влезать в обсуждения с одним единственным советом "не использовать Cube, HAL, SPL". Какие еще цитаты приведете по этому поводу? Я считаю полезным высказывать свое мнение. Прислушиваться к нему или нет личное дело каждого. А вот и подходящая цитата:"You can lead a horse to water, but you can't make it drink".
  12. STM32СubeMX и подобные

    Цитата(Quasar @ Feb 23 2018, 14:55) А лампочкой поморгать это safety critical? Как вообще лампочка связана с safety critical? Вообще удивительно какой бардак у многих в голове. Ok, зайдем с другой стороны, как вы подтверждаете safety critical? Ваш софт проходит сертификацию на DO-178B, например, или вы просто по "пацанский зуб даете"? Какой-нибудь управляемый L2 коммутатор D-link или soho роутер от них же, ни разу не лампочкой поморгать, но в нем скорее всего обычный линукс. И там это решение вполне оправдано, так как там не стоит задачи в спец. сертификации. А вот на бортовом вычислителе боинга 737 вы линукс не встретите, и не потому, что он сильно сложнее, а потому, что сделав вычислитель на линукс вы упашетесь его сертифицировать и доказывать что оно надежно. Потому что в настоящем safety critical надо доказывать, а не просто трындеть. Если проект подразумевает safety critical с соответствующей сертификацией, то он подразумевает и соответствующее количество трудочасов и денег на него. В рамках этого проекта, естественно, разумно выделить группу для написания надежной замены ST'шному HAL'у. С которой потом, можно будет пройти все сертификации. А когда у вас задача спроектировать железку без доп. требований по надежности, а вы все равно тратите время на перепись HAL'а, полагая (почему-то?), что ваш быдло код лучше "индусского", вы просто разбазариваете время и деньги, отвлекаясь от основной задачи. Следую мудрым советам: “Never argue with an idiot. They will drag you down to their level and beat you with experience.” ― Mark Twain
  13. STM32СubeMX и подобные

    Цитата(Quasar @ Feb 22 2018, 15:27) Есть мнение, что те, кто отрицательно пишет про HAL не умеют работать с чужым кодом или очень любят охотится на блох там, где нужно охотиться на медведя. ... От HAL очевидно придется уйти только тем, у кого: 1) Дикая серия и камень взят впритык, ибо на больших сериях каждый доллар на счету; 2) Если у вас жесткие требования по потреблению. А еще тогда, когда надо чтобы работало всегда, например, safety critical. Так, к слову, некоторые очень любят исполхзовать Linux, чтобы, например, лампочкой поморгать... Выбор инструментария и ответственность эа результаты его применение целиком лежит на разработчике. Нельзя запретить желающим писать с кубическим акцентом...
  14. STM32СubeMX и подобные

    Цитата(halfdoom @ Feb 15 2018, 06:15) Куб действительно удобен для начального раскидывания ножек и периферии. Можно подсмотреть в инициализацию и реализацию. Но на этом все. Полностью согласен. Вот только слово можно иногда переходит в нужно по причине никудышней документации, как мимнимум отвратительно переведенной на английский, не всегда полной, достаточно часто неточной и противоречивой, а также совершенно отсутствующих в ней примеров.
  15. STM32СubeMX и подобные

    Цитата(scifi @ Feb 14 2018, 07:36) Не надо грязи. Всё видел. Ну да, у этих покорявее, но документация вполне рабочая. А мсье изволит эстетствовать. Равняться надо на лучшее, а желающие могут спать на потолке...