Суть вот в чем: есть железка, в которой и программа и большая порция данных хранится во внешнем ПЗУ (29С020). Доступ ко всему объему памяти осуществляется постранично по 64К, страницы переключаются битами порта 3. Программа продублированна во всех страницах, т.е. переключение страниц во время выполнения программы не должно ее сбивать. Однако, вслучае выполнения вот такой например конструкции:
sbit P3.x ; выбор страницы
acall yyy
подпрограмма вызывается не с того адреса, причем если использовать lcall - все Ок.
Глюк проявляется на AT89C52, на DS80C320, например, такого нет.

Сразу скажу: в данном случае проблема была решена вставкой nop после sbit, однако не приведет ли в каком-либо другом случае подобных механизм доступа более чем к 64К памяти к глюкам?

Спасибо.

NeoN
Давно я 51 занимался. Может быть и ошибаясь
Размер команды acall - 2 байта, команды lcall - 3 байта, поэтому в одном случае шина успевает переключаться, в другом - нет. Введение nop просто даёт дополнительный такт. Надо смотреть времянки памяти и процессора. Если на шине сидят еще устройства, но они могут вносить дополнительную емкостную нагрузку и затягивать фронт. Тут надо смотреть характеристики микросхем. Я порт P3 использовал для переключения банков, всё работало без сбоев, просто ёще раз внимательно просмотрите времянки.

Странно. ИМХО, если проблема только в этом, то у lcall вместо acall опкод бы не правильнй выбирался, и это уже не lcall бы был .
Но дело еще хуже - атмел просто не стабильно работает из внешнего ПЗУ - иногда прога улетает черти куда. тактовая - 16МГц с копейками... А даллас, который команда за 4 такта - идеально... Если смотреть сигналы атмела - не нравиться ~PSEN - фронт растянут на 50нс где-то, как будто там выход с открытым стоком и pullup. Но если верить доке - там двухтактный выходной каскад... Мрак просто.

Сейчас негде быстро посмотреть, но что-то мне вспоминается, что у классических MCS51 при выполнении записи в порт фактическое состояние его выводов изменяется где-то в начале цикла выборки следующей команды. Таким образом, возможно, что адрес после переключения не успевает стабилизироваться к моменту считывания кода. Что будет на выходах ПЗУ при изменении адреса в процессе чтения - вопрос сложный. Возможно, в описанном случае код команды LCALL не искажается, a ACALL - искажается.
Что касается Атмела вообще, то мы в своей работе активно использовали AT89C51, 52, 55, S8252 именно с переключением банков ПЗУ (правда, только данных, не программ). Программа читалась только из банка 0 (при помощи внешней логики все адреса старше A15 обнулялись на время действия PSEN). На нескольких сотнях устройств никаких проблем замечено не было.

это точно проделки конвеера
нельзя же они пишут что после записи в порт I/O читать изменения через такт

Есть такая традиционная проблема 51-х : "проблема ALE".
ALE лучше подавать на регистр через резистор 300-500 ом.

Никогда не видел у Атмела PSEN плохим - может у Вас с этим
проводом проблема ? Емкостина там, нагрузка глючит итп.