roboforum.ru

Что то я запутался или просто туплю сегодня. При возникновении прерывания управление естесственно переходит на обрпаботчик соответствующий. Вопрос: при этом основной цикл программы продолжает выполняться или ждет пока закончит выполняться обработчик прерывания?

Понятно, так я и думал . Спасибо за помощь!

С практической точки зрения возможно одновременное выполнение нескольких задачь так как время мы измеряем и ощущаем с конечной точностью. 10-40 мС для человека это 1 мгновение - квант времени - и события произошедшие за это время можно считать одновременными.

Уровень -- начинающий, поэтому такой вопрос: В сложной системе с множеством датчиков и множеством исполнительных устройств использовать один микроконтроллер я считаю не совсем правильно. Такая же ситуация как в программировании (монолитные программы не пишут – разбивают на модули, классы и пр.). Мне бы хотелось спроектировать дерево микроконтроллеров. Тот, что в корне получает от компьютера команды и возвращает данные. Полученные команды разбирает, то, что относится именно к нему, выполняет, то, что относится к его детям (контроллерам следующего уровня) передает им . Данные от датчиков детей (и их детей и т.д.) объединяет со своими и их возвращает в ПК (что то типа XML). Отсюда вопрос – как организовать связь между контроллерами.

greyder писал(а):Отсюда вопрос – как организовать связь между контроллерами.

ИМХО I2C

Совмещать поддержку USB и вычислитель …, ну не знаю, дальности полета пули на одной ATTiny2313 тоже не очень эффективно и надежно (можно не комментировать). Задача – понять возможности и ограничения МК AVR. Я программист – оттуда и пурга. Повторное использование удачных решений повышает надежность. Потеря эффективности компенсируется быстротой разработки сложных систем. Обычно говорят так – самые эффективные программы по памяти и быстродействию можно написать на ассемблере, но пишут на Java, С, Basic и пр. .
Пример на пальцах: Задали построить устройство регулировки микроклимата в комнате – холодно закрываем форточку, жарко открываем. Не проблема -- 1 МК, 1 датчик, 1 исполнительный механизм. Собираем за пол часа. Потом оказывается, что при постановке задачи забыли сказать, что датчик с последовательным протоколом уже есть и надо использовать именно его – не проблема, разбираемся что за датчик, ковыряемся с протоколом, отлаживаем … . Потом выясняется что датчик не один а 4, нужно брать среднюю температуру, а форточка тоже не просто так открывается и т.д. . Кода подойдет время сдачи проекта какая-нибудь фенечка влечет к тому, что на нашем устройстве просто не хватает мультиплексоров опросить датчики или регистров для управления механизмами.
Такие истории можно писать сколько угодно и про любую область применения. К стати то, что я пытаюсь разузнать помогло бы развить «Проект [[Open Robotics]] - универсальные модули для построения роботов» (это я так подмазываюсь).
Теперь конкретный вопрос: Для связи МК с родителем (в режиме слейва) и детьми (в режиме мастера), что лучше использовать и как это лучше сделать? Оба направления должны быть. Каналы должны быть разные (один для общения с родителем, один для детей). Мне кажется i2c подойдет, но как это сделать?

Michael_K писал(а):Например, http://sine.ni.com/np/app/main/p/ap/daq ... q,n24:cRIO (не реклама).

Выглядит тяжеловесно, хотя детально не смотрел.

Michael_K писал(а):В вашем примере, вы потратите БОЛЬШЕ времени и денег на разработку,
так как с каждым новым датчиком вам все равно придется делать вот это это:

greyder писал(а):- разбираемся что за датчик, ковыряемся с протоколом, отлаживаем

Только еще вам придется отлаживать и протокол взаимодействия причем на всех узлах вероятно дополнять протокол новыми средствами, если старых не хватает, ставить еще один МК и т.д.

Потратить время на изучения этого вопроса сейчас и потратить деньги на пару тройку МК для реализацию этих идей я могу себе позволить. Протокол (логический) между МК я предполагаю что-то типа упрощенного XML. При появлении нового датчика придется менять только тот блок куда он подключен и тот который обрабатывает с него данные (поменять логику обработки данных если она изменилась). Остальные (их может быть между ними много) трогать не надо.

Michael_K писал(а):Разработка такой ("расширяемой" итп.) системы само по себе - совсем непростая задача,
а вот области применения (и рынки) очень ограничены.

Да, к сожалению это только хобби. Хотя, все зависит от результата.

Michael_K писал(а):А безапелляционно заявлять, что

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

- это неверно.
Это взгляд очень односторонний и зашоренный, имхо.
Реальность полна компромиссов.

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

То что хотелось бы получить в результате в прикрепленном файле (обведено красным). Повторюсь: Блок с каналом для связи с родителем (стрелка с лева) и с каналом для связи с детьми (стрелка и ромбик с права), также есть выходы как у обычного МК (PA, PB, ... те что останутся). По ощущениям достаточно 1 МК и 1 мультиплексора для того чтобы из одного i2c сделать два отдельных канала. Прошу прощения что пишу без подготовки, но я как раз хотел бы узнать где можно про такое прочитать. Так же хотелось бы все таки узнать на сколько я не прав.