roboforum.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот это другое дело так бы сразу и начали - с такой схемой я категорически СОГЛАСЕН
И производительность МК разгрузили и внешних элементов не налепили. Кстати, я не понял тогда, а зачем вам еще и внешние элементы? Ноги МК разгрузить что ли?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2 hudbrog

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