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

Протоколирование работы ПО, пример в приложенном архиве. Сделать получилось очень через ()() и собственно о том вопрос, как это можно сделать более удобным образом. А суть весьма интересная (для пик-контроллеров проф. уровня) и заключается в http://caxapa.ru/377436.html
следующем: Ранее я писал, как можно выкрутиться из ситуации (см. ссылку), когда большой объём констатных строк не умещается в прошивке, и их можно перенести во внешнюю память. Идея в том, что на выходе компилятора (в данном случае GCC) можно получить файл прошивки и файл для внешнего ПЗУ (содержащего только строки), при том, что изначально строки вписаны в исходники естесственным образом. В памяти контроллера только остаётся адрес (во внешней памяти) и длина строки. Но обращаться к таким данным придётся уже вручную, через специальный макрос, например... Делается это таким образом, что строки попадают в специальную секцию, а потом с помощью objcopy она извлекается в файл для внешнего ПЗУ. На самом деле вся эта история в значительной степени вызвана наличием в программе большого количества сообщений используемых как протокол работы ("лог"). Их можно отключить, но на практике это означает значительные затруднения при дальнейших разборах полётов. Но если говорить только о протоколе работы, то можно допустить, что внешнее ПЗУ вовсе не нужно. Его роль может исполнять программа на ПК, принимающая от прибора адреса (смещения в файле) строк и другие данные и распечатывающая всё в человеческом виде. Т.е., например, если есть функция dprintf("message %s number %d", str, num) выводящая отладочное сообщение, то не обязательно в сторону ПК передавать строку "message blablabla number 123", можно передать попоросту аргументы функции dprintf в виде двоичных данных. И если str указывает на область константных данных, то попросту адрес передать. А если не константные данные -- то текст из str. Вместо строки формата передаётся её адрес в ROM. Но двоичные данные в силу разных причин неудобно передавать. Если это какой-то канал связи, то там могут быть ограничения на используемый набор символов. Если это попросту последовательный порт, то в этом случае принимающая сторона должна располагать специализированным ПО. Готового ПО для записи двоичных данных не существует (для текстовых строк же вполне годится тот же Hyperterminal). Кроме того, при передача текстовых данных удобно тут же глазами наблюдать за процессом, в реальном времени. И текстовые данные допускают какие-то искажения при передаче (копировании через буфер обмена: пропадание переводов строк, пробелов) -- при просмотре вручную это не слишком критично. Если же передавать адреса строк как есть, в двоичном виде, то нужна специальная программа, готовое ПО не позволит так принимать данные. В силу сказанного видится интересным такой вариант. Что какая-то часть наиболее важных данных по-старинке передаётся текстом (хотя бы для удобства наблюдения вручную). Не текстовые данные же передаются, например, в 16-ричном виде, но каждое поле данных разделяется каким-либо разделителем, например пробелом, что позволяет раздельную обработку полей (на приёмной стороне нет необходимости знать о размере типа данных в машинном представлении передающей стороны). Так, например, dprintf("message %s number %d variable %s", str, num, str2) превратиться в "$A123 $B456 123 "ddssds fdfdfd"", где $A123 -- адрес строки формата, $B456 адрес str (расположенной в сегменте константных данных), 123 -- число num, "ddssds fdfdfd" -- строка str2 в области переменных. Дальше, понятно, легко декодировать имея ROM файл зашитый в прибор (для извлечения строк из указанных адресов). Легко копировать через буфер обмена, редактор текста и т.п. Также частично информация видна глазами. Концепция в приложенном файле, как это можно сделать для gcc. Видно, что в test.out отсутствуют строки. Но они есть в strings.bin. И запуск "./test.out | ./decode strings.bin" их показывает. При том, что в исходнике (test.c, в самом конце) строки тоже есть.