ISP: в эхе пропадают символы перевода строки, в эхе пропадает '\n' Опции

[guest53493]

Возникла необходимость написать собственную программу прожига прошивок для LPC2129 (версия загрузчика 1.70). При реализации протокола ISP обнаружилась следующая особенность. Когда посылаешь команду через UART, загрузчик, как известно, по умолчанию возвращает эхо этой команды. Команда должна заканчиваться парой символов возврата каретки и перевода строки ('\r\n'). Так вот, бывает так, что в эхе символ '\r' приходит, а '\n' - нет. А вместо '\n' приходит, например, буква 'O' (первая буква слова OK - результат выполнения команды). У меня прога ждёт эха на каждый отосланный символ, поэтому, естественно, возникает ошибка.

Проблему эту, конечно, можно обойти, но всё-таки интересно - это такая "особенность" ISP или я делаю что-то не так? Знающих прошу отозваться.

[andrewlekar]

Я в своём программаторе (LPC1768, LPC1114) вообще решил отключать эхо. Это оказалось проще, чем парсить всё, что там валится.

[esaulenka]

Микро-советик.

Делал программатор для LPC1111, тоже было лень разбирать, что за эхо валится.
Послал команду отключения эха, и несколько дней разбирался, что за хрень происходит. Почему-то чтение прошивки (для проверки) при отключенном эхе работало совершенно некорректно.
Помучался-помучался и включил эхо обратно. Не так и сложно его отрабатывать (во всяком случае, если оно себя "штатно" ведёт).

Не исключаю, конечно, что у меня руки кривые, но на идеальность NXP'шного загрузчика теперь не расчитываю :-)


Посмотрел: побайтово эхо сравнивать я поленился, но длина "что послали" и "что отразилось" совпадает. Все отправляемые строки заканчиваются /r/n, если что.

[guest53493]

Спасибо ответившим.

Почему-то чтение прошивки (для проверки) при отключенном эхе работало совершенно некорректно.

У меня наоборот: без эха работало корректно, с эхом - хрень. При внимательном прочтении описания протокола обмена обнаружилась интересная деталь:

All ISP commands should be sent as single ASCII strings. Strings should be terminated with Carriage Return (CR) and/or Line Feed (LF) control characters. Extra <CR> and <LF> characters are ignored.

Короче, я подозреваю, дело у меня было вот в чём. Загрузчик воспринимает три типа строк: с '\r' на конце (ввод с клавиатуры), с '\n', и с '\r\n'. При этом, после получения '\r' он, видимо, ещё некоторое время ждёт '\n', и, если тот не приходит, считает это концом строки и начинает выдавать свой ответ. У меня программатор работает посимвольно, т.е. посылает символ - ждёт эха - сравнивает ответ - посылает следующий символ и т.д. Я думаю, что пока я дожидаюсь эха на '\r', сравниваю ответ и посылаю следующий '\n', наступает таймаут ожидания и загрузчик решает, что строка закончилась.

Всё нормально заработало, когда я стал завершать все вводимые строки не '\r\n', а '\n'. Что интересно, все известные мне программаторы заканчивают строки на '\r\n', но все они посылают команды строками, а не посимвольно. При этом ответы всегда приходят с '\r\n' на конце, независимо от вида строки запроса.

И да, без эха всё работает ощутимо быстрее. Основное время приходится на передачу данных по UART.