let's see
Участник-
Постов
317 -
Зарегистрирован
-
Посещение
-
Remote contract position
let's see опубликовал тема в Предлагаю работу
Brushless Motor Controller - the scope of workEvaluate STM32F0 FOC STEVAL-SPIN3201 solution in both sensored and sensorless mode.Evaluate the motor parameter identification process for FOC Spin small brushless hobby motor (600-900KV)Advise components modification to spin the motor at 16.8V with a max current of 40amps.Basic knowledge of English is required. Rates are subject for negotiation.Thank you. -
Именно так. Ну если солдатик оловянный, то и универсальность не удержит... Не рекомендую "рассуждать о крахе и подъеме Голливуда, не видя ни одного фильма".
-
Удаленная работа для студентов на американскую компанию
let's see опубликовал тема в Предлагаю работу
Необходимо быстрое написание программных инструментов под Windows 10 для тестирования валидации firmware. Языки программирования Pelles C/Python. -
Embedded Software Testing
let's see опубликовал тема в Документация
Embedded Software Testing Краткий курс по-английски: FYI Для тех, кому интересно. -
Маленькая беспроводная сеть
let's see ответил let's see тема в Wireless/Optic
Спасибо за ответ. Точные цифры получу только вместе с заказом, а для этого надо сначала представить предложение, вот и спрашиваю в общем виде. По внешнему виду, в оригинальном проекте энергопотребление не самое болхшая проблема, а вот для добавляемых устройств, не считая фона, - критичная. Пока видится мастер, как и был, а все остальные слейвы, включая фон. Также полагаю, что сенсоры будут бродкастить, а исполнительные просто слушать. Обновление. В старом проекте идет обмен пакетами по 120 байт, каждые 4 миллисекунды, т.е. матер->слейв; подтверждение(8 байт) + свои 120 байт, мастер подтверждает и все сначала. Для обмена с фоном пакет 180 баит каждые 200 миллисекунд. Для сенсоров и актуаторов задержка не боле 4 миллисекунд при пакетах в 16 байт. -
Маленькая беспроводная сеть
let's see опубликовал тема в Wireless/Optic
Имеется старый проект, в котором два устройства соединены классическим БТ. Естественно, один мастер, один слейв. Обмен данными двусторонний и достаточно интенсивный. Задержки - неприемлимы. Необходимо добавить к этой сети смартфон, в основном, в качестве индикатора и несколько(пока 4) сенсоров/актюаторов. Об'ем данныь низкий, требования к энергопотреблению очень жесткие, задержки совершенно неприемлимы. Пожалуйста посоветуйте возможные архитектурные решения с их обоснованием. Расстояние между устройстами до 3 метров.В случае потери соединения, сеть должна снова сама воссоединиться. Заранее благодарен. -
STM32 & ISO-TP стратегия
let's see ответил sergeyklenov тема в STM
А кто как не разработчик должен это определять?! Не надо смешивать доставку данных с их содержанием. -
STM32 & ISO-TP стратегия
let's see ответил sergeyklenov тема в STM
Делюсь собственным опытом/мнением. Использую систему команда - статус, запрос - ответ. Обе стороны имеют тайм-аут, по-которому переходят в другой режим работы. Например, послана команда усановить какую-то величину на каком-то выходе. В ответ передатчику посылается статус приемника как подтверждение приема. Скорее всего, значениеуказанного выхода уже включено в статус устройства. Если нет, то посылается отдельный запрос на чтение данного значения. Про тайм-ауты я уже упоминал. Это все, наверное, очень просто и слишком в общем виде, ну так проработка деталей - Ваша работа. Данная методология отлично себя зарекомендовала на множестве проектов, в том числе и с коммуникацией по CAN с наличием более сотни устройств на одной шине и, соответственно, с коллизиями и потерями пакетов по различным причинам, которые необходимо анализировать и принимать меры. Запомните, потери неизбежны, а вот фиксирование таких потерь и устойчивость системы к ним - это уже другая история. Успехов. -
По поводу 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. Данная информация доведена до вашего сведения, а не для дальнейших дискуссий.
-
Это если кому-то интересно. На робота, которого я разработал, поставили стрелялку. По этой причине с ним проводили BLACK BOX testing. Исходников не спрашивали, что с ним делали не могу знать, но по результатам испытаний претензии пред'явили к системам коммуникации и battery management. Через месяц, после повторных испытаний продукт был закуплен.
-
Очень хорошо, что читаете цитаты и знаете к кому их относить. К сожалению, сделать еще один шаг и понять, что я ни спорить, ни дискутировать по известным причинам не буду не получаеться. Уважаемую публику прошу извинить за офтоп, но что делать, если как сказал Жванецкий:" Товарищ не понимает" ну и что-то там еще про доцента... Больше не буду отвлекать.
-
Аргументы у каждого свои. А далее, см. приведенную выше цитату Марка Твена.
-
Я считаю полезным высказывать свое мнение. Прислушиваться к нему или нет личное дело каждого. А вот и подходящая цитата:"You can lead a horse to water, but you can't make it drink".
-
Следую мудрым советам: “Never argue with an idiot. They will drag you down to their level and beat you with experience.” ― Mark Twain