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

Гляньте в AVRStudio - там все прекрасно видно - в следующем такте после исполнения команды

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

От серии это независит. Прикиньте процедуру переключения на ASM и подсчитайте время ее выполнения в зависимости от частоты тактирования (в DataSheet для этого все есть). Раньше не имея всяких 'студий' поступали именно так.

Не совсем всё так просто.
Порт действительно переключается на следующий такт. Это действительно можно увидеть в AVR Studio. А теперь тонкости:
Как правило когда задают такой вопрос, то подразумевается что планируют операции ввода-вывода. Так вот операция ввода выполняется медленнее операции вывода. В связи с этим возникают иногда проблемы! Приведу пример рабочей программы, где это будет видно наглядно.

readusb:
sbic pinb,RXF ; по готовности - продолжить
rjmp PC-1 ; иначе повторить
cbi portb,RD ; читать
; in wl,pind ; USB (особенности AVR ядра)
sbi portb,RD ; завершить
in wl,pind ; USB
cpi wl, label ; метка?
breq read1 ; если да, то ввести команду
readex:
clt ; иначе, - сбросить

Если не учитывать особенности ядра, то необходимо вводить там где стоит коментарий!

Это не особенности ядра, а особенности алгоритма и частоты тактирования. Просто с более высойкой частотой тактирования вы промигиваете RD сильно быстро для USB, а командой in автор этого кода делал задержку на 2 такта. AVR и ядро AVR здесь абсолютно не при чем, вместо IN можно было спокойно применить две слудующих подряд команды NOP.

Господа давайте подругому...
есть кусок кода...
init:
SBI DDRx,Y -порт на вывод
////////....
Чушь всякая....
///////
CBI DDRx,Y
SBIC PINX,Y
;---
X,Y один и тотже пин и порт
в результате получаем недействительные данные при опросе ноги

приходиться между CBI и SBIC всовывать задержку

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

насчет предидущего письма - да это особенность авр- но это в шите оговаривается - что между оут и ин всунуть ноп

Сообщение отредактировал Kovrov - Mar 3 2006, 04:57

В DataSheet на AVR об этом тоже говориться с примерами кода и диаграм. Нет здесь особой сложности то. Просто внимательнее надо изучать первоисточник (DataSheet).

К примеру,в полном даташите на м16 на стр 51 это четко и ярко иллюстрировано
но нет ни слова о варианте со сменой направления
если это относится и к моему вопросу то я только рад!
но хотелось бы точности в этом вопросе.....

Я раз сталкнулся с этой проблемой на Mege8. Пришлось вводить задержку, причем 1-3 мкс было мало (при кварце 7.3728). Поставил 5 мкс - все четко заработало.

к вашему вопросу относится диаграмма еа стр. 50 tpdmax.


Ой!

Вы забывает еще о том, на что нагружена нога. Если емкостная составляющая очень велика, задержки с установкой уровня могут быть очень большими.

tpdmax.-- ????

tpd.max ~ 2 такта.
(Figure 24. Synchronization when Reading an Externally Applied Pin Value)

В полне солидарен. Хорошее замечание!
Так же, как дополнительный NOP при каждом переключении для ввода/вывода - необходим...