Hexapod

=DeaD=

blindman писал(а):

обработчик прерываний, в котором только вызов, сохранение и восстановление регистров занимают свыше 90 тактов?

Можно ссылочку где почитать почему это именно 90 тактов?

blindman писал(а):

DeaD, ты же должен прекрасно понимать, что тот метод, что используешь ты - не панацея. У каждого метода есть свои достоинства и недостатки, и их надо учитывать в каждом конкретном случае.

Я его панацеей и не объявлял пока

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

blindman

Да наворотить можно всякого. Стоит вполне определенная задача - управлять 18 сервами мегой16. Решается она просто, без всяких внешних примочек, с минимальной загрузкой процессора, остается куча ног для всяких датчиков - больше ничего не надо.

Сдается мне, что тот, кто не разберется с простейшей микросхемой счетчика, вряд ли сможет успешно программить многоконтроллерную систему

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

=DeaD= писал(а):

Можно ссылочку где почитать почему это именно 90 тактов?

Ссылочки почитать нету, но посмотреть можно легко. Открываешь тот проэкт, что ты выкладывал в вики, в avr studio, запускаешь симуляцию , смотришь в дизассемблере код прерывания по таймеру -- сколько там регистров сохраняется на входе и восстанавливается на выходе, считаешь циклы. Попутно замечаешь, с какой частотой вызывается это прерывание.

=DeaD= писал(а):

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

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

=DeaD=

У меня всё еще остался вопрос - как всё-таки работает ваша схема на регистре сдвига в случае с 18 сервами? Сколько и каких ног ей надо и сколько обвязки в виде регистров сдвига надо будет делать для этого?

blindman писал(а):

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

Симметрично. Вы вдруг решили, что лишних несколько корпусов логики ну абсолютно никому не мешает, а вот МК все просто под завязку используют. Однако я сужу не просто так, а по тому какие проекты тут вижу, а вы можете показать проект на этом сайте который МК под завязку пользует? Ну или хотябы на 10%, кроме как для управления серв? Только вот не надо рассказывать, что вот еще немного, совсем чуть-чуть, и они как ломанутся хотя-бы на 50% МК пользовать...

PS: Если у меня это занимает 90 тактов - это не значит что нельзя уменьшить это время, там столько всего наворочено в этом прерывании, поскольку я как раз делал самостоятельный проект и для меня использование хоть 95% производительной мощности МК было некритичным, поскольку у меня этот МК больше ничего не делал кроме этих задач.

hudbrog

Хм.. а я поддержку оратора про использование отдельной логики, а не мощностей основного процессора. Самому лично приходилось мегу8535 забивать на 100% программируя на ассемлере, а потом еще и долго заниматься оптимизацией кода, выбивая нехватающие десятки байт.
Только вот что именно использовать в качестве отдельного элемента - вопрос еще тот, и тут каждый выбирает то, к чему больше привык. Или что удобнее в контексте конкретной задачи. Видел несколько проектов где для управления почти всей переферией выделялась отдельная авр, которая тока тем и занималась, что опрашивала состояния энкодеров, давала управляющие сигналы всякой внешней фигне, а для основного процессора это все упаковывала в аккуратные пакетики и передавала по удобной шине. Для кого-то это может оказаться удобнее заменить на ПЛИСку, или и вовсе взять кайпрессовский псок. Но использовать почти все ресурсы камня для выполнения побочной, в общем-то, задачи - не стоит. все это мое имхо.

EdGull

батенька! не забывайте, речь идет исключительно об единичном экземпляре!
или вы 8535 тоже для единичного экземпляра на асме под 100 помидоров забивали? :wink:

hudbrog

Дык, ясный пень для серии забивал. Для единичных экземпляров я давно уже всех агитирую идти на армы и забывть про подобные проблемы. А еще использовать внешние модули, когда вес и размер готового продукта не принципиальны.
Для данной задачи то как раз, если бы речь шла о серии, то я бы посидел с бумажкой и посчитал, насколько реально уместить и управление сервами и остальной код в одну микросхему. И сделал все в одной меге.
А тут речь идет об одном экземпляре, потому я и говорю что надо использовать несколько микросхем сразу. Лично я бы вообще не замарачиваясь сходил в магазин, типа терры той же самой, и купил готовый модуль управления 16ью сервами. Ибо стоит он около 1к рублей, время, которое я бы затратил на разработку этой, примитивной в общем-то вещи (а потому не интересной для разработчика), стоит сильно больше.

blindman

=DeaD= писал(а):

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

Конечно. Я что, лысый ?

Я ж никому ничего не навязываю. Здесь уже привели немало ссылок на разные реализации задачи, и я еще раз повторюсь, что нужно смотреть на специфику задачи. В вике сегодня-завтра выложу примеры - хочу собрать все по теме в одном месте. Что использовать - личное дело каждого

=DeaD= писал(а):

как всё-таки работает ваша схема на регистре сдвига в случае с 18 сервами? Сколько и каких ног ей надо и сколько обвязки в виде регистров сдвига надо будет делать для этого?

Для 18 (до 20) серв достаточно будет 2 счетчиков 4017 и 4 ног контроллера -- OC1A и OC1B на тактовые входы счетчиков, еще 2 любые на входы сброса. У счетчика 10 выходов, с каждым тактовым импульсом единица перемещается на следующий выход. При макс. ширине 2000мкс как раз укладываемся в 20мс. При этом прерывания возникают в худшем случае 2 раза за 1мс, а не раз в 10мкс!

И еще раз : для данной задачи, как ее описывает топикстартер, внешние компоненты не нужны. Делаем 2 прерывания от 16-битного таймера, и в каждом рулим 9(10) сервами -- так же как в случае с внешним счетчиком только устанавливаем биты портов программно в прерывании

=DeaD=

hudbrog писал(а):

Самому лично приходилось мегу8535 забивать на 100% программируя на ассемлере, а потом еще и долго заниматься оптимизацией кода, выбивая нехватающие десятки байт.

Вот вы скажите честно:
1. Какую задачу решали и какое отношение она к робототехнике имела?
2. При чем тут десятки байт? Когда мы говорим о производительности? Вы на 100% производительность МК пользовали?

hudbrog писал(а):

использовать почти все ресурсы камня для выполнения побочной, в общем-то, задачи - не стоит.

Не стоит когда у вас есть куда использовать эти ресурсы. Я утверждаю что большинство даже не собирается эти ресурсы использовать хотя бы на 20-50%. Жду доказательств обратного, крайне желательно, чтобы это был проект из робототехники и адекватно сделанный, а не реализующий delay через пустой цикл.

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

blindman писал(а):

для данной задачи, как ее описывает топикстартер, внешние компоненты не нужны. Делаем 2 прерывания от 16-битного таймера, и в каждом рулим 9(10) сервами -- так же как в случае с внешним счетчиком только устанавливаем биты портов программно в прерывании

Вот это другое дело

так бы сразу и начали - с такой схемой я категорически СОГЛАСЕН

И производительность МК разгрузили и внешних элементов не налепили. Кстати, я не понял тогда, а зачем вам еще и внешние элементы? Ноги МК разгрузить что ли?

Правда для случаев шасси на колёсах но с манипулятором такое не пройдёт - там ШИМ нужен для движков, но всё равно вариант очень даже применимый для большинства.

blindman

Ну во-первых, в манипуляторе не 16 серв и даже наверно не 8, а во-вторых - не забываем, что есть еще 2 8-битных таймера -- можно их использовать для движков, или использовать 8-битные для серв (с ухудшением разрешения), а 16-битный - ШИМ на движки.

Да, внешние компоненты нужны, если ног не хватает. А что там будет - счетчики, регистры, или еще один МК - дело пятое. Я сейчас делаю контроллер на 32 сервы (реально потребуется пока не больше 24, но запас не помешает). По ресурсам вполне хватит меги32,если код разрастется -- можно будет заменить на 644. Если бы там были только сервы -- просто вывел бы все ноги наружу, как раз 32. Но там еще на SPI радиомодем, плюс датчики и индикация. Поэтому буду ставить 4 x 4017, и использовать все таймеры. ИК-диоды и тсопы правда обламываются

hudbrog

Цитата:

Вот вы скажите честно:
1. Какую задачу решали и какое отношение она к робототехнике имела?
2. При чем тут десятки байт? Когда мы говорим о производительности? Вы на 100% производительность МК пользовали?

1) Официальное название: система радиочастотной идентификации объектов с переменным радиусом обнаружения. К робототехнике.. если когда захочется сделать локацию робота по радиомаячкам - вот это примерно он =) Определяло расстояние до объекта с достаточно высокой точностью/вероятностью )
2) Использование производительности микропроцессора - очень спорный вопрос. Скажем, есть критичные места, когда приходится сидеть и считать такты, _отключать прерывания_, чтобы не тратиться на их обработчики и т.п., а есть времена когда микроконтроллер уходит в sleep на десятки миллисекунд.
А речь о производительности тут идет потому, что на мой взгляд, робототехника - это направление, требующее применения систем реального времени. Когда задержка отклика на изменение условий в единицы милисекунд может привести к опе (например, от гиры/акселерометра приходит сигнал о том, что робот потерял равновесие). И вот тут дергать прерывания каждые несколько десятков микросекунд - неприемлемо. Потому что прерывание, которые может произойти в любой момент, требует сохранения всех регистров, которые его обработчик будет изменять, это десятки (а то и сотни) тактов overhead'а. И соответственные задержки.
Если все что вы собираетесь делать - это рулить сервами, тогда конечно, соклько угодно. А вот если вы хотите, как тут описывают, летающие роботы, или еще какую-нить такую радость - тогда уж извините.

=DeaD=

blindman писал(а):

Ну во-первых, в манипуляторе не 16 серв и даже наверно не 8, а во-вторых - не забываем, что есть еще 2 8-битных таймера -- можно их использовать для движков, или использовать 8-битные для серв (с ухудшением разрешения), а 16-битный - ШИМ на движки.

8-битный вроде только один с компаратором

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

hudbrog писал(а):

Если все что вы собираетесь делать - это рулить сервами, тогда конечно, соклько угодно. А вот если вы хотите, как тут описывают, летающие роботы, или еще какую-нить такую радость - тогда уж извините.

И много тут сделано было летающих роботов?

blindman

=DeaD= писал(а):

8-битный вроде только один с компаратором

Два во всех мегах, кроме мега8, 8515 (может и 8535 - не помню). А в некоторых моделях они еще и двухканальные

hudbrog

Цитата:

И много тут сделано было летающих роботов?

Совсем оффтопик уже, но это вопрос подхода. Есть подход более сложный/дорогой, но и гибкий. Есть подход менее гибкий, зато быстрый и простой. Я ситаю что правильно обучать более сложному подходу, зато позволяющему в дальнейшем расширяться. Хотя, может я и не прав. Может для популяризации направления стоит идти по простой дороге.

=DeaD=

blindman писал(а):

Два во всех мегах, кроме мега8, 8515 (может и 8535 - не помню). А в некоторых моделях они еще и двухканальные

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

Redallex

Цитата:

1) Официальное название: система радиочастотной идентификации объектов с переменным радиусом обнаружения. К робототехнике.. если когда захочется сделать локацию робота по радиомаячкам - вот это примерно он =) Определяло расстояние до объекта с достаточно высокой точностью/вероятностью )

2 hudbrog

Уже хочется сделать локацию робота по радиомаячкам

Вопрос: у вашей системы радиочастотной идентификации маяки со своим питанием или как метки RFID?
На сколько сложна в повторении система в домашних условиях на коленке? И на сколько я понял, это была комерческая разработка и исходников со схемами нам не видать как своих ушей :wink:

?

roboforum.ru

Hexapod

Кто сейчас на конференции