roboforum.ru

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

Разумеется ждет. На то оно и прерывание

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

Это все тлетворное влияние многозадачных систем . Народу начинает казаться, что сам процессор может одновременно выполнять несколько программ Так вот, это невозможно. Даже в винде на одноядерном проце все задачи выполняются по очереди, просто переключения между ними частые.

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

Да тормознул просто, мне многозадачность пока не нужна, просто пишу на асме программу и чтоб регистры не пересекались в основном цикле и в обработчике решил уточнить

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

Вообще такой совет: чем меньше связка МК, тем более надежно они будут работать, потому по своему опыту скажу что если ног МК хватает на все датчики и исполнительные механизмы, то лучше использовать один МК. А вообще МК связываются между собой: I2C, UART, SPI...

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

ИМХО I2C

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

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

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

Да. Но это не говорит ни о чем, кроме того, что "жизнь разнообразна в своих проявлениях".
Можно и противоположных историй напридумывать тысячу - и что? Это ни о чем не говорит.

У специализированных системах на микроконтроллере и "универсальных расширяемых масштабируемых систем"
совсем разные задачи и области применения. Если вам важно время разработки, или вы не уверены в спецификации
(то есть высока вероятность, что появится еще один неизвестный датчик, еще один канал связи итп.).
то стоит смотреть в сторону готовых компьютеризированных систем.
Например, http://sine.ni.com/np/app/main/p/ap/daq ... q,n24:cRIO (не реклама).

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

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

Только еще вам придется отлаживать и протокол взаимодействия причем на всех узлах,
вероятно дополнять протокол новыми средствами, если старых не хватает, ставить еще один МК и т.д.
Это имеет смысл, если задача, например, "не предполагает серийного использования"
или "цена не имеет значения" и т.п.
Разработка такой ("расширяемой" итп.) системы само по себе - совсем непростая задача,
а вот области применения (и рынки) очень ограничены.

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

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

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

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

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 сделать два отдельных канала. Прошу прощения что пишу без подготовки, но я как раз хотел бы узнать где можно про такое прочитать. Так же хотелось бы все таки узнать на сколько я не прав.