Создание собственной системы стабилизации
смысл глубинный в малине?
Если только свою операционку написать… Эх, хорошая была в своё время 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
}
пример на bash:
# Set up GPIO 4 and set to output
echo "4" > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio4/direction
# Set up GPIO 7 and set to input
echo "7" > /sys/class/gpio/export
echo "in" > /sys/class/gpio/gpio7/direction
# Write output
echo "1" > /sys/class/gpio/gpio4/value
# Read from input
cat /sys/class/gpio/gpio7/value
в тактах процессорных разницу посчитайте, и еще расскажите как получить прерывание по событию на ножке 😉
могу рассказать, только для чего? чтобы еще раз повторить довольно известный факт об отсутствии в Linux каких либо ограничений на доступ к железу?
а такты считать при использовании “языков высокого уровня” вообще-то не принято. не для этого они созданы.
об отсутствии в Linux каких либо ограничений на доступ к железу
Аналог прерывания от события на ножке в user space получится продемонстрировать?
а что, интересно, продемонстрировано в последней строке моего примера на баше?
там нарисовано чтение значения на ножке. Для вас это тоже самое, что и прерывание по событию?
да ёпрст… “событие” на цифровом входе — изменение его уровня. “прерывание” — вызов callback-функции по наступлению события (счетчик) либо по условию (уровень == 0/1). а как еще узнать про изменение кроме как прочитать ячейку памяти (“значение на ножке”)??
в общем, не надо больше про “Linux не пускает к железу напрямую”. в Linux любое устройство есть файл с блочным или символьным доступом, которое, по желанию/требованию mmap-ится в память без каких-либо трудностей.
Имхо все эти изыски для пары человек из миллионов.
важные вопросы сегодняшнего дня
-чтобы ахрс держало уровень горизонта в резких ускорениях
-чтобы инерциалка хотябы в пределах 30 секунд при перемещениях не уходила бы по позиции больше метра
а что в них такого важного? все уже давно придумано, реализовано и скопипащено тысячи раз. у меня Flymentor (на одних аналоговых гироскопах) начинает заваливать горизонт только через 2-3 минуты непрекращающейся “колбасни”. (уже) ширпотребный Parrot мобилками управляется и проблем не знает. китайцы продают игрушки по 20 уе, которые с успехом держат что угодно на любых ускорениях и висят на месте как вкопанные.
а тут (не конкретно тут, а образно) все что-то свое придумывают, для чего не хватает 9DOF+барометры+GPS+камеры 😉
довольно известный факт об отсутствии в Linux каких либо ограничений на доступ к железу
Прямой доступ к железу несомненно есть (в частности “чудесный” механизм маппирования), но ядро, опять же, предоставляет этот доступ когда ЕМУ угодно, а не когда угодно приложению в пользовательском пространстве…
Спустившись на уровень драйверов, в принципе, наверно можно заблокировать шедуллер и делать что то одно и вовремя, но ведь это изврат, который заблокирует всю ОС, а главное - не предусмотрен самой идеологией ядра линукса… (линукс изначально заточен - не пускать юзеровское пространство в обход шедуллера)… Не так ли ??