Ну я. Один проект на PIC, и он единственный - на С. 100 %

Даже не знаю, о каких недостатках и преимуществах тут говорят
И вообще. Структура проектирования у каждого давно сложилась - у кого-то ОС, у кого-то автоматы, у кого-то что-то вообще примитивное. Под задачу выбирается контроллер с нужной производительностью, чтобы не ломать собственную структуру, в которой удобно и понятно.
Разговор действительно ни о чем.

Милейший,вы что,издеваетесь?Илм действительно не понимаете,что пишете полный бред?Как может севшая батарея RTC повесить шину!?Ведь при включении питания девайса RTC должны перейти с бата-
рейного питания на рабочее.Имхо,у вас или диод на рабочее питание неправильно стоит или его нет во-
все.
Вам тут уже дали совет как корректно сбросить модуль.Код в обработчике в остальном вроде правильный.
Я тоже работаю c RTC филипса,тока PCF8583,но не суть.
Сделано уже штук 20 девайсов,стоят в необслуживаемых будках.Этой зимой тоже умерло парочка ба-
тарей,ничего не зависло.Я в менюшке установки времени при записи значений в регистры еще пишу
в ОЗУ ПСФ-ки еще тест-с адреса 10 тест лестница.И дальше при каждом включении в старт-апе прове-
ряю тест,и если не проходит,я с часами просто не работаю и отсылаю смс-сбой часов.
Так-что вы меня пока што убедили тока в старой истине-умелыми руками мона и столб уронить.

Ну я. Живой. А какая, по Вашему, альтернатива?

+1.

Разговор о том, что НЕ НАДО залезать в каое-то определенное болото, пусть оно и кажется пока теплым (а когда уже не совсем устраивает, пусть даже подсознательно, похоже некоторые начинают себя на фанатизм накручивать). Кругозор нужно уметь раздвигать. Кругозор в контроллерах, языках, приемах программироания. Надо! А сидеть на каком-нибудь мелком контроллере в ASM и писать очевидные вещи нельзя. Для себя любимого это вредно .

Хм, с каких это пор модераторы Электроникса за "пустую болтовню" вместо четко обозначенной помощи?
Приучили нас тут "шаг влево, шаг вправо - побег", а сами вдруг вольницу пропагандируют?

По моему личному мнению, Вы не совсем правы. Развитие себя любимого за счет смены платформы - это, на мой взгляд, переработка чего-то уже кем-то съеденного. Да, это расширение кругозора, но не в ту степь. Кто мешает на том же PICе или AVR расширять кругозор в "языках, приемах программирования", что , на мой взгляд, наиболее важно?
Объясните, в чем принципиальная разница между ARM с Linux и i486 с Windows? Программирования, по моему мнению, как такового там давно уже нет, а есть сплошное разбирательство с чужой писаниной.

Надеюсь, что эта "болтовня" кому-нибудь действительно 'четко' помочь принять стратегическое решение.

На первый вопрос я указал причину. Я не вылизывал - это голова.
На второй вопрос - ответ простой. На PIC18 - понятно. Но человек писал, что "красивее чем система комманд PIC16 не найти." Поэтому я и просил - "продемонстрируйте красоту PIC16 на данном примере."

А в принципе, я не понимаю только одного. Это два совершенно параллельных семейства. Я абсолютно не вижу смысла перехода как в одну сторону, так и в другую. Потому, что сама работа предполагает целый цикл. И требует и отладочных средств, и наработки (в том числе и с учётом особенностей семейства), и компиляторы и прочие программные средства, а также некоторые моменты работы с поставщиками. Изменение всего этого, не то что бы вызывает особые сложности, но всётаки с этим необходимо считаться. Поэтому переход с семейства на новое семейство требует значительной причины для этого. Я не призываю сторонников PIC галопом переходить на AVR. Не понимаю почему к этому призывают меня, обвиняя в "фанатизме", при этом в данном посте совершенно нет ни одного примера который бы оправдывал такой переход. То что PIC18 выполнит приведенный мной фрагмент также - это предлог? Вот скажите мне GM? У меня atmega8 без кварца за 1.15$ получает 6 каналов АЦП и управляет стрелками на 6 шаговых двигателях. Двигателя сидят непосредственно на ножках. Испытания все пройдены и выпускаются тысячами. Наравне с PICами. Отказов не больше. И ещё один момент. Если я запаиваю atmega88, то я могу прогу отлаживать в DBGWARE. Назовите мне PIC18 c этими же характеристиками. И давайте сравним цену.


Я обозначу свою позицию и больше не вижу смысла участвовать в споре на "понятиях", так как реальных аргументов - увы не прозвучало.

Я перейду на PIC в случае реального серьёзного преимущества в данном семействе. В частности я уже примерялся к PIC24H. Кстати на мой взгляд он ближе к AVR чем к PIC16. Но буду учитывать сумму всех факторов. То есть стоимость, достовабельность, отладочные, компиляторы и прочее. Естественно я буду сравнивать с текущими кристаллами. Также я буду сравнивать и другие. В частности я просматривал и M16C и ARM7. В настоящий момент вероятность перехода мной на PIC всётаки мала. Скорее будет переход на ARM7. Но зарекаться не буду.

Нет, не представляю, как можно оставаться в рамках одной платформы в более-менее разнообразных проектах. Кроме собственно ядра, есть еще и питание, аппаратные средства микроконтроллеров (порты, таймеры, АЦП и проч), корпуса и другие факторы, что заставляет менять платформу.
Какие еще приемы программирования? Лабай (сорри, только "Вокзал для двоих" закончился) на ЯВУ, вот и все приемы.


Ну, решение можно принять только попробовав что-то новое. Если свободная дискуссия подтолкнет кого-то попробовать другую платформу или такой "прием программирования" как ОС, то уже хорошо.


Если быть объективным, это не аргумент. Если Вам нужна отладка в серийном изделии, то сколько же Вы их выпускаете?

Альтернатива это, как сразу сказал, это PIC'и.

http://www.microchip.com/ParamChartSearch/...n&pageId=75
http://www.microchip.com/ParamChartSearch/...n&pageId=75
http://www.microchip.com/ParamChartSearch/...n&pageId=75

Значительно более высокая производительность, больше памяти, более развитая периферия за те же деньги (вообще-то даже дешевле). Система команд у PIC'а (особенно dsPIC33) на фоне системы команд меги выглядит просто божественным совершенством. Система прерываний так же более развита. Средства разработки более чем доступны. Да чего уж там, они и так есть у каждого - они одинаковы для любых пиков (ICD2, пик кит 2, мплаб). Микрочиповский С компилятор на основе GCC также весьма хорош.

Для _многих_ случаев (ну не для всех конечно), 40 мипс dsPIC33 показывает большую производительность, чем 55 - 60 мипс ARM, и в качестве вычислителя и, разумеется, в качества чисто контроллерного ногодрыжества.

Можно любить одного человека, а можно развести гарем... ИМХО, вопрос воспитания и мировоззрения...

В топике уже 10 страниц,из них 80% ни о чем.Нельзя-же считать аргументами утверждения "у AVR-щиков холестерин в моске"или утверждать о глючности кристаллов,не разобравшись ни железом,ни как правильно с ним работать. Но 20% процентов дискусси по крайней мере для меня были полезными.Скачал таблицу с PICами,посмотрел цены и возможности и был впечатлен.ИМХО,AVR медленно,но верно сливает PIC.Еще год-два,и усе-приплыли.PIC серьезно модифицировал ядро,снизил цены,да и общий выбор кристаллов по сравнению с AVR впечатляет.Такое впечатление,что ATMEL на 8-битники просто забил Похоже,все силы брошены на АVR32.Ядро не модернизировалось с незапямятных времен,выбор кристалов почти на порядок меньше.Обещанные XMEGA в полном тумане.Короче,перспективы не радуют...

Есть АВР с ТАКТОВОЙ ЧАСТОТОЙ 48 МГц, т.е. 48 МИПС в пике. Мне кажется, в сравнении с такими АВР даже dsPIC33 будет выглядеть бледновато, хотя он и 16-битный, следовательно, по большому счёту сравнивать не корректно. Что уж там говорить о пик18 и ниже.

Но, согласитесь, - это уже некрасиво. Просто повышать частоту. А где же работа ума?.
К стати, МИПС АВР - это не совсем одно и то же, что МИПС dsPIC33 (команда MAC, к примеру). А если учесть, что там и DMA есть...