debug console over AVR-ISP, Поток отладки направляем на ISP порт Опции

[demiurg_spb]

Хочется решить раз и навсегда проблему отладочной консоли для семейства AVR.
Хочется получить обычную консоль на ПК, которая принимает DEBUG-поток от AVR через LPT или USB-FT2232 программатор,
подключенный к MCU на ISP разъём. Поток данных односторонний MCU->программатор->ПК.
Видится 2 режима работы:
1 - UART (для мега64, мега128 и остальных имеющих TXD на ISP разъёме)
2 - SPI для всех остальных.
Нужно также предусмотреть спец-преамбулы для режима SPI, чтоб консоль не ловила весь SPI трафик MCU с периферией.
Может кто уже делал что-то подобное?
Может ReAl поможет и выпустит в свет новую прогу AVREL-CONSOLE? :-)
Сам готов помочь. Так, глядишь, сделаем общеполезную тулзу.

[Petka]

Если можно сделат soft-spi, то можно сделать и soft-uart. Причём если устраивает полста байт в секунду, то ~50*10=~500 -> 480бод или около софт-уарт делается легко при любой загруженности контроллера где-то в дебрях таймер-тикового прерывания. При этом практически не нагружая контроллер не только "в среднем", но и "в пике".

soft uart плох по той причине что он асинхронный, медленный, требует доп периферии, таймера как минимум =(. а так тоже применимо.

А хвостик с 74hc14 или max232 у меня есть и есть шлейф "для байт-бластера" с тремя колодками тоже - средняя ставится именно на такой хвостик и работает с выведенными на pin7,8 ногами. Это для тех плат, где SPI занят в системе, пара свободных ног осталась а единственный UART занят (или свободен - тогда выведен он).

как минус - лишние приблуды. одного программатора должно быть достаточно. потом всё это дело надо передёргивать...

По SPI - на мой взгляд, если хочется использовать аппаратный SPI как отладочную консоль между обращениями к имеющимся в системе SPI-устройствами, то таки надо своодный выход chip select и имеет смысл подумать о spi-uart-мосте на отдельной платке. Хоть max-каком-то, хоть в программаторе, хоть на специально для этого выделенной mega8/48.

на SPI тоже свет колом не сошёлся.

Если встречное устройство чужое, то тогда софтовые решения конечно не годятся, но аппаратные ввиде одногейтового логического элемента, ( которым, правда, нужно управлять ) отключающего RX модема на время передачи отладочной информации, будут работать.

опять-таки лишние приблуды. всё-таки посмотрите "abd-протокол" - нужно всего 3 сигнальных линии. приактически "никакие" накладные расходы на стороне отлаживаемого контроллера. (не нужны ни таймеры ни прерывания) такой-же минимум на стороне отладчика. нет абсолютно никаких требований на времянки. можно использовать любые свободные GPIO.

P.S. немного Offtop: предложенный мной вариант годится не только для AVR но и любого другого котроллера (ARM т пр.) как минимум с тремя GPIO =)

[zltigo]

приактически "никакие" накладные расходы на стороне отлаживаемого контроллера.

До тех пор, пока нужно делать "практически ничего" . Как только мне потребуется положить несколько байт зараз, то у железного UART может спасать FIFO, а у ногомахательных интерфейсов появятся накладные расходы, причем уже не "никакие" . Нет, я не утверждаю, что не надо использовать ногомахание никогда, просто это крайняя мера, а не штатное решение.

[Petka]

До тех пор, пока нужно делать "практически ничего" . Как только мне потребуется положить несколько байт зараз, то у железного UART может спасать FIFO, а у ногомахательных интерфейсов появятся накладные расходы, причем уже не "никакие" . Нет, я не утверждаю, что не надо использовать ногомахание никогда, просто это крайняя мера, а не штатное решение.

FIFO может быть как у железных решений, так и у софтверных, таких как abd-протокол. abd-протокол стоит воспринимать примерно как "uart+аппаратный контроль потока". только полностью синхронный и всего 3 линии.

[zltigo]

так и у софтверных, таких как abd-протокол.

Могут. Я отрицал этот факт?
Я только сказал, повторяю "..а у ногомахательных интерфейсов появятся накладные расходы, причем уже не "никакие" "
P.S.
А у 'abd' второй клок лишний - раз линия данных одна, то и захват линии клоков можно реализовать. Будет интерфейс 'a/сb/d'

[Petka]

А у 'abd' второй клок лишний - раз линия данных одна, то и захват линии клоков можно реализовать. Будет интерфейс 'a/сb/d'

вторая линия осуществляет квитирование. за счёт этого осуществляется flow control. попробуйте прочитать внимательно. на самом деле интересно ваше мнение.
P.S. abd - совсем НЕ SPI. Больше на abd похож I2C. но всё равно это другое.

[zltigo]

вторая линия осуществляет квитирование. за счёт этого осуществляется flow control.

flow control при необходимости обеспечивается тем, что тактировку осуществяет приемная сторона. Или та-же приемная сторона давит управление клоком.

Больше на abd похож I2C. но всё равно это другое.

Другое, отличающееся наличием аппаратной избыточности в виде дополнительного провода. При этом кроме I2C есть еще массовые решения на 2x сигнальных проводах - та-же PS/2 клавиатура. Впрочем, можно и об однопроводных поговорить - тоже массовых прототипов хватает. Если рассматривать интерфейс заточенный под отладочный терминал (допустима ассиметрия в том числе и по скорости и flow control), то софтовая реализация однопроводного не представляется сложной.

[Petka]

flow control при необходимости обеспечивается тем, что тактировку осуществяет приемная сторона. Или та-же приемная сторона давит управление клоком.

abd - двунаправленный. приёмных сторон две!

Другое, отличающееся наличием аппаратной избыточности в виде дополнительного провода. При этом кроме I2C есть еще массовые решения на 2x сигнальных проводах - та-же PS/2 клавиатура.

i2c - имет существенный минус для програмных реализаций - слэйв должен успевать за синхросигналом. т.е. передача не может быть приостановлена "посередине" транзакции. аналогично и с PS/2.

Впрочем, можно и об однопроводных поговорить - тоже массовых прототипов хватает.

однопроводные априори имеют треования к времянкам. т.е. нужен таймер или калиброваные циклы. если выскочило прерывание - прощай времянки...

Если рассматривать интерфейс заточенный под отладочный терминал (допустима ассиметрия в том числе и по скорости и flow control), то софтовая реализация однопроводного не представляется сложной.

вот только зачем? какой профит от этого? один провод меньше трёх. Но тема топика "over ISP" т.е. 3 провода уже есть. Я преложил и реализовал своё видение этого протокола на 3х линиях. причём эта реализация бесплатна при использовании программатора "by Petka" и прочих микроконтроллерных COM программаторов. + программаторы на "bitbang". т.е. теоретически все поддерживаемые avreal.

[Qwertty]

abd - двунаправленный. приёмных сторон две!

I2C тоже две.

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

Вы ошибаетесь. Приостановить слейв может - достаточно "придержать" SCL.

[Petka]

Вы ошибаетесь. Приостановить слейв может - достаточно "придержать" SCL.

Отнюдь! Слэйв может просто не успеть "придержать" SCL. именно по этой причине есть ограничения на скорость передачи в I2C. (10, 100, 400, 3400кбит/с). По этой-же причине софт-реализация Слэйва I2C сложнее Мастера.

Я тоже про двунаправленный говорю.

видимо мы говорим о разном. я говорил про полный двунаправленный flow control. как я писал выше при софтовой реализации слэйв i2c если не успеет (а как раз тогда и имеет слысл), то не сможет приостановить передачу в удобном для него месте.

Отнюдь. Простейший пример для затравки - '0' это импульс минимальной длительности соответствующий атомарной записи 0->1 - вещь вполне стабильная и конфигурируемая в терминале. '1' это импульс любой длительности, но гарантированно длиннее 'нулевого'.

передать импульс легко, согласен. а вот его софтово поймать - сложнее. разжевать почему?

Повторяю, плата это эти три ноги НАВСЕГДА отданные программатору "by Petka" и прочим.

В общем случае ДА. Многие вообще через JTAG отлаживаются и ничего, живут как-то =) Альтернатив вообще нет. Разве что через RESET отлаживаться, но это тоже отнюдь не всегда можно.

[zltigo]

видимо мы говорим о разном. я говорил про полный двунаправленный flow control.

Если говорить о терминальном применении, то двунаправленный нинафиг не нужен - достаточно, что-бы тупенькое отладочное устройство могло тормозить крутой терминал.

передать импульс легко, согласен. а вот его софтово поймать - сложнее.

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

разжевать почему?

Пока получается наоборот .

[Petka]

Если говорить о терминальном применении, то двунаправленный нинафиг не нужен - достаточно, что-бы тупенькое отладочное устройство могло тормозить крутой терминал.

Согласен. Если ограничиться только терминалом, то да. Может подойти и 1wire и i2c при наличии аппаратной поддержки со стороны теминала. Однако стоит вспомнить предысторию вопроса, то есть много уже готорых программаторов, в которой это поддержки уже нет =(. Большой популярностью обладают компьюnерные gpio программаторы (LPT, ftdichip bitbang и подобные).
Если конструктивно, то кто поделится с общественностью своим 1wire или i2c решением? Согласен даже провести тесты, что окажется быстрее/проще/надёжнее/удобнее.

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

Сейчас говорим о терминале, а через полчасика захочется ещё и команды устройством получать... Дамп памяти скинуть, калибровочные константы получить, серийник, в тестовый режим перевестись.... Я закладывался и на такое тоже. А вам есть что предложить для этого? =)

Пока получается наоборот .

тоже полезно =)

[zltigo]

Сейчас говорим о терминале, а через полчасика захочется ещё и команды устройством получать...

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

[Petka]

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

1-wire отпадает т.к. надо задействовать таймер.
До скольки предлагаете снизить скорость i2c? какой режим работы выберем? multimaster? если нет, то кто будет мастером?

[zltigo]

1-wire отпадает т.к. надо задействовать таймер.
До скольки предлагаете снизить скорость i2c? какой режим работы выберем? multimaster? если нет, то кто будет мастером?

Я хоть слово говорил, что надо эмулировать 1-wire или i2с? Это просто примеры решения определенного класса задач.
Сформулированную мной задачу - интерфейс для подключения терминала, ассимметричный, имеющий flowcontrol только от отлаживаемого устройства, могущий иметь разные скорости (от устройства больше, от терминала много меньше) и могущий иметь разные протоколы от и к устройству можно реализовать на одном проводе и без привязки ко времени на стороне отлаживаемого устройства. При этом сложность программно-аппаратных решений на стороне терминала значения не имеет, а на стороне отлаживаемого устройства достаточно ногомахания и работы по опросу.

[Petka]

...
Сформулированную мной задачу - интерфейс для подключения терминала, ассимметричный, имеющий flowcontrol только от отлаживаемого устройства, могущий иметь разные скорости (от устройства больше, от терминала много меньше) и могущий иметь разные протоколы от и к устройству можно реализовать на одном проводе и без привязки ко времени на стороне отлаживаемого устройства.

ПодЕлитесь решением?

[zltigo]

ПодЕлитесь решением?

Одним из многих? Легко.
Про передачу в сторону терминала уже писал. Про передачу в сторону устройства:
Устройство либо по запросу ввиде очень длинного засаживания линии терминалом, либо вообще все время, передает поминаемые ранее максимально короткие импульсы. В ответ на эти импульсы терминал может затянуть или не затянуть этот импульс на линии. Соответственно, передавая таким образом В ТЕМПЕ ДИКТУЕМОМ устройством свои нолики и единички. В случае, если используется непрерывный поток импульсов, фрейм передаваемый с терминала должен начинаться с затягивания импульса. Для работы по запросу, логично использовать запрос не для передачи 7/8 бит, а для передачи фрейма, концом которого является, например, комбинация из восьми незатянутых импульсов.
Вот такой один из первых пришедших у голову вариантов не требующих, вопреки Вашему утверждению, таймеров, прерываний и прочего на стороне устройства.
Думаю, что если объявите конкурс, то получите еще много работоспособных идей и для однопроводки. А уж для двухпроводки, когда можно использовать явное тактирование, и говорить нечего.

[Petka]

Одним из многих? Легко.
.....

сразу возникает первый вопрос:
устройство задавило линию: как "терминал" определит это устройство хочет передать очередной бит или это предлагают терминалу передать свой бит?

[zltigo]

сразу возникает первый вопрос:
устройство задавило линию:

Устойство НЕ давит линию, оно передает, когда хочет и может.

"терминал" определит это устройство хочет передать очередной бит или это предлагают терминалу передать свой бит?

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

[Petka]

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

Хорошо. Фрэйм закончился. Терминал получает "строб". Так это новый бит от устройства или предложение начать передачу для терминала?

[zltigo]

Так это новый бит от устройства или предложение начать передачу для терминала?

Мне казалось,что я все разжевал . Если строб, то готовность принимать от терминала, если импульс длиннее строба, то новый фрейм/байт.

[Petka]

Мне казалось,что я все разжевал . Если строб, то готовность принимать от терминала, если импульс длиннее строба, то новый фрейм/байт.

Видимо не всё. Возвращаемся к моему предыдущему вопросу: Терминал обнаружил начало (только передний фронт) импульса. Он не знает будет ли это строб или это "затянутый импульс". Что делать терминалу дальше? У терминала есть данные, для отсылки. Что делать?

[zltigo]

Возвращаемся к моему предыдущему вопросу: Терминал обнаружил начало (только передний фронт) импульса. Он не знает будет ли это строб или это "затянутый импульс".

Он может это узнать. Длительность короткого импульса определяемого быстродействием контроллера устройства ему известна, она-же соответствует времени через которое устройство просканирует наличие затягивания импульса терминалом. Значит у него есть этот интервал времени для разборок с длинной импульса. Можно наложить и протокольные ограничения, например, после передачи фрейма устройством, оно должно выдать не менее одного короткого строба в качестве разрешения передавать терминалу.

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

Видимо не всё.

Достаточно вариантов?

[Petka]

Он может это узнать. ......
Достаточно вариантов?

Достаточно. Дело за малым... Сделать соответствующий терминал. Видимо на программируемой логике. Ну и написать функции get/putchar для МК. И софт верхнего уровня, для использования всего этого. Будет-ли это когда-нибудь реализовао и будет ли это достоянием общественности? Сомневаюсь.

[zltigo]

Дело за малым...

Да.

Сделать соответствующий терминал. Видимо на программируемой логике.

Или на более быстром контроллере, или с обвеской в несколько корпусов дискретной логики. Но и CPLD/FPGA+CPU не редкость для всяческих USB ->Нечто адаптеров.

Ну и написать функции get/putchar для МК.

Ну это вообще-то считанные строки.

Будет-ли это когда-нибудь реализовао...

Это, или не это, но однопроводные интерфейсы при малейшем желании реализуемы, даже если дополнительно выдвигать условия подобные Вашим. Не говоря уже о двухпроводных. Три провода, это уже замного.