Создание собственной системы стабилизации
Чёт с буржуйским туго
When DELAY_ES_SHADOW is set to 1, shadowing of external sensor data is delayed until all data has been received.
пока не получит все данные не сложит в регистры?
может это включает шадоу технологию, пока идет запись пишется в дублирующий регистр а чтение происходит из основного, как только дописалось регистры меняются местами
альтернатива - читаются данные как есть
Просто не могу понять, куда девается ось - тупо нули в 2-х регистрах, зацепил регистр статуса компаса - ничего не поменялось… возможно придётся регистры для отдельного чтения, id всякие, сдвигать принудительно, дабы регистры с 49 по 4f были чисто для данных с датчика…
был дохлый компас, все оси завелись - перепутал только ориентацию… надо повернуть на 180 гр. разберусь и в небо)))
видать когда мпу пеканул - компасу тоже досталось - дым знатный был т.к. всё это у меня висело на проводах 0.1 - отгорели почти все )))
видать когда мпу пеканул - компасу тоже досталось - дым знатный был т.к. всё это у меня висело на проводах 0.1 - отгорели почти все )))
Дым?😃 У тебя аккум на плату замкнул?
если на компас подать 5 вольт с ограничением по току ампера 3 то сгорает дотла. и на плате дырка прогорает
Дым? У тебя аккум на плату замкнул?
не, 5 вольт достаточно - это же второй набор датчиков, я его выносил подальше чтобы можно было крутить легко на проводах 0.1 в лаке - отгорели только так )))
даже некалиброваный hmc показывает намного точнее чем калиброваный AK и не плывёт от близости ноута или холодильника…
Я тут был воодушевлён применением RPi в качестве контроллера полета… Так вот последние изыскания показали, что при работе с SPI многозадачный линукс становится фактически однозадачным… Иными словами - запустив в одном терминале процесс обмена данными по SPI и их выводом на экран, другие задачи запускаться не собираются до тех пор пока мы не убьём этот процесс…
Вывод: нафига тогда всё это (?), и вопрос по передаче видео по WiFi и тому подобное отпадает сам собой… Не понятно как люди, делающие платы типа “NAVIO” надеются на развитие этого направления (?).
Там правда у них какойто “патч” линукса… и похоже I2C… - но это, по моему, только усугубляет проблему…
вот вроде решили эту задачу Linux autopilot on Raspberry Pi
вот вроде решили эту задачу
Решили (?)… влепили всётаки 103-й stm на борт, а распберри “как бы сбоку”…, чего он там у них делает тогда ?
STM32F4XX - DCM + EKF на 16 “осей” 18% времени ядра - смысл глубинный в малине? её если и пользовать то как датчик визуальной навигации…
смысл глубинный в малине?
Если только свою операционку написать… Эх, хорошая была в своё время OS/2 от IBM… у нее под каждый запущенный процесс была возможность гибко выставлять приоритеты и кучу других системных настроек, распределением нагрузки на процессор можно было управлять прям из GUI…
Винда-собака всё похоронила своей “дружественной концепцией”, и теперь юзеры даже не знают что информация в виде файлов хранится, для них это просто “пиктограммы”…
(немного грусти)))
полуось - даа было время лихое ) проблема - свою ось на малину написать - человекочасов не хватит ( без оси тоже грустно (читай - задолбаешся с регистрами работать напрямую)…
было время лихое
Вообще странно как то - 21 век за окном, а нормальной RTOS для ARMa или i386 нету (штоб с командным интерпретатором, а не компилируемым исходником), не кому не надо, типа.
Может плохо искал просто(?)…
почему (любимая)-RTOS и eLua или PAWN не являются “нормальными”?
RTOS и eLua или PAWN не являются “нормальными”?
Их можно держать на флешке, грузить, и потом писАть задачи на языке высокого уровня ? , кажется нет. А хочется - типа линукса, но с поддержкой ядром реалтайма/аппаратных прерываний.
А хочется - типа линукса
линукс — это ОС, а не интерпретатор. скрипты же можно хранить хоть в облаке и загружать их по мере необходимости.
имхо интерпретируемый код по определению не оптимален для микроконтроллеров достаточно объемист и непригоден с точки зрения быстродействия
есть куча задач, в которых можно наплевать на объем и быстродействие. кнопочная логика управления, UI для OSD, форматирование телеметрии, навигация. вместо перекомпиляции/перепрошивки создал (изменил) скрипт на внешней карточке и пользуйся.
а с быстродействием пусть RTOS разбирается, она для этого и создана.
линукс — это ОС, а не интерпретатор.
Я с этого и начал - “хочется ОС”, а не компилируемое ядро, которым по факту и являются всякие “RTOS” и им подобные… им до настоящей ОС еще далеко…
имхо интерпретируемый код по определению не оптимален для микроконтроллеров достаточно объемист
Для ARM11 - оптимальность кода не имеет значения (в контексте задачи контроллера полета), быстродействия заглаза, главное чтоб “приложение пользователя” имело возможность прямого доступа к железу,
а так по факту получается - имеем проц аж 1.6 Ггц, а из-за Линукса даже обычный интегратор ДУСа не получается реализовать по человечески, (ОС не пускает к железу напрямую)…
ОС не пускает к железу напрямую
вы сейчас о чем, прямой доступ к /dev/* за железо уже не считается?
вы сейчас о чем
Я думаю он примерно об этом:
GPIOA->BSRRL = 0x0c00;
или вот об этом:
while( GPIOA->IDR & 0x0100) {
// bla-bla-bla
}