Petka 0 21 февраля, 2010 Опубликовано 21 февраля, 2010 · Жалоба Если можно сделат 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 0 21 февраля, 2010 Опубликовано 21 февраля, 2010 · Жалоба приактически "никакие" накладные расходы на стороне отлаживаемого контроллера. До тех пор, пока нужно делать "практически ничего" :). Как только мне потребуется положить несколько байт зараз, то у железного UART может спасать FIFO, а у ногомахательных интерфейсов появятся накладные расходы, причем уже не "никакие" :(. Нет, я не утверждаю, что не надо использовать ногомахание никогда, просто это крайняя мера, а не штатное решение. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Petka 0 21 февраля, 2010 Опубликовано 21 февраля, 2010 · Жалоба До тех пор, пока нужно делать "практически ничего" :). Как только мне потребуется положить несколько байт зараз, то у железного UART может спасать FIFO, а у ногомахательных интерфейсов появятся накладные расходы, причем уже не "никакие" :(. Нет, я не утверждаю, что не надо использовать ногомахание никогда, просто это крайняя мера, а не штатное решение. FIFO может быть как у железных решений, так и у софтверных, таких как abd-протокол. abd-протокол стоит воспринимать примерно как "uart+аппаратный контроль потока". только полностью синхронный и всего 3 линии. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 0 21 февраля, 2010 Опубликовано 21 февраля, 2010 · Жалоба так и у софтверных, таких как abd-протокол. Могут. Я отрицал этот факт? Я только сказал, повторяю "..а у ногомахательных интерфейсов появятся накладные расходы, причем уже не "никакие" " P.S. А у 'abd' второй клок лишний - раз линия данных одна, то и захват линии клоков можно реализовать. Будет интерфейс 'a/сb/d' Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Laptop 0 21 февраля, 2010 Опубликовано 21 февраля, 2010 · Жалоба Часто даже в меге128 оба уарта заняты, поэтому я пользуюсь отладкой через почти программный уарт на OC выходе таймера. И времени практически не отнимает и времянки гарантированы. В качестве бонуса получаю простой проводок без всяких формирователей (инверсия не требуется). А там где возможно конечно используется обычный уарт. Во всех случаях используются кольцевые буферы и работе программы в реалтайме ничего не мешает. Так что сыпется и сыпется себе информация о отладке в терминалку. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Petka 0 21 февраля, 2010 Опубликовано 21 февраля, 2010 · Жалоба А у 'abd' второй клок лишний - раз линия данных одна, то и захват линии клоков можно реализовать. Будет интерфейс 'a/сb/d' вторая линия осуществляет квитирование. за счёт этого осуществляется flow control. попробуйте прочитать внимательно. на самом деле интересно ваше мнение. P.S. abd - совсем НЕ SPI. Больше на abd похож I2C. но всё равно это другое. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 0 21 февраля, 2010 Опубликовано 21 февраля, 2010 · Жалоба вторая линия осуществляет квитирование. за счёт этого осуществляется flow control. flow control при необходимости обеспечивается тем, что тактировку осуществяет приемная сторона. Или та-же приемная сторона давит управление клоком. Больше на abd похож I2C. но всё равно это другое. Другое, отличающееся наличием аппаратной избыточности в виде дополнительного провода. При этом кроме I2C есть еще массовые решения на 2x сигнальных проводах - та-же PS/2 клавиатура. Впрочем, можно и об однопроводных поговорить :) - тоже массовых прототипов хватает. Если рассматривать интерфейс заточенный под отладочный терминал (допустима ассиметрия в том числе и по скорости и flow control), то софтовая реализация однопроводного не представляется сложной. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MDD 0 22 февраля, 2010 Опубликовано 22 февраля, 2010 (изменено) · Жалоба Хочется решить раз и навсегда проблему отладочной консоли для семейства AVR. Есть подозрения, что "раз и навсегда" проблему программирования и отладки по одним и тем же проводам похоже решил решить :) сам Атмел. В новых Хмегах ведь PDI (Program and debug interface). Правда есть большие сомнения, что с его помощью получится сделать консоль. Я сейчас отлаживаюсь по такому принципу: - заливаете один раз загрузчик и дальше работаете через UART/RS232 и для заливки, и для отладки. Но глобально это проблему "абсолютной минимизации ног" не решает. Ноги PDI с другими интерфейсами не совмещены, а бутлоадер ведь надо как-то сначала залить... Изменено 22 февраля, 2010 пользователем MDD Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Petka 0 22 февраля, 2010 Опубликовано 22 февраля, 2010 · Жалоба flow control при необходимости обеспечивается тем, что тактировку осуществяет приемная сторона. Или та-же приемная сторона давит управление клоком. abd - двунаправленный. приёмных сторон две! Другое, отличающееся наличием аппаратной избыточности в виде дополнительного провода. При этом кроме I2C есть еще массовые решения на 2x сигнальных проводах - та-же PS/2 клавиатура. i2c - имет существенный минус для програмных реализаций - слэйв должен успевать за синхросигналом. т.е. передача не может быть приостановлена "посередине" транзакции. аналогично и с PS/2. Впрочем, можно и об однопроводных поговорить :) - тоже массовых прототипов хватает. однопроводные априори имеют треования к времянкам. т.е. нужен таймер или калиброваные циклы. если выскочило прерывание - прощай времянки... Если рассматривать интерфейс заточенный под отладочный терминал (допустима ассиметрия в том числе и по скорости и flow control), то софтовая реализация однопроводного не представляется сложной. вот только зачем? какой профит от этого? один провод меньше трёх. Но тема топика "over ISP" т.е. 3 провода уже есть. Я преложил и реализовал своё видение этого протокола на 3х линиях. причём эта реализация бесплатна при использовании программатора "by Petka" и прочих микроконтроллерных COM программаторов. + программаторы на "bitbang". т.е. теоретически все поддерживаемые avreal. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Qwertty 0 22 февраля, 2010 Опубликовано 22 февраля, 2010 · Жалоба abd - двунаправленный. приёмных сторон две! I2C тоже две. i2c - имет существенный минус для програмных реализаций - слэйв должен успевать за синхросигналом. т.е. передача не может быть приостановлена "посередине" транзакции. Вы ошибаетесь. Приостановить слейв может - достаточно "придержать" SCL. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 0 22 февраля, 2010 Опубликовано 22 февраля, 2010 · Жалоба бутлоадер ведь надо как-то сначала залить... Залить, как обычно, потом эти пины использовать для других целей. abd - двунаправленный. приёмных сторон две! Я тоже про двунаправленный говорю. однопроводные априори имеют треования к времянкам. т.е. нужен таймер или калиброваные циклы. если выскочило прерывание - прощай времянки... Отнюдь. Простейший пример для затравки - '0' это импульс минимальной длительности соответствующий атомарной записи 0->1 - вещь вполне стабильная и конфигурируемая в терминале. '1' это импульс любой длительности, но гарантированно длиннее 'нулевого'. вот только зачем? какой профит от этого? один провод меньше трёх. Но тема топика "over ISP" т.е. 3 провода уже есть. А какого черта их резервировать под отладчик??? Я их почти всегда после программирования использую для других нужд. причём эта реализация бесплатна при использовании программатора "by Petka" и прочих микроконтроллерных COM программаторов. + программаторы на "bitbang". т.е. теоретически все поддерживаемые avreal. Повторяю, плата это эти три ноги НАВСЕГДА отданные программатору "by Petka" и прочим. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MDD 0 22 февраля, 2010 Опубликовано 22 февраля, 2010 · Жалоба Залить, как обычно, потом эти пины использовать для других целей. Я не зря оговорился, что речь идет о Хмега и PDI. У ножек PDI нет альтернативных функций (если не считать RESET). При этом есть подозрения, что Атмел приготовил этот интерфейс на смену старому ISP. Наверняка новые АВРы будут именно с ним. Из названия ясно, что PDI позволяет отлаживаться. Как я понимаю по тому же принципу, что и JTAG. Так что здесь задача стоит наоборот - пристроить к "пропащим" ножкам консоль. Я в JTAGах не силен. Можно ли с его помощью организовать что-то типа такого: контроллер складывает информацию в некий буфер, а РС через JTAG ее "прозрачно" забирает? Чтобы без остановки процессора? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 0 22 февраля, 2010 Опубликовано 22 февраля, 2010 · Жалоба Я не зря оговорился, что речь идет о Хмега и PDI. А здесь речь как раз НЕ идет об этом. Я в JTAGах не силен. Можно ли с его помощью организовать что-то типа такого: контроллер складывает информацию в некий буфер, а РС через JTAG ее "прозрачно" забирает? Чтобы без остановки процессора? Да как угодно делается и так и, просто, задействуется брейкпойнт на выводе байта, нем смахивается информация и на автомате продолжается. И отдельные каналы встречаются. Посему если речь идет ОБ ОТЛАДОЧНЫХ интерфейсах и ОТЛАДЧИКАХ, то с эмуляция консоли вполне обыденное дело. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Petka 0 22 февраля, 2010 Опубликовано 22 февраля, 2010 · Жалоба Вы ошибаетесь. Приостановить слейв может - достаточно "придержать" SCL. Отнюдь! Слэйв может просто не успеть "придержать" SCL. именно по этой причине есть ограничения на скорость передачи в I2C. (10, 100, 400, 3400кбит/с). По этой-же причине софт-реализация Слэйва I2C сложнее Мастера. Я тоже про двунаправленный говорю. видимо мы говорим о разном. я говорил про полный двунаправленный flow control. как я писал выше при софтовой реализации слэйв i2c если не успеет (а как раз тогда и имеет слысл), то не сможет приостановить передачу в удобном для него месте. Отнюдь. Простейший пример для затравки - '0' это импульс минимальной длительности соответствующий атомарной записи 0->1 - вещь вполне стабильная и конфигурируемая в терминале. '1' это импульс любой длительности, но гарантированно длиннее 'нулевого'. передать импульс легко, согласен. а вот его софтово поймать - сложнее. разжевать почему? Повторяю, плата это эти три ноги НАВСЕГДА отданные программатору "by Petka" и прочим. В общем случае ДА. Многие вообще через JTAG отлаживаются и ничего, живут как-то =) Альтернатив вообще нет. Разве что через RESET отлаживаться, но это тоже отнюдь не всегда можно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Qwertty 0 23 февраля, 2010 Опубликовано 23 февраля, 2010 · Жалоба Отнюдь! Слэйв может просто не успеть "придержать" SCL. именно по этой причине есть ограничения на скорость передачи в I2C. (10, 100, 400, 3400кбит/с). По этой-же причине софт-реализация Слэйва I2C сложнее Мастера. Успеет. Он просто не сможет опоздать :) - достаточно держать SCL в 0 все время, когда слейв занят чем то другим, а не мониторингом шины. Скорость конечно может получиться очень низкой, это зависит от загруженности слейва, но Ваш вариант с возвратом такта имеет точно такой же недостаток. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться