roboforum.ru

[=DeaD=]

Надо бы дотестировать и отправить тебе уже модуль
А пока едет - инструкцию напишем, там действительно дописать часа два, не больше.

[pashteet]

Протестируй, плиз, на "помехозащещенность", т.е. как себя будет вести дальномер, если крутить сервой (т.е. меняются ли его показания)

[=DeaD=]

Хм, а можно потом? Я сейчас что-то вообще зашиваюсь, а тут целый стенд надо будет собирать с программой на ПК, т.к. через терминал такое не отловишь...

[pashteet]

ну если не отловишь, тогда и Бог с ним =))))

[boez]

Сюда вот напишу, это ж вроде уже не поддержка, а обсуждение решений.

В общем предложение у меня немного поменять идеологию работы со счетчиками в сервоконтроллерах - в обоих, и на 32 сервы, и на 16. Приведенный вариант - модификация 4017/servo_lld.c на 32 сервы, откусив лишнее - получим на 16.

Основные моменты организации существующей прошивки: сброс счетчиков происходит единожды при инициализации, затем просто на каждый счетчик выдается цикл импульсов - 8 штук с заданными интервалами от 500 до 2500 мкс, затем еще 2 подряд и ждем остаток до 20500 мкс, все это делается в обработчиках OUTPUT_COMPAREXX. Режим таймеров - свободный счет (WGMx = 0000).

Я предлагаю такую последовательность: 500 мкс в состоянии 0 - синхронно все счетчики, затем 8 интервалов с заданными временами, отдельно на каждом счетчике, затем остаток до 21000 - общий для всех счетчиков (досчитавшие свою последовательность счетчики сидят в состоянии 9) и затем сброс. Достичь этого можно двумя путями:

1. Перевести таймеры в режим CTC по ICRx. Синхронный старт, одинаковый период - по идее они должны оставаться синхронными все время. Плюсы - четкий период 21 мс, минусы - нифига не понятно из даташита, будет ли это вообще работать. А именно, можно ли пользоваться всеми тремя OCRxy в режиме WGMx = 1100 и что с ними всеми будет происходить при TCNTx=ICRx, когда таймер перещелкивается на 0. Возможно, они просто еще раз щелкнут - ну значит надо ими щелкнуть обратно и только затем дать сброс.

2. Повесить обработчик на свободный Compare (OCR1B у целого контроллера и OCR3B у половинки) на 21000 мкс и в нем вписывать 0 прямо в счетчики таймеров. Плюсы - работать будет гарантированно. Минусы - период будет больше на время обработки прерывания - это будет заметно в случае если прерывания запрещены на какое-то время.

В любом случае выкидывается расчет calc_ocr[block][8], в восьмые ячейки по старту вписывается 21 мс и всегда там лежит, это гарантирует что девятый раз OCRxy не вызовется, период таймера наступит раньше. И проверка на восьмую ячейку из process_timer тоже уходит. В периоде таймера сбрасываются счетчики и ставятся все Compare на 500 мс (а можно меньше).

Приаттачены примерные исходники обоих вариантов. Компилилось и тестилось все исключительно собственным мозгом, так что могут быть любые баги

[blindman]

Что-то как-то сложно все. Надо оставить все как есть, только в одном из обработчиков прерываний добавить генерацию импульса сброса в момент, когда счетчик перешел из 9 в 0. Для этого обработчика чуть скорректировать начальное значение OCRxx чтобы этот обработчик срабатывал позже других, когда все счетчики уже гарантированно находятся в состоянии 0. Тогда импульс сброса не будет портить импульсы на выходах.

[boez]

Да не скажи, по размеру кода, особенно для 32-сервовой версии мой вариант может и поменьше будет - из четырех обработчиков выкидываются проверки на восьмую ячейку.

А переход из 9 в 0 в существующей версии не годится для сброса - он же плавающий по времени, он идет в начале "остаточного" интервала - может быть у одного счетчика через 8*0.5=4 мс от начала, а у другого через 8*2.5=20 мс. Жестко можно привязать только конец остаточного интервала - а в нем уже нужен переход 0-1, а не 9-0. Вот для этого я и добавил кусочек в 500 мкс после окончания остаточного интервала.

[=DeaD=]

Схема версии с энкодерами