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 с другими интерфейсами не совмещены, а бутлоадер ведь надо как-то сначала залить...

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

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 все время, когда слейв занят чем то другим, а не мониторингом шины. Скорость конечно может получиться очень низкой, это зависит от загруженности слейва, но Ваш вариант с возвратом такта имеет точно такой же недостаток.