konstantinmirin писал(а):Аргументы? Я привел конкретную проблему, решения которой в рамках подхода "один МК и канал на все устройства" я не вижу. Как можно одновременно упавлять несколькими устройствами? Допустим мне нужен постоянный поток видео с камеры (реализовывается с помощью ТВ-тюнера и радиокамеры), постоянный поток данных с дальномера(-ов) (реализовывается с помощью опроса дальномеров микроконтроллером) и в это время - повороты камеры, управление колесами и т.п. Как контроллер, занятый опросом дальномеров (или других сенсоров) может делать что-то еще?
А как вообще тысячи пользователей через один и тот же магистральный интернет-канал работают? И ничего, не хрюкают
konstantinmirin писал(а):Но привязавшись к такому решению, потом будет сложнее от него отойти. Просто "переписать дрова и поставить" не получится.
Какие есть мысли по этой проблеме?
Как раз перейти от такого решения к разветвленному никакой проблемы. Просто в драйвере, в адресе устройства записывайте не только i2c-адрес контроллера на шине, но еще номер COM-порта с которым работаете, а потом если что ставите 2 usb-uart моста и часть адресов переписываете на другой COM-порт. Всё давно продумано
логика полностью взята с годами проверенного решения - интернета.
konstantinmirin писал(а):- проблема одновременной работы при подходе "один МК на все устройства" принципиально не решается. Максимум что может быть - правильное управление каналом и командами за счет протокола, либо софтверного решения на компе.
Вопрос не в том, решается это или нет, вопрос в том, что это не является проблемой в таких задачах
konstantinmirin писал(а):Я думаю что найдя "золотую середину" - один МК на ГРУППУ узлов (на 4 колеса например, на два привода pan-tilt и т.п.) можно построить вполнеприлично работающую машину.
Безусловно, там же вы поймёте, что нафиг не надо несколько МК, если конечно портов этого МК хватит
konstantinmirin писал(а):Тут просто прикол - меньше железок - больше програмить; больше железок - меньше програмить. Но кроме количества кода беспокоит еще и быстродействие.
Прикол в том, что "больше программить" МК мы уже закончили - берите ORFA и юзайте
Добавлено спустя 3 минуты 29 секунд:konstantinmirin писал(а):Событийнай модель - это прекрасная идея. Более того, это и есть самый правильный подход. Но параллельность это не отменяет
Например, надо созадть событие "данные от дальномера" и передать его на комп. Когда создавать? Кто будет следить за тем, чтобы его создать? Прикольно было писать на прерываниях. Данные поступили - вот тебе и событие. Подумать надо, очень дельная мысль. Просто до конца проблему это не решает. Все равно надо по одному каналу передавать разные данные одновременно.
Забудьте пока про событийность, реализуйте её на уровне ПК, а через МК тупой опрос. Как только дорастете до задач где реально не будет хватать тупого опроса - там обсудим
а пока это придумывание вопросов на свои ответы
konstantinmirin писал(а):Верно, можно. Прога и так параллельная. Все что надо сделать - общаться с устройствами через один канал. И этот канал просто представить узлом (в терминах РОС) и сделать для него mutual exclusive доступ. Минус подхода только в том, что появляется "узкое место".
Не обязательно выносить этот канал на уровень ROS, хотя наверное желательно.
Чтобы место стало "узким" надо его нагрузить реальной работой так, чтобы оно перестало справляться, а так в любой системе можно придумать тысячи гипотетических "узких мест"
"обычные проги" давно не пишу.