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 модема на время передачи отладочной информации, будут работать.

[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'

[Laptop]

Часто даже в меге128 оба уарта заняты, поэтому я пользуюсь отладкой через почти программный уарт на OC выходе таймера. И времени практически не отнимает и времянки гарантированы. В качестве бонуса получаю простой проводок без всяких формирователей (инверсия не требуется). А там где возможно конечно используется обычный уарт. Во всех случаях используются кольцевые буферы и работе программы в реалтайме ничего не мешает. Так что сыпется и сыпется себе информация о отладке в терминалку.

[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), то софтовая реализация однопроводного не представляется сложной.

[MDD]

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

Есть подозрения, что "раз и навсегда" проблему программирования и отладки по одним и тем же проводам похоже решил решить сам Атмел. В новых Хмегах ведь PDI (Program and debug interface). Правда есть большие сомнения, что с его помощью получится сделать консоль.
Я сейчас отлаживаюсь по такому принципу:

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

Но глобально это проблему "абсолютной минимизации ног" не решает. Ноги PDI с другими интерфейсами не совмещены, а бутлоадер ведь надо как-то сначала залить...

Сообщение отредактировал MDD - Feb 22 2010, 07:57

[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.

[zltigo]

бутлоадер ведь надо как-то сначала залить...

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

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

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

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

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

вот только зачем? какой профит от этого? один провод меньше трёх. Но тема топика "over ISP" т.е. 3 провода уже есть.

А какого черта их резервировать под отладчик??? Я их почти всегда после программирования использую для других нужд.

причём эта реализация бесплатна при использовании программатора "by Petka" и прочих микроконтроллерных COM программаторов. + программаторы на "bitbang". т.е. теоретически все поддерживаемые avreal.

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

[MDD]

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

Я не зря оговорился, что речь идет о Хмега и PDI. У ножек PDI нет альтернативных функций (если не считать RESET). При этом есть подозрения, что Атмел приготовил этот интерфейс на смену старому ISP. Наверняка новые АВРы будут именно с ним.
Из названия ясно, что PDI позволяет отлаживаться. Как я понимаю по тому же принципу, что и JTAG.
Так что здесь задача стоит наоборот - пристроить к "пропащим" ножкам консоль. Я в JTAGах не силен. Можно ли с его помощью организовать что-то типа такого: контроллер складывает информацию в некий буфер, а РС через JTAG ее "прозрачно" забирает? Чтобы без остановки процессора?

[zltigo]

Я не зря оговорился, что речь идет о Хмега и PDI.

А здесь речь как раз НЕ идет об этом.

Я в JTAGах не силен. Можно ли с его помощью организовать что-то типа такого: контроллер складывает информацию в некий буфер, а РС через JTAG ее "прозрачно" забирает? Чтобы без остановки процессора?

Да как угодно делается и так и, просто, задействуется брейкпойнт на выводе байта, нем смахивается информация и на автомате продолжается. И отдельные каналы встречаются. Посему если речь идет ОБ ОТЛАДОЧНЫХ интерфейсах и ОТЛАДЧИКАХ, то с эмуляция консоли вполне обыденное дело.

[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-обмена все другие протоколы не обладают такой особенностью.

[vesago]

В качестве инструмента предлагаю известный клон аврисп на меге8 + подрихтованную Гудвином прошивку.

Код

После прошивки подключаем терминалку на скорости 115200 и смотрим отладочный вывод из target
Функции в target:

void init_debug(void)
{
  PORTB=0x00;
  DDRB=0x38;
  PORTB.3=1; // сигнал MOSI программатора - используется как SS
  delay_ms(1);
  PORTB.3=0;
  delay_ms(1);
}

void putchar( char c)
{
  unsigned char n;
  for (n=0;n<8;n++)
  {
    if (c & 1) PORTB.4=1; // сигнал MISO программатора - данные
    else PORTB.4=0;
    PORTB.5 =0; // сигнал SCK программатора - clock
    delay_us(100);
    PORTB.5 =1;
    delay_us(100);
    c=c>>1;
  }
}

Пардон, посмотрел выше уже есть аналогичное решение..

Прикрепленные файлы

 avrusb500_1.5_debugout.rar ( 42.78 килобайт ) Кол-во скачиваний: 27

 

[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 для МК. И софт верхнего уровня, для использования всего этого. Будет-ли это когда-нибудь реализовао и будет ли это достоянием общественности? Сомневаюсь.

[defunct]

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

Для себя решил этот вопрос с помощью I2C Slave на m8/48 - который представляет собой конвертер I2C <-> UART.
Понятно, что это решение пойдет не для всех AVR, а только для тех у кого есть I2C (правда никто не мешает умельцам примостырить софтовый I2C, но мне оно было не нужно, да камней без аппаратного I2C - парочка мег, и тиньки... где консоль вроде как и лишняя). I2C шину на технологический разъем 4 пина Vcc/SCL/SDA/GND.
Конвертер питается от таргета.

Из плюсов:
- не ограничен использованием только для AVR, применим и с МК других семейств;
- не ограничен только отладкой, можно использовать просто как дополнительный UART;
- двухсторонняя связь;
- подключение непосредственно к КОМ порту компа;
- работа через любой стандартный терминал;
- масштабирование по самые немогу - хоть 10 "консолей" (понятно что это могут быть и не консоли, а напр доп. 485-й порт).

из минусов:
- еще 1 разъем на плате,
- объем дебажного сопроводительного софта на таргет железе ~2.5kb Flash.
Второй минус правда нивелируется если I2C шина используется для чего-то еще, т.к. из 2.5k - 2KB занимает драйвер i2c.

[zltigo]

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

Да.

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

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

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

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

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

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

[manul78]

Я может слегка не в тему, но спрашиваю потому как всех вас, господа застать в одном месте сложно...

По DebugWIRE есть какие нибудь наработки, или это "тайна за семью печатями" ? На AVRFreaks разговор такой, типа
в Атмеле не такие дураки сидят чтобы DebugWIRE выкладывать на растерзание. Есть только протокол JTAGICE MKII в виде
диалога "AVRStudio<-->JTAGICE MKII", а вот JTAGICE MKII <--> DebugWIRE MK что-то не встречал, хотя данным отладочным
интерфейсом снабжены уже почти все AVR. Там-же AVRFraks была попытка объединиться в группу для попытки "расковырять" DebugWIRE методом: Хороший многоканальный цифровой осциллоскоп и изучение входных и выходных данных
JTAGICE MKII и DRAGON-а... Но что-то заглохла тема, а недавно полез она вообще исчезла Были так-же попытки раско-
пать upgrade-прошивки, но так как они закриптованы, разумеется ничего не вышло...

Вот интересно, кроме китайцев кто-нибудь победил ATMEL ? Проще конечно даже дешевый DRAGON купить и забыть, но вот
действительно любопытно, что из себя представляет DebugWIRE ? Скорость, возможности и пр. Спрашиваю т.к. китайские
клоны JTAGICE MKII работают ГОРАЗДО быстрее оригиналов.

P.S. Готов поучаствовать в коллективном "изучении" DebugWIRE, осциллоскоп цифровой имеется... JTAGICE MKII не имею, пользуюсь первым ICE-ом, но на DRAGON для такого дела разорюсь...

Сообщение отредактировал manul78 - Feb 24 2010, 23:11

[zltigo]

По DebugWIRE есть какие нибудь наработки, или это "тайна за семью печатями" ?

Не интересуюсь в принципе - купить дешевле.

[ReAl]

По DebugWIRE есть какие нибудь наработки, или это "тайна за семью печатями" ?

Я сделал только маленькую "разлочивалку" - временное блокирование фьюза dW - где-то тут тема бегает.
Сделано на тини13. Оказалось, что дракон (по крайней мере той версии, что у меня) не может это сделать, если контроллер тактируется от внутреннего 128кГц с забытым CKDIV8=on, для него это слишком низкая частота.
Но там просто одна байтовая команда подаётся, я её слизал простым осциллографом и просто по образцу выдал.

По скорости - там явно есть команды от хоста в контроллер эту скорость изменить. Дракон для реальной работы такое посылает.

Смысла ввязываться в раздалбывание полного протокола я не вижу.

[manul78]

Смысла ввязываться в раздалбывание полного протокола я не вижу.

Понятно...

Мне честно говоря сильно не горит, просто любопытно из познавательных соображений. Как там всё организованно...
В режиме отладки через SPI перекачиваются целые дампы памяти, меняется программный счетчик, пошаговые дела.
В МК что ? Организован аппаратный JTAG модуль+интерфейс ? Если так, то данный модуль считается по приоритету
выше чем само ядро? Или JTAG модуль обеспечивает прямой доступ к конвейеру и "втюхивает" ему свои команды, иначе
как можно организовать "многокомандные" отладочные процедуры не используя память программ ?

AVRStudio (команда "верхнего" уровня) --> JTAGICE MKII (заголовок+пачка комманд AVR) --> JTAG модуль МК --> конвейер

Возможно такое, или там всё проще(сложнее) ?

[demiurg_spb]

Для себя решил этот вопрос с помощью I2C Slave на m8/48 - который представляет собой конвертер I2C <-> UART.

Спасибо за предложение, но что-то исторически сложилось, что предпочитаю более дубовые интерфейсы: SPI, UART.
А I2C как-то не по душе мне - много чего софтом надо делать...
Да и устанавливать ещё один технологический разъём поздновато, уже столько сделано без него.

А из темы я, пожалуй, вынес для себя, что пока самым простым будет собрать программатор на COM лучше USB->COM и использовать его же как консоль.
Остальные решения требуют бОльших трудозатрат. Для контроллеров без TXD на ISP разъёме реализовать soft-uart.
Меня пока прельщает это решение.