За сколько времени реально осуществляется переключение направления порта?, в мегах, тинях? Опции

[Kovrov]

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

[prottoss]

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

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

[Kovrov]

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

[BVU]

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

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

[SasaVitebsk]

Не совсем всё так просто.
Порт действительно переключается на следующий такт. Это действительно можно увидеть в 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 ; иначе, - сбросить

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

[defunct]

...

Код

    cbi        portb,RD; читать
;    in        wl,pind    ; USB (особенности AVR ядра)
    sbi        portb,RD; завершить

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

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

[Kovrov]

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

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

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

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

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

[BVU]

Не совсем всё так просто.
Порт действительно переключается на следующий такт. Это действительно можно увидеть в AVR

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

[Kovrov]

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

[MRW]

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

[defunct]

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

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

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

Ой!

[Георгий]

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

[Kovrov]

стр. 50 tpdmax.

tpdmax.-- ????

[defunct]

tpdmax.-- ????

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

[BVU]

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

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

[SasaVitebsk]

...

Код

    cbi        portb,RD; читать
;    in        wl,pind; USB (особенности AVR ядра)
    sbi        portb,RD; завершить

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

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

Господа простите за резкость, но я не такой баран чтобы не подпирать ноги, не учитывать быстродействие подключённых устройств и т.п. Я схемотехник. И когда я привожу пример, я отвечаю за то что дополнительных схемотехнических особенностей нет!
Теперь непосредственно к defunct. Посмотрите внимательно на текст проги. Я не делаю никакую задержку там где стоит коментарий. Коментарий это коментарий!!!!
А если я туда добавлю два нопа как Вы предлагаете то как раз работать и не будет!!! Я их как раз убирал. Т.е будет правильным такой код

cbi
nop
nop
in
sbi

а код который я привёл работает не благодаря а вопреки! Потому как на момент чтения порт ещё не возвращается в "1" !!!

cbi
sbi
in

Это чётко описано в PDF на микросхему. Покрайней мере в PDFах на at90xxxxx
Код я взял с реальной проги работы с ftdi245. Применял такое несколько раз. Первый раз когда столкнулся, то бился и отлаживал, выяснял причину. Потом нашёл где-то в PDFе.
Пока.

[defunct]

Это чётко описано в PDF на микросхему. Покрайней мере в PDFах на at90xxxxx
Код я взял с реальной проги работы с ftdi245. Применял такое несколько раз. Первый раз когда столкнулся, то бился и отлаживал, выяснял причину. Потом нашёл где-то в PDFе.

Резко высказываться вам приходится лишь потому, что в прошлый раз Вы выразились очень туманно, это касается коментария (на русском, напротив закоментированной команды in) в коде и последней строчки.

cbi portb,RD; читать
; in wl,pind; USB (особенности AVR ядра)
sbi portb,RD; завершить

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

подчеркнутое в цитате - неверно, т.к. никакой особенности ядра нет!
см. даташит стр 50...

Теперь непосредственно к defunct. Посмотрите внимательно на текст проги. Я не делаю никакую задержку там где стоит коментарий. Коментарий это коментарий!!!!

Это все понятно.

А если я туда добавлю два нопа как Вы предлагаете то как раз работать и не будет!!! Я их как раз убирал. Т.е будет правильным такой код

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

Я схемотехник.

В таком случае вы должны сразу изъясняться технически верно, желательно со ссылками на техн. документацию, а не пользоваться голословными утверждениями типа:

Так вот операция ввода выполняется медленнее операции вывода.

PS: вообще все что Вы теперь сказали - понятно, однако не просить же у Вас прощение за то, что в прошлый раз вы высказались не достаточно ясно?

PPS: простите уж и меня за резкость, очевидно я тоже в своем предыдущем высказывании допустил непростительную вольность..

[SasaVitebsk]

В таком случае вы должны сразу изъясняться технически верно, желательно со ссылками на техн. документацию, а не пользоваться голословными утверждениями типа:

Когда выясняешь какой-то вопрос, то результат запоминается а процесс -- не очень. С Вами бывало?
С данным вопросом я разбирался очень давно. Сейчас попытаюсь вспомнить заново.

Если понадобятся ссылки на документацию, то я их найду, но пока попробуйте поверить на слово. Лишнего времени у меня как и у других нет. Теперь по сути.

На самом деле AVR (вопреки мнению начинающих) выполняет команду не за 1 такт, а за 4. Но каждая последующая команда начинает выполнятся со смещением в один такт. Т.о. якобы время исполнения команды составляет один такт.

1.2.3.4 команда1
__1.2.3.4 команда2
____1.2.3.4 команда3

Для исполнения арифметических команд данный факт не имеет значения, но для команд ввода-вывода это не так.
Давайте попробуем подумать вместе. Что делает ядро при команде "out porta,r19"? СНАЧАЛА извлекает значение из регистра и ПОТОМ выводит его в порт. (В каком такте это происходит я не знаю)
А что делае команда "IN"? СНАЧАЛА вводит из порта, ПОТОМ заносит в регистр. Надеюсь то что я сейчас пишу очевидно. Предположем что ввод осуществляется во втором такте, а вывод в четвёртом. В результате получим следующую картину.
1. 2.3.X OUT где X - операция вывода
__1.X.3.4 IN где X - операция ввода.

Очерёдность здесь видна глазом.

Всё это учтено в AVR Studio по моему. Проверять сейчас некогда. Попробуйте сами.
Всё равно лучше запоминаются те факты которые установлены самими.

Внимание! Всё сказанное мной отнюдь не отменяет, а лишь дополняет сказанное другими выше.
Действительно необходимо учитывать:
1) Время ответа внешнего устройства (если имеется)
2) Быстродействие Вашего микроконтроллера
3) Имеющуюся емкостную нагрузку (и как следствие подпорку ножки)
4) Схему включения (может Вы используете одну и туже ножку)
5) Ну и особенность ядра, описанную выше.

Кстати аналогичные проблемы возникают и у др. МП.

Кстати коментарий я ставил (и обычно ставлю ) для себя, а не для других. Чтобы легче было вспомнить. Я не занимаюсь обучением других. Отсюда и проблемы с пониманием.

Сообщение отредактировал SasaVitebsk - Mar 5 2006, 12:49

[vet]

SasaVitebsk
Ну, зачем же так дезинформировать общественность?
Выполнение типичной команды AVR занимает 1 такт. В этот же такт происходит выборка следующей команды. См. даташит на мегу128, релиз 2467J, стр. 13 "Instruction Execution Timing".

[beer_warrior]

Саш все так, да не то.
Открываем даташит на М16 -Instruction Execution Timing
стр.11 Figure 7.
Видим - инструкция выполняеться за такт.Чуть выше описана работа 4-тактного конвейера, но там четко видно разделение fetch - execution.
Необходимость дополнительной задержки обусловлена именно временем
установления сигнала - напомню у мег логические уровни КМОП т.е. порог
срабатывания достаточно высокий, входное сопротивление, емкость - тоже.
Кроме этого стоит разделить старые девайсы с асинхронным входом
и новые с синхронным, которые действительно дают задержку на такт.

[prottoss]

Саш все так, да не то.
Открываем даташит на М16 -Instruction Execution Timing
стр.11 Figure 7.
Видим - инструкция выполняеться за такт.Чуть выше описана работа 4-тактного конвейера, но там четко видно разделение fetch - execution.

Наверное, не много ошиблись (или у меня даташит другой?):

Figure 6. The Parallel Instruction Fetches and Instruction Executions;

Figure 7. Single Cycle ALU Operation...

Конвейер то получается не 4-х, а 2-х тактный, или я не прав? В первом такте выборка из ФЛЭШ(памяти программ), во втором - выполнение инструкции , выбранной в прошлом такте, и выборка следующей инструкции и т.д

[beer_warrior]

Наверное, не много ошиблись (или у меня даташит другой?):

Figure 6. The Parallel Instruction Fetches and Instruction Executions;

Figure 7. Single Cycle ALU Operation...

Я имел в виду именно Figure 7. Single Cycle ALU Operation

Конвейер то получается не 4-х, а 2-х тактный, или я не прав? В первом такте выборка из ФЛЭШ(памяти программ), во втором - выполнение инструкции , выбранной в прошлом такте, и выборка следующей инструкции и т.д

Да тут я притормозил, 2 такта конечно. Поэтому и инструкции ветвления
1-2 тактные, в зависимости от выполнения условия.

[SasaVitebsk]

Ребята если я дезинформировал общественность, то извиняйте. То, что я писал я не из пальца высосал. Где-то прочитал. Я поищу источник. Хотя я не удивлюсь если в последних кристаллах что-то изменилось. Данная прога и ещё одна с аналогичным построением работала на ATMEGA163 и ATMEGA8515. С другой стороны выполнение команды за такт, - не совсем характерно. Необходимо выбрать команду инкрементировать указатель команд, выбрать значение сделать что-то со значением и т.д. Внутренних тактов должно быть более одного. Иногда применяют умножение частоты. Но не в AVR. AVR статическая. Хотя всё это уже из области раздумий. Поищу более точное описание.

Тем не менее при вводе-выводе надо также учитывать особенности связанные именно с AVR. О чём я и писал! А именно вставлять програмную задержку м/у выводом и вводом. Я не рекомендую финты ушами которые делал я. В данном случае изделие я использовал как вспомогательное и в серию оно не планировалось. А необходимо было получить максимальное быстродействие.

А детали конвеера я уточню.

[beer_warrior]

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

[prottoss]

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

Мне кажется не совсем так. В приведенной схеме МК сначала загоняет в регистр скан-код, по линии sdata/key_port, а потом по этой же линии считывает состояние клавиатуры. В схеме все лишнее убрано для наглядности. Ниже при веденный код не считывает состояние клавы, если убрать NOP() (макрос asm("nop")). Хотя все уровни жесткие - лог.0 и лог.1

Код

#define KEY_PORT PB5

...

// читаем состояние порта клавиатуры
    PORTB |= (1 << KEY_PORT); // обнуляем порт
    DDRB  &= ~(1 << KEY_PORT); // меняем направление порта на ввод
    NOP();// ждем установления  состояния порта
    // если бит порта клавиатуры установлен, обрабатываем нажатие кнопки
    if(PINB & (1 << KEY_PORT))
    {

    .....

    }
    // меняем направление порта на вывод
    DDRB |= (1 << KEY_PORT);

[beer_warrior]

И что мы видим - к key_port подключены RC-цепочка кнопки и резисторы.То о чем я говорил.
Я в свое время имел немало сексу ISM-трансиверами, ридерами магнитных карточек, клавиатур итп. Везде ловил уровень одним тактом. В принципе считаю экспериментально доказанным,что это работает.
На самом деле спор этот смысла не имеет - надо писать без нопов имея в виду, что в случае проблем надо будет вставлять задержку и далеко не всегда один такт, это сильно зависит от конкретной схемы и скорости контроллера.

[prottoss]

И что мы видим - к key_port подключены RC-цепочка кнопки и резисторы.

RC-цепочки нет, только резисторы. Возможно, за конденсатор Вы приняли две земли - от батарей и от резистора. Резистор к земле нужен для подтягивания уровня на key_port к земле, так как кнопки сканируются единицами, (к регистру подключены катоды 7SegLEDов через ключи). Я пробовал ставить вместо ключей TTL-буферы, а так же использовал в качестве key_port отдельную линию МК, но перед считыванием состояния кнопок (ради эксперимента) переключал на ввод, а после считывания опять на вывод - результат не изменился. Считывание порта происходило только через такт после выполнения команды SBI DDRB, key_port...

Кстати, посмотрите даташит на всеми нами любимый ATmega32. Страница 50. Figure 25. Synchronization when Reading a Software Assigned Pin Value. И то что там написано немного выше, и приведенный код немного ниже. Там все написанно черным по белому.

Все вышесказанное, естественно, только в том случае, если на входе нет емкостной нагрузки, и то, ну о-очень большой.



Извиняюсь, что повторил то что было уже сказанно в сообщениях выше

Сообщение отредактировал prottoss - Mar 5 2006, 19:06

[prottoss]

В довершении ко всему вышесказанному хочу привести вот такой простой код, с которым можно быстро поэксперементировать на любой макетке с минимумом деталей. Главное, чтобы был МК с двумя портами, светодиод и токоограничивающий резистор для него. К примеру возьмем мегу16. И так, садим светодиод через резистор анодом к любому пину порта В, катодом к земле.

Зашиваем вот такой код:

Код

clr r18;

ldi r16, 0xff
ldi r17, 0x00;
out portb, r17; обнуляем состояние линий порта В
out ddrb, r16; порт В на вывод
out porta, r16; подключаем пулл-ап резисторы
out ddra, r16; порт А - на вывод
nop; задержка для установления состояния порта
in  r18, pina; читаем состояние на выводах порта (должен быть 1 во всех разрядах)
out portb, r18; зажигаем светодиод

а затем вот такой:

Код

clr r18;

ldi r16, 0xff
ldi r17, 0x00;
out portb, r17; обнуляем состояние линий порта В
out ddrb, r16; порт В на вывод
out porta, r16; подключаем пулл-ап резисторы
out ddra, r16; порт А - на вывод
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;nop; задержка для установления состояния порта
in  r18, pina; читаем состояние на выводах порта (должен быть 1 во всех разрядах)
out portb, r18; зажигаем светодиод

угадайте, где светодиод загорится, а где нет :-)

Сообщение отредактировал prottoss - Mar 5 2006, 19:36

[SasaVitebsk]

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

Как говорят классики: "человек видимо не понимает"!
Я извинялся лишь за колличество тактов. 2-4. В любом случае не один. Всё остальное что я написал соответствует действительности. Так какая разница какое кол. тактов на самом деле?
Там же я написал что всё это можно проверить в AVR Studio. Так о чём мы спорим?

Набираем следующую программу.

.include "m88def.inc"
ldi r18,$ff
out ddrb,r18
ldi r18,0
out portb,r18
ldi r18,$ff
out portb,r18
in r18,pinb
in r18,pinb
nop
nop

Компилируем и выполняем её по шагам.
и видим что первый in нам возвращает 0 в регистр r18, а второй $ff. Порядок вывода любой зрячий может увидеть если раскроет порт B в отладчике. Он увидит что после выполнения команды out значение $ff появится ТОЛЬКО в portB, а на PINB значение появляется на следующий такт!!!

И где здесь конденсаторы?????

Ещё раз утверждаю. Данное ЧЁТКО прописано в PDF!

[defunct]

Господа об чем спор? все верно говорит beer_warrior...
Прикрепляю рисунок из даташита с небольшими пояснениями:
Происходит изменение уровня сиганала на входе порта PINX.
Для того чтобы этот сигнал зафиксировался в защелке PINX требуется минимум 0.5 такта (T pin delay min Tpd.min) и максимум 1.5 такта (T pin delay max - Tpd.max). Команда же считывания значения регистра PINX выполняется за 1 такт. Так что никаких фокусов и никаких "особенностей ядра" - в любом случае (если остутствует внешняя дополнительная задержка) максимум за 3 такта, а в идеале за 2 такта реальное значение сигнала будет прочитано.

Сообщение отредактировал defunct - Mar 5 2006, 22:33

Эскизы прикрепленных изображений

 

[defunct]

Я извинялся лишь за колличество тактов. 2-4. В любом случае не один. Всё остальное что я написал соответствует действительности. Так какая разница какое кол. тактов на самом деле?

большая разница, т.к. PINX считывается не за 2 и не за 4, а за 1 такт.

Порядок вывода любой зрячий может увидеть если раскроет порт B в отладчике. Он увидит что после выполнения команды out значение $ff появится ТОЛЬКО в portB, а на PINB значение появляется на следующий такт!!!

1 такт на то чтобы значение попало в защелку PINX, а далее можно читать, за 1 такт.

Ещё раз утверждаю. Данное ЧЁТКО прописано в PDF!

Прописано, только смотря как преподнести. Вы преподносите все это так, что задержка присутствует из-за медленного выполнения инструкции считывания. А на самом деле инструкции ввода и вывода данных порта выполняются одинаково за 1 такт. PINX - обычный синхронный регистр, который защелкивается каждым положительным фронтом SYSTEM clk - который соответствует началу выполнения команды.

[SasaVitebsk]

Прописано, только смотря как преподнести. Вы преподносите все это так, что задержка присутствует из-за медленного выполнения инструкции считывания. А на самом деле инструкции ввода и вывода данных порта выполняются одинаково за 1 такт. PINX - обычный синхронный регистр, который защелкивается каждым положительным фронтом SYSTEM clk - который соответствует началу выполнения команды.

Уважаемый 'defunct'. Я ни в малейшей степени не планирую завязывать перебранку. Я думаю Вы правы. Я очень давно разбирался c этими вещами. Лет 7 назад. Возможно наложились др. МП.
Но, - просто посмотрите начало темы. И вопрос. И мой первый ответ. И последний ответ с примером.
Я ничего не "преподношу". Я изначально сообщил что имеется "особенность". И эта особенность не связана ни с какими конденсаторами на ножках. А связана только с организацией ввода-вывода AVR. Я ошибся в причине возникновении задержки, но сам факт остаётся фактом. Между выводом и вводом необходим такт задержки. И это надо учитывать при написании быстрых участков программы, где важно максимальное быстродействие. В ряде случаев незнание этих особенностей приводит к ошибкам.
Итак прошу прощение у тех кого я ввёл в заблуждение по академическим знаниям.
Обращаю внимание тех, кого интересует практический подход.

[SasaVitebsk]

Ошибочный топик

Сообщение отредактировал SasaVitebsk - Mar 7 2006, 01:10

[defunct]

/offtop
Уф.. Аж неловко как-то..
Сорри, совсем не хотел доводить дело до откровений..
Максимум что я заслужил с Вашей строны - фраза "Ок"

Но, - просто посмотрите начало темы. И вопрос. И мой первый ответ. И последний ответ с примером.

Да, с практической стороны у Вас все Ок.

Сообщение отредактировал defunct - Mar 7 2006, 01:23

[Kovrov]

пока вы тут спорили - пришлось от АСКа отказаться
ибо на смену направления ушло около 18 тактов
здесь конечно свои заморочки
во первых пара каменей 90s2313+tiny2313
а задача была связь двух этих монстров с сверх минимальным сжиранием ресурсов
(т.к практически все аппаратн прелести уже подвязаны - пришлось изголяться с таймером и передавать за прерывание всего один бит ;-)
аск (или как следствие смена направления у 90s уже не выдержало)
ж---
а вообще господа, всем спасибо
приятно, когда люди обсуждают проблему на уровне алу, и глядя, таким образом, в корень пытаясь выяснить истину
ещё раз всем спасибо!!!!

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