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? :-)
Сам готов помочь. Так, глядишь, сделаем общеполезную тулзу.

[smac]

Хочется решить раз и навсегда проблему отладочной консоли для семейства AVR.

Записываюсь в добровольцы. Толку от меня наверное много не будет, но чем смогу помогу.

[AHTOXA]

Сам готов помочь. Так, глядишь, сделаем общеполезную тулзу.

Вот тут нечто вроде: http://elm-chan.org/docs/avr/avrisp.html

[ReAl]

Хочется получить обычную консоль на ПК, которая принимает DEBUG-поток от AVR через LPT или USB-FT2232 программатор,
подключенный к MCU на ISP разъём. Поток данных односторонний MCU->программатор->ПК.
...
2 - SPI для всех остальных.
Нужно также предусмотреть спец-преамбулы для режима SPI, чтоб консоль не ловила весь SPI трафик MCU с периферией.

LPT как SPI slave? Как-то очень сомнительно, даже для неразумно низких частот. Разве что адаптер делать другой с какой-то аппаратной поддержкой, но для LPT уже не хочется упираться.

Ну а FT2232 MPSSE только мастер.
В этом свете проще на пару контактов колодки вывести txd, rxd (для мега128 и подобных можно просто продублировать) и запустить на UART на канал B микросхемы FT2232. Но это мало чем отличается от просто байт-бластера и любого COM-порта.

У FT2232 на канале B имеет "Fast Opto-Isolated" режим, там она выступает на приём как slave, но там по сути синхронный режим USART со старт-битом и 9-битовой посылкой.

Для SPI slave можно попытаться придурить режим FIFO в FT2232 - т.е. при заведомо низкой частоте SCK подавать его на строб WR, а уже в PC из байтов выгрызать нужный бит для MISO. Байтовую синхронизацию пробовать делать по какой-то другой ноге, используемой как CS.

Ещё в режиме MPSSE есть команды ожидания установления заданного уровня на adbus4, можно комады считывания состояния ножек чередовать c ними, но, боюсь, тормознуто будет.

Ну и никто не мешает не выходя из режима MPSSE использовать вход MISO как "1-битовый логанализатор" - на максимально возможной частоте SPI вводить данные, со стороны контроллера игнорировать SCK (в принципе, это задача адаптера - закрыть соотв. буфер) и разбирать поток. Но вводимый бит один, это только UART.

sync bitbang как 8-канальный логанализатор позволит анализировать sck, miso, cs, но там проблемы со стабильностью частоты.

async bitbang или FIFO в "авторежиме" (вроде бы получиться заставить запустив ~TXE на WR через инвертор получить максимально возможный темп ввода через FIFO без воздействй со стороны микроконтроллера) - это ещё два способа сделать логанализатор и из него выгребать нужное... Вопрос максимальной частоты уверенно декодируемого потока.

Такое ощущение, что такой SPI-debug-канал при микроконтроллере-мастере надо делать на "микроконтроллерном" адаптере.
"Згвалтувати" наконец-то меня на stk500v2 и, к примеру, в "Petka" добавить соответствующие возможности.

[Petka]

Хочется решить раз и навсегда проблему отладочной консоли для семейства AVR.
...программатор,
подключенный к MCU на ISP разъём. Поток данных односторонний MCU->программатор->ПК.

тут я выложил на суд общественности своё решение этой задачи:
одладочный порт
этот алгоритм может быть добавлен во все программаторы. в том числе LPT/FT2232

...
Такое ощущение, что такой SPI-debug-канал при микроконтроллере-мастере надо делать на "микроконтроллерном" адаптере.
"Згвалтувати" наконец-то меня на stk500v2 и, к примеру, в "Petka" добавить соответствующие возможности.

уже как пол года сделано. см выше =)

[zltigo]

Хочется решить раз и навсегда проблему отладочной консоли для семейства AVR.

Похвально, только будьте проще и независимие - заливаете один раз загрузчик и дальше работаете через UART/RS232 и для заливки, и для отладки.

[ReAl]

уже как пол года сделано. см выше =)

Интересно.
Но что-то мне кажется, что для FT2232 это будет "медленно и печально" независимо от того, кто в этой связке мастер. Ну, может, те команды ожидния помогут.

Я если уж делаю отладку на UART, то стараюсь частоту повыше, а при наличии достаточного количества ОЗУ у меня этот самый uart_file_putc вообще в кольцевой буфер складывает, короткие строки в него полностью помещаются и программа идёт дальше с минимальными задержками.
В другом месте обмен с компом всё равно есть, в протокол добавлены "информационные" пакеты и dll обмена выфильтровывает их в log-файл и отдаёт через callback основному приложению, оно в отдельное окошечко "инженерного" режима летит вместе с отладочной информацией от самой dll и в заисимости от установленного loglevel.
Т.е. если у меня вообще доходит до такой отладки, то обычно ресурсов достаточно и канал заложен, а как раз SPI-шные ноги заняты по прямому назначению. Поэтому до сих пор пропускал мимо все подобные обсуждения.

[demiurg_spb]

Похвально, только будьте проще и независимие - заливаете один раз загрузчик и дальше работаете через UART/RS232 и для заливки, и для отладки.

Так сейчас и делаю. Но есть девайсы и без RS и сам бутлоадер опять-же.
Поэтому и хочется альтернативы. Трафик-то в DEBUG мизерный он никак не скажется на работе SPI периферии.

тут я выложил на суд общественности своё решение этой задачи:
одладочный порт

Ссылка не работает...

этот алгоритм может быть добавлен во все программаторы. в том числе LPT/FT2232

Это здорово!

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

Ничего, мы не торопимся - 20-50 байт передать за секунду нормально

[Petka]

Интересно.
Но что-то мне кажется, что для FT2232 это будет "медленно и печально" независимо от того, кто в этой связке мастер. Ну, может, те команды ожидния помогут.

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

Я если уж делаю отладку на UART, то стараюсь частоту повыше, а при наличии достаточного количества ОЗУ у меня этот самый uart_file_putc вообще в кольцевой буфер складывает, короткие строки в него полностью помещаются и программа идёт дальше с минимальными задержками.

воспользоваться таким подходом можно и в моей реализации.

В другом месте обмен с компом всё равно есть, в протокол добавлены "информационные" пакеты и dll обмена выфильтровывает их в log-файл и отдаёт через callback основному приложению, оно в отдельное окошечко "инженерного" режима летит вместе с отладочной информацией от самой dll и в заисимости от установленного loglevel.

Это возможно, когда устройство слишком умное и подразумевает штатное подключение к компу. Однако, когда утройство настолько самодостаточно, что подключение каких-либо интерфейсов проблематично, отладка по линиям ISP программатора - самое то. Т.е. запрограммировал, и не отрывая программатора по тем же линиям отладился - удобно.

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

Это правильный подход =)
Однако никода точно не узнаешь где понадобится отладка а где нет. Кстати понятное дело что мой отладочный протокол можно повесить на любые другие ноги, не только ISP.

Ссылка не работает...

поправить свой пост уже не могу вот новая:
http://electronix.ru/forum/index.php?s=&am...st&p=678116

[zltigo]

Трафик-то в DEBUG мизерный он никак не скажется на работе SPI периферии.

Что? Как оно это не скажется? Либо в Вас есть выделенный отладочный интерфейс, либо его нет.

[Petka]

Что? Как оно это не скажется? Либо в Вас есть выделенный отладочный интерфейс, либо его нет.

Видимо имелось ввиду, что в вашем случае нужно использовать для отладки ценный UART. Да, SPI (на котором часто сидит ISP) тоже иногда очень ценный ресурс, однако например я чаще испльзую soft SPI. (впрочем soft I2C тоже работает лучше чем TWI).

[zltigo]

Видимо имелось ввиду, что в вашем случае нужно использовать для отладки ценный UART.

Это на самом деле зависит о загрузчика - какой напишите.
А мое удивление было о другом - о расшаривании отладочного интерфейса с мотивацией, раз трафик маленький, то работе подключенной перефирии не помешает. А вот тот-же ценный UART можно на уровне протокола и расшарить для отладки. У меня, как апологета отладочной консоли , практически штатно заложена в консольный драйвер формирование SLIP фреймов, на случай если потребуется гнать не только отладочную инфомацию в канале.
При этом все, что на во фреймах выводится на консоль в качестве отладки.

[Petka]

А вот тот-же ценный UART можно на уровне протокола и расшарить для отладки. У меня, как апологета отладочной консоли , практически штатно заложена в консольный драйвер формирование SLIP фреймов, на случай если потребуется гнать не только отладочную инфомацию в канале.
При этом все, что на во фреймах выводится на консоль в качестве отладки.

Интересно, где возможно воспользуюсь. Однако если идинственный UART использеутся например для связи с модемом, то такой подход неприменим. (знаю какой будет ответ - "не загонять себя в угол единственным UARTом")

[ReAl]

(знаю какой будет ответ - "не загонять себя в угол единственным UARTом")

Если можно сделат soft-spi, то можно сделать и soft-uart. Причём если устраивает полста байт в секунду, то ~50*10=~500 -> 480бод или около софт-уарт делается легко при любой загруженности контроллера где-то в дебрях таймер-тикового прерывания. При этом практически не нагружая контроллер не только "в среднем", но и "в пике".
А хвостик с 74hc14 или max232 у меня есть и есть шлейф "для байт-бластера" с тремя колодками тоже - средняя ставится именно на такой хвостик и работает с выведенными на pin7,8 ногами. Это для тех плат, где SPI занят в системе, пара свободных ног осталась а единственный UART занят (или свободен - тогда выведен он).

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

[zltigo]

Однако если идинственный UART использеутся например для связи с модемом, то...

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