roboforum.ru

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

_________________
жизнь это компьютерная игра:сценарий так себе, зато графика потрясающая!
удиви печень:выпей воды!

Что-то не думаю что это будет "немного" дороже


К сожалению не четверть, а порядка 95% и жестко по времени.
А при специализированной схеме работы как в OR-AVR-M128-S уходит всего 5% времени и не жестко по времени прерываний.

Добавлено спустя 11 минут 8 секунд:

Что за суровые рабочие будни у школьников? а вообще можно просто будет сделать кнопку, которая на кирпичике заменит управление реальными движками на вывод на экранчик информации о выдаваемой на движки мощности и направлении.

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

Это вы что-то... накосячили... имхо.



Итого разрешение = 5*N+5 тактов проца.



Ну посчитать конечно надо...
только законченные кубики, простота соединений, имхо, предпочтительнее.

2Michael_K: Еще посчитаем вход в прерывание и выход из него, а еще прерывание с какой частотой вызываем? Чтобы обеспечить хотя-бы шаг сервы 5мкс (200 шагов от 1000мкс до 2000мкс)? Получается:

в 5мкс имеем при частоте 16МГц = 80 тактов.

Пусть у нас 32 сервы и мы их отрабатываем за 4 захода, это у нас постоянно будет 8 серв в работе.

Итого на 8 серв имеем 8*5+5=45 тактов уже + еще вход-выход из прерывания.

Ну и как? Сколько % проца это съест?

Добавлено спустя 48 секунд:
И при этом нашу работу постоянно будет колбасить это прерывание в самые неожиданные моменты

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

Будет вызываться каждые 5 миллисекунд и занимать одну миллисекунду.
С учетом входов-выходов и формирования передних фронтов...
...ну, я бы сказал, процентов тридцать пять от силы.
Пусть даже 50, но не 95 же!!!

Кстати, по восемь серв делить неправильно при такой проге.
Разрешение будет слишком большое - в байт позиция не влезет

Впрочем, это неважно!
Юзерской проге хватит и 5% при правильном построении окружения для нее.

Единицы измерения не те - не "милли", а "микро", но это мелочи.

Важно другое - почему 1 микросекунду то? В одной микросекунде 16 тактов всего. А надо вызов прерывания + 5*N + 5.

Вызов и возврат из прерывания это, наверное, минимум тактов 15-20, еще 8 серв + еще 5 тактов итого 40+5+15..20=60..65 тактов

60..65/80=75..81% - где 35% ?

Добавлено спустя 1 минуту 36 секунд:
Только кроме юзерской проги есть еще и обработка датчиков и работа с периферией (тем же экранчиком) и т.п. - всё это занимает время и будет хаотично прерываться обработкой серв.

В общем предлагаю просто привести пример контроллера на AVR, программируемого пользователем и спокойно отрабатывающего 32 сервы

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

Dead, при всем уважении, вы не поняли, видимо, суть проги...
Миллисекунда - это насколько может болтаться задний фронт сервы.
Таймер работает не с частотой разрешения, а с частотой ШИМ - то есть 50 герц
(рассмотрим только один "заход")
То есть он вызвался и миллисекунду молотит - формирует задние фронты.

Грубо говоря, вместо множества частых прерываний нужно одно редкое но длинное.
Так всякие оверхеды на входы выходы, подготовку регистров минимизируются.
Именно поэтому я и не стал описывать эти процедуры - они занимают относительно
немного времени, чем приведенный выше ЦИКЛ.

К этому же таймеру привязать прием из уарта в буфер, подсчет времени,
формирование звука, опрос кнопок, еще какую нужно скорострельную шнягу,
и юзерской программе останется только медленно и печально собирать данные
и готовить данные для этого "готового окружения".

Это несложно все делается... с моей точки зрения.

Michael_K, я понял суть проги даже в нескольких вариантах мы же перебирали всё это, пока думали как сервоконтроллер делать на 32 сервы

Мы сейчас про сколько серв говорим? Если про 32, то за 1мс просто не управится, т.к. 32*5+5=165 тактов, а в 5мкс у нас всего 80 тактов. Получается, что только 14 сервами можно так рулить с шагом даже 5мкс, а крупнее шаг делать особо смысла нет.

Добавлено спустя 1 минуту 10 секунд:
А если сюда еще добавить формирование звука, приём из уарта и т.п. - получится вообще штук 8 серв и всё. А 8 серв можно и на обычных прерываниях отработать, не залипая на 1мс.

Добавлено спустя 3 минуты 1 секунду:
Есть, кстати, более замороченный способ отрабатывать сервы пачками - работая сразу со всем портом целиком. Там теоретически можно попытаться успеть.

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

Тогда что за непонятки с миллисекундами.


Да, поэтому разбиваем по 14 - получаем три прерывания по одной миллисекунде
каждые 20 миллисекунд. Ну и еще три очень коротких для передних фронтов.
Это 3/20 = 15%... С учетом всяких оверхедов пусть 35!!!

Добавлено спустя 43 секунды:
Грубо говоря, вместо множества частых прерываний нужно одно редкое но длинное.
Так всякие оверхеды на входы выходы, подготовку регистров минимизируются.
Именно поэтому я и не стал описывать эти процедуры - они занимают относительно
немного времени по сравнеию с приведенным выше ЦИКЛом.

Добавлено спустя 1 минуту 17 секунд:

Да... И не больше 50% времени.

Нельзя целую миллисекунду сидеть в прерывании. Это минимум 10 пропущенных байт переданных по последовательному каналу на скорости 115200, и как минимум 1 при 19200. Можно еще кучу проблем поиметь, но одной этой более чем достаточно

_________________
Проект [[Open Robotics]] - универсальные модули для построения роботов
Модули Open Robotics можно приобрести в магазине shop.roboforum.ru

---

Day OFF? You must be pulling my leg! Stop making humor before someone sees you, fool!

---

Я же про это и говорю!!!
Воткните в конец цикла
sbic UCSRB,чего-то там
ldi tmp,UDR
st Y+,tmp
и ваша проблема будет решена, а цикл удлинится незначительно.

Ну, блин, разве это не очевидно?
Уж от вас-то, ребята, никак не ожидал...

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

_________________
Проект [[Open Robotics]] - универсальные модули для построения роботов
Модули Open Robotics можно приобрести в магазине shop.roboforum.ru

---

Day OFF? You must be pulling my leg! Stop making humor before someone sees you, fool!

---

Не понял мысли...
Способы есть разные, но не все они жрут 95 процентов.
Дороже, чем аппаратная поддержка? В каком смысле?

Я предлагаю фактически сделать окружение, с прерыванием по одному таймеру...

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

Про то и разговор, что тем самым навязываются юзеру какие-то приемы программирования, причем не вполне очевидные

Добавлено спустя 4 минуты 7 секунд:

В смысле загрузки процессора

_________________
Проект [[Open Robotics]] - универсальные модули для построения роботов
Модули Open Robotics можно приобрести в магазине shop.roboforum.ru

---

Day OFF? You must be pulling my leg! Stop making humor before someone sees you, fool!

---

А юзер этого и не увидит.
Он будет писать "Move(SERVO_7,15);"
и Get_Uart_Char();

Я предлагаю фактически сделать окружение, с прерыванием по одному таймеру...

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