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

Допустим, у вас есть DCOM, RPC или что-то в этом роде, для связи приборов? Как вы поступите? Напишете какой интерфейс будет у каждой программы, какие функции, какие аргументы, какие возвращаемые значения (ну примерно как интерфейс паскалевского модуля, только без переменных, только функции). И через этот интерфейс сделаете взаимодействие. А теперь то же самое вручную через сокет или последовательный порт. Имя функции, аргументы, обратно возвращаемое значение... Пакеты завернуть в CRC и снабдить серийным номером (защита от повтора), реализовать повтор передачи и подтверждение приёма. Предусмотреть механизм однозначеного разделения пакетов (out-of-band символы). В каком именно виде передавать вообще не важно. Проще текстом. Тогда, при отладке, CRC можно отключить и работать руками. И наблюдать опять же удобно. Вопрос как изначально определить интерфейс. Я бы поступил таким образом: некий конечный автомат (на стороне подчинённого), общий для всех возможных функций, который для каждого состояния определяет какие функции могут вызываться и какие вызывать переходы между состояниями (внутри программы может и не быть автомата -- это для понимания логики). После (пере)подключения, установки соединения и т.п. всё начинается с одного известного состояния. А конкретный состав функций определяется уже скорей назначением прибора. Если требуется передача данных больших объёмов, или некоторые функции выполняются длительное время без возможности выполнения других функций -- это легко предусмотреть как отдельные состояния упомянутого автомата. Каждый ответ подчинённого прибора может состоять из кода текущего состояния и каких-то дополнительных данных например -- printf("\r%u %s %2.2X\r\n", state, message, crc). А каждая команда начинаться с префикса ('\r' в ответе), далее произвольное число пробелов (табов), далее команда, далее аргументы разделённые пробелами, далее (опционально -- при отладке отключается) разделённые пробелами CRC (считается от первого символа префикса до последнего непробельного символа), далее перевод строки. Префикс желательно такой чтоб с клавиатуры удобно вводить (например, ':', как в *.HEX) ну это уже несущественные детали (вспоминаем холивар текст vs bin), на самом деле можно в двоичных пакетах то же самое и отлаживать тогда вдвойне веселее (два говнокода вместо одного). Если RS-485 и сеть то придётся ещё и адрес, и тут, возможно, бинарный протокол лучше. Хотя и адреса руками писать можно, если что... Да, в текстовом протоколе нет проблем с разделением пакетов. В бинарном придётся либо полагаться на out-of-band символы (BREAK в RS232, например). Из-за этого в MODBUS и геморрой с таймаутами (там таймаут -- это признак конца). В TCP можно "urgent" использовать, но не стоит... (на разных платформах работает по-разному, но в rlogin используется -- посмотрите как устроен этот протокол). Либо кодировать с escape-символами (как это делает PPP, например), что мне кажется более адекватным способом. На таймаут я бы вообще не полагался (потом всё упрётся в конкретную ОС и драйвер порта, будете мучаться). Вещи вроде BREAK хорошо работают только до тех пор, пока нет задачи управлять через два порта и три tcp сокета подряд. А потом только escape или текст. Да, в тексте чисто двоичные данные (но их, обычно, мало) придётся кодировать, например, в hex. А числа текстом как есть, так даже проще, особенно float и т.п.