Кто работал, известно ли время предустановки данных на внешней системной шине относительно окончания импульса чтения nRD (рис.29 ТУ)?
То есть, какое время следует подержать данные на шине до того, когда импульс чтения закончится?
Миландр таинственно молчит... (Впрочем, можно проще сказать: послал...)

Прошу прощения, следует уточнить, молчит где? Форум, почта, телефон, в документации не написали?

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

Ну, такие вопросы может техподдержка и не знать, может эта часть - лицензированная часть ядра. По телефону такой вопрос можно сходу и не ответить. Попробуйте форум.


Например, там в документации только в двух местах пишут про то как шить Миландры по SWD, фактически упоминание и больше ничего. Но на форуме мне ответили подробно что и как.

Но что значит импульс чтения, у меня нет ТУ, есть лишь их документация в PDF. Может речь про фронт/спад чтения?

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



ТУ в этой части дословно повторяет общедоступную спецификацию в PDF.
Речь о сигнале nRD (рис.29 спецификации). Картинку не могу загрузить, файл docx - тоже (мне "запрещено загружать файлы такого типа"!!!).

ТСКЯ.431296.008CП стр.134 Рисунок 29. Диаграмма чтения. Документ более старый и диаграмма чтения показана подробнее, чем в последней версии.

Скажите честно, зачем Вы собираетесь НЕ-держать данные после завершающего фронта на nOE? Или держать меньше одного такта системной частоты (12.5 нс).
Это же классическая параллельная шина, дается время на установления значения на шине, потом захват, но вряд ли задумано так, что по фронту nOE должно что-то пропадать за доли нс. Это не проблема главного конструктора, это может быть Вы задумали что-то нестандартное.

Добавлю: я могу привести немало примеров даташитов, где опущена точно такая же информация. Как это может препятствовать подключению внешних устройств - не понимаю пока что, но надеюсь Вы поясните.

Спасибо. Но в части цикла чтения ничего дополнительно нет. Любезно обозначили время удержания th = 0, а вот tsu - нет. Вместо этого бесполезная жирная стрелка "фиксация данных". Как этот "момент фиксации" расположен относительно nRD, либо чего бы то ни было другого осмысленного - предлагается пофантазировать самостоятельно... Уж не говорю о том, сколько читаемый код с шины данных должен постоять на шине до наступления сего счастливого момента.

Уважаемый AVR!
Разумеется, у Миландра проблем тем меньше, чем меньше контролируемых параметров при сдаче микросхемы по ТУ. Да и выход годных может оказаться меньше.
Но при этом игнорируются интересы разработчика аппаратуры - и это проблема (естественно, не главного конструктора МК).
Формат форума не позволяет всерьез обсуждать методику разработки цифровой аппаратуры, для которой и требуется параметр tsu.
Я, правда, думал, что это всем разработчикам известно, ибо классика.

Ваш первначальный вопрос вроде-как касался именно времени tdh? На рисунке 29 (лист 122 спецификации ТСКЯ.431296.008CП версии 2.17.0 от 01.02.2017) оно показано, а в тексте далее сказано, что оно равно нулю. Т.е. менять данные на внешней шине можно одновременно с фронтом окончания сигнала nRD. А жирная стрелка "Фиксация данных в микроконтроллере" как раз и указывает на то, что данные считываются с шины до фронта окончания сигнала nRD, и если вдруг вы их измените одновременно с фронтом, то ничего страшного не произойдёт - считанные данные не исказятся.
Что же касается его точного положения - скорее всего оно неизвестно с достаточной точностью, чтобы приводить конкретное значение.
Схемотехнику достаточно знать, что чтение данных с шины осуществляется в момент времени после 1/2 tcycle но до фронта окончания nRD. Т.е. именно в этот момент времени данные на шине должны быть верны. И что изменение данных на шине в момент фронта окончания сигнала nRD никак не исказит считанные микроконтроллером с шины данные.
Собственно, все схемы так и делаются - сигнал nRD заводится либо на nCE, либо на nOE микросхемы на внешней шине, из которой производится чтение (ОЗУ, ПЗУ, регистр, шинный формирователь и т.д.). А это значит, что изменение данных на шине как раз происходит в момент фронта окончания сигнала nRD. И никаких специальных мер по удержанию данных на шине ещё какое-то время не делается. Всё работает как есть.

Нет.
Перевод: tsu - set up time - время предустановки;
th - hold time - время удержания.



А что заставляет Вас думать, что установления данных в момент 1/2 цикла достаточно? На рисунке они явно устанавливаются раньше (но насколько раньше - непонятно).
Пофантазируем еще.
Момент "полцикла" на рисунке примерно совпадает с фронтом CLKO при СPOL=0.
А возможно, всего лишь надо установить данные до переднего фронта CLKO при СPOL=0 (последнего, при активном nRD)? Тогда - за какое время до фронта CLKO?
С другой стороны, похоже, "фиксация данных" происходит по спаду CLKO при СPOL=0.
Тогда возможно, данные достаточно установить на шине чуть раньше, чем закончится последний импульс CLKO при активном nRD? Тогда - за какое время до спада CLKO?
Но при этих предположениях нам надо знать взаимное положение CLKO и nRD, а также, строго говоря, и моментов переключения адреса. Чего разработчики МК (видимо беспокоясь о нашем душевном равновесии) не предоставили.
Возможно, вероятно, похоже...... Так аппаратуру не разрабатывают. О том и речь.

Это абсолютно очевидно, что достаточно чтобы данные были установившиеся в диапазоне между 1/2 и 3/4 цикла. Всё, больше ничего знать для успешного "создания аппаратуры" и не надо. 1/4 цикла при максимальной тактовой 80 МГц это 12.5 нс, вполне обычное время для СОЗУ. Какие проблемы, какие претензии.


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

Цитата из документации:

Если бы было жесткое требование установить данные на шине ДО начала сигнала nRD - об этом было бы сказано прямо. И преведено время -
не менее такого то значения. Но такого нет, т.к. такое требование само по себе абсурдно. В этом случае работа с внешней памятью, подключенной "классически" (когда сигнал nRD контроллера подключается к входу nOE микросхемы) принципиально невозможна. Где вы возьмёте сигнал, формирующийся до начала nRD, по которому внешняя микросхема будет выставлять данные на шине? Микроконтроллер его не генерирует. А логики, предугадывающей появление сигналов на линиях и генерирующей сигналы ДО появления других сигналов, пока что не придумали. Как и микросхем памяти, заранее выставляющих данные на шину, до появления сигнала на входе nOE.
99% схем построены так, что выдача данных на общую шину инициируется передним фронтом сигнала nRD, выдаваемым контроллером на внешние микросхемы (на вход nOE, nCE, или ещё какой управляющий вход - не важно). Оставшийся 1% - редкие специфичные случаи и специфичные или просто ущербные микросхемы памяти.

А теперь конкретно. Как бы сделал я.
Подключение внешней ОЗУ (ПЗУ, регистра, шинного формирователя) классическое - сигнал nRD контроллера подключается к входу nOE микросхемы. Из рисунка 29 следует, что фронт начала сигнала nRD соответствует моменту времени 1/4 tcycle, а фронт окончания 3/4 tcycle. Момент "защёлкивания" данных с шины микроконтроллером - где-то между 1/2 tcycle и 3/4 tcycle. Наихудший случай, когда он соответствует моменту времени 1/2 tcycle. Т.е. у микросхемы есть время 1/4 tcycle после фронта начала сигнала nRD (а для неё он nOE), чтобы выставить на шину достоверные данные. Остаётся подобрать микросхему, у которой время выборки данных по сигналу nOE было бы меньше, чем 1/4 tcycle. Ну и само время tcycle можно настраивать в микроконтроллере битами WAIT_STATE[3:0] регистра EXT_BUS_CONTROL.

Кому все еще интересно, из источников, которым я вынужден доверять:
время предустановки данных относительно окончания импульса nRd вычисляется:
Tsu= (период клока ядра + 66 нс)*1,2.
Множитель 1,2 - рекомендуемый запас 20%.
При максимальной частоте ядра 144 МГц - примерно 90 нс.
Вот теперь можно определить допустимую длительность nRd как сумму задержки переключения периферийного устройства из третьего состояния в активное + Tsu.

Как-то неправдоподобно медленно, не доверяю Вашему источнику.