roboforum.ru

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

Michael_K писал(а):Нет - заказывает у вас мозги с нужными опциями...
Да, немного дороже, но у него получается два полноценных законченных мозга,
а не один мозк и один довесок...

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

Michael_K писал(а):

Да и рулить кучей серв без специфичного контроллера как OR-AVR-M128-S

Да чего уж там больно специфичного? Софт только.
Четверть времени в прерывания уходит? Да и фиг с ним...

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

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

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

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

К сожалению не четверть, а порядка 95% и жестко по времени.

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

Код: Выделить всё

; Задние фронты серв внутри прерывания от таймера
loop:
   movw   Y,X      ;1 указатель на таблицу позиций серв
   inc   cnt      ;1 счетчик для ШИМ
   breq   done      ;1 досчитали до нуля?
; Серва1
   ld   tmp,Y++      ;2   Берем позицию первой сервы
   cp   cnt,tmp      ;1   сравниваем со счетчиком
   brne   skip      ;1/2 если равно
   сbi   SERVO1_BIT   ;2   сбрасываем бит
; Серва2
   ld   tmp,Y++      ;2   Берем позицию второй сервы
   cp   cnt,tmp      ;1   сравниваем со счетчиком
   brne   skip      ;1/2 если равно
   сbi   SERVO2_BIT   ;2   сбрасываем бит
...
; СерваN
   rjmp   loop      ;2 в цикле


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

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

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

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

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

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

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

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

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

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

Будет вызываться каждые 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 сервы

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

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

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

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

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

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

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

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

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

Michael_K, я понял суть проги даже в нескольких вариантах.

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

Если про 32, то за 1мс просто не управится

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Michael_K писал(а):Дороже, чем аппаратная поддержка? В каком смысле?

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

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

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

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