Создание собственной системы стабилизации
Я у себя немного накосячил, удалил гербер файлы для заказа, сейчас на скорую руку переделал, у кого есть GerbView, проверте пожалуйста, ибо у меня была 30-дневка - кончилась… там обе платы…
Top Layer: pcbname.GTL
Bottom Layer: pcbname.GBL
Solder Mask Top: pcbname.GTS
Solder Mask Bottom: pcbname.GBS
Silk Top: pcbname.GTO
Silk Bottom: pcbname.GBO
Drill Drawing: pcbname.TXT
Не забудьте, что Вам придется еще учитывать возможные пропуски прерываний! а то показания “скакать” начнут…
Я передумав кучу вариантов все же остановился на использовании аппаратного режима чтения PWM, проще всего, но пришлось отказаться от 8 и задействовать только 4 (количество свободных счетчиков), а остальные решил на отдельное устройство выводить (все равно они дискретные как правило).
А что значит пропуски прерываний?
Скорость изменения ШИМ мне кажется физически будет меньше, чем 50 Гц.
Нас ведь интересуют только изменения положения стика управления. Таким образом частоту опроса можно поставить хоть 1 Гц, так что даже если прерывание будет обрабатываться только раз в секунду, ничего страшного не будет.
Я бы с удовольствием его вызывал только при изменении скважности ШИМ, но увы, такого способа нет, во всяком случае программно.
Скорость изменения ШИМ мне кажется физически будет меньше, чем 50 Гц.
Нас ведь интересуют только изменения положения стика управления. Таким образом частоту опроса можно поставить хоть 1 Гц
ничего подобного. например, видели как упраляют 3D вертолетом профессионалы? они стики с такой скоростью дергаю что они их даже не видно становится. и приемники у них выдают частоту шима 70Гц. поэтому про частоту опроса в 1 Гц даже и не думайте, проверено. прием шима - это приоритетная задача, и нужно опрашивать его с той же частотой что и выдается он с приемника. а вот все остальные датчики, баро, компас, джипиэс, можно опрашивать в между делом и то, лучше как минимум в 2Гц.
ничего подобного. например, видели как упраляют 3D вертолетом профессионалы? они стики с такой скоростью дергаю что они их даже не видно становится. и приемники у них выдают частоту шима 70Гц. поэтому про частоту опроса в 1 Гц даже и не думайте, проверено. прием шима - это приоритетная задача, и нужно опрашивать его с той же частотой что и выдается он с приемника. а вот все остальные датчики, баро, компас, джипиэс, можно опрашивать в между делом и то, лучше как минимум в 2Гц.
Ну это я утрированно конечно про 1 Гц, частоту опроса можно подобрать такую, что никаких пропусков не будет и управление вполне плавное. Лично для меня дергать стики даже с частотой 3 Гц управляя коптером как-то не реально… Тем более что при управлении интересует только конечное положение стика, а не весь путь, что он проходит за 0,1 с.
Ну и в конце концов если так хочется, ставь частоту опроса приемника 50 гц (хотя это нафиг не нужно, но если очень хочется, то можно) скорость обработки прерывания позволяет хоть 500 поставить, там инструкций очень мало., обработка занимает точно меньше 0,2 мс
А вот насчет датчиков не согласен, так как раз желательна максимальная частота для сглаживания погрешнойстей измерения. Да тому же Калману чем больше данных скормишь, тем быстрее получишь величину, близкую к истинной, ИМХО.
P.S. И не путайте частоту ШИМ с приемника и частоту изменения ШИМ. Приемник может хоть 400Гц выдавать, это его личгное дело, опрашивать с такой частотой изменение смысла нет абсолютно.
А что значит пропуски прерываний?
В основном цикле программы присутствуют еще прерывания от ДУСа , акселерометра, и прочей периферии, таким образом возможна ситуация когда фронт от сигнала с приемника попадет на момент обработки другого прерывания и будет пропущен, а у Вас там важное переключение режимов происходит.
ну на следующем пимпульсе поймает, не уж-то вы с частотой 50гц режимы переключать задумали, это первое второе есть ещё приоритеты и т.д. 😃
ну на следующем пимпульсе поймает
Да там же основной цикл чтения положительного фронта “рвется” то есть значение в 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