Понял, спасибо, учту при случае...


Так что, для новых кристаллов команда SBI перестала быть Read-Modify-Write? Для каких конкретно?

Вроде как получается оба. Я больше.

Честно говоря я редко по опросу работаю и на такие грабли как-то ни разу не наступал. А может наступал да не заметил. Короче надо внимательно за этим следить. Мегу 64 до этого не пользовал. А вот сейчас, по иронии судьбы, - начал. м8515 использовал, но как то пронесло.

Атмельцы тоже не так глупы, как Вы пытаетесь их выставить. Эти две фичи (инвертирование бита PORTB и особенность инструкции SBI) сильно взаимозависимы и появились в АВРках ОДНОВРЕМЕННО. А именно, в тини13.



мега88 дешевле и мощнее (SRAM*2). Ну разве только по параметру "удельная стоимость одной ножки" м8515 лучше



GM, в этой ветке их уже называли как минимум в двух постах. Повторю ещё раз: для всех новых чипов, начиная с тини13.

Вот именно поэтому ("нет, но не во всех и нужен") м8515 нельзя сравнивать с м88, у м8515 есть то, чего нет у м88 - внешняя шина. Но она есть у более мощного кристалла м162, поэтому я согласился с тем, что м8515 "уходит". м8535 - тем более, её можно заменить на целый выводок более мощных кристаллов.
А вот м162 заменить пока не на что. У меня в прошлом году был проектик, в котором стоят м162, epm240t100 и 32кбайт ОЗУ. Ставить туда что-то 64-ногое с внешней шиной вообще неинтересно было - и так пару ног свободных осталось, только более мощную ПЛИС и всё - тоже невыгодно. По ОЗУ что м8515, что м162 - всё равно не проходили, так что в этом смысле можно было и м8515 поставить, но какого-то смысла это не имело. Кажется, цена равна была, а доп UART на терминалку для отладки не помешал.




Ну если считать по числу серийно выпускаемых типов кристаллов, то таки я. А если считать, что неиспользование исправления "некрасивости" в команде, приводящее к незначительному увеличению объёма кода и времени исполнения при работе с некоторыми регистрами - не так плохо, как незнание того, что не всегда так было и ещё бегают кристаллы, где это глюкоопасно - то тогда надо ещё подумать

Кстати, а мега32 тоже уже на выброс? Да, я понимаю, мега324 и всё такое, но по цене 32-ая пока выигрывает, кажется.

Дело не только в работе по опросу. В примерах scmRTOS аналоговый компаратор используется для программной генерации прерывания, но иногда надо на некоторое время это прерывание блокировать. Естетсвенно, сбросом/установкой ACIE. Но если не отследить, то прерывание может оказаться потерянным из-за сброса ACI из-за RMW-шности.
Естественно, в scmRTOS это отслежено :-)




ГДЕ? Где в этой теме я "пытаюсь их выставить"? И, кстати, когда появились ACSR, ADCSR, для которых SBI/CBI могут привести к "неожиданным эффектам" на вполне ещё серийных кристаллах?

Есть определённое поведение команды, есть нюансы её употребления, которые могут привести к глюкам. Я обратил на это внимание.

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

Кстати, продолжая старый разговор - ну уж после того, как SBI/CBI стали "не-RMW" - их двухцикловость выглядит несколько странной, у них теперь не больше работы, чем у OUT.

По этому параметру AT89S51 всё равно не переплюнуть
А m88 - слишком другой кристалл, см. выше. Хотя автора "защиты" этот вопрос, кажется, не волнует.

:-) очень волнует... Да ставте любой кристал куда вздумается..яж не с флагом вышел типа " даЁшь М8515 каждому крестьянину". Новое поколение кристалов естественно сменяет старое.. кто ж с этим спорит..Но зачем, к примеру, применять более "мощный" чип? разве что по ценнику...или код ну не лезет то понятно..а так вопрос спорный. 8515 раньше появился на свет, а м88 это "сыночек"...ну чуток по продвинутее или что типа того..А так одного поля ягода..Хорошо что Вы не утверждаете что 8-биткам ужо не место на столах эмбедеров.:-)

Эти нюансы уже ушли в прошлое, не цепляйтесь за чипы 5-летней давности. Кстати, даже в глубоком прошлом эти "глюки" были описаны в даташите, этому специально уделено внимание как распространённым ошибкам у начинающих пользователей. Вы, мне кажется, всё пытаетесь обвинить Атмел в потенциальной глючности АВРок. Только, пожалуйста, приводите факты, а не домыслы. Как показывает практика, 99% глюков оказываются следствием невнимательного чтения даташитов.

В принципе, если вместо слова "глюк" в Вашем предложении, которое я процитировал, стояло бы слово "ошибки из-за незнания ДШ", я бы с Вами согласился, такое напоминание об "узких" местах использования АВРок только на пользу. Но это не глюк.

Вы хотите сказать, что надо всем быстро отказаться от применения м162, м32, м64/м128 ?
Но ПОЧЕМУ? Только потому, что давно разработаны?

Извините, бред.
Кажется. Причём не могу понять - откуда это взялось. То, что я иногда говорю "лучше бы" или даже "плохо, что" этого не означает. Это говорят многие про многое, причём чаще всего про то, что более-менее активно используют, "понимание приходит во время еды". Считал бы АВР потенциально глючными - не использовал бы их.
Или я должен подпрыгивать с транспарантом "лучше нету АВР-ок, Атмел-чемпион", чтобы никому не казалось, что я обвиняю Атмел?

Я позволил себе выделить. Итого статистичиески в 99% случаев допустимо применять слово "глюк" вместо длинного словосочетания.
Глюк программы - это когда она временами ведёт себя странно. Если не учесть "нюансы" - вероятность этого увеличится.
Я говорил о глюках программы, а не кристалла. Причём с самого начала говорил о том, что надо учитываеть имеющееся поведение, а не о том, что имеющееся поведение глючное (т.е. есть глюк кристалла).

Спасибо обоим. ReAlу за уточнение нюансов, а CD_Eaterу за введение в курс сегодняшнего состояния кристаллов.

Честно говоря не секрет, что даташиты читаются плохо. По разным причинам. Конечно немаловажная причина - недостаточное знание языка оригиналов. Непростительная причина - банальная лень. Но ещё хуже обстоит дело с перечитыванием этих даташитов. Мельком взгляд бросаешь - да всё то же, - ан нет есть нюанс мелким подчерком.

Вы меня жутко заинтриговали ReAl. У Вас не бывало иногда такого состояния когда Вы смотрите на свою программу и вродебы нашли хомут дичайший. "Боже! Как оно вообще могло работать! Блин, но ведь работало лет пять без проблем." Ну а потом выясняется что было всё правильно, а вы разбирая свою же прогу не усмотрели какой нибудь мелочи.
Вот так Вы сегодня меня в ступор ввели. Ну и я бросился некоторые свои исходники пересматривать. Оказывается в большинстве проектов флаги вообще не сбрасываются. Обхожусь аппаратным сбросом по прерываниям и т.п. Но в двух местах обнаружил. И что же -- сброшено правильно.

Видимо всётаки когда-то наступал на эти грабли, но забыл. Старость не радость. Склероз.

в m162 - все хорошо.. вот только JTAG выведен "по-козьи".
Сплошное мучение с отладкой в 4k..

А его таки в прямом смысле слова "дают каждому крестьянину" в придачу с STK500..

2 ReAl
Хорошо, про "глюк программы" нет возражений

Кстати, насчёт возможной однотактовости SBI. Представьте, что это всё же сделали бы. Тогда единая на все АВРки таблица "AVR instruction set" перестала бы быть универсальной, появились бы трудно отслеживаемые различия в количестве тактов на разных чипах. Многие проекты полагаются на растактовку инструкций, и при переносе старого проекта на новый чип потребовалось бы ПЕРЕСЧИТЫВАТЬ такты участков, использующих SBI/CBI. Это намного сложнее, чем, например, заменить идентификаторы портов или их битовых полей. Обычно при переводе проекта на более новый чип требуется подкорректировать работу с периферией, это сделать нетрудно т.к. просмотром исходника легко выделить те места, в которых эта периферия используется. А попробуйте просмотром исходника (не Вашего) понять, зависит ли корректная работа программы от длительности исполнения найденной инструкции. Короче, проблем бы это добавило и Атмельцам (перелопачивать ядро), и разработчикам (переносить проекты). А так какая красота: таблица инструкций общая на всё семейство, ядро совместимо снизу вверх! Лепота!

Сообщение отредактировал CD_Eater - Jul 23 2007, 21:13

Бывало и не раз :-), часто в ситуации "а как я это тогда сделал, сейчас опять надо". В этих случаях я иду на нарушение правила "не редактировать старые исходники в архиве" и дописываю комментарий (если его не было, если же был - то ступор и не возникает).

Да прекрасно представляю, что такое сохранять совместимость со старыми "особенностями"
Потому и сказал "будет выглядеть странно" (например, для того, кто не знает, что раньше оно было RMW), а не "и чего они не сделали однотактовой".
Лучше бы они сразу так сделали


Наоффтопили мы тут... Придёт лесник и всех разгонит...

Видимо вы не совсем правы, вот в документе на тайни говорится: "Do not use Read-Modify-Write instructions (SBI and CBI)..."(с.132, 133), т.е. явно указывается, что это всё-таки Read-Modify-Write инструкции.

С другой стороны там говорится "Note that, unlike most other AVRs, the CBI and SBI instructions will only operate on the specified bit, and can therefore be used on registers containing such status flags" (с.23, 216)

Выходит поведение CBI/SBI зависит от того, присутствуют там подобные флаги или нет. Кто-нибудь может прояснить ситуацию?

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

А лесник никуда и не уходил.
Если автору уже всё ясно, пора бы и закончить.

Спасибо всем. Все понял.

Всё просто - часть даташита подредактировали, другую часть забыли. Такое бывает нередко. В одной из будущих ревизий где надо подправят

А Вы подумали, что действие SBI зависит от номера порта???