вот именно поэтому
у NXP линейка АРМовская широченная, потому как рассчитана на широченный круг использования в различных областях электроники
а у Самсунга линейка на кого направлена?
вот и ответ

а то, что в телефонах Самсунга филлипсовые чипы стоят, так это нормально
У них же дивизионная структура компании....
Точно также например в Моторолле тот же самый филлипсовый радиоканал присутствует
ничего необычного

Похоже на наличие перекоса в сторону избытка ума за счет дефецита вежливости.
Претворим бред в реальность.
0. Если суслика не видно, это не значит, что его нет. Так же и глюки.
1. Как подвесить TWI у Меги8/16/32 ( я думаю и другие также):
а)создать прецедент ошибки - можно просто не впаивать слэйв.
б)Сгенерировать старт-условие и передать адрес.
в)При этом модуль, есс-но выдаст ошибку, которую мы, закурировав до дыр даташит, пытаемся
сбросить, сгенерировав стоп-условие.
г)Если не подождать примерно 12-15 мС, и попытаться опять выйти на шину, модуль навечно
зависнет условии старт-стоп. Если подождать указанное время, то модуль отвисает, и с ним можно работать.
Теперь о том, как разряженная батарейка завешивает систему.
PCF8563, в отличии от PCF8583 умеет работать на 400 кГц. Но в схему вкралась ошибка, ирезуки поставили для скорости 100кГц, т.е 10 или 15к, создав тем самым прецедент для ошибок. Ситема была построена следующим образом: PCF вырабатывает для проца внешнее прерывание 1/64 сек, а проц считывает по шине данные. При считывании данных ошибка не обрабатывалась. После считывания данных анализировался флаг валидности данных и, в случае обнаружении сбоя данных ( что означало бы, что был сбой по питанию), производилась попытка проинициализировать PCFку. В этом месте анализ ошибки производился и, в случае ее возникновения, производились прописаные в даташите действия и повторная попытка записи. В этом месте все остальные действия притормаживались, поскольку залить 16 байт на скорости 400кбит не должно было быть заметно.
Результат:
На шине периодически возникали ошибки но, поскольку повторное старт условие генерировалось не чаще 15 мС, то модуль успевал отвисать и ошибка не проявлялась. Ошибки могли возникать( и, скорее всего возникали) в процессе запуска первого и наладки последующих. Но эти ошибки не были перехвачены - при запуске проги, если прога повисла, это нормальная ситуация, а наладчики, может пару раз и удивились, но включив-выключив устройство пару раз PCFка инициализировалась и зависоны прекращались. После того, как у пользователей разрядилась батарейка, после каждого включения потребовалась инициализация со всеми вытекающими.

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

З.Ы. А сравнивать PIC24 или dsPIC33 с АВРами, по моему, некорректно - железяка совсем другого уровня. Как и ARM. PICи больше подходят для работы с сигналами, у них для этого все есть, а АВРы и ARMы хороши для применений в UI - здесь они даже удобнее PICов.

Лет 5 писал для ПИКов на асме, после чего пишу почти 10 лет в основном на Си, и разве что иногда асемблерные вставки делаю.

На АВР сразу начал писать на Си.

Возникали ли у вас какие-нибудь трудности, которые были на AVR и которых не было на PIC и наоборот?

Уважаемый, о чем Вы здесь говорите, если Вы показали нам исходник в котором
просто некорректно обслуживается TWI_BUS_ERROR!
Цитирую даташит специально для Вас:
Status 0x00 indicates that a bus error has occurred during a Two-wire Serial Bus transfer.
A bus error occurs when a START or STOP condition occurs at an illegal position in
the format frame. Examples of such illegal positions are during the serial transfer of an
address byte, a data byte, or an acknowledge bit. When a bus error occurs, TWINT is
set. To recover from a bus error, the TWSTO Flag must set and TWINT must be cleared
by writing a logic one to it. This causes the TWI to enter the not addressed Slave mode
and to clear the TWSTO Flag (no other bits in TWCR are affected). The SDA and SCL
lines are released, and no STOP condition is transmitted.

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


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

2 oran-be Ну и зачем так многа букаф?Вы утверждали,что у AVR кривой модуль TWI,а теперь са-
ми признаетесь в кривизне реализации.
Теперь насчет

Очередной бред.Откуда эти данные?Результаты долгих экпериментов бессонными ночами.?Тогда вы да
ром теряли время.
У меня есть система многоточечного котроля температуры в зале с мощными TV и FM пердатчиками.
Хост контроллер,связанный через RS-485 с 2 периферийными контроллерами на Мегах8.На каждой из
Мег висит на I2C по 8 датчиков температуры DS1621.В полную параллель,без экранированных про
водов-на плоском 4-х проводном шлейфе.Единственно,скоость TWI выставленно минимальная-што-то около 10кгц.Никакой паузы в 12-15 мС при NASK нет и в помине,все пашет без сбоев уже больше
3 лет.

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

Я думаю, что Вы не поняли, что Овеновский ПЛК может быть установлен и настроен тупым монтажником, не знающим ни С, ни тем более ассемблера. В этом цимус ПЛК Или у Вас Мега8 тоже может отдаться такому монтажнику?

ну во-первых в моих исходниках асемблера нет вобще, кроме
команд типа asm("wdr"); asm("sei"), и то чисто по привычке
Во-вторых, моя мега8 могла бы отдаться и такому монтажнику, если он конечно читать умеет
Я конечно не спорю что для ПЛК там стараются упростить как можно больше,
но все-таки TTX девайса не должен кардинально страдать.

Спасибо ,хоть ко мне это не отнеслось


а) Понятное дело
б) Если читаем ,старт потом адрес (получаем первый НАСК) ,ячейка (получаем второй НАСК) ,рестарт и адресс (получаем третий НАСК) .Есть такая пословица ,1 раз - случайность ,2 раза - совпадение ,3 раза - закономерность
в) Естественно ,если трижды не дошло
г) Да ,есть такое дело ,тоже как то уперся рогами ,ни одного упоминания тоже тогда не смог найти ,помог простой анализ ,дело в том что после стопа флаг TWINT не проверяется ,и все что нужно было сделать ,так это ввести тупую задержку равную 1 такту CLK .Многие как правило "случайно" обходят эту проблему ,так как часто между стартом и стопом идет выполнение программы большее этому периоду или при записи допустим в ЕЕПРОМ все равно нужно делать значительную задержку .
Мне немного повезло больше ,я это обнаружил на "заре"освоения TWI

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

Причем тут ПДП-11? Если мне память не изменяет, "Тезей" это не сильно удачная попытка скопировать (в добавками) 84-й ПИК.



Трудности с писаниной? Да вроде нет. Вообще - какая разница под какой проц писать? Как и какой проц осваивать? Когда это 1-й или 3-й - это еще может, когда их второй-третий десяток пошел - это уже без разницы.
Любой новый проц - 2 часа на чтение даташита, остальное - "в процессе". Чуть больше может уйти на освоение незнакомой до тоо среды программированияя и/или особенностей компиляторов.

В целом же - выбор проца и т.п., это не техническая проблема, поэтому меряться пи..ками как тут все время происходит - совершенно бессмысленно. В 90% случаев проц выбирают совсем под другим соображени, чем "сколько мипсом на 48мгц".

Да какая нафиг разница, сколько у него мипсов, если AVR и PIC16F819 не могут обеспечить достаточную для работы UART'a (или чего подобного) точность внутреннего тактового генератора в диапазоне -20 +100, а ST7Lite09, PIC16F88 или F690 - могут ?

И это еще более-менее техническая проблема, в основном на выбор влияют как я уже говорил - не технические.

Превосходно знаю этот камень, даже активно в своё время использовал в своих разработках, но при всей его уникальной и в чём-то достаточно удобной архитектуре считаю его... редкостным г. - сначала по качеству (процент брака в партиях доходил до 10%), затем и по отсутствию какого-либо развития, абсолютно мёртвой поддержкой, и информацией об изменениях в кристаллах... этот 1878ВЕ1, кстати, до сих пор выпускается с абревиатурой "ОП" А последний "осиновый кол" в этот контроллер "забили" с момента жуткого повышения отпускных цен на него - дешевле стало переработать изделия, чем закупать ВЕ1.



Ещё как тут говорят некоторые трезвые головы: сравнивать 8-и, 16-и и 32-х разрядные мк и дсп абсолютно бессмысленное занятие - это принципиально иные платформы/понятия/методы, отсюда совершенно разная производительность, которую мипсами ("попугаями") без всякого принципа не корректно мерять. Пример: три года назад переносил проект управления 5-ю ШД написанный на чистом C с PIC18F452 на TMS320LF2406A с удвоением числа ШД - результат меня по началу ввёл в некоторый ступор: если на пике проект откровенно был "затолкан ногами" как по коду, так и по производительности, и в некоторых местах откровенно "тормозил", то на тмс'е с удвоенным колличеством ШД это занимало всего порядка 25% от его производительности. При этом из внешних аппаратных возможностей в обоих проектах использовал только USART и SPI. И всё это при четырёхкратной разнице в "попугаях" и на мой взгляд не самом удачном решении USART'а на тмс'е.

Я наверное не трезвый - я сравниваю. Естественно по самому важному параметру - целесообразности применения. Приведенные Вами PIC и TMS по цене отличаются незначительно и в ценовой категории помянутого PIC буквально тесно от 32 битников.
Так почему-бы и не сравнивать честно, без оглядки на "особые условия" в виде восьмибитовости. А то получается, что-то типа - автомобиль жигули самый лучший, но среди российских .

эээ... либо я выразился не совсем точно, либо мы немного недопоняли друг-друга: я хотел сказать, что сравнивать совершенно разные мк с точки зрения разрядности/архитектуры в рамках мипсов-"попугаев" далеко не корректно. Насчёт приведённых PIC и TMS замечу, что это сейчас тесно от разных интересных предложений в их ценовом диапазоне, а три года назад там было слегка пустовато, да и упомянутый PIC уже давно имеет более интерсные аналоги.

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

Жызнь поворачивается щас таким боком, что затраты на инструментарий становятся реальным фактором. Конечно, 3-4-5Куе на рабочее место для какой конторы и не деньги, но всё-же... Если задача решается на мелком ядре с бесплатным инструментом, есть соблазн пользоваться этим. И пользуются. И считают такую возможность реальным плюсом некоей архитектуры. Например, для АРМ, ни один из производителей такого не сделал. И понятно, почему. ;О) А пользоваться ворованым становится опасно.
Да и созданная инфраструктура под мелкие контроллеры тоже стоит времени и денех. Поэтому я, например, буду пользоваться мелочью до упора. И в новых разработках, в том числе. Кидаться на новый супер-пупер чип раз в пол-года, слишком расточительно. ;О)