hudbrog писал(а):Совсем оффтопик уже, но это вопрос подхода. Есть подход более сложный/дорогой, но и гибкий. Есть подход менее гибкий, зато быстрый и простой. Я ситаю что правильно обучать более сложному подходу, зато позволяющему в дальнейшем расширяться. Хотя, может я и не прав. Может для популяризации направления стоит идти по простой дороге.
Вообще правильным более простым подходом считаю вариант с прерываниями, которые вызываются только когда надо. Более универсальным и сложным подходом надо пожалуй считать дочерние МК, как предложили тут тоже уже.
А логику лепить вокруг контроллера - это только ноги экономить. Их вроде редко когда не хватает.
Вопрос: у вашей системы радиочастотной идентификации маяки со своим питанием или как метки RFID? На сколько сложна в повторении система в домашних условиях на коленке? И на сколько я понял, это была комерческая разработка и исходников со схемами нам не видать как своих ушей ?
Да, к сожалению ни исходников, ни схем дать не могу. Максимум - могу дать кусочек библиотеки работы с трансивером ATA5428 от того же атмела. Ибо этих библиотек, как оказалось, нет в природе почему-то. Хотя сразу скажу, что не стоит эту 5428 трогать. Зло это глючное. В некоторых моментах фактическая реализация отличается от даташита, что приводит к желанию разработчика повесица. Питались от одной литиевой батарейки-таблетки. Такой батарейки в штатном режиме работы должно хватать, по прикидкам, на годик примерно. Но это уже особенности. По поводу наколенности.. Прототипы плат и монтаж на них я заказывал, ибо дюже ленив. Хотя можно и спаять, коли руки на месте. Вообще задача-то не сложная, особенно если правильный трансивер выбрать. Проблему я там вижу тока одну - антенна. Ибо определение расстояния происходит по энергетике сигнала, а для большинства вариантов антенн(особенно миниатюрных и печатных) у них диаграмма направленности очень уж некрасивая.
Вообще правильным более простым подходом считаю вариант с прерываниями, которые вызываются только когда надо. Более универсальным и сложным подходом надо пожалуй считать дочерние МК, как предложили тут тоже уже.
Дык, а я о чем и говорил. За жесткую логику в отдельных корпусах я как раз никого ни разу не агитировал. Я агитировал за отдельное решение. Не обязательно МК. Может лучше даже ПЛИСы, но это уже отдельная песня, сильно зависит от требований решения.
Внешняя логика для управления стольким количеством серв - лучший вариант для данной задачи. Не вижу смысла спора, тут просто кому как нравица. Но еще раз повторю - для данной задачи логика будет как раз панацеей
Добавлено спустя 5 минут 35 секунд: кстати, на схеме что я приводил, можно было на одном таймере юзать до 32 серв если я не ошибаюсь..
Какую схему ты имеешь виду? Если из проекта Paparazzi - то нет, не получится. Просто принцип работы там такой - максимальное количество серв на одно прерывание равно периоду ШИМ / на макс. ширину импульса, т.е. 20000 / (от 2000 до 2500) = от 8 до 10.
Это хорошо. Только вот есть пожелание: т.к. концепция вики - это статьи, то максимум иллюстрирующего кода и схем публиковать не в архиве, а непосредственно в статье. Например, схему подключения 4017 по тексту вставить, чтоб не требовалось лезть в архив. Если есть возможность, то и какие-то ключевые куски кода запостить текстом со ссылкой, что рабочий проект в архиве... Тогда это будет законченный материал.
Uncle, если у тебя такие проблемы, то и советовать не стоит. Код смотрел? Комментарии читал? Какие вопросы по коду, что непонятно? В примерах достаточно комментариев, объясняющих, как сделать и 8, и 16, и 24.
ksp писал(а):Делаю робота на 6 ногах (18 серв): Подробности http://kspzel.livejournal.com/ Назрел вопрос: можно ли на ATMega16 НОРМАЛЬНО рулить 18 сервами? Нормально - значит хотябы 256 положений для одной сервы и чтобы при этом ничего не тормозило. У меня пока что положений 20 на каждую.
Где покупали сервы и сколько это стоило вместе с доставкой?
я конечно понимаю что ся всеми любима, но раз уж возникают моменты когда у вас 90 тактов тратится на сохранние регистров.. то либо у вас ся компилится через 5-ю точку, либо код ужасный.. если мне неименяет память то только SREG потребует на сохранение 6 тактов.. и по 4 на любой другой...сохранить 21 регистр... хех.. этож нада умудриться...
CC: cli in tmp, SREG ; 1 такт на чтение регистра статуса push tmp ; 2 такта на укладку байта в стек push r17 ; -----||----- push r16 ; -----||----- {interrupt code} pop r16 ; 2 такта на вытаскивание из стека pop r17 ; -----||----- pop tmp ; -----||----- out SREG, tmp ; 1 такт на восстановление регистра sei reti
итак, на положить вначале и достать вконце тратим 4 такта на 1 регистр на срег тратим +2 такта на его чтение.. ну итого было 90 тактов.. 90-6=84... срег сохранили.. 84/4 = 21...
Прекрасно. Хорошо считаешь. Правда не забываем, что для того, чтобы перейти с вектора прерывания на обработчик, а затем вернуться из прерывания тоже нужно время.
Компилятор не намного тупее человека, и если для реализации алгоритма компилятор использовал 20 регистров, в большинстве случаев вряд ли удастся написать на ассемблере используя только 10. А вот насколько оптимален алгоритм - это уже другой вопрос.
они вроде не совсем лишние, пример выдрал с проги что недавно писал.. разве прерывания запрещаются при входе в прерывание ? можно запретить прерывания после сохранения СРЕГ-а, но есть маааленькая вероятность что в этот момент произойдет еще одно прерывание.. я лучше напишу наверняка.. тем более пара байт кода не добавит объема проге, которая и так процента памяти не занимает
на си для контроллеров писать так и не смог, рука не поднимается )))
из опыта написания прог на сях для ПК, скажу что на переменные не скупился.. а тут как-то сразу ощущаешь ограничения.. ив небольших прогах как-то привыкаешь пользоваться отдельными регистрами под отдельные нужды.. и потому при входе в прерывание врятли используется более 5-7 регистров...
?
