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

Цитирую: 

в пике форматируете вывод как вам удобно. то есть как потом удобно декодировать софтом. если хотите разбираться с парсингом текста - ну так принтф вам в руки. всё. под лабвиндовсом пишете парсер который все ваши параметры будет выводить на индикаторы, текст тоже можно выводить в любом виде.

Т.е. я на пике printf'ом форматирую как мне удобно, после чего посылаю labwindows по-дальше и читаю всё прекрасно глазами в hyperterminal. Не надо плодить сущности сверх необходимого. Когда понадобятся виртуальные показометры, тогда и будет labwindows, а скорей что-то своё. Но, что показательно, внутри получается тот же printf.

самая фича - продуманный API, что сокращает количество исходного кода в разы. я поэтому и подсел на эту вещь, да отказался от текстового терминала, что тут оочень быстро написать парсер, проверить CRC

Чтобы написать парсер -- нужно вначале определиться с "языком". Будь он текстовый или бинарный -- дело десятое. Только с бинарным работать гораздо сложней: набор символов полностью пересекается с передаваемыми данными (как разделять поля данных, например?), есть проблемы интерпретации числовых значений (ввиду разного предствления в разных ЭВМ). Да, для бинарных протоколов разработаны средства вроде ASN.1, BER, google protobuf, вариантов много. Но чем оно модней и современней, тем хуже лезет внутрь МК. И во всём этом CRC -- последнее дело. CRC можно и в текст добавить, а-ля NMEA или Intel HEX. Вопросы на засыпку: почему Intel HEX текстовый? И проблем с его интерпретацией на порядок меньше, чем с бинарными elf и т.п. Вы же скорей имеете ввиду какой-то крайне примитивный случай, мол у вас передаётся один единственный пакет (C-структура, например) и тогда просто и удобно. А если данные могут сильно различаться по составу (типу)? А если на 90% данные уже состоят из текста? Почему бы сразу не передавать текст, а не заниматься чем-то странным.