'У костра'

Может быть какой-то процесс слишком долго выполняется?

Переписал для пробы драйвер MPU под обработчик прерывания завершения обмена и отладил.  Работает - аж самому понравилось!  Немного тестов и будут результаты и бинарники.

[2017-09-20 07:24:08] m-s писал(а): для mpu это наиболее важно

совершенно верно, более того это устраняет проблему глючного FIFO, которое теряет байты когда хочет и приходится его периодически сбрасывать, теряя ценную инфу с гироскопа. Сейчас же данные читаются по прерыванию готовности через DMA, и по прерыванию завершения обмена DMA обновляется указатель. А обсчитываются уже в рамках многозадачности, не портя временем расчета время цикла. 

[2017-09-20 07:24:08] m-s писал(а): А проблему с планированием потока компаса не удалось победить?

Удалось, сейчас ошибка планирования не превышает половины миллисекунды - то есть в пределах обычного таймслайса многопоточной ОС

[2017-09-20 07:24:08] m-s писал(а): кто-то портирует ardupilot под chibios

На мой вкус любая ОС в полетном контроллере это зло

[2017-09-20 08:48:37] m-s писал(а): Это не OC в обычном понимании, скорее hal и планировщик.

Я знаком с ней Это вроде неплохой HAL и не очень хороший планировщик. Однако: во-первых, ОЧЕНЬ много системных вызовов делается с запрещенными прерываниями - я же запрещаю прерывания не дольше чем на пару команд. Во-вторых, нет POSIX-совместимости а работа с ФС делается через ту же самую FatFS от ChaN. И в третих, простая вытесняющая многозадачность без приоритетов по round-robin, что никак не годится в данном случае. Конечно, я последний раз ее юзал в 13 году и многое могло поменяться, но впечатление убогости осталось.

Для полетного контроллера, где все выделение памяти делается при инициализации (не нужен сложный распределитель памяти), устройства раз и навсегда закреплены за драйверами (не нужны сложные механизмы синхронизации) и сливают данные в общий "котел" AHRS (не нужны сложные мутексы и прочее), лучше вообще обойтись без ненужных сущностей в виде ОС, шелла и прочего, и сохранить возможность понимать что, как и когда происходит.

Именно поэтому я и считаю что 3 слоя оптимальны - прерывания для получения данных, основной цикл для их обработки и все остальное, работающее когда другим нечего делать. Все что требуется - это не ожидать ничего в прерывании, что сейчас и удалось добиться.

UPD. Глянул я в тот порт... лучше промолчу.

Кстати, ни одна ОС не обеспечивает возможности  назначить в качестве обработчика прерывания метод класса без дополнительных телодвижений. А эта возможность позволяет очень удобно работать с прерываниями из C++ классов без обычных мучений. Я коммит сделал, можно посмотреть код AP_InertialSensor_Revo.cpp как это все получилось.

UPD. Хоть все ОС это и позволяют, ни один ХАЛ при ожидании семафора не поднимает приоритет процессу, владеющему семафором, а просто тупо ждет. Мню тут отчитали на неких форумах что мол я слишком много ругаю код из апстрима - это вот очень наглядный пример почему его нельзя не ругать

Запилил то же самое для компаса, попутно решив проблему потери семафора шины при возврате из таймерного обработчика. Заработало сразу же, без отладки.

Завтра верну запуск обмена в таймерное прерывание, запилю барометр - и можно будет собирать бинарники. 

пока только от ревомини, чтобы получить летабельную версию.