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 отлаживаться, но это тоже отнюдь не всегда можно.

[Qwertty]

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

Успеет. Он просто не сможет опоздать - достаточно держать SCL в 0 все время, когда слейв занят чем то другим, а не мониторингом шины. Скорость конечно может получиться очень низкой, это зависит от загруженности слейва, но Ваш вариант с возвратом такта имеет точно такой же недостаток.

[Petka]

Успеет. Он просто не сможет опоздать - достаточно держать SCL в 0 все время, когда слейв занят чем то другим, а не мониторингом шины.

1. Вы так сами пробовали? (при реализации софт слэйва)
2. Вот считал слэйв состояние линий, что дальше прикажете делать? сразу SCL опускать? Или на второе чтение сразу-же выходить? А если между этими двумя чтениями прерывание выскочит? Ну не ориентировался I2C на софтовую реализацию слэйва исключительно мастер.

Ваш вариант с возвратом такта имеет точно такой же недостаток.

Это не недостаток это достоинство, когда скорость получается максимально возможной из "возможностей" двух сторон.

в протоколе abd квант времени, нужный для обработки протокола можно выделять абсолютно в любой удобный момент времени (как на мастере так и на слэйве), не надо на этот квант запрещать прерывания, его можно вызывать и в IDLE. И ни одного пропущенного бита не будет. И скорость получится максимально возможной без искусственных ограничений. может и 10Мбит получиться может и больше. Он разрабытывался для межмикроконтроллерного GPIO-обмена все другие протоколы не обладают такой особенностью.