Протокол управления программатором, Взаимодействие ПО на ПК и ПО в МК :) Опции

[Reanimator++]

Разработал проект настроечной машины для электронных компонентов.
Суть в том что компонент содержит микросхему, машина проводит ряд измерений и зашивает в микросхему калибровочные данные.
Машина содержит программное обеспечение на ПК и измерительные-программирующие платы под управлением МК.

Со временем количество поддерживаемых микросхем стало расти, ПО компьютера и плат обновляться.

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

Особенно ситуацию усугубляло то что некоторые чипы поддерживают одинаковые протоколы с разным смысловым наполнением и соответственно со стороны ПК управляются одними командами.
У некоторых чипов наоборот от версии к версии протокол менялся (а в некоторых вообще были баги, требующие индивидуального подхода к отдельной ревизии чипа) при сохранении смыслового наполнения.

Появилась проблема проверки совместимости версий прошивки плат и версий ПО компьютера.
(где и какие поддерживаемые чипы, какие версии протоколов, баги и т.п.)
Начали появляться новые версии плат с измененным функционалом и другими поддерживаемыми чипами.


Хотелось бы организовать относительно простой и понятный протокол для управления всем этим безобразием.
Кто и как решает подобные проблемы? (когда задача одна - измерить и прошить - а способов ее исполнения множество).

[eugen_pcad_ru]

Мировые бренды постоянно разрабатывают и совершенствуют протоколы обмена. Присоединяйтесь к ним или проводите параллельную модернизацию.
ИМХО простого и понятного протокола для обмена с множеством совершенно разных устройств в принципе быть не может.

[Reanimator++]

Тут ваша подпись очень кстати, мой вопрос звучит как постановка задачи )

Наиболее близкое из устройств к моему - программатор.
Есть множество серийно выпускаемых программаторов и список поддерживаемых чипов у них исчисляется сотнями (тысячами?).
Разные семейства чипов требуют разных подходов.

Интересно как аналогичная задача уже решалась людьми.
Не хотелось бы изобретать велосипед.

Для меня даже более важен сам подход, нежели детали
- организация синхронизации версий софта ПК и софта МК (подход к перечню поддерживаемых устройств)
- масштабируемая структура протокола.

[V_G]

Если говорить о программаторах микросхем, то чаще всего это - промежуточное интеллектуальное звено между машиной и объектом программирования, со своим интерфейсом и софтом. Поэтому вряд ли стоит придерживаться идеологии построения интерфейсов программаторов.

Другой случай - прошивка настроечных данных (и часто самой программы) в конечный объект (микроконтроллер), снабженный стандартным интерфейсом и бутлоадером. Лично я, применяя процессоры семейства AVR, придерживаюсь системы команд атмеловского софтового программатора AVRProg. И даже свежие xmeg'и, не отраженные в настройках AVRProg, стараюсь с помощью своего бутлоадера представить известным программатору чипом. С некоторыми ограничениями, для меня некритичными.
К сожалению, AVRProg уже давно не развивается, потому в будущем возможны проблемы.

[eugen_pcad_ru]

Как правило это USB<>интеллектуальное_звено<>JTAG.
ИМХО перспективным может быть еще LAN<>интеллектуальное_звено<>JTAG. Есть примеры таких девайсов у Jtag Technologies.
В качестве интеллектуального звена думается лучше использовать встроенный комп с линухом (хоть я и не его сторонник )
Проблема в дальнейшей отладке по JTAG. Обычно хотят еще отлаживать по JTAG, и здесь неизменно приходится обращаться в родному железу и софту производителя.
Как-то так наверное.

[Bulaev]

Покупка ATE не решит проблему?

[A. Fig Lee]

Разбивается все на обьекты:
1) Какие напряжения выставлять.
Например, define A=12V, B=5V ...
2) Определяются критические тайминги
Аналогично A = 10 mS, B=20 uS
3) Определяются ноги.
4) поехали..
Выставить А напряжение на ноге Б, подождать время С..

Гдето так..

[Reanimator++]

Bulaev
Что есть ATE?

A. Fig Lee
Примерно понял вашу мысль. Получается развернутое текстовое описание программирующих действий в протоколе.
Что-то типа псевдокода.
Нужен только хорошо отлаженный исполнятор.
Особенно в плане работы с данными (какой бит выходных данных в какой момент подставлять, в какой момент считывать и куда класть результат).

Осталось только продумать вопрос совместимости исполнителей с головным ПО
Надо чтобы исполнитель сообщал свою аппаратную конфигурацию, список выходных пинов и поддерживаемых функций на них.
У меня на некоторых пинах есть такие штуки как установка аналогового напряжения, измерение аналогового напряжения, измерение частоты, температуры (температура относится ко всему устройству), и т.п.