'У костра'

[2017-01-02 15:03:15] kozin писал(а): то при частоте вызовов 1кгц я в консоли получаю 1-символьные значения крайне нестабильно, раз у несколько сек.

Там везде стоит проверка что вывод в консоль запрещен из таймерных функций, так что вывод получается ТОЛЬКО если по какой-то причине прерывание было отложено и затем вызвано из основного потока.

[2017-01-02 15:03:15] kozin писал(а): если функция не успела отработать за отведенный период ее прерывают и перезапускают

Это вопросы реализации конкретного шедулера, я так не делаю.

[2017-01-02 15:03:15] kozin писал(а): обственно кто таков этот функтор и в чем его специфика - для меня темный лес

Просто обертка для того чтобы можно было унифицированно вызвать метод любого класса без возни с оператором ->*

[2017-01-02 15:03:15] kozin писал(а): в доке другой пример

Дока ни о чем, если в двух словах то нужны 2 дополнительных потока - высокого приоритета и желательно реалтайм, и низкого приоритета. Звязываться с настоящей многозадачностью было лениво, поэтому реалтайм поток реализован как и в АПМ на таймере, а низкоприоритетный на простой кооперативной многозадачности во время исполнения разнообразных dalay()

[2017-01-02 15:03:15] kozin писал(а): тоже стало все рассыпаться именно тогда когда он повесил обновление на таймер

Но у меня-то при -O0 работает! Хотя явно выполняется дольше чем без оптимизации.

у меня кстати ряд варнингов показывает эклипс

втч https://github.com/night-ghost/ardupilot/blob/master/libraries/AP_InertialSensor/AP_InertialSensor_Invensense.cpp#L811

Description    Resource    Path    Location    Type
No break at the end of case    AP_InertialSensor_Invensense.cpp    /ardupilot/libraries/AP_InertialSensor    line 811    Code Analysis Problem

[pinmap] спасибо! классно!

если я не надоел еще тут своим "нудежом" то какие есть мысли по DRDY.

если пин не заведен на процессор - то тут при  чтении регистров мпу наобум лишняя нагрузка на проц, спиай и саму мпу, поэтому цель поймать цикл готовности данных и в этот момент их забрать. т.е. важно забрать за один цикл измерения забрать 1 сэмпл, не 2 или больше и в то же время не пропустить.

в ситуации когда используется drdy - идеально поставить легковесную функцию в аппаратное прерывание, для регистрации фронта импульса. Если же проверять пин DRDY циклически из таймера, то чтобы гарантировано попасть в момент близкий к фронту импульса состояние пина нужно проверять с частотой на порядок выше чем частота сигнала, т.е. при частоте измерения мпу 1кгц нужно опрашивать пин как минимум на 10 кгц. Причем в случае если фронт импульса зарегистрирован то важно не запускать повторные измерения пока пин в активном сотоянии, следует дождаться нового фронта. При этом можно установить таймер на паузу чуть меньше чем цикл измерения мпу, а затем проверять пин с высокой частотой.

если же пин готовности мпу проверять тупо с частотой измерений, т.е. 1кгц то проверка пина может придтись не на начало импульса а гдето к его концу и велика вероятность что чтение  регистров может совпасть с процессом их переустановки в результате измерения. зы. я не знаток мпу, чисто по аналогии с другими спи устройствами

Вдогонку про Пинмап. Есть еще таблица таймеров в pwm_in.c и еще одна таблица таймеров в timer.c. По уму их тоже надо бы в описатель платы засунуть, но вроде бы в пределах семейства они остаются неизменными

[2017-01-03 09:10:11] kozin писал(а): вроде как тут регистрируется

Это да, как я уже сказал я стараюсь по максимуму не трогать код ВНЕ ХАЛа. 

[2017-01-03 09:10:11] kozin писал(а): 1кгц

Кстати о получение данных с МПУ совмещено с их не самой легкой обработкой, так что иногда эта _poll_data выполняется аж 1286uS - так что килогерц это весьма оптимистично.

ради интереса посмотрел используют ли аппаратные прерывания в клинфлайте.

https://github.com/cleanflight/cleanflight/blob/master/src/main/drivers/accgyro_mpu.c#L216