Создание собственной системы стабилизации
а чего там интересного? проц <-spi->mpu<-aux i2c->hmc
мпу вычитывает компас и складывает себе в регистры, сама без принуждения, мы потом из них всё забираем…
ноги 2 - ещё прерывание и вообще сейчас висит 9250 и 6000+5883(2 набора, 2 cs, 2 прерывания)
Серёг, прерывание на компасе нафиг не надо, тем более если читаешь через МПУ. Или у тебя чтение через режим обхода?
мпу вычитывает компас и складывает себе в регистры, сама без принуждения
Так зачем тебе прерывание? МПУшка всё равно по своей инициативе считает, одним кадром СПИ ты сразу все датчики получаешь. Да и компас, датчик не нуждающийся в интеграции, стало быть пропуск отсчета никак не скажется на точности работы ИНС.
Так зачем тебе прерывание? МПУшка всё равно по своей инициативе считает, одним кадром СПИ ты сразу все датчики получаешь.
да всё одним кадром, и прерывания с него нет, я про то - если вешать компас на SPI то не хватит одной лапы (cs) и придётся забыть о каком-то датчике…
проблема сейчас другая - где я ось потерял )))
все настройки мпу на “складирование” данных
PIOS_MPU6000M_WriteReg(PIOS_MPU60X0_SLV0_REG_REG, PIOS_MPU6000M_HMC5883_DATAOUT_XMSB_REG); // откуда начинать читать
PIOS_MPU6000M_WriteReg(PIOS_MPU60X0_SLV0_ADDR_REG, PIOS_MPU6000M_HMC5883_I2C_ADDR | 0x80); // читать пачку
PIOS_MPU6000M_WriteReg(PIOS_MPU60X0_SLV0_CTRL_REG, PIOS_MPU60X0_I2CSLV_EN | 6); // резервирование регистров для данных - куда складывать
т.е. всё по-порядку должно забираться
#define MPUREG_ACCEL_XOUT_H 0x3B
#define MPUREG_ACCEL_XOUT_L 0x3C
#define MPUREG_ACCEL_YOUT_H 0x3D
#define MPUREG_ACCEL_YOUT_L 0x3E
#define MPUREG_ACCEL_ZOUT_H 0x3F
#define MPUREG_ACCEL_ZOUT_L 0x40
#define MPUREG_TEMP_OUT_H 0x41
#define MPUREG_TEMP_OUT_L 0x42
#define MPUREG_GYRO_XOUT_H 0x43
#define MPUREG_GYRO_XOUT_L 0x44
#define MPUREG_GYRO_YOUT_H 0x45
#define MPUREG_GYRO_YOUT_L 0x46
#define MPUREG_GYRO_ZOUT_H 0x47
#define MPUREG_GYRO_ZOUT_L 0x48
#define MPUREG_EXT_SENS_DATA_00 0x49 // это от компаса
#define MPUREG_EXT_SENS_DATA_01 0x4A
#define MPUREG_EXT_SENS_DATA_02 0x4B
#define MPUREG_EXT_SENS_DATA_03 0x4C
#define MPUREG_EXT_SENS_DATA_04 0x4D
#define MPUREG_EXT_SENS_DATA_05 0x4E
догнал надо частоту дискретизации с i2c править
I2C_SLV4_DLY_EN When enabled, slave 4 will only be accessed at a decreased rate.
I2C_SLV3_DLY_EN When enabled, slave 3 will only be accessed at a decreased rate.
I2C_SLV2_DLY_EN When enabled, slave 2 will only be accessed at a decreased rate.
I2C_SLV1_DLY_EN When enabled, slave 1 will only be accessed at a decreased rate.
I2C_SLV0_DLY_EN When enabled, slave 0 will only be accessed at a decreased rate.
Чёт с буржуйским туго
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 разбирается, она для этого и создана.