Перейти к содержанию
    

Petka

Свой
  • Постов

    1 438
  • Зарегистрирован

  • Посещение

Весь контент Petka


  1. debug console over AVR-ISP

    abd - двунаправленный. приёмных сторон две! i2c - имет существенный минус для програмных реализаций - слэйв должен успевать за синхросигналом. т.е. передача не может быть приостановлена "посередине" транзакции. аналогично и с PS/2. однопроводные априори имеют треования к времянкам. т.е. нужен таймер или калиброваные циклы. если выскочило прерывание - прощай времянки... вот только зачем? какой профит от этого? один провод меньше трёх. Но тема топика "over ISP" т.е. 3 провода уже есть. Я преложил и реализовал своё видение этого протокола на 3х линиях. причём эта реализация бесплатна при использовании программатора "by Petka" и прочих микроконтроллерных COM программаторов. + программаторы на "bitbang". т.е. теоретически все поддерживаемые avreal.
  2. FTDI с последними драйверами в глюках замечена не была. Если не открыть порт, это дело явно не в программаторе а в ОС или софтинах, токорые открывают тот же самый порт. Да, только для первоначальной прошивки Для возможности отладки в прошку v7 был внедрён протокол "abd".
  3. debug console over AVR-ISP

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

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

    soft uart плох по той причине что он асинхронный, медленный, требует доп периферии, таймера как минимум =(. а так тоже применимо. как минус - лишние приблуды. одного программатора должно быть достаточно. потом всё это дело надо передёргивать... на SPI тоже свет колом не сошёлся. опять-таки лишние приблуды. всё-таки посмотрите "abd-протокол" - нужно всего 3 сигнальных линии. приактически "никакие" накладные расходы на стороне отлаживаемого контроллера. (не нужны ни таймеры ни прерывания) такой-же минимум на стороне отладчика. нет абсолютно никаких требований на времянки. можно использовать любые свободные GPIO. P.S. немного Offtop: предложенный мной вариант годится не только для AVR но и любого другого котроллера (ARM т пр.) как минимум с тремя GPIO =)
  6. debug console over AVR-ISP

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

    Видимо имелось ввиду, что в вашем случае нужно использовать для отладки ценный UART. Да, SPI (на котором часто сидит ISP) тоже иногда очень ценный ресурс, однако например я чаще испльзую soft SPI. (впрочем soft I2C тоже работает лучше чем TWI).
  8. Исходники самой последней прошивки нигде не выложены. Собирался выложить в общий доступ после того, как будет некоторое количество положительный отзывов типа "всё работает, глюков замечено не было". Не хочу, что бы исходники, вероятно с багами расползались по Интернету. Если интересуют исходники с целью помочь в разработке, то разумеется дам в индивидуальном порядке.
  9. debug console over AVR-ISP

    в том протоколе, что я реализовал отсутствует "мастер". скорость получается максимально возможной (т.е. ограничивается стороной, которая медленнее всего "поллит") воспользоваться таким подходом можно и в моей реализации. Это возможно, когда устройство слишком умное и подразумевает штатное подключение к компу. Однако, когда утройство настолько самодостаточно, что подключение каких-либо интерфейсов проблематично, отладка по линиям ISP программатора - самое то. Т.е. запрограммировал, и не отрывая программатора по тем же линиям отладился - удобно. Это правильный подход =) Однако никода точно не узнаешь где понадобится отладка а где нет. Кстати понятное дело что мой отладочный протокол можно повесить на любые другие ноги, не только ISP. поправить свой пост уже не могу вот новая: http://electronix.ru/forum/index.php?s=&am...st&p=678116
  10. debug console over AVR-ISP

    тут я выложил на суд общественности своё решение этой задачи: одладочный порт этот алгоритм может быть добавлен во все программаторы. в том числе LPT/FT2232 уже как пол года сделано. см выше =)
  11. Тогда снимаю возражение. Остаётся вопрос по надёжности и совместимости.
  12. Да, такой способ и применяется в "AvrUsb500 by Petka" для первоначальной заливки контроллера. Однако этот процесс оооочень медленный и совсем несовместимый с stk500. ИМХО более перспективны "программаторы" не на FT232RL, а на FT2232. (смотрите сайт AvReal).
  13. должна быть ЕДИНИЦА! нет. По схеме это сопротивление должно быть 200 Ом (R6). Перепроверьте мультиметром все связанные цепи.
  14. номер компорта и настройки правильные?
  15. попробуйте любым другим терминалом войти в консольный режим программатора.
  16. разберитесь сначала с этим. должен гореть при подключенном программируемом устройстве. (если вы не меняли в консольном режиме "Reset target at connector polarity test(1=on 0=off)" должно стоять "1=on", проверьте) Это какой-то "бубен". Программатор делает все необходимые манипуляции и с ресетом в том числе. Функция есть. Проверьте неоднократно все соединения, прозвоните, нет ли нигде паразитных связей? какое сопротивление от вывода reset программируемого контроллера до вывода rst_adc программатора (при отключеных питаниях)?
  17. светодиод должен не моргнуть а загореться постоянно.
  18. Нет, он ПРАВ. надо читать не только первые 2 страницы даташита, но и раздел "memory programming"
  19. Проверяйте "контакты". Отсутствие закороток в кабелях, всё-ли правильно подключено и.т.п.
  20. такое может быть. программатор запитывается через защитные диоды по выводам программирования или reset. обычно рекомендуют шлейф ~20см. как подключены на вашей плате линии программирования и ресет? Это зря. разберёмся.
  21. avreal

    Давно назрела необходимость отделить мух от котлет. В avreal в одну кучу свалены настройки программатора и параметры прошивки (файл с прошивкой, фузы). Логично в .bat/Makefile указывать ТОЛЬКО параметры а настройки программатора хранить отдельно в конфигурационном файле. т.е. Если на ноутбуке есть только программатор FT2232 а на ББ программатор LPT, то надо при прошивке одного и того же проекта на ноуте и ББ лезть в .bat/Makefile. Логичнее на ноуте использовать один файл настроек программатора а на ББ другой. А в командной строке задавать только Фузы, Файл прошивки, чип. Как это может выглядеть: avreal при старте читает дефолтный конфиг (или иначе конфиг дефолтов) в котором может быть заданы (а могут быть и не заданы) некоторые параметры. Потом читает параметры из командной строки, и если есть пересекающиеся атрибуты, то ругается и/или использует то, что задано в командной строке.
  22. Смотрел. ничего внятного в разделе "Skype и операторы сотовой связи" нет. Одно обмусоливание заголовков газет. Зато раздел "Критика" объёмнее. P.S. Модераторам: надо бы тему подчистить, а то тут мы намусорили сильно. :laughing: ... тоже в режиме приёма.
  23. Ок. Раз уж Вы такие "правильные", то должны знать, что законы многих стран запрещают предоставление услуг связи без возможности "прослушки". Если Скайп ВНЕ ЗАКОНА, то какие проблемы? Просто не используйте его. :laughing: Ссылочкой подтвердите.
×
×
  • Создать...