leonidpr писал(а):
Спасибо за то что подробно описали процесс. вы правы, дело тут в неумении проектировать. Просто разработка под МК носит еще и свою специфику, как вы знаете, которая отражается и на процессе проектирования. я понимаю, что можно сделать модули, обслуживающие интерфейсы связи, а протоколы реализовать в виде задач, каждая из которых просто читает или пишет то, что модуль интерфейса накопил в буфере. Но мне кажется это неэффективным решением. ведь если оперировать терминами ОС, задача, обслуживающая протокол должна в таком случае периодически просыпаться, что бы посмотреть, пришло что-то или не пришло.
х-м-м, а вот тут идейка пришла. ведь можно сделать что-то вроде мьютекса, который будет взводиться обслуживающим интерфейс модулем, когда пришел блок данных. Соответственно задача, которой эти данные нужны будет спать, пока они не появятся. И плюс реализовать возможность сообщить модулю, обслуживающему интерфейс взводить мьютекс только по приходу N байт (ну или пакетов, не принципиально).
То что под МК разработка специфичная я знаю. А я думал у вас одновременно работает 1 или 2 устройства и не надо динамически, вернее автоматически переключаться между интерфейсами. Тогда вам нужен мультиплексор типа как железнодорожная сортировочная станция или как мультиплексор в телефонной станции(АТС).
Есть разные пути решения. Я бы даже сказал парадигмы программирования. Можно сделать как вы сказали процессами/потоками/задачами и планировать их работу усыпляя и пробуждая потоки. А можно и описать логику командным или функциональном стиле. Тогда пришли данные с генерировалось событие(или сигнал) который вызывал функцию, та быстро обработала параметры и вернула управление.
P.S. Если делать управление на задачах, то можно и на сообщениях сделать связывание. Правда то уже микроядро со всеми вытекающими последствиями.
Вход
Регистрация
FAQ
Поиск
