Создание собственной системы стабилизации
Блин, опять растраты
И конца им что-то не видно 😵 😆
Как ни ломал голову себе, задач под ARM не нашел. Вот и интересно Ваши мотивы. Если это не тайна конечно.
Ну не знаю, для меня ARM - это просто удобно. Ткнули в коде точку останова, IDE остановилась в нужном месте, все переменные можно посмотреть. А с той же ардуиной это без пляски с бубном фиг выйдет.
Или мегабайт флэш памяти например, легко берем цветной логотип для вывода на ЖК-экран и кладем в проект, не задумываясь хватит места или нет. Учитывая что процы стоят одинаково, чего экономить.
Что касается Атмеги, то например для Multiwii пока хватает, а вот Ардукоптер уже достиг предела возможностей, уперлись в ограничения вроде по памяти что ли.
И конца им что-то не видно
Блин щя накоплю на дорогущие аналоговые датчики, и сделаю отдельно плату проца и плату IMU через SPI АЦП (ADC - по русски 😃 )…
Что касается Атмеги, то например для Multiwii пока хватает, а вот Ардукоптер уже достиг предела возможностей, уперлись в ограничения вроде по памяти что ли.
Как писал выше где-то mahowik -напихали фич, что в проц не влазит, а нормально так и не одна не работает - вот где раздолье программерам, а мы чё только сколхозить на другое железо? - да там же, как в том анекдоте - ну и сволочть председатель, поедь отдохи, а тут же работы непочатый край 😃
Как ни ломал голову себе, задач под ARM не нашел.
Ну это просто, сделайте простую стабилизацию без извратов на плавающей точке на АВРе с акселем и компасом, потом расскажите сколько ещё ресурсов осталось
Сосбно вот:
“Жирная периферия”, “Жирная математика - FPU”, частота, внутрисхемная отладка, дешевле проц (с тойже жирностью ), ну и т.д.
, хочется чтоб всё красиво было.
Тут случайно наткнулся на магнитометр HMC5983 беглое ознакомление с даташитом показало что тоже самое что HMC5883 только есть SPI, температурная компенсация и частота измерений 220 герц. Кто что думает?
СПИ это хорошо, не хочу и2ц по религиозным соображениям, хотя успешно пользую
А то мне на монокоптере не хватило быстродействия 5883 в 100Гц
странно, а гиру пользовать не модно?
Блин щя накоплю на дорогущие аналоговые датчики, и сделаю отдельно плату проца и плату IMU через SPI АЦП
Сергей, набор можешь огласить?
набор можешь огласить?
могу, но пока не затеплится надежда купить - нет смысла 😦 да и с данной хренью ещё не разобрался 😦 …
странно, а гиру пользовать не модно?
не совсем видимо корректно выразился… Не “один мотор - 4 сервы”, а “один мотор - одна серва, с вращающимся мозгом”
Вот что имел в виду
Подобная проблема с определением ориентации есть и у аппаратов на эффекте Коанда - слишком быстро вращаемся
Ок. Спасибо за ответы.
кстати, vis.asta, я так понял, что тоже AVR использует, только с нуля написанную, несколькими людьми. У него на скриншотах - просто вытащенная телеметрия, явно дистанционная.
…
Я пока на фильтрах вибрации застрял. В статике - всё ОК. и картинки и углы, но как включаю двигатели с винтами, так ужас. Не то, что бы ужас-ужас, но надо ещё до ума доводить. А времени не хватает.
Как писал выше где-то mahowik -напихали фич, что в проц не влазит, а нормально так и не одна не работает - вот где раздолье программерам
Ага, чтобы у всех так не работало 😃
Для старенькой Атмеги имхо просто отличные результаты 😃 Цена платы-то 80$ всего.
кстати, vis.asta, я так понял, что тоже AVR использует,
нет 32f4…
отпишусь - провёл эксперимент - после передачи показаний с гир акселя и магнитометра поставил точку останова, эта гадость сериалит мне уже абы что с переполнением, вот и вешается - буду разбиратся…
тут вся периферия F1 и F4 , у меня так сказать найдите 10 отличий, но блин этот код работает(проверял), а мой нет, что за беда не знаю, ибо затыкается не только уарт затыкается и i2c- просто перестаёт считывать данные с датчиков, да и с гиры тоже (с акселя данные есть всегда), попробовать что-ли туда прикрутить SPI и посмотреть что будет, правда с наскоку чёт не удалось собрать проект, но я особо не упирался не смотрел…
тут вся периферия F1 и F4
под эклипсом собрал, изначально он под Atollic, попробую адаптировать под своё железо посмотрю что будет, а то запёрся совсем…
воевал с версией 2_2 симптомы теже плюс cycleTime взбесился, что-то с математикой не то ибо если отключаю fpu Uart даже не пытается запустится - странно, наверно я где-то проект неправильно настраиваю. В проекте что лежит в git мелкоплата отрабатывает за 2600 новая за 730, а на “чистом” вие (без Калмана ) новая завелась на 3500😵
запустил эту же версию на мелкоплате - цикл тотже 3500 странно… ладно дело сейчас не в этом, блин что я делаю не так при переносе на F4:)
запустил эту же версию на мелкоплате - цикл тотже 3500 странно
У Ф4 частота выше настолько же, на сколько он быстрее. Если формирование millis() и micros() не испарвлено , то твои миллисекунды будут быстрее на соотношение частот процев 😃
Если формирование millis() и micros() не испарвлено
Исправлено и в отладчике смотрел - всё правильно, боюсь что-то или в прерываниях или в настройке самого проекта намудрил…
А теперь на пальцах, для особоодарённых - тоесть меня 😃
// cycles per microsecond
static volatile uint32_t usTicks = 0;
// current uptime for 1kHz systick timer. will rollover after 49 days. hopefully we won't care.
static volatile uint32_t sysTickUptime = 0;
static void cycleCounterInit(void)
{
RCC_ClocksTypeDef clocks;
RCC_GetClocksFreq(&clocks);
usTicks = clocks.SYSCLK_Frequency / 1000000; // ну тут, если не путаю, 8 - на обеих платах одинаково - от кварца в 8мГц отталкиваемся?
}
// SysTick
void SysTick_Handler(void) // откуда вызывается прерывание? незнаю :(
{
sysTickUptime++; // а один ли кГц?
}
// Return system uptime in microseconds (rollover in 70minutes)
uint32_t micros(void)
{
register uint32_t ms, cycle_cnt;
do {
ms = sysTickUptime;
cycle_cnt = SysTick->VAL;
} while (ms != sysTickUptime);
return (ms * 1000) + (168000 - cycle_cnt) / 168; // тот же кГц умноженый на 1000 вернули с поправкой на что? тактовую проца?
}
// Return system uptime in milliseconds (rollover in 49 days)
uint32_t millis(void)
{
return sysTickUptime; // ну и вернули тот-же кГц ?
}
[QUOTE=SergDoc;4177128]А теперь на пальцах, для особоодарённых - тоесть меня 😃
Сергей, вы столько уже провели времени в компиляторах, что давно бы уже разобрались с устройством и выбрали одну среду, а адаптировали под нее только чистую логику из других проектов. Вместо этого вы тратите многие часы борясь с чужими глюками 😃
clocks.SYSCLK_Frequency - это точно частота кварца, а не системной шины? Вообще частота кварца программно вроде недоступна. Только после прескалеров.
вроде как-то так:
RCC_Clocks->SYSCLK_Frequency = HSE_VALUE; // HSE_VALUE=8000000
вроде как-то так:
RCC_Clocks->SYSCLK_Frequency = HSE_VALUE; // HSE_VALUE=8000000
Итак, если коротко - HSI - это 8 МГЦ, внутренний RC генератор.
HSE - Это внешний генератор, в данном случае кварц.
SYSCLK - это системная частота. Она получается умножением кварца на PLL коэффициент. Скорее всего в вашем случае это 168МГц.
вот описание
То есть делить нужно не на 8М, а на 8М*PLLCLK. Так что подсказали вам похоже правильно - коэффициент неверный использовался.
ну да чёт не догнал сразу, о вот надо для 103-го нарыть такую и сравнить, а то я пользовался уже готовым system_stm32f10x.c , а тут сам собирал system_stm32f4xx.c
вот блин а к 103-му то и нет такой фишки 😦
небольшей разбор полётов:
это отсюда
#define DWT_CYCCNT ((volatile uint32 *)0xE0001004)
///////////////////////////////////////////////////////////////////////////////
uint32 uSClock(void) {
// TODO: no check for wraparound
register uint32 PrevTick, Tick, mS;
__disable_irq();
Tick = *DWT_CYCCNT;
PrevTick = sysTickCycleCounter;
mS = sysTickUptime;
__enable_irq();
return ((mS * 1000) + (Tick - PrevTick) / TicksuS);
} // uSClock
у меня же получается:
uint32_t micros(void)
{
register uint32_t ms, cycle_cnt;
do {
ms = sysTickUptime;
cycle_cnt = SysTick->VAL; // значение SysTick = 0хЕ000E010 ? SysTick->VAL = 0x00028831 ?
} while (ms != sysTickUptime);
return (ms * 1000) + (168000 - cycle_cnt) / 168; // а не нормально должно быть (ms*1000)+12 получается
}
остаётся вопрос по sysTickUptime …