Да, с перетиранием тоже постоянно сталкивались, добавляли потом защиту стека для потоков, но не всегда помогает :) Ага, спасибо, просмотрел Вашу публикацию.
Кроме того, рассматривается случай, когда доступа к исходникам ThreadX нет и не предвидится.
А если не секрет, то зачем тогда именно ThreadX использовали?
Мы тут не говорим, что во FreeRTOS что-то плохо с переключением потоков. Я уверен, что все прекрасно переключается. Дело в том, что у них context_switch делается прямо ассемблерной вставкой внутри обработчика прерывания PendSV. А хочется отдельную функцию, без всяких прерываний, которую можно вызвать явно.
… FreeRTOS перед первым запуском задачи инициализирует стек
А про инициализацию в статье есть :)
Давайте изначально проинициализируем создаваемый поток так, как если бы мы выходили из прерывания — /* Simulate the stack frame as it would be created by a context switch interrupt. */
Если вы про Embox, то у нас не под Keil. Собираемся легко из консоли)
На странице проекта есть короткое описание как собирать. Для прошивки stm32 используем openocd.
Да, скорее всего это следствие постоянного наращивания функционала, тогда бывает и появляются странные ветки в дереве :) Но со временем мы их разгребаем.
Про RISC-V: Мы поддерживаем SPARC LEON3, которая на базе SPARC V8, то есть интерес к подобным архитектурам у нас есть. Насколько я знаю, RICS-V очень свежая, а мы в данный момент занимаемся более используемыми архитектурами. Но думаю, до RISC-V в будущем дойдем.
У Embox лицензия BSD, то есть можно использовать в сторонних разработках без проблем.
А при чем тут дальний космос? Вроде как удельный импульс плазменного двигателя всего раз в 50-100 больше ЖРД. То есть до Альфы Центавра мы точно на нем не долетим :)
Не знаком с историей РД-301, но когда увидел его в питерском музее космонавтики, то стало интересно почему все не обломалось на этапе «а давайте сделаем двигатель на фторе»? Да и выглядит двигатель на порядок сложнее других РД, и наверняка на его создание было немало сил положено.
Вот, например, что википедия говорит:
Прошёл полный объём стендовых испытаний, включая официальные, но в полётах ни разу не использовался,[2] при том, что к полётам был вполне готов.[3] По эффективности двигатель был близок к двигателям на паре кислород-водород. В обращении двигатель оказался сложным и опасным из-за высокой химической активности фтора, высокой токсичности компонентов топлива и продуктов их реакции.
Нельзя было что ли первым делом оценить опасность такой реакции?
Обнаружение узкополосных помех удобно производить в частотной области, в то время как для обнаружения спуфинговых атак следует анализировать поведение псевдозадержек, энергетического потенциала и доплеровского смещения на наличие перескоков.
Скажите, а Вы решали обе задачи — с узкополосными помехами и спуфингом? Было бы интересно побольше узнать как обнаруживается спуфинг на практике (там же вряди ли согласованный фильтр сработает?). И какие предположения делаются про отношение сигнал/шум?
И еще один вопрос. На картинке с фильтром Калмана помимо екомпаса и гироскопа еще есть датчик давления. Интересно, для чего он там? :)
Например, создать пилу-болгарку, которая без смены диска может менять размеры и/или количество зубцов
Думаю что размер менять будет сложно :) Из деталей для диска большего радиуса получится создать диск меньшего радиуса только с зубьями, т.к. у них кривизна окружностей разная, и поэтому «детали» не подойдут.
Мне не очень понятно как связать силу тока двигателя и тип поверхности. От силы тока зависит угловая скорость двигателя, а это не совсем то что нужно. Сначала я хотел решать более общую задачу определения причины разладки (то есть причиной может быть не только поверхность, но и падение напряжения на двигателе). И в этом случае электроизмерения действительно необходимы.
Но так как я решал задачу определения замедления машинки, то пришлось делать на одном акселерометре :)
Про квадрацикл не думали, спасибо за мысль :)
Что касается тестирования, то была идея сделать лабиринт на улице, чтобы машинка выбирала наиболее благоприятную поверхность. Но это не так просто. А так на улице как минимум по поверхности асфальт/песок обязательно попробуем!
Неплохая статья, на сайте Unity и правда все менее понятно.
Арсенал средств это CMock? Mock хорошая штука, и ребята молодцы, что пробуют добавить их в Си. Однако версия в Unity слишком уж урезана. По сути мы можем только проверить результат возврата (например, можно легко сэмулировать что в куче закончилась память). Но ведь моки чаще применяются когда дорого использовать реальные ресурсы типа БД, либо нужно быстро разработать прототип (не ясно как это сделать CMock'ом из-за его ограниченности).
Полностью согласен, что логику нужно отделять от аппаратно зависимого кода. Это помогает, но не является решением всех проблем. Но, как выше писал Антон, сделать тест сетевухи без сетевого стека не получится, также не получится сделать его и на PC. То есть получается, что нам все равно нужно запускать тесты либо на железке, либо на qemu. Ну а раз мы запускаем тесты на таймер, mmu, сетевуху, то почему бы не запустить тесты на список тоже на qemu? С интеграционным тестированием еще сложней. Если список можно протестировать и на хосте, так это всего лишь алгоритм, то исполнение интеграционных тестов может зависить глубоко внутри от планировщика, файловой системы, да и от частоты процессора в конце концов. То есть все равно исполнения на PC и на целевой платформе могут различаться.
Да, Вы правы, тест не совсем корректный. Но:
1. «date -u --rfc-3339=date» выдает только дату без времени, то есть проблемы с секундами не возникает.
2. Соглсен, по хорошему нужно сбрасывать время на целевой платформе макросом TEST_SETUP_TARGET, в котором вызвать команду «date» c нужными параметрами. Но кроме как с помощью ntpdate точное время в нашей системе никак не выставить, только если эта команда не вызывается в стартовом скрипте. Таким образом, если считать, что стартовый скрипт заранее подготовлен и ntpdate в нем не вызывается, то тест корректен (в таком предположении)
Да, средствами чистого Си такую регистрацию тестов сделать не возможно. У нас это реализовано при помощи gcc расширения __attribute__ ((section(«name»))). То есть все структуры struct test_case из моего комментария выше упорядочиваются в отдельных линкер секциях.
Часть кода, которая реализует добавление в такой «массив»:
/* The relative placement of sections within a particular array is controlled
* by the value of order_tag argument. */
#define __ARRAY_SPREAD_SECTION(array_nm, order_tag) \
".array_spread." #array_nm order_tag ".rodata,\"a\",%progbits;#"
/* Every array entry, group of entries or marker symbols are backed by an
* individual array (empty for markers) defined as follows. */
#define __ARRAY_SPREAD_ENTRY_DEF(type, array_nm, entry_nm, section_order_tag) \
type volatile const entry_nm[] __attribute__ ((used, \
section(__ARRAY_SPREAD_SECTION(array_nm, section_order_tag)), \
aligned(__alignof__(array_nm[0]))))
То есть под каждый массив создается секция ".array.spread__array_nm*" и в нее помещаются элементы (section(__ARRAY_SPREAD_SECTION(array_nm, section_order_tag)) в макросе __ARRAY_SPREAD_ENTRY_DEF)
Я как-то просматривал эту книгу. Она сильная, но там по большей части методология тестирования приведена — например, паттерны и стратегии, тестирование легаси кода. Я в статье постарался сделать упор на реализацию на практике. К тому же в данной книге, насколько мне известно, примеры приведены на Unity, что в какой-то мере закрывает лишь вопрос с unit тестированием.
P.S. Кстати говоря, Unity синтаксически хуже чем googletest, как минимум потому что в нем приходится проделывать лишние действия для регистрации тест кейзов.
А если не секрет, то зачем тогда именно ThreadX использовали?
А про инициализацию в статье есть :)
И приводится код функции
pxPortInitialiseStack.На странице проекта есть короткое описание как собирать. Для прошивки stm32 используем openocd.
Да, скорее всего это следствие постоянного наращивания функционала, тогда бывает и появляются странные ветки в дереве :) Но со временем мы их разгребаем.
Про RISC-V: Мы поддерживаем SPARC LEON3, которая на базе SPARC V8, то есть интерес к подобным архитектурам у нас есть. Насколько я знаю, RICS-V очень свежая, а мы в данный момент занимаемся более используемыми архитектурами. Но думаю, до RISC-V в будущем дойдем.
У Embox лицензия BSD, то есть можно использовать в сторонних разработках без проблем.
Вот, например, что википедия говорит:
Нельзя было что ли первым делом оценить опасность такой реакции?
Скажите, а Вы решали обе задачи — с узкополосными помехами и спуфингом? Было бы интересно побольше узнать как обнаруживается спуфинг на практике (там же вряди ли согласованный фильтр сработает?). И какие предположения делаются про отношение сигнал/шум?
И еще один вопрос. На картинке с фильтром Калмана помимо екомпаса и гироскопа еще есть датчик давления. Интересно, для чего он там? :)
Думаю что размер менять будет сложно :) Из деталей для диска большего радиуса получится создать диск меньшего радиуса только с зубьями, т.к. у них кривизна окружностей разная, и поэтому «детали» не подойдут.
А в чем именно узкое место исследований известно? Требуется много времени для некоторых химических реакций?
Но так как я решал задачу определения замедления машинки, то пришлось делать на одном акселерометре :)
Что касается тестирования, то была идея сделать лабиринт на улице, чтобы машинка выбирала наиболее благоприятную поверхность. Но это не так просто. А так на улице как минимум по поверхности асфальт/песок обязательно попробуем!
Арсенал средств это CMock? Mock хорошая штука, и ребята молодцы, что пробуют добавить их в Си. Однако версия в Unity слишком уж урезана. По сути мы можем только проверить результат возврата (например, можно легко сэмулировать что в куче закончилась память). Но ведь моки чаще применяются когда дорого использовать реальные ресурсы типа БД, либо нужно быстро разработать прототип (не ясно как это сделать CMock'ом из-за его ограниченности).
1. «date -u --rfc-3339=date» выдает только дату без времени, то есть проблемы с секундами не возникает.
2. Соглсен, по хорошему нужно сбрасывать время на целевой платформе макросом TEST_SETUP_TARGET, в котором вызвать команду «date» c нужными параметрами. Но кроме как с помощью ntpdate точное время в нашей системе никак не выставить, только если эта команда не вызывается в стартовом скрипте. Таким образом, если считать, что стартовый скрипт заранее подготовлен и ntpdate в нем не вызывается, то тест корректен (в таком предположении)
Часть кода, которая реализует добавление в такой «массив»:
То есть под каждый массив создается секция ".array.spread__array_nm*" и в нее помещаются элементы (section(__ARRAY_SPREAD_SECTION(array_nm, section_order_tag)) в макросе __ARRAY_SPREAD_ENTRY_DEF)
Структуры struct test_case попадают в некий глобальный массив, а далее все эти функции run_nm будут вызваны при старте системы одна за одной:
Фреймворк на данный момент в составе проекта (кстати, проект открытый). Но в будущем мы планируем его отделить.
P.S. Кстати говоря, Unity синтаксически хуже чем googletest, как минимум потому что в нем приходится проделывать лишние действия для регистрации тест кейзов.