Создание собственной системы стабилизации
ну на следующем пимпульсе поймает
Да там же основной цикл чтения положительного фронта “рвется” то есть значение в OCR увеличится на величину задержки в других прерываниях.
не я чего-то не догнал, в прерывании то что? запомнили цифирку с канала и дальше побежали, а дальше пусть основной цикл разбирается что с ней делать…
В основном цикле программы присутствуют еще прерывания от ДУСа , акселерометра, и прочей периферии, таким образом возможна ситуация когда фронт от сигнала с приемника попадет на момент обработки другого прерывания и будет пропущен, а у Вас там важное переключение режимов происходит.
Стоп - стоп, а как же очередь ?
Обработалось прерывание от ДУСа (как имеющее больший приоритет), обрабатывается прерывание от таймера(как имеющее меньший приоритет). Оно же никуда не изчезнет.
фронт от сигнала с приемника попадет на момент обработки другого прерывания и будет пропущен
Фактически вам нужен не сам фронт, а состояние пина на момент прерывания. Даже если немного упустите момент, ничего страшного не случится. Главное, что бы все прерывания какие у вас вообще могут быть, не занимали очень много времени.
Читать значения датчиков по прерыванию - не самая лучшая идея (Разве что использовать DMA, если есть возможность). По прерыванию можно выставить флаг готовности каких либо данных (например от акселя), а когда когда будет время, прочитать сенсор. При чтении сенсоров, главное что бы вы успели прочитать до прихода новых данных. В этом плане обработка сигналов от приемника - приоритеная задача, т.к. пропустить импульс достаточно просто - но с этой задачей без проблем справляется даже ATMEGA, что уже говорить про ARM32 😃
не я чего-то не догнал, в прерывании то что? запомнили цифирку с канала и дальше побежали, а дальше пусть основной цикл разбирается что с ней делать…
Все верно, в прерывании вызвали функцию обработки. Вся обработка происходит через функцию как раз для того, чтобы в случае прихода другого прерывания. после его обработки. вернуться в функцию обработки ШИМ и продолжить считать дальше.
Все что нужно успеть - это запомнить 1 цифру или сбросить таймер. все остальное не критично.
не догнал, в прерывании то что?
В прерывании Евгений (Geniok) переключает настойку триггера счетчика (фронты) см. выше пост…
Грамотно (не только мое мнение) делать как у “rual”, с учетом пропусков, или полностью аппаратно.
Да там же основной цикл чтения положительного фронта “рвется” то есть значение в OCR увеличится на величину задержки в других прерываниях.
Даже если так, хотя шанс меньше 0,0001%. ничего страшного не будет, на след. такте получим правильное значение.
У меня тут недавно была склейка 2-х периодов ШИМ на выходе каждый 0,4 с, на моторы никакое влияние не оказывало. (описывал на прошлой странице)
В прерывании Евгений (Geniok) переключает настойку триггера счетчика (фронты) см. выше пост…
Грамотно (не только мое мнение) делать как у “rual”, с учетом пропусков, или полностью аппаратно.
Это делается не в самом прерывании, а в функции, так что это переключение в любом случае произойдет.
В прерывании только вызывается функция.
Оно же никуда не изчезнет.
Оно не исчезнет ессно, но обработается позже согласно приоритетов которые Вы раздадите всем прерываниям, а у Вас импульсы то в реалтайме и ни как не засинхронизированы с другими.
В прерывании только вызывается функция.
Функция вызванная из прерывания - и является телом прерывания!!!
мы спорим помоему ни о чём, у меня весь цикл на F103-м занимает 4000 мкс (это с Кальманом и со всякой дребеденью) т.е. какое-то прерывание если и попадёт в шим, то сдвиг на 1-2 мкс (78 - 156 тактов) ну как-то - да приёмник шумит больше…
шанс меньше 0,0001%
Согласен, на практике может и прокатить, но лучше не рисковать…
Оно не исчезнет ессно, но обработается позже согласно приоритетов которые Вы раздадите всем прерываниям, а у Вас импульсы то в реалтайме и ни как не засинхронизированы с другими.
Функция вызванная из прерывания - и является телом прерывания!!!
Все верно!
Но, во-первых сама ошибка ни на что не повлияет, так как на следующей итериции цикла я получу правильное значение.
А главное, переключение фронтов все равно произойдет.
Еще раз говорю, 2 дня назад у меня стабильно каждые 0,4 секунды происходила склейка 2- периодов. То есть частота, выдаваемая на моторы падала до 25 гц, а величина заполнения ШИМ вместо допустим 1500мкс была 3000мкс. Это никак не влияло на поведение моторов.
Так что проблема надуманная. ИМХО.
P.S. Если очень переживаете, ставьте наивысший приоритет да и все.
Читать значения датчиков по прерыванию - не самая лучшая идея
Качество стабилизации , по моему , основная задача а оно зависит в первую очередь от частоты опросы ДУСа, аксель всеравно 50-ти герцовый фактически. Хочу как раз у себя попробовать (этож экперимент!) основноу приоритет отдать ДУСу, а остальные подождут…
вот я тут makefile поломал, ну и как искренне русский теперь бы инструкцию почитать, как они вообще делаются 😃
Качество стабилизации , по моему , основная задача а оно зависит в первую очередь от частоты опросы ДУСа, аксель всеравно 50-ти герцовый фактически. Хочу как раз у себя попробовать (этож экперимент!) основноу приоритет отдать ДУСу, а остальные подождут…
Чтение датчиков занимает кучу времени. Делать это в прерывании - не самая хорошая идея, имхо.
Тем более что ты все равно с ДУСа будешь иметь нектороый шум, который еще надо отфильтровать, и частота у тебя сама собой упадет.
Тут больше важно иметь все показания со всех датчиков одномоментно, то есть производить обноваление показаний с единой частотой для всех датчиков, допустим те же 50Гц.
вот я тут makefile поломал, ну и как искренне русский теперь бы инструкцию почитать, как они вообще делаются 😃
А от чего make ? На чем “сидишь” ?
eclipse gcc Cygwin+maple
- не самая хорошая идея
Это как раз все надо пробовать, “поиграть” -так сказать, все остальное и так как в известных готовых проектах, ограничено “железом”.
Это как раз все надо пробовать, “поиграть” -так сказать, все остальное и так как в известных готовых проектах, ограничено “железом”.
Ну чтож, тогда будет очень любопытно узнать результаты.
eclipse gcc Cygwin+maple
Ууу, ядерная смесь! 😃
Увы, не подскажу, сам на IAR и VisualStudio.
Качество стабилизации , по моему , основная задача а оно зависит в первую очередь от частоты опросы ДУСа
Вы меня не поняли. Читать значения акселя, надо с той частотой, на которую вы его настроили (ну если мы говорим о цифровом сенсоре). Только читать не обязательно сию минуту как пришло прерывание от него, у вас есть время это сделать до следующего прерывания.
Вот примерный алгоритм главного цикла программы
loop {
if (Gyro_ready) {
Read_gyro_data;
new_data_received = true;
}
if (accel_ready) {
Read_accel_data;
new_data_received = true;
}
if (new_data_received) {
Update_DCM; // Обновление алгоритма стабилизации DCM, MARG, CF, EKF ну или что у вас там
Set_Output_PWM; // Выставляем новые значения PWM на моторы
}
... другая работа что у нас еще осталась, например отправить телеметрию
}
Суть сего в том, что в прерывании от Гиры, вы выставляете флаг Gyro_ready и все. Прерывание занимает пару микросекунд времени, в итоге даже если прерывание от гиры, попадет на прерывание от Приемника, вы потеряете пару-тройку микросекунд, что при длине импульса PWM от 1000 до 2000мкс - практически - ничто.
Компилер CodeSourcery ARM EABI (2011.09-69)
это есть, ааа сейчас попробую пересобрать, кажется догнал в чём беда…
No rule to make target `objSTM32/dummy/../AeroQuad32/AeroQuadMain.elf', needed by `elf'. Stop.
нет правила для сборки, блин где ж его найти, патчи настроены всё видится, чего-то ещё не хватает, затык был сначала тут:
LIB_MAPLE_HOME = …/Libmaple/libmaple
убрал лишнюю точку - всё увиделось LIB_MAPLE_HOME = ./Libmaple/libmaple
проверте пожалуйста
сам и проверил на работе всё нормально…
Компилятор начал подавать признаки жизни, но что-то не так 😦
**** Build of configuration Default for project AeroQuad ****
make all
Compiling C: AeroQuad32/MapleCompatibility/flash_stm32.c
Compiling C++: AeroQuad32/AeroQuadMain.cpp
Compiling C++: AeroQuad32/MapleCompatibility/EEPROM.cpp
Compiling C++: Libraries/AQ_I2C/Device_I2C.cpp
Compiling C++: Libraries/AQ_Math/AQMath.cpp
Creating library: Libmaple/libmaple/libmaple.a
arm-none-eabi-ar rcs Libmaple/libmaple/libmaple.a objSTM32/dummy/./AeroQuad32/MapleCompatibility/flash_stm32.o objSTM32/dummy/./AeroQuad32/AeroQuadMain.o objSTM32/dummy/./AeroQuad32/MapleCompatibility/EEPROM.o objSTM32/dummy/./Libraries/AQ_I2C/Device_I2C.o objSTM32/dummy/./Libraries/AQ_Math/AQMath.o
Linking: objSTM32/dummy/./AeroQuad32/AeroQuadMain.elf
arm-none-eabi-gcc: ./Libmaple/libmaple/libmaple/syscalls.o: No such file or directory
rm Libmaple/libmaple/libmaple.a
make: *** [objSTM32/dummy/./AeroQuad32/AeroQuadMain.elf] Error 1
**** Build Finished ****