Микроконтроллеры

Спору нет, hsh очень непроработан http://caxapa.ru/pyramid/
к сожалению (для развития hsh), мы уже отказались от wake. Но не потому что он плох, нет, это хороший протокол, и хорошо документированный. Но есть два "но": 1. Нет квитирования - слейв должен знать, что его ответ дошел до мастера. Ваша мысль о переносе битов квитирования в байт команды очень хороша и "в духе wake"! 2. Так уж есть, что wake описывает Data Link и Network уровни протокола (OSI). В этом его сила (все уже сделано) и его слабость (надо постараться, чтобы положить его, например, на modbus RTU или ASCII, или даже на SLIP). Недавно тут обсуждалась Пирамида - вот пример независимости от Data Link уровня (ссылка на обсуждение с автором http://caxapa.ru/m …wwwboard.html?id=11961). Повторю, wake - хороший протокол для сферы, где он предназначен изначально, но его развитие несколько затруднено (особенно п.2.). Теперь о ваших замечаниях/комментариях: 1. "Квитирование реализуется на командном уровне." Можно делать и так (реализовывать ack на уровне приложения), но ведь мы хотим по максимуму делать на более низком уровне. 2. "Не совсем понимаю, зачем нужна команда «запрос разъединения»." Ее передают и мастер, и слейв после рестарта. Мастеру, может быть, интересно знать, что слейв ресетнулся. Вот от "закрытия соединения" я бы отказался легко :). 3. "Не понял, как это у Вас приемник второй раз передает подтверждение пакета 1, не приняв пакет 2 от передатчика?" Вы правы, это надо убрать. 4. "Получается, у Вас приемник всегда после рестарта по собственной инициативе передаёт пакет с кодом команды «нет соединения»?" Еще раз правы, это я тоже выдрал "и другой оперы" и для обсуждаемой темы это не годится..