Будем ждать(:-). Ради интереса посмотрел описание AT90CAN128, там с MPCM и TXC битами уже разобрались, осталось им разобраться с битом ADIF, когда используются SBI/CBI инструкции для записи в ADCSR.

Ну так! Оно и сейчас зависит, только не для MPCM, а для ADIF. Замечу, что здесь думать не надо, есть описание, там всё чётко и ясно прописано, надо ему следовать, но не бездумно(:-). Я привык доверять документам.

Уверяю Вас - если SBI не трогает немодифицируемые биты, то она так поступает независимо от номера порта. Ибо для ядра все порты равны, т.к. схема подачи сигнала записи в порт одна и та же для всех портов, а какая периферия стоит по ту сторону порта - ядру всё равно.

Да я бы сам был рад увериться, но вот цитата (отн. новый док. 4250h, с.287)

• Bit 4 – ADIF: ADC Interrupt Flag
This bit is set when an ADC conversion completes and the Data Registers are updated. The
ADC Conversion Complete Interrupt is executed if the ADIE bit and the I-bit in SREG are set.
ADIF is cleared by hardware when executing the corresponding interrupt handling vector. Alternatively,
ADIF is cleared by writing a logical one to the flag. Beware that if doing a Read-Modify-
Write on ADCSRA, a pending interrupt can be disabled. This also applies if the SBI and CBI
instructions are used.

Которая явно противоречит с вашими уверениями. Грубо говоря, хочу с помощью команды SBI установить бит 6 (ADC Start Conversion), чтобы запустить начало преобразования, но при этом может сброситься бит ADIF от предыдущего преобразования, хотя SBI, по вашим уверениям, не должна влиять. Что интересно, в других местах адресного пространства атмел убрал влияние SBI/CBI на такие биты, соответственно, из документа исчезло описание багов.

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

Ох, вашими бы устами...да мёд пить(:-) И не беспокоюсь совсем, подумаешь ADIF, да на этот ацп со слезами не взглянешь(:-).

Расскажите лучше, как они реализовали SBI/CBI без чтения-модификации-записи?

Да хотя бы так - от каждого триггера порта линия EN идёт отдельно (а не все 8 соединяются, как было бы можно для RMW), по команде SBI на шину данных блока портов выставляется 0xFF (по CBI - 0x00), а на линии EN активный уровень только на выбранный дешифратором 3-на-8. По OUT же на шину EN выставляются активные уровни на все 8 линий, на данных - из команды. Добавляется небольшой дешифратор и, что может оказаться больнее, шина из 8 персональных EN для каждого бита плюс элемент 2И на входе EN каждого триггера. Убавляется ветвь в автомате для отработки команд, которая производила чтение порта, прогон через АЛУ с формированием нужной команды (OR/AND) и формирователь нужного байта данных для операции (по сути - тот же мелкий дешифратор, только на шину данных, а не шину EN), запись результата назад.
Соответственно, команды SBI/CBI в таком виде легко могут быть однотактовыми, у них тот же путь исполнения, что и у OUT. Но, как правильно отметил CD_eater, это может "развалить" времянки у существующих программ. Хотя я предпочёл бы ускорение :-)

Сложно у вас как-то...и сомнительно мне(:-)

Вот смотрю я на рис.10-2 документа 4250, и не вижу никаких линий EN. Зато вижу два триггера и три линии WPx, WDx и WRx, ведущие на вход С. Атмельцы манипулируют, скорее всего, с сигналами синхронизации, а не с мифическими сигналами EN. Да и это тоже накладно, для 4 портов понадобится 64 линии связи, а для 32 портов - не менее 288 (!).

Опять оффтопим...

Ну попробуйте нарисовать схему, которая может персонально записывать в 32*8 триггеров (порты*разрядность) без 128 управляющих линий. А куда они идут - на "мифические" EN или через те же логические элементы (но спрятанные от Вас за пределами поясняющего фрагмента схемы) напрямую на тактовый вход - разницы никакой. В любом случае - для независимой записи - независимые сигналы.

По картинке из даташита невозможно записать отдельный бит, гляньте на примечание под ней.
Теперь берём и разводим с дешифратора 3-на-8 восемь линий - по одной на каждый бит, линия одна на одноимённые биты всех портов. Теперь возле каждого WPx (которые "are common to all pins within the same port") поставим логику и замешаем для каждого бита "его" линию битовой выборки с признаком команды SBI и со стробом записи для данного регистра (тех же ACR/ACSR, не только для портов это сделано). Получим персональный сигнал. А для записи по OUT надо замешать бит шины данных, а не дешифрованный номер бита, но эта линия уже показана на том рисунке. Получается "жирная" логика на пути стробирующего сигнала - это всегда плохо, если Вы работали с ПЛИС, Вы, думаю, с этим согласны.

Можно строб записи WR объединить c сигналом выборки (ENABLE) регистра Px в логическом элементи за пределами показанного в даташите рисунка и получить строб WPx. Можно этот логический элемент в несколько другой форме поместить внутрь триггера и на строб записи подать напрямую WR, а на получившийся вход EN подать сигнал выборки Px. Если логика простая - то почти всё равно. Если логика усложняется, то с точки зрения быстродействия и отсутсвия всяких иголок может оказаться лучше на вход стробирования триггера подать "чистый" сигнал WR, а все независимые (порождаемые разными командами) разрешения свести по "ИЛИ" на входе EN. Смотрите - в той схеме, что в даташите, сигналы WPx и WRx получены каждый объединением по "И" процессорного сигнала WR, а потом они опять идут в логику. Можно наоборот - сначала всю логику разрешений записи по разным поводам свести в один сигнал "пишем" и результат комбинировать со стробом записи, тогда тот сигнал "пишем" и есть EN. На уровне жонглирования булевыми выражениями результат тот же, в кремнии реализуют тот, который окажется компактнее или быстрее, на картинке в даташите нарисуют тот, который нагляднее.

Опять как-то неоправданно сложно у вас, а ведь еще надо оставить обычный доступ к портам. Я бы сделал следующим образом, используя алгоритм чтение-модификация запись.

1) Читаем один из 32 портов.

2) Обнуляем те спецбиты порта, которые сбрасываются записью логической единицы. Т.е. логическое И содержимого порта и выхода таблицы (по числу портов), в которой прописаны спецбиты.

3) Устанавливаем бит, заданный командой SBI/CBI.

4) Записываем результат обратно в порт.

Вот как-то так. Ну а если таблица для нового чипа не подправлена, то будет баг, что мы и наблюдаем.

вот таким образом, мы и получаем 2 такта на команду

Да останется он.

А таблица места не жрёт?
Фактически, я предложил для команды OUT подавать сигнал WPx на все 8 бит байта (один дешифратор на все порты, занимающий гораздо меньше места на кристалле, чем дешифратор той таблички), а для команд SBI/CBI - только на выбранный бит.

Это уже совсем оффтоп, но выглядит так (bitnum - поле команд sbi/cbi):

EN[7..0] = out_cmd or (sbi_cmd or cbi_cmd) and dc3to8(bitnum);
DATA[7..0] = cpu_data[7..0] and !cbi_cmd or sbi_cmd;

EN - единые для всех портов, это 8 сигналов. Причём этот дешифратор уже есть, это его выходы замешиваются в прочитанный байт в RMW-цикле, т.е. он уже был ещё в старых версиях отработки этих команд.
Да, теперь возле каждого триггера их надо подмешать к управляющим сигналам, грубо, ещё 32*8=128 элементов. Но Ваша табличка из 32*8=128 бит сама по себе плюс логика для своего считывания врядли намного меньше потребует. В виде не именно "таблички", а скомпилированной/соптимизированной логической функции - наверняка меньше, так как довольно много портов "без этих глупостей".
Но RMW для порта потребует ещё отдельнeю ветвь в автомате процессора, а в таком виде отрабатывать будут те же части, что и для OUT, просто по дороге кое-что замаскируется.
Поэтому кардинального различия в объёмах и сложности я не вижу, +- такая мелкая разница, что слово "неоправданно сложно" не подходит.

Только не надо говорить, что "ну уж они-то думали" :-) Раз смогли запихать EEADDR/EEDR в нижнюю, а TIMSK в верхнюю область IO, то могли и тут пропустить :-)

Пора этот фрагмент обсуждения выбрасывать куда-то в раздел по построению цифровых схем :-)
Завязываю.

Не мы, а они(:-)!

Ну а раз это есть на практике, значит 75%, что они используют довесок к R-M-W автомату...Было бы интересно, конечно, узнать, как сделано на самом деле, но уже надоело, я тоже заканчиваю тему.