Собственно вопрос к тем кто пробовал,
работает ? глюки ? хинты ?

С самим ISP нималейших проблем быть просто не может. Конкретно "Magic" не пробовал - не интересен он мне.

Сам ISP понятное дело работает...
Интересует именно вопрос работы через конвертеры, а у меня их нету
Настораживают несколько вещей:
1. Команды смены скорости
2. Flow Control
3. Эхо всех посылок

У меня задачка немного другая на самом деле, мне нужно шить несколько LPC через другой контроллер,
а писать ПЦ софт как-то не хочется...

А какие проблемы? Обычная команда, как и собственно команда прошивки.



Где-же Вы там его узрели-то? Нету его.




Ну и что??? Хоть конвертор, хоть что, оно по жизни дуплексное, хотя можете и не принимать эхо, если не хотите.

Тока "абстрактный" переходник или мой софт должен ловить эту команду и менять скорость UART ?
Ну или не менять а отвечать что поменял...
Это Вы так шутите ?
Из даташита на LPC2103:
4.7 ISP flow control
A software XON/XOFF flow control scheme is used to prevent data loss due to buffer
overrun. When the data arrives rapidly, the ASCII control character DC3 (stop) is sent to
stop the flow of data. Data flow is resumed by sending the ASCII control character DC1
(start). The host should also support the same flow control scheme.
USB полнодуплексный ? Это как ?
то есть мне гарантированно что при отправке строки "Privet" эхо первых символов я получу еще до отправки всей строки ?

через FTDI работает без проблем плюс еще подключены DTR/RTS на reset и вход в бутлоадер.
правда я тоже обычно мажиком не пользуюсь.
FTDI как раз используется что бы не ставить на плате преобразователь уровней, а прямо от FTDI TTL идет на LPC.
Плюс еще большой выбор баудрейтов (не стандартных) т.е. можно шить на гораздо большей скорости, но тут гглавную задержку вносит протокол загрузчика - он полудуплексный и надо ждать ответ по USB. А если загрузиь в RAM простой код, который сразу по странице данные принимает (я делал по 8 кб), то тут скорость увеличивается кардинально.

Сообщение отредактировал KRS - Feb 5 2009, 22:28

Спасибо за инфу,
значит подозрения насчет "эха" вычеркиваем,
я с FTDI не имел дела,
что там со сменой скорости и flow control ?

Это Ваша команда. Не подавайте, если не хотите.



Какое отношение софтовый flowсontrol имеет к гипотетическим проблемам конвертора. А железного нет как класс. А с софтовым или сами разбирайтесь, либо операционке скажите, дабы разбиралась. Железу оно без разницы - байт и байт.



Ну и нафига Вам такие гарантии? Отправили всю строку и ждете пока эхо закончится, или просто подтверждение придет. Кроме того, чего-то Вас таже буферизация операционной системы не волнует почему-то .

насколько я знаю бутлоадер (я даже дизассемблировал некоторые версии и здесь писал о дыре, которую уже заделали) не использует бутлоадер flow control. Вообще бутлоадер в смысле обмена по UART довольно простой ( IMHO для бутлоадера так и должно быть). Ему и скорость UART по барабану!!! главное чтобы засинхронизировался!
А команда смены баудрейта в нем реализовано криво! там стоит проверка на стандартные значения!
Луче сразу коннектится на нужной скорости! Ее определить легко (зависит от возможностей чипа, есть ли там встроенный резонатор...)
FTDI позволяет установить любой баудрейт (который может получится из возможностей ее прескалера) об этом лучше читать в их даташите!
Могу сказать что я шил LPC2129 на скорости 250000, 125000

Это моя команда только если я сам пишу "прошивальщик",
а если она уже есть в софте(например в Flash Magic) ?
Писать парсер в контроллере - плохо
Писать свой софт для прошивки на ПЦ - пока считаем что то же плохо...
Ну не все так просто, в реальности меня интересует прошивка не только через USB-UART но и через RS485-UART,
я же уже вроде как объяснил что "конвертор" будет моим, поэтому и пытаюсь выяснить все возможные подводные камни.
Волнует, поэтому и вопросы...

Вообще софтовый и железный flow control под виндами обеспечивает драйвер а не программа! COM порт (в том числе и виртуальный) можно открыть указав софтовый flow control (XON/XOFF) и это уже проблема драйвера и железа! USB переходник если поддерживает XON XOFF должен это делать уже в железе, а не через USB.

НО еще раз про LPC бутлоадер. ну не помню я (я кстати и у LPC 2103 дизаасмблировал бутлоадер) что бы там было flow control. но даже если он и есть это формальность! он никогда не будет задействован потому что LPC без проблем успевает складывать принятые байты в RAM!!!

То есть реализация софтовой flow control вероятно не потребуется ?
Учитывая что "конвертер" USB-UART пишу я сам.
Я только двумя руками за,
за то чтоб скорость ни разу не менялась, только как определить нужную ?
115200 было бы разумно...
и никаких команд о смене скорости...



Подождите, что значит в "железе" ?
XON/XOFF для USB не преусмотрен, все это на уровне фирмвари, которую и нужно мне написать...

Да нет ее там. Просто не нужна совсем.



Плохо пользоватся  фигней общего назначения с картинками.



Тем более надо наплевать на "Magic" - Вы уже потратили время на бесплодные размышления, которого достаточно было для написания в первом приближении желаемого.




Задать в пределах оговоренных в документации.

Не будем тратить время на обсуждение остальных вопросов,
раскажите как просто прошить LPC через 485 интерфейс.

Конкретнее связки такие:
PC-USB-SAM7A3-LPC
PC-RS232-RS485-SAM7A3-LPC

и нужно шить LPC в любом варианте...

Просто и шить. Проблемы-то какие? В том, что эхо будете тупо свое получать или вообще не получать?

В первом варианте вообще никаких проблем - хоть как-то обеспечте прозрачную трансляцию байтов и все. У меня так бутовый загрузчик шьется своим AT200 через центральный контроллер блока, ну только разве центральный тоже  LPC

Второй вариант уже зависит от Вашей реализации шелезяк и софта в SAM (к чему, кстати, жтот зверинец из ARM7), но при построчной буферизации будет жить.