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

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

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

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" добавить соответствующие возможности.

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


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

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

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

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

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

Ссылка не работает... Это здорово!

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

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

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

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

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


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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I2C тоже две.

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

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



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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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



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

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

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

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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для себя решил этот вопрос с помощью 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.

Да.

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

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

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

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

По 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 для такого дела разорюсь...

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